Summary
When you use an existing remote seeding backup job name for a server and a volume that you have run at least one successful SnapVault backup, the backup count maintained in the local computer is inconsistent with the backup count in the storage system. As a result, an incremental SnapVault backup job runs as a base backup job. To resolve this issue, use a new job name or redirect re-seeding to a different volume or storage system.
Symptoms
When you use an existing remote seeding backup job name for a server and a volume that you have run at least one successful SnapVault backup, the backup count maintained in the local computer is inconsistent with the backup count in the storage system.
If you then address this inconsistency by forcing a base backup so as to ensure data integrity, the nibbler.log file displays the following message:
Jun 22 08:52:55 2007:5064:WARNING:SV Backup request base_snap_cnt [1] < last backup base snap cnt [3]. Secondary qtree may have been modified. Forcing base backup.
Resolution
Remote seeding by definition means creating a new base backup for a server without the need to run the backup through a slow network infrastructure, such as a wide area network. To perform remote seeding, run an image backup of the server to tape and seed this image to the storage system from a local computer.
A re-seeding refers to all seeding attempts after the first remote seeding, regardless of its success or failure. A re-seeding requires that a new backup job is created with a new <JobName>. If the previous job definition is used for the backup, it is possible to run the backup as a base backup. The backup count maintained in the local computer is inconsistent with the backup count in the storage system.
To resolve this issue, do one of the following:
- Create a new backup job with a new name each time you attempt a remote seeding process. This is the easiest way to ensure that the old backup count is not used for sanity checks.
- Redirect seeding to a different volume or storage system to break any existing relationships and their corresponding backup counts.
Note: The backup count file is a function of <NodeName>, <FilerName>, <JobName>, and the destination <VolumeName>. A change in any of these results in the system disregarding the old base counts kept by the client.