Is CBT working across restores of volume-level backups?

[pfeifix]

if I restore a volume-level backup into a partition of same size on another (physical) disk, can the CBT-based volume-level backup of an incremental chain be continued based on the CBT information of the volume (on the old disk) before the restore? Does VBR match the info of the old disk to the new one?

I have read somewhere that by restoring to a larger volume the block information changes and thus all blocks have to be re-written initially to the backup.

If - in theory? - the restore to a new disk's volume of the *same* size as on the backed-up disk, the CBT could be matched when the next incremental backup is made, does VBR support this? I doubt it will the case even when the volume sizes (before and after the restore) match.

Can anybody (from Veeam?) elaborate on this?

[Gostev]

No, we will detect that "offline changes" happened to the disk, discard CBT information (because we cannot know what exactly has changed) and perform "full scan" incremental backup where each disk block will be read and have its content compared against its state in the backup, to determine if it has changed. Thanks

[pfeifix]

Thanks, I have suspected that. I assume the small increment isn't even possible via persistent CBT information when the backup gets restored to the very same disk (physical or virtual)?

The background behind the question: I am looking for a way to maintain the change information base after a restore of data. What would happen when using a file-level (or file share) backup? Will the next incremental backup after a restore detect and save only the changed parts (files)?

By the way: I would be interested in how exactly a file is tracked across such (file-level or file share) backups. From the help pages I got the information that some metadata of the file like its parent folder is kept and the last change timestamp of the file decides whether it is backed up again (as a whole). What happens when a file is moved between folders? Does the new increment backup up the whole file again or is the tracking procedure able to detect that the file has only been moved -which could cause only its metadata information to change, without the necessity to save the overall file content again in the next incremental.

[Gostev]

It will be perfectly normal small increment, which would simply take longer to create for the reason I explained above.

File-level backup with Agent and with File Share backup functionality work very differently, particularly when it comes to tracking changes, so it's best not to mix them in the same discussion in the dedicated Agent forum. Further, file-level backup with agent has an option to use CBT for large files (newer capability), or not to use it for any files (default).

[pfeifix]

"It will be perfectly normal small increment, which would simply take longer to create for the reason I explained above."

I have tried this out but the next incremental taken after the restore of the volume (to a same size partition) was as large as the whole data on the volume. So sadly everything was re-written, the VIB had roughly 1 TB after the job run.
Where is the CBT information stored, is it inside the VBK/VIB files or in the VBM? I am asking because I had to reimport the backup using the VBK because the VBM had disappeared for some reason.

I am very interested to restore the backup and continue the incrementals without all of the data again. Can you guide me through the exact process of how to achieve this by using re-imported VBK/VIB files?

[Gostev]

It's not expected that we restore a volume to a different state comparing to what it was when a backup was taken and I think it's worth deeper investigation with support. It should be trivial to compare what's in backup (which is supposed to be bit-identical raw image of the source volume) vs. what was restored to the same-sized volume.

@Dima P. been covering you for a while here now but please take this discussion over as the PM

[Dima P.]

Hello,

I have tried this out but the next incremental taken after the restore of the volume (to a same size partition) was as large as the whole data on the volume.

Did you recreate the entire volume? If so - unfortunately the backup will be identical to full size of the volume. Right now there is no way to match newly created partition during recovery which previously deleted partition.

I am very interested to restore the backup and continue the incrementals without all of the data again. Can you guide me through the exact process of how to achieve this by using re-imported VBK/VIB files?

Is file level recovery an option or you actually want / need to perform volume-based recovery? How the recovery was performed via agent itself or via Veeam B&R console. Thank you!

[pfeifix]

Did you recreate the entire volume? If so - unfortunately the backup will be identical to full size of the volume. Right now there is no way to match newly created partition during recovery which previously deleted partition.

During the restore I selected a new disk but let the size of the backup image determine the new partition size. When reading the forum posts correctly VBR should be able to continue the incremental backup (small size increments) while blocks read from the new but equally sized disk can be matched to the block information in the former backup.

Is file level recovery an option or you actually want / need to perform volume-based recovery? How the recovery was performed via agent itself or via Veeam B&R console. Thank you!

File-based backup is not really an option because files are often moved between directories without other changes made to them. In this case the whole file content is backed-up again which unnecessarily blows up the repository over time.

[Dima P.]

pfeifix,

Thank you for the update! So it was a bare meta recovery, let me check with QA team. Stay tuned!

[pfeifix]

Hello Dima,

I had opened Case #06376477 last week since I need assistance in re-creating the lost VBM file for my backup. I have managed to map the existing job back to the imported VBK-VIB files but cannot continue the incremental backup chain without the missing VBM file.

May I kindly ask for explicit instructions on how to do this. I know there is a Powershell command called "New-VBRBackupMetadata" but this gives me an error when executing it using the name of the imported backup:

New-VBRBackupMetadata -BackupName "Agent Backup Job 1"
New-VBRBackupMetadata : Error in NewVBRBackupMetadata
At line:1 char:1
+ New-VBRBackupMetadata -BackupName "Agent Backup Job 1"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Agent Backup Job 1:String) [New-VBRBackupMetadata], ApplicationFailedException
+ FullyQualifiedErrorId : NewVBRBackupMetadata,Veeam.Backup.PowerShell.Cmdlets.NewVBRBackupMetadata

Right now I cannot continue the incremental backup chain so things are a bit urgent.

[Dima P.]

new disk but let the size of the backup image determine the new partition size.

That's exactly the problem.

If you restore entire backup to the original machine or entire volume to the same disk we can continue the backup without loosing the CBT and incremental backup will be small. If you restore to another location and the disk is new, we cannot match the previously created block map and volume will be stored as full (incremental restore point will contain the full disk).

I had opened Case #06376477 last week since I need assistance in re-creating the lost VBM file for my backup. I have managed to map the existing job back to the imported VBK-VIB files but cannot continue the incremental backup chain without the missing VBM file. May I kindly ask for explicit instructions on how to do this.

Sorry for the delay, I'll review the case.

[Dima P.]

Looks like the case was closed already. Support folks re-opened the case and will take it from here. Thank you!