Block-level incremental backup

Question

Hi all,&nbsp;Veritas informs. Backup of entire virtual machine, with full schedule: backs up only the blocks that have changed since the .vmdk was created.Conslusion:&nbsp; if the virtual machine completely is lost, it is impossible to restore from full backup with the Enable option “Block-level incremental backup”. Is this the right conclusion?I have the opposite result. 1) I delete the virtual machine.&nbsp; 2) I successfully restore a virtual machine from full backup. Guest OS Linux.&nbsp;“Block-level incremental backup is enabled.Please explain.AndriiDocument Link: https://www.veritas.com/content/support/en_US/doc/21902280-127283730-0/v27791754-127283730&nbsp;&nbsp;

rleon · Answer

Accelerator is actually the cause of your confusion. But the poor writing of the documentation is to blame.Just to be clear:BLIB: Block Level Incremental Backup. NetBackup term when referring to backups that utilize CBT. Veritas just LOVES creating it's own terms for referring to other people's features!CBT: Changed Block Tracking. A VMware feature.Let's break down this critical sentence from the document about NetBackup BLIB/CBT:...full schedule ...Backs up only the blocks that have changed since the .vmdk was created.This is only true when Accelerator is enabled. The really infuriating thing about this is that the documentation is not technically wrong, it's just not giving you the full picture by building a better context to what it is really saying, by providing all the conditions and prerequisites for getting the same results.Anyway, here's what really happens. (They should really put this in the document better, like put it in a table or something!)BLIB without Accelerator Full backup - NetBackup actually does a REAL Full (Some call it Active Full or Forced Rescan Full). I.e., VMware sends the entire VM without CBT to NetBackup. YES, WITHOUT CBT even though you enabled BLIB in the policy! Slower backup time because more network/san data traffic to NetBackup.BLIB without Accelerator Incremental backup - NetBackup tells VMware to send CBT (changed data only since the last Full or CBT). Fast backup time because there is much less data traffic to NetBackup.BLIB with Accelerator Full backup -&nbsp;NetBackup tells VMware to send CBT. Fast backup time because there is much less data traffic to NetBackup. Once the changed blocks are received, NetBackup "Synthesize" a new Full by combining this new CBT with previous CBTs and the previous Full. The previous Full could itself be a Synthesized Full as well.BLIB with Accelerator Incremental backup -&nbsp;Same thing happens as the above. NetBackup still creates a Synthesized Full. The main difference is that in the NetBackup catalog DB, this backup is flagged as an Incremental. But you might ask 'why not just flag this as a Full anyway since it is really another Synthesized Full?' Well, Incrementals use up less catalog DB space than Fulls because Fulls record all file path details. That is why even with Accelerator, it is still not wise to make every backup everyday a Full.&nbsp;...BLIB...This option reduces the size of full backups as well as the size of incremental backups...The above statement in the document can really confuse people.What BLIB 'reduces' is the backup traffic going over the network/san to NetBackup, making the backup time faster because VMware sends less data to NetBackup.Whether the disk usage is 'reduced' depends on whether you are using Deduplication (such as MSDP) or not.If you do not have Deduplication, backups received will use up more disk space, regardless of whether backups were received with or without BLIB/CBT.About your test:I have the opposite result. 1) I delete the virtual machine.&nbsp; 2) I successfully restore a virtual machine from full backup. Guest OS Linux.&nbsp;“Block-level incremental backup is enabled.It worked because when you restore, NetBackup automatically 'combines' (or synthesizes, whatever you prefer to call it) the previous Full and your BLIB Incremental(s) into a single thing before sending it to VMware.Proof: Do your exact same test again, but this time, before you restore, manually expire the previous Full backup image for this VM. (You can do this in the Catalog interface). You will find that all BLIB Incremental backup images that depend on this Full will automatically expire as well, even though you only manually expired the Full. This is because the BLIB Incrementals are dependant on that Full, and without the Full, the Incrementals are just random garbage data blocks that cannot be used, so NetBackup expires them for you. In short, you will not be able to restore your Incremental backup of that VM when the previous Full is gone.

rleon · Answer

Hi,Accelerator on VMware cannot work unless BLIB/CBT is enabled.But BLIB/CBT backups can work alone without Accelerator enabled.Accelerator itself requires MSDP deduplication. So if you're using things like BasicDisk or direct-to-tape backup, then you cannot use Accelerator.&nbsp;I posted some more points about VMware BLIB/CBT backups a while back, see if this helps.https://vox.veritas.com/t5/NetBackup/Netbackup-7-7-3-Block-level-incremental-Backup-for-Vmware/m-p/858209#&nbsp;

sdo · Answer

This :"Backs up only the blocks that have changed since the .vmdk was created. Note that the blocks that are not initialized are excluded from the backup."...is principally trying to get across the point that even with thick vmdk that only the used blocks are backed-up. IMO, this part "only the blocks that have changed since the .vmdk was created" will always mean that the first full backup is a full backup and so does backup eveything and so will always be able to recover a VM, because it really does include everything since the VMDK was &nbsp;created.

davidmoline · Answer

Further to SDO's reply.&nbsp;IMHO the wording poorly describes the process.For acellerator backups of VMware, the first backup taken (whether full or incremental) will backup the entire vmdk files (excluding emtpy and deleted space). It will also enable CBT on the VMware side if this is not already done.&nbsp;It will also (and this is the important bit) create a track file for the VM which contains the CBT state at the time of the backup.When the next backup is taken, this track file used together with the CBT in VMware to determine which blocks have changed since the last backup (either full or incremental).&nbsp;If you still have your backup logs from the test you performed, you should notice in the detailed job status for the first backup a line just after one saying "info&nbsp;bpbrm&nbsp;(pid=273179)&nbsp;accelerator&nbsp;enabled", that "Info bpbrm(pid=6192) There is no complete&nbsp;backup image match with track journal, a regular full backup will&nbsp;be performed".For subsequent backups you will only see the first entry.CheersDavid

andriipushkarov · Answer

Clarification. In this case, I use the parameters

Attributes: “Use Acceleraror” = NO

VMware: “Enable block-level incremental backup” = YES

“Enable block-level incremental backup” is needed to feature be able to restore a VM from an incremental backup.

Forum Discussion

Block-level incremental backup

8 Replies

Related Content

Enable block level incremental backup

Vmware Block level incremental backup

vvr block-level backup

VMWare image backup with Block Level Incremental

NDMP - how does it work? (file level or block level)