Deduplication Database Backup

The Deduplication Database (DDB) is protected by the DDB Backup subclient. This subclient backs up the active DDBs on a MediaAgent host.

When you create a storage policy with deduplication enabled, the DDB backup subclient is automatically created under the File System Agent on the MediaAgent client where the DDB's are hosted.

If multiple DDBs are hosted on the MediaAgent, only one DDB Backup subclient is created for that MediaAgent, and the same DDB backup job backs up all active (non-sealed) DDBs available on that MediaAgent.

The DDB Backup subclient manages the following processes:

• Automatically defines the DDB as the content

• Uses the same deduplicated storage policy as that of the DDB

• Performs only FULL backups of the DDB, and the backed up data is sent to the appropriate backup media

• Backs up only active (non-sealed or non-offline) partitions of the DDB

  If any sealed or offline partitions of DDB occur during a DDB backup job, the backup process skips those partitions and backs up only active partitions.

  The DDB Backup is automatically associated with a System Created DDB Backup schedule policy. This schedule policy runs full backup job every day at 04:00 PM every twenty four hours. If you want to modify the schedule, see Modifying a Schedule Policy.

Important:

• Do not delete the DDB subclient. If the DDB subclient is deleted accidentally, see Replacing a Deleted DDB Subclient for instructions.

• Do not configure DDB partitions on multiple mount points that point to the same directory, as the DDB backup job with snapshot will fail because creating multiple snapshots of the same drive is not supported.

DDB Backup Support

DDB Backups are supported on all storage libraries. (disk, cloud, tape). However, note that DDB backups are not recommended on Archive Object Storage, like S3 Glacier/Deep Archive, Azure Archive and Oracle Archive.

DDB backups are not supported on Cluster Share Volumes (CSV).

DDB Backup Process

When the DDB backup job starts, the following events are triggered:

• All communication to the active DDB is paused for a few seconds. The information in memory is committed to disk to ensure that the DDB is in a quiesced state.

• The DDB process creates a snapshot of the volume by using VSS (Windows) or LVM (Linux) snapshots.

  The Linux platform also supports Extended 3 File System (ext3) and VERITAS Volume Manager (VxVM) file systems.

  For better performance on snapshots, see Performance Tuning for DDB Backup.

• Note:The LVM (Linux) snapshot of the DDB hosted on a Linux machine requires a free space that must follow the given calculation:

  5% of volume space as COW space and should be greater than or equal to 4GB and lesser than 50GB. That is:

  If 5% of the volume space is less than 4GB, then it will use 4GB as COW space.

  If 5% of the volume space is more than 50GB, then it will use 50GB as COW space.

  Note

  This percentage also includes any free space requirement specified by your hardware vendor. However, the snapshot of the DDB hosted on a thin logical volume grows dynamically and shares space from thin pool if required free space is not available.

• After the snapshot is created, all the communication to the DDB is resumed, and the DDB is automatically backed up from that snapshot.

  If VSS (Windows) or LVM (Linux) snapshot fails, by default, the DDB backup fails with the following error message:

  For Windows:

  Error Code: [19:857]

  Description: The job has failed because the VSS snapshot could not be created

  For Unix:

  Error Code: [19:857]

  Description: Snap not supported on the volumes holding DDB paths or we failed to take snapshot. Backup will fail, error=[Case specific error message]

  However, you can configure to use live volume backup DDB. For more information, see Frequently Asked Questions - What happens if the Snap creation fails during DDB backup?

• After the successful DDB backup, the snapshot is deleted. During this stage, the Job Controller displays the DDB Backup job in a running state.

Notes:

• The DDB backup jobs are resilient to the individual partitions in a deduplication database. When a DDB backup job is run, the partitions that are successfully backed up point to the current job whereas the partitions that failed still point to the previous successful DDB backup job. When a DDB backup job is run again later, the failed partitions are backed up first followed by the partitions that were backed up successfully in the previous DDB backup job.

• By default, the DDB backup jobs are disabled for the auxiliary copy operation, and these jobs appear as unavailable when viewed from the primary copy.

  To allow or prevent the copying of DDB backup jobs during the auxiliary copy operation, see DDB Backup Jobs during Auxiliary Copy.

DDB Backup Pruning Process

DDB backup pruning works differently on an active and sealed DDB.

Active DDB

DDB backups do not follow the retention settings on the associated storage policy copy. By default the DDB backup job is pruned if it does not hold the latest backup of any active DDB. However, you can configure the Option to retain extra DDB backups for every partition parameter to retain multiple DDB backups for each partition.

For example, if a DDB backup job includes four DDBs, then the job is pruned only when all four of the DDB's are backed up again. If the next DDB backup operation backs up only two DDBs because the other two were offline during the backup operation, the previous backup job will not be pruned until the remaining two DDBs are also backed up.

Sealed DDB

The DDBBackup subclient does not backup a DDB after it has been sealed. When a DDB is sealed, all existing DDB backup jobs that contain the sealed DDB are retained indefinitely.

To allow pruning for these DDB backup jobs, see Pruning Deduplication Database Backup Jobs of Sealed DDB for instructions.