cancel
Showing results for 
Search instead for 
Did you mean: 

Netbackup 7.7.3 Block-level-incremental-Backup for Vmware

cel1
Level 3

Hello , 

  We are planning to activate Block-Level-Incremental backup for our Vmware machines backups and I want to know what are the drawbacks of this option and its impact on backup sizes , backup windows , and resources consumption (CPU , storage ..) . Also what are the other benefits apart the better support of incremental backups .

Last question : what was the first release of Netbackup to introduce this feature ?

Regards,

Zakaria

 

 

5 REPLIES 5

X2
Moderator
Moderator
   VIP   

I would start with the VMware Administrator's Guide (Chapter 7).

Also, perform a search on this topic in this forum and  you will see quite a few informative posts.

I think it was introduced in some version of 7.1.x. Someone who has been using NetBackup longer than me can possibly give the exact version.

RLeon
Level 6
   VIP   

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

 

hello, 

  Thank you for your responses but I want also to know if we will have an overhead in resource consuption during backup or restore operations beacuse as I have understood NBU will synthetize a Full backup from an incremental + Full so I think this can lead to an overhead in Vmware and Media server levels , and I'm not sure if this beahvior really exist and if it is endurable or not .

Regards,

Zakaria

 

hello, 

  Thank you for your responses but I want also to know if we will have an overhead in resource consuption during backup or restore operations beacuse as I have understood NBU will synthetize a Full backup from an incremental + Full so I think this can lead to an overhead in Vmware and Media server levels , and I'm not sure if this beahvior really exist and if it is endurable or not .

Regards,

Zakaria

 

RLeon
Level 6
   VIP   

For Media Server during backup: BLIB should reduce overhead because the Incremental blocks has already been "picked out" by VMware.

For VMware during backup: CBT should reduce disk read needed - and therefore overhead - during each Incremental backup.

For Media Server during restore: If you are restoring an entire VM, you would "bother" the Media Server just as much whether you let it "synthesize" a Full+Inc in one go, or - when not using BLIB - you manually restore the Full first, then manually restore the non-BLIB incremental files. This "overhead" is negligible unless you need to perform restore operations all the time.

For VMware during restore: Either way it will still need to receive the entire VM worth of data from the Media Server over the network, then store it in its Datastore. It's overhead should be the same either way.