Remove clients from a backup but VBK file never shrinks.

[tsightler]

Just a small correction, if you setup an incremental job with a synthetic full with transform every day, the result on disk is the same as a reversed incremental. And yes, this would have the same issue, freed blocks would eventually be reused, but the VBK file would never shrink.

[eiskra]

Right - I meant with transform.

And thanks for the confirmation.

[KarlW]

Hi there,

We have a very large environment and VMs come and go as customers get new servers and old ones are decommisioned.
It has come to my attention that when excluding VMs (after they've first been included in the job) and then deleting the VM Backup from the backup file, the space isn't freed.
On the other hand this was way back in 6.0 and it might have changed in the new version.

I've excluded a couple of VMs, and also deleted them from the backup file, but still no disk space is freed.

Any suggestions on what to do? Making the job a new is a tough one, because we have based our jobs on Datastorages (there might be a better way though).

Any little tip for a relativly new admin in Veeam would be appriciated.

[Enden]

Hi,

I have a bit of trouble with disk space in my lab repository. Right now I have about 5 GB free space and no budget to increase this. Since this is my lab it's not really critical to protect all VMs, and I removed one 600 GB VM from all backup jobs expecting disk space to eventually being freed up. That's not happening. Is this by design, or am I missing some setting?

My retention policy was set to 14 days, but I lowered it to two days a week ago. I also set retention policy for deleted VMs to 1 day, but still no result. I'm backing up using reversed incremental backups. What is the correct procedure to remove data from the repository?

[Enden]

Well, reading this thread more or less cleared that up

Thanks for merging admin/mod!

[Ingo]

Hi all,

I have a problem with my reversed-incremental-Backup, the size of the Reversed-Incremental-VBK is 1432 GB, if you perform an "normal" full-backup the size is 854 GB. Is there any trick to reduce the size of the reversed-incremental-VBK without performing an active full backup?

Thanks in advance,

Ingo

[foggy]

Ingo, please read through this topic to get better understanding of the nature of your issue. Basically, it is explained by the fact that NTFS not actually removes data on its deletion but rather marks all the blocks belonging to deleted data as unused so that they could be reused by some other data. The only way to reduce the size of the file is to recreate it from scratch without writing the unneeded blocks (i.e. perform an active full backup).

[cparker4486]

This thread has been very informative but there's something I'm not 100% clear on yet.

Does an active full create a new and independent backup chain?

If so would that mean the following is safe?

1. Copy existing VBM, VBK, and VRBs to secondary storage.
2. Delete copied files.
2. Run Active Full job which will create new VBM and VBK backup chain on primary storage.

In other words, the new VBM and VBK files have nothing to do with the old files and B&R doesn't care that the old files do not exist when the Active Full is run.

[foggy]

Does an active full create a new and independent backup chain?

Yes.

In other words, the new VBM and VBK files have nothing to do with the old files and B&R doesn't care that the old files do not exist when the Active Full is run.

Yes, this is correct in case of an active full (not so in case of incremental run, unless you have the ForceCreateMissingVBK key set to 1).

[HJAdams123]

Hello and Good Day Veeam Community...

My organization runs reverse incremental backups. We don't do any periodic fulls or synthetic fulls. Also, I am using Veeam B&R version 6.5. Hypervisor is Vmware ESXi 5.1. Now, I am certain I read somewhere that as information is deleted from a virtual machine, that data is never truly removed from the VRB file. So what happens over time, you have a bloated VRB because it still has blocks that no longer exist in the current virtual machine. Is that correct? Assume that for space and other business reasons, I can't run period fulls or synthetic fulls. Is there a utility I can run that "compact" my full recovery VRB to make it smaller?

Thanks!

Harold

[foggy]

Harold, you are correct regarding the deleted data behavior, however, the only way to reduce the size of any file on NTFS is to recreate it from scratch (and this is what active full actually does).

[HJAdams123]

Thank you for the clarification. I would love to implement active\synthetic fulls in my backup plan, but don't have the space to keep more than one full backup at a time in most cases. I think if we looked at something like Data Domain as a backup target along side Veeam, the prospect of having multiple fulls in place is not as daunting. (Data domain has global dedupe and dedupes inline.) Thanks for the feedback

[veremin]

While thinking about Data Domain implementation, kindly see these general recommendations regarding DD usage in conjunction with Veeam; might be helpful.

Thanks

[foggy]

Though you cannot perform periodic active fulls, you still could run sdelete on the VMs to mark all the blocks belonging to deleted data as free, this won't reduce the VBK file size, but these blocks could then be reused by some other VM data. Just note that doing so for thin disks will expand them.

[tim5700]

I am running Veeam B&R 6.5 to backup my VMware environment. I have a regular backup job that is set to backup all my VMs. The job is set up as a "reverse incremental" with 20 rollbacks. When I first started running this job, the resulting full backup file was about 1.1 TB. However, several months later, the full backup file is now 2.1 TB. Is there a way to shrink this file?

[nefes]

Please review this topic: Remove clients from a backup but VBK file never shrinks.
It should answer your questions.

[yizhar]

Hi.

I also suggest using several jobs with fewer VMs each, vs a single large job.
Having several jobs gives you more flexibility and mobility, with smaller VBK files for each job.
You can backup large data servers (files/mail server) in a single VM per job method, while other small servers (DC/TS/etc) using multiple servers per job.

Yizhar

[foggy]

I am running Veeam B&R 6.5 to backup my VMware environment. I have a regular backup job that is set to backup all my VMs. The job is set up as a "reverse incremental" with 20 rollbacks. When I first started running this job, the resulting full backup file was about 1.1 TB. However, several months later, the full backup file is now 2.1 TB. Is there a way to shrink this file?

Basically, you can try to recreate the backup file from scratch by running active full and see whether this will reduce the VBK size.

[eandry]

Hi everyone,
best wishes for 2014 !

Something strange with Synthetic full with previous backup rollback : I had a backup job with 6 VM and a tape job backing up the vbk everyday. Since the vbk grew up rather quickly, I decided to remove 3 VM from the job and create another one for them (without tape backup).
Doing this, I thought that the vbk would have been smaller because it would contain only 3 VM... But it remained the same size (and keep growing)

So, isn't the vbk file supposed to contain only the last backup data ? Is it a bug or something I misunderstood about vbk/vrb ?

Thanks for your help.

[Gostev]

Happy New Year Emmanuel. You should run the Active Full backup on the job, please review this topic for more details. Thanks!

[buwprof]

Hi All,
Happy new 2014!

I have a similar Problem, it's related to available Space on a "removable" Media ...

First of all. Veeam Implement a Shrink feature for your Backup Files. This is a very needed feature. And do NOT stop COPY Jobs on a given time, just let them finish a VM or delete that VM from COPY VBK and truncate the File!

Ok, here are is a scenario which i had some days ago.
You have:
One Backup Repository and a "removable" Backup repository like a USB Media, lets say 2TB

You Backup VM's each day (Backup Size ~1.4 TB FULL). And have copy Jobs to copy every days restore point to removable Media.

Everything is fine. Except this one...

You have a Machine like a File Server in your Backup with around 600GB.
Now you have a Copy Job which starts right after the Backup Job (FULL Backup, as of some reasons this took quite more time as expected).
After this Full Backup a Copy Job is running from 00:00 till 23:59, then it gets stopped and restarted.
The Copy of the File Server has done around 450GB of Data into the VBK File and was aborted. So it is INCOMPLETE!
Next Copy Job runs from 00:00 and restarts the Server copy (because it's incomplete)
Now you have a VBK File with 650GB and a VIB with 1.1TB = 1.7TB but only 1.4TB worth of Data to restore...

Just correct me if i am wrong...

[Vitaliy S.]

Hi Thomas,

Happy New Year to you too!

Now you have a Copy Job which starts right after the Backup Job (FULL Backup, as of some reasons this took quite more time as expected). After this Full Backup a Copy Job is running from 00:00 till 23:59, then it gets stopped and restarted.

Yes, your argument is understandable, but the backup copy job does initial sync only once and then transfer only changes, so it shouldn't take much time to transfer changes, right? Am I missing something?

P.S. btw, resume option is available when you're transferring data over the WAN link using WAN Accelerators

Thank you!

[veremin]

You might want to consider seeding the backup files first; so that, only changes will be transferred during initial run. Thanks.

[breakaway]

I've gotten into a situation where my backup repository is 100% full (only a few KB left). To free up some space, I wanted to delete some VMs from my backup so I right clicked and selected "Remove from Disk" on the VMs in question. The process completed successfully, but no space has been freed up in the backup repository!

The backup job type is a forward incremental with periodic fulls every weekend.

Does Veeam require free space on the volume before it can actually delete VMs out of on-disk backups?

[Vitaliy S.]

Remove VM from backup does not physically deletes VMs, it marks VM blocks as deleted in the backup, so next time you run the job it will re-use these blocks for new data (in case of reversed incremental mode). If you want to free up some space on the repository, you need to adjust the retention policy settings and run the job.

Can you please tell me what is the retention policy set on the job, and how many files you have on your repository?

Also in order to be protected from these situations in future, I would suggest using Veeam ONE that will inform you on low free space on the repository and has a predefined report template for planning capacity of the repository.

[foggy]

The space should be reclaimed after a new active full. Since you seem not to have enough space for it, probably it is worth deleting some older restore points manually.

[masonit]

I understand that this problem has to do with NTFS. Is there the same issue with ReFS?

\Masonit

[Vitaliy S.]

I don't recall any method of shrinking file on the fly on ReFS.

[iwik]

Remove VM from backup does not physically deletes VMs, it marks VM blocks as deleted in the backup, so next time you run the job it will re-use these blocks for new data (in case of reversed incremental mode). If you want to free up some space on the repository, you need to adjust the retention policy settings and run the job.

Can you please tell me what is the retention policy set on the job, and how many files you have on your repository?

Also in order to be protected from these situations in future, I would suggest using Veeam ONE that will inform you on low free space on the repository and has a predefined report template for planning capacity of the repository.

I would like to have some option to run some "maintenance" task which will shrink (rebuild) existing vbk file, because if I'm out of space to store another full backup (produced by active full), what else I can do?

[foggy]

Remove some older backups manually to free some space up.