Do not perform incremental backups

Incremental backups of VOB storage cause problems when they are restored.

Instead of modifying an existing data container when a new version of an element is checked in, HCL VersionVault creates a new container at a different pathname within the source storage pool and then deletes the old container. This mechanism defeats the purpose of most incremental backup schemes, which typically back up only files that have changed since a previous backup. A series of incremental backups of a VOB would capture every container and then would restore containers that had been purposely deleted, filling the VOB storage directory with useless data.

For example, suppose that one or more new versions of a particular element are created each day for a week. Each day’s incremental backup saves a different source container for that element. If you restore from such a backup at the end of the week, you restore all those containers to the storage pool, even though only one of them (the most recent) corresponds to the current state of the VOB database. A subsequent run of checkvob would report many unreferenced data containers, which you must then delete.

Given this situation, avoid incremental backups of VOB storage or, if this is not possible, perform only a few incremental backups before the next full backup.