What is the difference between Progressive Incremental and Adaptive Subfile backups and how should they be used?
Tivoli Storage Manager backup-archive client can perform different backups based on need and environment. It is important to know how incremental backups and subfile backups operate and under which conditions each should be implemented.
When the user requests an incremental or subfile backup, Tivoli Storage Manager has to determine it's eligibility by identifying the following:
1. checks each file against the user's include-exclude list in the client options file
2. checks the management class of each included file (whether there is a backup copy group or not)
3. checks the mode, frequency, and serialization parameters within the management class copy group
Both Incremental and Subfile backups are managed by policy, meaning each file is bound to a management class. This management class contains the backup copygroup which determines the following attributes:
Destination = where to store backed-up files (storage pool)
Serialization = how to manage files that are modified during backup
Frequency = how often a file is to be backed up
Mode = specify whether a file has to have changed to be eligible for backup
VERexists = how many versions to retain on the server
VERdeleted = how many versions to keep after a file has been deleted from client
RETExtra = how long to retain inactive version of a file
RETOnly = how long to retain the last remaining version of a file which has been deleted from the client
Progressive Incremental Backup
An incremental backup is the standard method used by Tivoli Storage Manager backup-archive client. This method first performs a full backup of a client system. Subsequent, incremental backups are performed on files which have been changed or modified since the initial backup. Progressive Incremental prevents unnecessary backups of unchanged data, offers more efficient use of storage resources by not storing redundant data and a faster recovery by not storing multiple versions of the same file. Progressive incremental backup also produces faster restores because only the version of the file requested needs to be restored.
For this particular technote we will assume the Progressive Incremental Backup referenced is a Full Incremental backup (always managed by policy), it should be noted however that it is possible to perform a Partial Incremental, which does not rebind the management class to files, does not expire files, and cannot recognize when files have been deleted from the client.
Versioning, assume that VERExist=2 within the file's management class:
Action 1: During Week 1, a Full Incremental backup is performed on the client system
Result 1: at this point we have our first version of all the files on the system
Action 2: Week 2, another incremental backup of the client system is initiated
Result 2: At this point only new files or files that have been changed will be backed up. Modified files are backed up to the server, we now have a second version of our file.
Action 3: Week 3, third incremental backup of the client system is initiated
Result 3: Only files that have changed since the second incremental are backed up, at this point Tivoli Storage Manager may have 3 versions of certain files stored, since VERExists parameter is set to "2", the oldest version will be marked for expiration and deleted the next time expiration runs
|Week||Operation||Actions Performed||Versions||Inactive Versions|
|1||Initial Full Incremental||Full Backup of all files on the client system occurs||1||0|
|2||Second Incremental||Backup of new or modified files on client system occurs, the entire file is backed up again even if only minimal change occurs||2||1|
|3||Third Incremental||Backup of new or modified files on client system, the entire file is backed up again even if only minimal change occurs. The
oldest version, the first file backed up, becomes marked for deletion (expired)
|4||Server runs Expiration Process||Deletes oldest inactive version (first incremental)||2||1|
Progressive Incremental is the recommended Backup Methodology and should be used when there is a stable network connection for files of all sizes. With a Progressive Incremental backup the user eliminates the need to retransmit backup data that has not been changed during future backup operations. This method allows the user to retrieve a specific version of a file as needed.
For more information about the Progressive Incremental methodology refer to the IBM Tivoli Store Management Concepts RedBook (SG24-4877-04), Section 4.3 and Section 6.4
Adaptive Subfile Backup
A subfile backup is used for limited bandwidth networks or when there is a limited connection. Examples include a modem, wireless, or mobile connection.
Unlike a Progressive Incremental Backup, a Subfile backup is a method that backs up only the parts of a file that have changed since the last backup. This reduces the amount of transfer time and data transferred over the network. The Server stores the base file, a complete full backup of the file, and subsequent subfiles called delta files (the changed parts of the file) which depend on the base file.
For smaller files (1 KB- 3 MB) a byte-for-byte copy of the file is stored in the subfile cache. The subfilecache is a cache folder created within the "\Tivoli\tsm\baclient" directory
For larger files (3MB - 2GB) a kind of "digital signature" of the file is stored in the client's subfilecache, which makes up only a small portion of the file. This is to minimize the amount of space consumed in the cache.
Files smaller than 1KB or larger than 2GB are currently not supported by subfile backup and will not be processed.
Assume VERExist=2 within the file's management class
|Client Operation Description||Client Action Performed||Data transferred||Version Components||Existing Versions|
|Initial Subfile Backup||Full backup of base file||5mb||Base File||1|
|Second Subfile Incremental (with minor changes)||Backs up modified bytes to first delta file||2kb||Base File + Delta File 1||2|
|Third Subfile Incremental (with extensive changes)||Backs up modified blocks to second delta file.||3mb||Base File + Delta File 2||2|
During the third subfile backup the oldest delta file will be marked for expiration to comply with the policy established by the management class.
Note: Although the base file is the oldest file, it will not be marked for expiration. This is because each subsequent delta file depends on the base file.
More information about subfile backups is available in the IBM Tivoli Store Management Concepts RedBook (SG24-4877-04), Section 6.5.5