FAQ for AhsayCBS v9 Deduplication and Migrate Data

1.What is the deduplication module?

The deduplication module is new feature introduced in AhsayCBS v9.1.0.0 and is free of charge.

It is used to identify and filter out duplicate or repeating data blocks during a backup job. As a result, only the unique data blocks are backed up to the storage destination(s), therefore significantly reducing data storage usage and storage costs.

As fewer backup data is generated due to deduplication, both backup and restore performance is greatly improved.

2.What if I disable deduplication on a backup set?

This option is not recommended.

If deduplication is disabled then backup jobs will upload all the data blocks from the file(s). If there are any updates to the file(s), they will be re-uploaded again as a full file.

It is similar to backup jobs in v8, v7, or v6 with in-file delta disabled, which will inevitably lead to slower backup & restore, higher storage usage, and storage costs.

3.What is the best practice for deduplication settings?

It is recommended to enable deduplication on all backup sets using the default options, as they are the optimal settings.

4.What is the "Migrate data" option?

Allows backup sets created in legacy versions such as v8, v7, or v6, to transition pre-v9 data into the new v9 deduplicated format.

To optimize resource usage and minimize any disruption to customer production servers, "Migrate data" is designed to gradually transition the pre-v9 data into the new v9 deduplicated format. Data is transitioned during a backup job whenever pre-v9 file(s) are updated, it will be processed by the deduplication module and the complete file will re-uploaded in v9 format. The pre-v9 file(s) will be moved to retention.

When this option is enabled, it will temporarily lead to higher storage usage which could be up to twice the original storage size. As data in both pre-v9 and v9 deduplicated format will co-exist until retention policy removes the pre-v9 files from the backup set.

The "Migrate data" option only affects those files that have been modified after upgrading to AhsayOBM/AhsayACB v9. It has no effect on files which stay unchanged after upgrading to v9. This is to minimize the load on network bandwidth. 

The time taken to completely transition the data will vary, depending on how fast the pre-v9 file(s) on the backup set are updated.

5.What if I disable "Migrate data" option?

When "Migrate data" option is disabled, if there are changes to pre-v9 data only the changed data will be backed up in v9 deduplicated format and not the whole file.

The storage usage will be less compared with "Migrate data" option enabled but restore performance will be much slower. This setting is only recommended if there are storage space limitations.

**Does not apply to Hyper-V and VMware backup sets, where first backup job after upgrading to AhsayOBM v9 is a mandatory full backup.

6.What is the best practice for "Migrate data" settings?

It is recommended to enable the "Migrate data" for all backup sets created in legacy versions such as v8, v7, or v6. However, this will require more storage space until all pre-v9 data are removed permanently according to their retention policies.

7.Is there another option to quickly convert data in legacy backup sets into v9 deduplicated format?

The alternative options are to either:

• Create a new v9 backup set with deduplication enabled and backup the data from scratch. Then remove the original legacy backup set after the new backup is completed.
• Delete the existing pre-v9 data on the backup set, the data will be backed up from scratch on the next backup job in v9 deduplicated format.
• (For advanced users only)

You can retain a copy of all old pre-v9 data without deleting them by moving $USER_HOME/blocks/$BackupSetID to another folder, e.g. $USER_HOME/blocks.bak/$BackupSetID, where $BackupSetID can be looked up from the backup set setting page of AhsayCBS. The next backup job will not see old data and will back up from scratch in full again in v9 format.

8.Why is a full backup job run on Hyper-V and VMware backup sets following an upgrade to AhsayOBM v9?

Data in Hyper-V and VMware backup sets use a proprietary change block tracking (RCT & CBT) mechanism to identify changes and don't contain checksums for v9 deduplication to detect changes. Therefore, the first backup for these backup sets after upgrading to AhsayOBM v9 requires all data to be backed up in full again. This enables deduplication to take place for subsequent backups so that more storage space can be saved in the future.