+22
Hi Fellow Hubians!
So can someone explain to me the reason for the upgrade backup chain format?
As I understand this changes the chain from having one single metadata file to separate for the per-vm backups. I can see this being a good idea from the separate and conquer point of view (or deal with less hassle if one of the metadata files gets corrupted, so if you only have one, it is much less fun) but are there any other reasons for the move?
Best answer by dips
View original
+20
I believe another reason for that is so if you want to move a VM from one backup job to another or a different repo it makes that process easier as well. I think it also ties into the option to be able to run a single VM backup again in a job if it fails instead of the whole job. I believe performance was another thing.
I could also be out in left field with that so take it as it is. 😋
+20
It enables migration of individual VM backups between repositories and jobs, and allows for better parallelised performance are the key points 🙂
per VM backup jobs used to say up to 300 VMs in a job, now it can exceed 1k for example (not sure the exact stopping off point for that but I’ve seen 1k performing well) 🙂
+17
Geoff - From my understanding, the new format with meta files per VM makes Veeam more flexible → ability to perform per-VM FULLs, move individual VMs, etc.
See ‘Backup Chain Formats’ here, where it discusses this.
+7
To add, it’s also speeds up verifications of backup chains and when running health checks against the chain.
Before we implemented per VM backups, we always used to run into health checks not completing in time due to the very short backup window we had.
+20
Is that further accelerated when using per-VM metadata vs traditional per-VM with one metadata file?
+7
Is that further accelerated when using per-VM metadata vs traditional per-VM with one metadata file?
Per-VM metadata
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
