Compatibility and resource usage for server processes
Review this information about resource requirements and compatibility issues to help plan your daily schedule and run processes in the optimal order.
- Process
- Lists the process or operation that is performed by the IBM Spectrum Protect™ server.
- Requirements and recommendations
- Lists any requirements that must be met before a process can be performed. Best practice information is also covered where it is applicable.
- Compatibility issues
- Lists any compatibility issues that might arise when you are running processes together.
- Prerequisite tasks
- Lists tasks that must be completed before the process is performed.
- Resource implications
- Lists resources that are required to run the process and provides guidance on how much usage can be expected:
- Low
- Resource usage is low. Running the process does not affect other operations.
- Moderate
- Resource usage is moderate. Running the process might affect other operations.
- High
- Resource usage is high. Dedicate the resource to running the process until it completes.
Tip: Mount points and volumes are used for most server processes. Because the use of these resources is highly variable, depending on environment configuration, the table does not include a usage designation.For operations that use file mount points with a device class of type FILE, set the mount limit parameter of the device class high enough to accommodate all simultaneous mounts. For example, the number of parallel backup sessions for a database backup are typically not more than 5, but for client backup, the mount point requirement can be in the range of 500 - 1000.
For operations that use physical tape mounts, the mount points are limited by the number of actual tape drives. When you are backing up storage pools to tape, plan to use parallel storage pool backup processes that do not exceed the number of available tape drives, and possibly leave some drives unused to remain available for client restores.
Process | Requirements and recommendations | Compatibility issues | Prerequisite tasks | Resource implications |
---|---|---|---|---|
Backing up the database |
None |
None |
Backing up storage pools |
– Mount points and |
Backing up or archiving client data |
Requirement: Define and configure client nodes within the IBM Spectrum Protect server. Recommendation: Back up storage pools immediately after the main client backup or archive operation is finished to ensure that a complete copy is created for the primary storage pool. |
Expiring inventory Running inventory expiration while you are backing up clients can cause resource contention problems. If expiration is processing a node that is being backed up, performance degradation is usually the result. Backing up storage pools Wait for client backups to finish before you start a storage pool backup. Otherwise, the storage pool backup copy does not include the entire client backup. |
None |
– Mount points |
Backing up storage pool |
Requirement: Store new data in the primary storage pool. |
None |
Backing up client data |
– Mount points |
Copying active data |
Requirement: Store new active data in the primary storage pool. |
None |
Backing up client data |
– Mount points |
Expiring inventory |
Requirement: Deactivated data must exist on the server. Recommendation: Run inventory expiration within its own processing window as much as possible. In addition, run inventory expiration before the reclamation process to ensure that the process reclaims as much space as possible, considering policy definitions. |
Backing up client data Expiring inventory while you are backing up clients can cause resource contention problems. If expiration is processing a node that is being backed up, performance degradation is usually the result. |
None |
– Locking (high) |
Generating backup sets |
Requirement: Store data in at least one primary storage pool. |
None |
None |
– Mount points |
Identifying duplicates |
Requirement: Store new data that is not deduplicated from client-side deduplication in a primary storage pool that is enabled for server-side deduplication. Recommendation: Run duplicate identification before reclamation (as much as possible). |
None |
Potential prerequisite: If you are backing up storage pools, the process might not run at optimal speed against objects that are already identified. In heavy deduplication environments, it can be beneficial to back up storage pools before you run duplicate identification. |
– Mount points |
Migrating storage pools |
Requirement: Store data in at least one primary storage pool. |
None |
Potential prerequisite: If data deduplication is being used in the storage pool that is being migrated, and the target storage pool is deduplicated, run duplicate identification before you move or migrate that data. |
– Mount points |
Moving data |
Requirement: Store data in at least one primary storage pool. |
None |
Potential prerequisite: If data deduplication is being used in the storage pool that is being migrated, and the target storage pool is deduplicated, run duplicate identification before you move or migrate that data. |
– Mount points |
Moving data by node |
Requirement: Store data in at least one primary storage pool. |
None |
Potential prerequisite: If data deduplication is being used in the storage pool that is being migrated, and the target storage pool is deduplicated, run duplicate identification before you move or migrate that data. |
– Mount points |
Reclaiming volumes in an onsite storage pool |
Requirement: Store data on storage pool volumes that are expired. In addition, put data on storage pool volumes that are identified as duplicated (through the identify duplicates process). |
None |
Expire inventory before you reclaim volumes in an onsite storage pool. Potential prerequisite: If deduplication is being used for the storage pool that is being reclaimed, complete duplicate identification and a storage pool backup before deduplicating data. |
– Mount points |
Reclaiming volumes in an offsite storage pool |
Requirement: Store data on storage pool volumes that are expired. In addition, data is on storage pool volumes that are identified as duplicated (through the identify duplicates process). The data must be in a copy storage pool that is flagged as offsite. |
None |
Expire inventory before you reclaim volumes in an offsite storage pool. Potential prerequisite: If deduplication is being used for the storage pool that is being reclaimed, complete duplicate identification and a storage pool backup before deduplicating data. |
– Mount points |
Replicating nodes |
Requirement: Store data in at least the primary storage pools and define and prepare a target server for replication. Recommendation: If you are using data deduplication for the replication process, run identify duplicates to completion in the primary storage pools before you run replication. This recommendation can be ignored if you are using client-side data deduplication for your entire environment. |
None |
Back up client data before you replicate nodes Potential prerequisite: If the replication process relies on data that is being deduplicated, run duplicate identification against all data that is being replicated. |
– Mount points |