.vbk file size

[marius roma]

I've been using VEB for some weeks and it looks really usefull.
I'm suggesting to use it to coleagues and friends.
Let me ask a question about .vbk files: I see that my .vbk file slowly increased it's size during the time, even if I've started measuring the size exactrly only some days ago and up to now I've not collected relevant data.
Should I expect that the size can decrease as soon as old files are removed from the backup?
Is it an automatic process or should I do anything?
Regards
Marius

[Dima P.]

Hello Marius,
When full backup is merged with the increment, the size should be reduced. Its handled by the retention mechanism of the Veeam Endpoint Backup.

[marius roma]

I made a test while looking at the size of the .vbk file on my USB drive for a long time.
Even after removing large folders from the backup and waiting for many days the size of the .vbk file never decreased.
Maybe the resons is that on the USB drive there is not anough free space to create a new .vbk file before deleteing the old large one?
Regards
marius

[Gostev]

Dima is not correct. VBK size can never reduce in size (no modern file system supports file shrinking). However, since unused blocks are reused by the new data, VBK will not be growing forever either (unless source data size is growing, which is almost always the case with endpoints anyway). Thanks!

[Epaminaidos]

(no modern file system supports file shrinking).

This is just wrong - at least for Windows. MS-Sqlserver can truncate existing multi-GB instantly - and has been doing so for at least 10 years. E.g. it truncates a 10GB-file to 5GB in less than a second.
It's very unfortunate that Veeam does not use this feature IMO. I do currently have a 1TB-vbk that contains less than 200GB of data.
How did that happen? I did some video-editing with my action-cam-footage, which generated about 800GB of temporary data. Unfortunately, this went into the backup. The 750GB are long gone now and I would like to keep a longer backup-history again. Having a huge 1TB-VBK prevents that, since the backup-disk is almost full.
My only option is to delete the backup and restart from scratch. It's surely possible, but not convenient.

[Dima P.]

Hi Otto,
Thanks for sharing your thoughts!

My only option is to delete the backup and restart from scratch. It's surely possible, but not convenient.

In upcoming release, we will have an option to schedule Active Full backup, so it will be possible to start a new backup chain automatically per the job settings. That should help.

We also plan to include compact option (the one from VBR backup job settings) but that’s not going to happen soon due the complicity of this feature.

[Epaminaidos]

Thank you for the quick reply. Starting a new backup-chain would create a second vbk and delete the old one after some time, wouldn't it?
This would not really help a user running low on backup-space, since he would now have two vbk-files.

And I am not sure that a "compact"-feature is really that complex. The vbk-file does probably use some internal storage-system anyway that keeps track of free blocks. All there is to do is to move all the used blocks to the beginning of the file and truncate the unused part after that.
Doesn't sound too complex to me

I just had to throw away the whole backup and recreate it from scratch within only 6 months of using Veeam because of the lack of this feature.
I am fine with having a shorter backup-chain when I run low on backup-space (would be even better if Veeam managed this automatically). But as soon as files are deleted on the source-drive, I would like to have a longer chain again.

How do you deal with this kind of issues in a corporate environment?
I am currently thinking about deploying (and buying) Veeam for about 100 computers - and I do certainly not want to shrink vbk-files manually for 100 machines...

[Dima P.]

Hi Otto,

Its complex in terms of implementation and testing

I do certainly not want to shrink vbk-files manually for 100 machines

As I said before, periodic active full might solve this problem. For instance, in v2 you can set active full to be created on a monthly basis, that would not require lots of storage and will rebuilt full backup from scratch. Another solution that might help is to use a repository with deduplication enabled (for instance, Windows 2012R2 server with deduplication). Good deduplication ratio, specifically when you are backing up identical OSs

[Epaminaidos]

Hi,
I just found your answer.

As I said before, periodic active full might solve this problem. For instance, in v2 you can set active full to be created on a monthly basis, that would not require lots of storage (...)

Doesn't it take about twice the space of a normal backup?

I'm still a bit sad that nobody seems to have the time to implement truncation of the vbk.
But I should not complain too much about a free product