Your experience one of the following errors:
- The first record available for reading from the Change Journal for volume '<drive letter>' is higher than the agent backup in previous backup and indicate there is a chance that file or directory changes will be not backed up.
- Change Journal for volume <drive letter> appears to have wrapped.
- The USN Journal was not registered because it experienced a wrap condition.
- Backup job was terminated due to Change Journal registration errors.
Like the Microsoft Event Viewer, the Microsoft Update Sequence Number Journal for NTFS (aka the NTFS Change Journal), has a defined file size for tracking the changes that occur on the computer. When the file is full, it drops the oldest line items allowing for new changes to be logged. If the Unitrends appliance find that the oldest record in the Change Journal is higher than the value expected, it will fail the Child backup (Incremental/Differential), present the error, and demand a new Full backup to ensure consistency and accuracy in the data to be collected.
There are two ways to resolve this issue, both require increasing the windows USN Journal size:
Using the Unitrends Client Agent (must have release 10.0.0-3 or newer):
- Ensure you have installed the most recent version of the Unitrends Client Agent.
- Edit the file C:\PCBP\MASTER.INI file (must be edited as admin).
- Change the value for ChangeJournalSizeMB to be up to 4096 if it is not set to this already (this value is in MB, thus 4GB up to 4GB of RAM). If it is 4GB and has wrapped, see below. This value is set automatically on clean agent installs, but is persisted from older agents which may be why the number is smaller.
- Save the master.ini file.
- Restart the Windows Service named BP Agent.
- Perform a new FULL backup of the client. The journal will be changed to the new size at that time.
Using the Microsoft method
Follow the instructions in the article "Windows agent file-level backup failure due to change journal wrap or Journal range exceeded." This process should be used selectively on volumes that continue to wrap above 4GB journal size.
NOTE: As of release 10.0.0-3 the master.ini (general configuration) parameter “ChangeJournalSizeMB” is now properly handled by the agent. If the maximum change journal size is smaller than the master.ini parameter, it will be enlarged to match the master.ini parameter. The agent will not decrease the maximum change journal size. On an initial agent install (no agent has been installed before), the default value for “ChangeJournalSizeMB” is 1024 (or 1 GB) or 2048 (or 2GB) depending on the Agent Version. We recommend you do not exceed the value of 4096 (or 4GB) in the master.ini as the master.ini method applies that journal size to ALL volumes, but typically only one volume needs more journal.
Journal change recommendations:
- Journal size for a volume should not be larger than 50% of system RAM. Up to the full journal "could" be loaded into RAM at backup time, as well as the NTFS Metabase for that volume. This can use excessive RAM. If the system does not have sufficient free RAM, other apps will be offloaded to the pagefile potentially causing server performance limitations. This can use 768MB Ram per million file changes incurred since a prior backup for the journal + 1.25GB RAM per million files listed in the NTFS metabase, potentially being substantial on systems with many millions of files.
- Journal size WILL eat it's space on disk. Before increasing journal size ensure sufficient free space in the volume exists.
- We recommend increasing the journal 2GB at a time until a happy medium is found. This can take trial and error and may still wrap periodically on days of high change.
- Microsoft recommended USN journal size is 512MB for the first 400K files + 128MB for each additional 100K files in the volume. therefore, 4GB should be more than most systems ever require. Systems with high performance databases, logging engines, ADFS replication, and other uses may wrap the journal quickly even with far fewer files.
- Where journals wrap, one should review whether image backups are a more suitable process vs file level backups. That said, the common reasons of high change on a server are typically scenarios that eliminate a server from image backup support (clusters, non_MS databases, ADFS, etc). Remember we do not (yet) support image backups for Elite/Premium DRaaS and one must be aware of impacts for local and cloud capacity when changing backup types, so do not simply change to image backups universally, only after reviewing resk vs reward.