MSDP Dedup storage + BLIB:
- BLIB (aka Vmware's CBT) will speed up Incremental backups
- If MSDP Accelerator is ON, then BLIB will speed up Full backups too. If OFF, then Full backups will not sped up.
- BLIB-based Incrementals depend on their Full. If the Full expires, so will all its BLIB-based incrementals. This can create situations where you believe an incremental is not supposed to expire yet, but it still disappeared because its Full expired. To avoid this issue, you can make the Full's retention longer than the BLIB-based incrementals' retention to cover the gap.
- Regardless whether Accelerator is Enabled or Disable, a BLIB-based Incremental backup can be used to restore a "Full" VM, even though it's supposed to be an Incremental backup.
- Quirk when Accelerator Enabled: A completed BLIB-based Incremental job will show up in the Activity Monitor as having the same size as a Full, but backed up alot faster than a Full. It doesn't actually use as much storage as a Full because it is only changed blocks, plus it will be further deduplicated.
- Accelerator Disabled: A completed BLIB-based Incremental job will show up in the Activity Monitor as a much smaller size than a Full, and completed alot faster because, well, it's just an Incremental backup. This is more aligned with the traditionally expected behavior of Incremental backups.
MSDP Dedup storage + no BLIB:
- No speed up for Full nor Incremental backups. Network traffic higher than if BLIB is enabled.
- Incremental backups much slower than when BLIB is used. This is because the entire virtual disk is actually read and send to NetBackup, where NetBackup then picks out the "Incremental parts" to store. With BLIB, VMware just already knows what Incremental blocks to send to NetBackup in the first place.
- Cannot use MSDP Accelerator because it depends on BLIB.
- non-BLIB Incrementals do not depend on their Full. I.e., even if you expire the Full, its Incrementals will continue to exist.
- A non-BLIB Incremental cannot be used to restore a "Full" VM. It can only restore the changed files since the last backup. A workaround is to restore the Full VM from the last Full backup first, then just restore the newer Incremental files on top of the restored guest OS.
- A completed non-BLIB Incremental job will show up in the Activity Monitor as a much smaller size than a Full. The job will complete faster than a Full, but not as fast as a BLIB-based Incremental. Only changed files since the last backup will be stored.
Direct to Tape + BLIB:
- Mostly the same as MSDP + BLIB, but no MSDP Accelerator, and no deduplicaion at storage.
- If you lost the Tape that has a Full, then your other Tape that has the Incremental will be useless because the Incremnetal depends on the Full.
Direct to Tape + no BLIB:
- Mostly the sames as MSDP + no BLIB.
- The Tape that has a Full is independent from the Tape that has an Incremental.
Bonus info:
If you use MSDP Accelerator for VMware, be careful when duplicating Incrementals to from MSDP to Tape. All Incrementals will rehydrate to Fulls when being duplicated to Tape.
E.g.:
Accelerator OFF: Full(100GB) + Inc(10GB) + Inc(10GB) + Inc(10GB) + Inc(10GB) + Inc(10GB) + Inc(10GB) = 160GB of Tape space used in one week.
But with Accelerator ON, all Incrementals will become 100GB when going to tape, making it 700GB Tape space used for the week.
Workaround: Only duplicate Fulls and not Incrementals to tape when using Accelerator for VMware, or, just disable Accelerator if you must duplicate the Incrementals too.
Reference: https://www.veritas.com/support/en_US/article.000075317
