08-08-2019 03:05 AM
Hi all,
Veritas informs. Backup of entire virtual machine, with full schedule: backs up only the blocks that have changed since the .vmdk was created.
Conslusion: 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. 2) I successfully restore a virtual machine from full backup. Guest OS Linux. “Block-level incremental backup is enabled.
Please explain.
Andrii
Document Link: https://www.veritas.com/content/support/en_US/doc/21902280-127283730-0/v27791754-127283730
08-08-2019 03:43 AM
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 created.
08-08-2019 04:35 PM
Further to SDO's reply.
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.
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).
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 bpbrm (pid=273179) accelerator enabled", that "Info bpbrm(pid=6192) There is no complete backup image match with track journal, a regular full backup will be performed".
For subsequent backups you will only see the first entry.
Cheers
David
08-09-2019 12:06 AM
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.
08-09-2019 12:58 AM
Hi,
I posted some more points about VMware BLIB/CBT backups a while back, see if this helps.
08-09-2019 01:08 AM
I want to clarify. The Accelerator topic is not relevant! The question is exclusively on block-level incremental backup
08-09-2019 05:20 AM
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...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. 2) I successfully restore a virtual machine from full backup. Guest OS Linux. “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.
08-09-2019 06:26 AM
I really appreciate your help.
Many thanks for the extended answer!
The next 5 days I will be absent.
07-22-2020 11:06 AM
This is an awesome explanation. Thank you for taking the time to explain and type this.