-
- Enthusiast
- Posts: 33
- Liked: never
- Joined: Jun 09, 2010 11:16 pm
- Full Name: Brian Kellogg
- Contact:
forever incremental vbk size
I ran a incremental backup of our file server over the weekend with a conversion of the vib to vrb files. The vbk file grew in size by about the same size of all the vib files added together. Will this happen each week and will I have to do a full backup again to shrink the file each month?
We sync all of or backup files off site each night and I'm trying to avoid having to copy the large vbk file each night and at the same time not have to do a full backup of the file server.
thanks,
Brian
We sync all of or backup files off site each night and I'm trying to avoid having to copy the large vbk file each night and at the same time not have to do a full backup of the file server.
thanks,
Brian
-
- Chief Product Officer
- Posts: 31775
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: forever incremental vbk size
Hi Brian, this means means VIB files contained mostly new data. If you add more new data to source VM disk, then VBK will grow again. However, if data on source VM is mostly updated instead of added, then VBK should not grow much, as before growing the file, Veeam Backup always tries to leverage any unused VBK blocks marked. VBK block is marked as unused when its data is moved into VRB, and there dedupe reference count to this block is zero. Note that if the block is still in use by another VM, then it will remain active - so this also comes into play of why VBK may grow. For example, a block was similar between 2 VMs and so got deduped, but then it changed in one of these 2 VMs - so both original and new block must be saved, which effectively grows the VBK file. Thanks!
-
- Enthusiast
- Posts: 33
- Liked: never
- Joined: Jun 09, 2010 11:16 pm
- Full Name: Brian Kellogg
- Contact:
Re: forever incremental vbk size
Thanks that makes sense...
But I also believe when a vib is converted to a vbr that no compression is being applied therefore the vbr file is much larger than a "normally" created vbr file. The compression ratio on all converted vib to vrb files shows 100%. The vbk file grew from 140GB to 300GB as well which still seems odd to me as when using reverse incrementals the vbk file size barely grew over three months. No new data had been added to the VM besides logs and normal Exchange processing stuff.
Just wondering if I'm reading this right and if this is working as intended? Thanks...
But I also believe when a vib is converted to a vbr that no compression is being applied therefore the vbr file is much larger than a "normally" created vbr file. The compression ratio on all converted vib to vrb files shows 100%. The vbk file grew from 140GB to 300GB as well which still seems odd to me as when using reverse incrementals the vbk file size barely grew over three months. No new data had been added to the VM besides logs and normal Exchange processing stuff.
Just wondering if I'm reading this right and if this is working as intended? Thanks...
-
- Chief Product Officer
- Posts: 31775
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: forever incremental vbk size
If you send us full logs, we will be able to tell if everything is alright with backup storage, compression ratios and if everything is working as intended.
-
- Chief Product Officer
- Posts: 31775
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: forever incremental vbk size
Brian, based on the log files you have provided, devs confirmed that currently there is an issue in the code which can cause unexpected VBK growth during transform operation. The issue will be addressed in 5.0.1 release scheduled for the end of this month. Thanks for catching this!
-
- Enthusiast
- Posts: 33
- Liked: never
- Joined: Jun 09, 2010 11:16 pm
- Full Name: Brian Kellogg
- Contact:
Re: forever incremental vbk size
Cool; thanks for the excellent support yet again!
Who is online
Users browsing this forum: Bing [Bot], mdippold, Paul.Loewenkamp, Semrush [Bot] and 77 guests