Journal-based backup

If the journal engine service is installed and running, then by default the incremental command performs a journal-based backup on file systems that are being monitored by the journal engine service.

Tivoli® Storage Manager does not use the journaling facility inherent in Windows NTFS or ReFS file systems or any other journaled file system.

The journal engine service records changes to an object or its attributes in a journal database. During a journal-based backup, the client obtains a list of files that are eligible for backup from the journal database. Performing backups regularly maintains the size of the journal.

Journal-based backup can increase backup performance. With journal-based backup, the client does not scan the local file system or obtain information from the server to determine which files to process. Journal-based backup also reduces network traffic between the client and server.

Tivoli Storage Manager filters the list by using the current include-exclude list. Tivoli Storage Manager processes, expires, and updates the resulting files according to policy constraints, such as serialization. The management-class copy frequency attribute is ignored during journal-based backup.

The journal engine service excludes specific system files (pagefile, registry, and so on) from having changes recorded in the journal. Because changes to these files are not journaled, Tivoli Storage Manager does not back up these files. See the journal service configuration file tsmjbbd.ini, which is in the Tivoli Storage Manager installation directory, for specific system files that are excluded.

To support journal-based backup, you must install the journaling engine service. Install this service by using the dsmcutil command or the GUI Setup wizard.

If the file specification on the incremental command is a file space, Tivoli Storage Manager processes any journal entries for that file space. Tivoli Storage Manager processes directories and file specifications that contain wildcards in the same way. Tivoli Storage Manager uses the domain list if you do not specify a file specification.

Note: Journal-based backup might not fall back to the traditional incremental backup if the policy domain of your node is changed on the server, depending on when the policy set within the domain was last updated and the date of the last incremental. In this case, you must force a full traditional incremental backup to rebind the files to the new domain. Use the nojournal option with the incremental command to specify that you want to perform a traditional full incremental backup, instead of the default journal-based backup.

When a user deletes a file with a long name, the Windows operating system might supply a short (compressed) name to the journal engine service. After the object is deleted, the compressed name can be reused and the deletion notice might no longer identify a unique object. During a journaled incremental backup, the attempt to expire the file fails because the compressed name is not known to the server. When this failure occurs, a record is placed in the journal, which indicates that the current directory is not exactly represented at the server. Use the incrthreshold option to specify what action is taken when this occurs.

The journal database is considered invalid and the client reverts to the traditional full incremental backup when any of the following events occur:

A journaled file space name changes.
The client node name changes.
The client contacts a different server to do the backup.
A policy changes occurs (new policy set activation).
The journal is corrupted (out of space conditions, disk error).
The journal service is not running.
The journal service is stopped or started for any reason, even if it is restarted because the system is rebooted.

Journal-based backup differs from the traditional full incremental backup in the following ways:

Tivoli Storage Manager does not enforce non-default copy frequencies (other than 0).
Attribute changes to an object require a backup of the entire object.

You can use the nojournal option with the incremental command to perform a traditional full incremental backup instead of the default journal-based backup.

Multiple journal-based backup sessions are possible.