Full and partial incremental backup

An incremental backup backs up only new and changed files. The type of incremental backup depends on what objects you select to be backed up.

If you select entire file systems, the backup is a full incremental backup. If you select a directory tree or individual files, the backup is a partial incremental backup.

If you select entire drives, the backup is a full incremental backup. If you select a directory tree or individual files, the backup is a partial incremental backup.

The first time that you run a full incremental backup, Tivoli® Storage Manager backs up all the files and directories that you specify. The backup operation can take a long time if the number of files is large, or if one or more large files must be backed up. Subsequent full incremental backups only back up new and changed files. The backup server maintains current versions of your files without having to waste time or space by backing up files that exist in Tivoli Storage Manager server storage.

Depending on your storage management policies, the Tivoli Storage Manager server might keep more than one version of your files in storage. The most recently backed up files are active backup versions. Older copies of your backed up files are inactive versions. However, if you delete a file from your workstation, the next full incremental backup causes the active backup version of the file to become inactive. You can restore an inactive version of a file. The number of inactive versions that are maintained by the server and how long they are retained is governed by the management policies that are defined by your Tivoli Storage Manager server administrator. The active versions represent the files that existed on your file system at the time of the last backup.

To start a full or partial incremental backup by using the client GUI, select Backup, and then select the Incremental (complete) option. From the command line, use the incremental command and specify file systems, directory trees, or individual files to include in the backup.

During an incremental backup, the client queries the server or the journal database to determine the exact state of your files since the last incremental backup. The client uses this information for the following tasks:

• Back up new files.
• Back up files whose contents changed since the last backup.
  Files are backed up when any of the following attributes change:

  • File size
  • Date or time of last modification
  • Extended Attributes
  • Access Control List
  • Sparse, reparse point or encrypted file attributes.
  • NTFS or ReFS file security descriptors:Owner Security Identifier (SID), Group SID, Discretionary Access Control List (ACL), and System ACL.
  • Directory attributes

  If only the following attributes change, the attributes are updated on the Tivoli Storage Manager server, but the file is not backed up:

  • Read-only or read/write
  • Hidden or not hidden
  • Compressed or not compressed

  The archive attribute is not examined by Tivoli Storage Manager in determining changed files.
  Files are backed up when any of the following attributes change:

  • File size
  • Date or time of last modification
  • Extended Attributes
  • Access Control List

  If only the following attributes change, the attributes are updated on the Tivoli Storage Manager server, but the file is not backed up:

  • File owner
  • File permissions
  • Inode
  • Group ID
  • Change time (ctime) attribute. See the updatectime option for details.
  • Icon location (Mac OS X only)
  • Type or creator (Mac OS X only)
• Back up directories.
  A directory is backed up in any of the following circumstances:

  • The directory was not previously backed up
  • The directory permissions changed since the last backup
  • The directory Access Control List changed since the last backup
  • The directory Extended Attributes changed since the last backup
  • The directory modification time stamp changed since the last backup

  Directories are counted in the number of objects that are backed up. To exclude directories and their contents from backup, use the exclude.dir option.

• Expire backup versions of files on the server that do not have corresponding files on the workstation. The result is that files that no longer exist on your workstation do not have active backup versions on the server. However, inactive versions are retained according to rules defined by the Tivoli Storage Manager administrator.
• Rebind backup versions if management class assignments change. Only objects that have active backup versions are bound again. Objects for which only inactive backup versions exist are not bound again.
  During a partial incremental backup operation, objects are rebound or expired as follows:

  If the file specification matches all files in a path:

  Rebinding and expiration occurs for all eligible backup versions that match the file specification. This is the case for an incremental command like dsmc incr c:\mydir\* -subdir=yes.

  If the file specification does not match all files in a path:

  Rebinding and expiration occurs for all eligible backup versions that match the file specification. However, eligible backup versions are not expired or rebound if they were in a directory that no longer exists on the client file system.

  Consider an incremental command like dsmc incr c:\mydir\*.txt -subdir=yes. Assume that some files in c:\mydir\ do not have the txt file type. Rebinding and expiration occurs only for files that match the *.txt specification and whose directories still exist on the client file system.

You can use the preservelastaccessdate option to specify whether to modify the last access date after a backup or archive operation. By default, the access date changes after a backup or archive operation.