Journal-based backup

A backup for a particular file system is journal-based when the IBM® Storage Protect journal daemon is installed and configured to journal the file system, and a valid journal has been established.

AIX operating systems Journal-based backup is supported on the AIX® Backup-Archive Client, on JFS and JFS2 file systems.

Linux operating systems Journal-based backup is supported on the Linux® Backup-Archive client on Ext2, Ext3, Ext4; XFS, ReiserFS, JFS, VxFS, and NSS. GPFS is not supported for journal-based backups on Linux.

If the journal daemon is installed and running, then by default the incremental command performs a journal-based backup on file systems which are being monitored by the journal engine daemon. The following conditions must be met in order to successfully perform a journal-based backup:

The journal daemon must be set up to monitor the file system that contains the files and directories being backed up.
A full incremental backup must have been run successfully at least once on the file system being backed up.
The file space image of the file system at the server cannot have been modified by an administrative command since the last full incremental backup.
The storage management policy for the files being backed up cannot have been updated since the last full incremental backup.

The journal daemon 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. Journal-based backup can increase backup performance because the client does not scan the local file system or contact the server to determine which files to process. Journal-based backup also reduces network traffic between the client and server

The backup-archive client filters the list based on the current include-exclude list and processes, expires, and updates the resulting files according to policy constraints, such as serialization. However, the client ignores the server frequency attribute during a journal-based backup. The reason for this is because a journal-based backup eliminates the backup version query to the server; therefore, the client does not know how many days have transpired since the last backup of the file.

The journal daemon does not record changes in UNIX special files.

The journal daemon excludes specific system files from having changes recorded in the journal. Because changes to these files are not journaled, the client does not back up these files. See the journal daemon configuration file tsmjbbd.ini located in the backup-archive client installation directory for specific system files that are excluded.

Note:

When using antivirus software, there are limitations to journal-based backup. Some antivirus software can incorrectly generate change notifications to the IBM Storage Protect journal service, causing files that have not changed to be incorrectly backed up during journal based backup. To avoid these problems, use Norton Anti-Virus Corporate Edition 8.0 and higher.
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.
Add an exclude snapshot statement to the tsmjbbd.ini file for AIX 6.1 (or later) to prevent JFS2 internal snapshot directories from being monitored by the journal-based backup daemon. If you do not exclude the snapshot directories, the files in them are backed up. Backing up the snapshot directories is redundant and wastes server space.

Under the following conditions, the journal database is considered invalid and the client reverts to the traditional full incremental backup:

A journaled file space name has changed.
The client node name has changed.
The client contacts a different server to do the backup.
Policy changes have occurred (new policy set activation).
The journal is corrupt (out of space conditions, disk error).
The journal is not running.

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

IBM Storage Protect does not enforce non-default copy frequencies (other than 0).
Changes to UNIX special files are not detected.

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