Commvault archival

Hi @Francesco_Russo 

Thanks for the question!

There are a couple of potential reasons why data isn’t stubbed on the first archiving job:

• Redundancy Check for Files that Qualify for Archiving
• Delayed Archiving

Redundancy Check

Before files on production filesystem are stubbed, the backup data must exist in at least 2 storage policy copies or cloud/GlusterFS.

Since production data is replaced by a stub, if only a singe copy of the backup data exists and this copy is lost, then archive recalls will fail, resulting in data loss.

Ensuring backup data exists in at least 2 backup copies, this insulates against a single point of failure if the data only exists in a single backup copy.

Delayed stubbing

Delayed stubbing prevents data loss in the event that you must perform a disaster recovery (DR) restore. Without delayed stubbing, when you perform a DR restore, recalls might fail for files that were backed up after the DR backup that is selected to be restored. By delaying stubbing, you can roll back to a previous CommServe DR version (within the minimum DR backups setting) without any data loss.

Stubbing is delayed by the number of DR backups plus the number of days that must pass after a DR backup.

Imagine if files are archived and stubbed on the first full backup that runs overnight, then a disaster occurs after the archive job, wiping out the Commserve, but before the next DR backup at 10:00am the next morning.

Files have been stubbed, but the latest Commserve DR backup is from the morning before the archive job. Production files have been replaced by stubs, but the DR backup used to restore the Commserve doesn’t contain the backup job metadata that the stubs point to, so the stubs are dead end, which results in production data loss.

Delayed archiving avoids this situation by ensuring no data is stubbed until a DR backup is also performed.

Thanks,

Stuart