Different types of image backups and their advantages and disadvantages

Different types of Image backup techniques in TSM

Normal Image Backups

• When you cannot resolve system memory problems or progressive incremental backup is otherwise unusable.

• There are too many changes in the file system (greater than 1,000,000 objects) for journal-based backup.

• Most of the file system contains small files (average size less than 1 MB).

• You must have a faster recovery time than what can be achieved with file-level restore.

• For AIX, HP-UX, Linux, and Solaris clients:

• Backups are faster.

• No scan time is required to determine what changed.

• Overall data movement is faster.

• Restore times are faster.

• You cannot restore individual files directly from the Tivoli Storage Manager server

• The volumes to be backed up remain online.

• Fuzzy backup processing occurs when the data is changed during the image backup processing.

• The volumes to be backed up remain online.

• The image backup is made at a single point in time.

• It is available only for AIX JFS2, Linux x86, and Windows operating systems

• During a full image backup (for example, when you issue the dsmc backup image command), the client sends a logical block image of a file system to the server.

• Subsequent backups are incremental-by-date image backups (for example, when you issue the dsmc backup image -mode=incremental command), in which the client queries the server for the last backup of the entire file system.

• The server sends the time stamp of last backup of the entire file system to the client.

• The client scans and compares the time stamp with the local file system, and backs up the new and changed files.

• The client requests an incremental image restore.

• The server sends the base image to the client.

• The server returns more files that must be applied to the base image to satisfy the recovery point.

• You need faster backups.

• You must be able to restore files to a specific point in time.

• Backups are faster.

• No scan time is required to determine what changed.

• Overall data movement is faster.

• Restore times are faster.

• Protection of files that changed after the image backup was created.

• In some cases, recovery time and recovery point objectives are improved.

• 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.

• Deleted files are not reconciled. Deleted files are not expired on the server. Therefore, when you restore an image with the incremental option, files that were deleted after the original image backup are present after the restore.

• More storage space is required on the Tivoli Storage Manager server.

• During a full image backup (for example, when you issue the dsmc backup image command), the client sends a logical block image of a file system to the server.

• Subsequent backups are progressive incremental backups in which the client queries server for the active backup version metadata.

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

• The client scans and compares the list with the local file system.

• The client backs up the new and changed files.

• The client requests an incremental image restore.

• The server returns the base image.

• The server returns more files that must be applied to the base image to satisfy the recovery point.

• The server optionally returns the list of files that must be deleted from the base image.

• When you need faster backups.

• When you want to restore files to a specific point in time.

• When you want to be able to reconcile deleted files.

• Backups are faster.

• No scan time is required to determine what changed.

• Overall data movement is faster.

• Restore times are faster.

• Protection of files that changed after the image backup was created.

• In some cases, recovery time and recovery point objectives are improved.

• More time is required to periodically create image backups.

• More storage space is required on the Tivoli Storage Manager server.

• The first time that you run an incremental backup with the snapdiff option, a snapshot is created (the base snapshot) and a traditional incremental backup is run by using this snapshot as the source. The name of the snapshot that is created is recorded in the Tivoli Storage Manager database.

• The second time an incremental backup is run with the snapdiff option, a newer snapshot is either created, or an existing one is used to find the differences between these two snapshots. The second snapshot is called diffsnapshot. The client then incrementally backs up the files that are reported as changed by NetApp to the Tivoli Storage Manager server.

• On Windows systems, it does not work for any of the NetApp predefined shares, including C$, because the client cannot determine their mount points programmatically.

• You must periodically take a new base snapshot with the createnewbase option to back up any files that might have been skipped