I have a VM which is a 20GB disk that's about half full. I did a backup earlier this afternoon after installing Office 2007 Ultimate, and my .VBK file was 9.9 gigabytes and I had a .VRB file which was 2.6 gigabytes.
I then installed some Windows updates, totalling 107 megabytes (compressed.) I took another backup. The new backup .VBK file is around 400 megabytes larger at 9.9 gigabytes and the new .VRB file is 3.2 gigabytes.
My question: If the new .VBK file is only around 400 megabytes larger than when I last ran this backup job four hours ago, why is the new .VRB file over three gigabytes? (Is it because those 400 megabytes of changes are scattered around the .VBK file and the deltas are done at a fairly large level, like say 1 megabyte?)
Just trying to know what to expect as far as how big my incremental backup files will be on an ongoing basis. I was thinking they'd be pretty small, but now I'm not so sure. (And I'm also thinking the performance boost with Veeam 4 can't be 20x higher in situations like this. I assume that the size of the .VRB file would correlate to the amount of changed blocks sent over during the incremental backup job?)
Well, I'm sure one of the Veeam folks can answer this more accurately, but here's my attempt at explaining this. Veeam looks at changes on a 1MB segment basis. In other words, even if only a single block changes in a 1MB segment, Veeam backs up that entire 1MB segment to the VBR and copies the new 1MB segment into the VBK. If you think about that, in the worst case scenario it would only take changes to 1000 block to create 1GB of changes (assuming all 1000 blocks changed on disk were in different 1MB segments, an unlikely case). However, applying a 107MB of patches to WIndows is likely to change 10's of thousands of blocks all over the disk. This large block size causes the VBR to be comparitively large in comparison to the actual amount of data changed.
This can be somewhat improved by defragmenting the disk since a disk with large blocks of free space will be more likely to cluster changed blocks close together potentially lowering the number of 1MB segments with changed blocks.
Tom is correct. Defragmentation should help to make all changes more physically consolidate instead of being spread out across VMDK.
The new 4.0 storage is designed to allow changing the block size very easily. We are planning to perform comprehensive testing after 4.0 is out to find the optimal block size, and if this does not reduce backup performance too much, we will possibly reduce the block size. This should allow for significant reduction of VRB sizes, especially for fragmented VMs.
Part of the problem here is that we cannot really reduce the block size significantly for "network" backup mode, because this will increase memory requirements for service console agent significantly. But for all other backup modes, extra memory requirement should not be a problem.
I understand. It's just very strange that it's so inefficient. We're using rdiff-backup, and the diff files it generates for .VBK backups are a fraction of the size of the .VRB files. For example, in the case I describe above, Veeam's .VRB file is 3.2 gigabytes. The rdiff-backup diff file for the .VBK file is around 800 megabytes -- 25% of the size! (Like Veeam, rdiff-backup also uses reverse delta files.) I guess it works at a much more fine-grained level than the .VRB files, and maybe gets the benefit of doing the diff file generation as a second pass by comparing two .VBK files (instead of doing it in a single pass like I guess the .VRB files are done.)
The other thing is that I'm using "optimal" as opposed to "best" compression -- I'll try "best" and see if I get better results.
I learned a bit more about why our .VRB files are so big.
Swap files!
We were doing backups of our full system, including the C: drive. Even though the system itself wasn't changing much from day to day, the swap file itself had different data depending on what happened to be swapped out, and where it was, which resulted in huge 1-3 gigabyte .VRB files every night.
Moving the swap file to its own disk (which isn't backed up) and redirecting C:\WINDOWS\TEMP to a directory on that same disk dropped our .VRB files down to 50-400 megabytes per run (averaging around 200-400 megabytes.) That's still pretty high, but it's a lot better than before.
A good question is: Are there any other recommended "best practices" for backing up VMs, like this? I assume there's nothing wrong with not backing up our swap file.
Alex, defragmenting the drive will also help to reduce the size of incrementals, but it may not worth it because on the other hand this will reduce deduplication efficiency for VMs made for the same template.
We are also planning some enhancements around reducing incrementals size in the subsequent releases, we are doing some research and prototyping right now.
