V5 Reversed Incremental continues to grow

[kerskine]

We're using V5.0 with Reversed incremental for some time now. I back it up to a NAS, then copy the .VBK file to an external drive to take offsite. I noticed that the .VBK file was getting pretty big, so I cleaned up the drives on the Virtual server. But the next day the .VBK file got bigger again.

So over the weekend, I did a full backup to see how big it would be and it was substantially smaller so I'm pretty sure I must be doing something wrong.

The latest .VBK file is 527GB, the full backup file is 325GB.

So my (limited knowledge) question is: Is there a way to start the reversed incremental backups over without losing the last 14 days worth of restore points?

[Vitaliy S.]

Hello Kevin,

so I cleaned up the drives on the Virtual server

Could you please clarify where did you do this? Is this your backup server or target storage?

The latest .VBK file is 527GB, the full backup file is 325GB.

Have you used the same set of VMs in both runs? Have you removed/added VMs from that backup job by any chance?

Is there a way to start the reversed incremental backups over without losing the last 14 days worth of restore points?

Every Full run creates a new backup chain, though all previous backup files will still be intact. All your restore points (previous backup files) will be removed according to your retention policy settings.

Thanks!

[Alexey D.]

Kevin,

Here is further reading on VBK size:
Deletion of VMs if no longer present
Re: VBK Growth
Hope it helps.

[kerskine]

Sorry, I wasn't very clear.

We deleted old files off the file server (the one I'm backing up). Since a picture is worth a 1000 words, below is what gets written to our NAS device by the Veeam backup.

The first line shows the Fill backup I ran on 1/31. The last line is the latest Reversed incremental file. These are on the same server after data was deleted. Every night the bottom file gets bigger, even though the real disk size is only 321MB.

So, I guess my question is how do I make the incrementals go back down to the 321MB size?

[Vitaliy S.]

Thanks for the picture. But could you tell me what is the size of the source VM? In addition, as far as I see you have almost 30 GBs of changed data for each incremental run, so I guess you've got a lot of changes for this server.

Please note that each time you run disk defragmentation, move/copy/delete files, virtual disk blocks are relocated, thus meaning that all those blocks will be treated as changed ones.

The size of the VBK file shouldn't be more than the total VM disk size, though VBK size growth is expected as it is explained in one of the forum post links that Alexey has posted above, please have a look.

[tsightler]

Deleting files does not delete the underlying blocks. If I have a file system, and I fill it full of 500GB of compressed data, then back it up with Veeam, the VBK will be ~500GB. If the next day I delete all of the files from that file system, the filesystem will show having 500GB free, but if I run a Veeam backup, Veeam will still backup 500GB. Why? Because even though I deleted the "files" on the filesystem the blocks are still full of dirty data from those old files. Veeam only looks at the block device, so if it sees data, in a block, it will back it up, it has no idea whether the data is part of a deleted file or not, it doesn't even know what a file is.

So what's the solution to this? Use "sdelete" when you're deleting a lot of files. Sdelete doesn't just delete files, but also writes zeros to the blocks that the files are in. It takes much longer, but at the next full backup Veeam will skip the zero'd blocks (or at least compress them to basically nothing). There's also an option for sdelete to write zeros to the already free space on the drive (I think it basically just writes a big file of zeros until the volume is almost full, then deletes it). I believe someone posted a script on the forum that will use sdelete to do exactly that.

[kerskine]

Thanks, I'll look into sdelete.

As far as the size of the VM, it's pretty much exactly the size of the full backup file (327GB).

To me, the ideal situation would be to start a new backup chain from a new full backup. And that's possibly what would happen if I delete all the current backups, but I don't want to lose them for obvuious reasons.

[tsightler]

So just run a real full backp again and start the chain over, no requirement to delete the older ones. You can run a manual full backup of a job at any time which will start a new chain.

[vihag]

I thought sdelete was for security wipes of disks, but I've done some reading on it and it looks like that and a defrag will probably sort this out. Thanks!