Different types of TSM incremental backups and their advantages and disadvantages

Progressive Incremental Backup

• The client queries the Tivoli Storage Manager server for active backup version metadata.

• The server returns a list of active backup versions for the entire file system.

• The client scans and compares the list with the local file system to determine which files are new or changed since the last backup.

• The client backs up the new and changed files.

• This method is the most comprehensive & by default recommended backup method for Tivoli Storage Manager.

• No redundant backups are made. You back up only what is changed.

• There is less network utilization because unchanged files do not have to be sent over the network.

• This method is a form of single-instance storage because a file is not backed up again if it does not change. Incremental backups are more efficient and save space on the server storage pools.

• Files are easier to restore because you do not have to restore the base backup version first and apply incremental or differential changes.

• The client system might run out of memory if the number of active backup versions is too large.

• The time that it takes to scan file systems that contain millions of files can exceed the duration of the backup window.

Incremental-by-date Backup

• When you run an incremental-by-date backup. The client queries the server for the most recent backup of the entire file system.

• The server returns the time stamp of the most recent backup of the entire file system.

• The client scans and compares the list from the server with the local file system and backs up the new and changed files that are based on the time stamp of the most recent backup.

• When the scheduled backups are not completed within the allotted time.

• The changes to the file system are additive or changing, but not deleted.

• You also run weekly (or periodic) full incremental backups.

• This method reduces the time that it takes to determine which files changed.

• This method removes the processing time on the server that is used to query the database for changed files.

• This method removes the network traffic that is used to communicate the query results.

• This method reduces the flexibility of the scope of the backup operation. You must back up the entire file system.

• The files are not backed up if the changes do not affect the date (for example, attribute, mode, ACL, rename, copy, move, and security changes).

• The deleted files are not expired on the server.

• Policy rebinding does not take place.

• The entire file system must be scanned.

• This method cannot be used if the client and server clocks are set to different times or are not in the same time zone.

Adaptive Subfile Backup

• The network is limited or constrained.

• The file sizes are small (less than 2 GB in size).

• Faster throughput.

• Reduced storage pool consumption

• This method uses a large amount of local cache space.

• Some processing time is required during the backup.

• The restore operations can take longer because of the base file and delta files are restored.

• The client can run out of disk space during the restore if disk space is constrained because of how files are reconstructed from the base files and the delta files.

Configuring Multiple session backup

• During a multiple session backup operation, files from one file specification might be stored on multiple tapes on the server and interspersed with files from different file specifications. This arrangement can decrease restore performance.

• To avoid the performance degradation in restore operations, set the collocatebyfilespec option to yes. This setting eliminates the interspersing of files from different file specifications by limiting the client to one server session for each file specification. Therefore, if the data is stored to tape, the files for each file specification are stored together on one tape, unless another tape is required for more capacity.

• The client might produce multiple accounting records.

• The server might not start enough concurrent sessions. To avoid this situation, the maxsessions server parameter must be reviewed and possibly changed.

• A query node command might not summarize the client activity.