Tuning backups with the mmbackup command

The mmbackup command performs all its work in three major steps, and all of these steps potentially use multiple nodes and threads:

1. The file system is scanned with mmapplypolicy, and a list is created of every file that qualifies and should be in backup for each IBM Storage Protect server in use. The existing shadow database and the list generated are then compared and the differences between them yield:
   • Objects deleted recently that should be marked inactive (expire)
   • Objects modified or newly created to back up (selective)
   • Objects modified without data changes; owner, group, mode, and migration state changes to update (incremental)
2. Using the lists created in step 1, mmapplypolicy is run for files that should be marked inactive (expire).
3. Using the lists created in step 1, mmapplypolicy is run for selective or incremental backup.

The mmbackup command has several parameters that can be used to tune backup jobs. During the scanning phase, the resources mmbackup will utilize on each node specified with the -N parameter can be controlled:

• The -a IscanThreads parameter allows specification of the number of threads and sort pipelines each node will run during the parallel inode scan and policy evaluation. This parameter affects the execution of the high-performance protocol that is used when both the -g and -N parameters are specified. The default value is 2. Using a moderately larger number can significantly improve performance, but might strain the resources of the node. In some environments a large value for this parameter can lead to a command failure.
  Tip: Set this parameter to the number of CPU cores implemented on a typical node in your GPFS cluster.
• The -n DirThreadLevel parameter allows specification of the number of threads that will be created and dispatched within each mmapplypolicy process during the directory scan phase.

During the execution phase for expire, mmbackup processing can be adjusted as follows:

• Automatic computation of the ideal expire bunch count. The number of objects named in each file list can be determined, separately from the number in a backup list, and automatically computed, if not specified by the user.
• As an alternative to the automatic computation, the user can control expire processing as follows:
  • The --max-expire-count parameter can be used to specify a bunch-count limit for each dsmc expire command. This parameter cannot be used in conjunction with -B.
  • The --expire-threads parameter can be used to control how many threads run on each node running dsmc expire. This parameter cannot be used in conjunction with -m.

During the execution phase for backup, mmbackup processing can be adjusted as follows:

• Automatic computation of ideal backup bunch count. The number of objects named in each file list can be determined, separately from the number in an expire list, and automatically computed, if not specified by the user.
• As an alternative to the automatic computation, the user can control backup processing as follows:
  • The --max-backup-count parameter can be used to specify a bunch-count limit for each dsmc selective or dsmc incremental command. This parameter cannot be used in conjunction with -B.
  • The --backup-threads parameter can be used to control how many threads run on each node running backup. This parameter cannot be used in conjunction with -m.
  • The --max-backup-size parameter can be used to further limit the size of a backup bunch by the overall size of all files listed in any single bunch list.
  • The --max-incremental-backup-count parameter can be used to limit the maximum number of objects in any dsmc incremental backup command to be n objects in a bunch. This option cannot be used with the -B, --max-backup-count, or -t full.
  • The --max-selective-backup-count parameter can be used to limit the maximum number of objects in any single dsmc selective backup command to be n objects in a bunch. This option cannot be used with the -B or --max-backup-count options.