After your system meets the Prerequisites and Guidelines for Retrieving File Versions, there are several reasons that previous versions of a current, renamed, or deleted file might not exist in the archive database:
If you suspend or delete a versioning job for a volume, its scheduled jobs do not run and no new versions are saved to the archive. For suspended jobs, users can retrieve available file versions from the archive. For deleted jobs, the file versions remain in the database but users cannot access them until a job with the same name is added back into the sys:\arkManager\arkConfig.xml file. For suspended jobs, the job’s Delete Policy continues to be applied to existing versions in the archive. Eventually, the file versions meet the criteria for deletion defined in the job’s Delete Policy.
If Keep Current Copy is enabled for the job’s Delete Policy, at least one file version of a file remains in the database if its source file is current on the source volume, even if the Maximum Keep Time elapses.
If Keep Current Copy is disabled, the archive deletes the file version when the Maximum Keep Time elapses.
A file is versioned only if it exists at the end of an epoch. If scheduled versioning processes are paused or delayed for a period of time that exceed the lifetime of a given file, its file version might not be captured, even if the file exists for a length of time that exceeds the epoch. Although the frequency of the epoch usually is less than the typical lifetime of your files, there might be occasions when the versioning time is extended. For example, if the time it takes to save versions of all the files eligible for versioning overlaps one or more scheduled epochs, some scheduled epochs might be skipped until the current process ends and the next scheduled start time occurs.
To avoid this problem:
Schedule a job’s epoch for a period of time shorter than a typical file’s lifetime for the volume, while allowing enough time to capture file versions.
Enable the Pool Snapshot option for capturing file versions.
Minimize the use and length of job pauses.
Novell Archive and Version Services 2.1 leverages NSS pool snapshot technology to save point-in-time versions of all files, including open ones. If you disable the Pool Snapshot option, the files that are eligible for versioning are copied directly from the source volume. Exclusively open files cannot be versioned and data might be inconsistent.
To avoid this problem, make sure to enable the Pool Snapshot option for the archive server.
If the Pool Snapshot option is disabled for your archive server, file versions are saved from the volume to the archive, which takes time. If a file is created during an epoch and exists at the end of an epoch, but a user deletes it before a version can be copied to the archive database, that file version is not saved to the archive database. If the Pool Snapshot option is enabled, versions of all files, even exclusively open ones, are captured by the snapshot and a point-in-time version of each file can be saved to the archive.
To avoid this problem, make sure to enable the Pool Snapshot option for the archive server.
If your Delete Policy is excessive, file versions might exceed retention thresholds too quickly to be of use to your users. Typically, the file’s archived versions are deleted automatically from the archive database as they exceed the Maximum Time to Keep Versions or the Maximum Number of Versions.
To avoid this problem, make sure your Delete Policy meets the needs of your users.