Journal-based backup
Journal-based backup is an alternate method of backup that uses a change journal maintained by the Tivoli® Storage Manager journal service process.
Journal-based backup is supported for all Windows clients.
To support journal-based backup, you must configure the journal engine service using the dsmcutil command or the client GUI setup wizard.
A backup for a particular file system will be journal-based when the Tivoli Storage Manager journal service has been installed and configured to journal the particular file system, and a valid journal has been established for the file system.
The primary difference between traditional incremental backup and journal-based backup is the method used for backup and expiration candidates.
Traditional incremental backup obtains the list of backup and expiration candidates by building comprehensive lists of local objects, and lists of active server objects for the file system being backed up. The local lists are obtained by scanning the entire local file system. The server list is obtained by querying the entire server inventory for all active objects.
The two lists are compared, and candidates are selected according to the following criteria:
- An object is selected as a backup candidate if it exists in the local list. but doesn't exist in the server list. The object is also a backup candidate if it exists in both lists, but differs according to Tivoli Storage Manager incremental criteria (for example, attribute changes, date and size changes).
- An object is selected as an expiration candidate if it exists in the server list, but doesn't exist in the local list.
Journal-based backup obtains the candidates list of objects to backup and expire by querying the Tivoli Storage Manager journal service for the contents of the change journal of the file system being backed up.
Change journal entries are cleared (marked as free) after they have been processed by the backup client and committed on the Tivoli Storage Manager server.
Journal-based backup is activated by configuring the journal service to monitor specified file systems for change activity.
Journal-based backup is enabled by successfully completing a full incremental backup.
The journal engine service does not record changes in specific system files, such as the registry, in the journal. Therefore, a journal-based backup will not back up this file. See the journal service configuration file, tsmjbbd.ini, in the client installation directory for excluded system files.
You can use journal-based backup when backing up file systems with small or moderate amounts of change activity between backup cycles. If you have many file changes between backup cycles, you will have very large change journals. Many changes to the journal-based backup file might pose memory and performance problems that can negate the benefits of journal-based backup. For example, creating, deleting, renaming, or moving very large directory trees can also negate the benefit of using journal-based backup instead of normal incremental backup.
Journal-based backup is not intended to be a complete replacement for traditional incremental backup. You should supplement journal-based backup with a full progressive incremental backup on a regular basis. For example, perform journal-based backups on a daily basis, and full incremental backups on a weekly basis.
Journal-based backup has the following limitations:
- Individual server attributes are not available during a journal-based backup. Certain policy settings such as copy frequency and copy mode might not be enforced.
- Other operating-system specific behaviors might prevent objects from being processed properly. Other software that changes the default behavior of the file system might prevent file system changes from being detected.
- If the file system is very active when a journal-based backup is in progress, it is possible that a small number of deleted files will not be expired.
- If you restore files to a file system that has an active journal, some of the restored files might get backed up again when the next journal-based backup occurs, even if the files have not changed since they were restored.
- Multiple journal-based backup sessions are possible.
- When using antivirus software, there are limitations to journal-based backup.
- A journal-based backup might not fall back to the traditional incremental backup if the policy domain of your node is changed on the server. This depends on when the policy set within the domain was last updated and the date of the last incremental backup. 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.
- Restore processing with journal-based backups (Windows)
The journal service attempts to identify changes that are made to a file as the result of a restore operation. If a file is unchanged since it was restored, it is not backed up again during the next journaled backup. The presumption is that you are restoring a file because it contains the data you need, so there is no point to backing up the file again when the next journal backup occurs. Changes to restored files that occur after the files are restored must be recognized as new changes and the file is processed in the next journal backup.