Comprehensive data protection for all workloads
Post Reply
kerskine
Novice
Posts: 3
Liked: never
Joined: Sep 30, 2009 10:19 am
Full Name: Kevin Erskine
Contact:

V5 Reversed Incremental continues to grow

Post by 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.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: V5 Reversed Incremental continues to grow

Post by Vitaliy S. »

Hello Kevin,
kerskine wrote: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?
kerskine wrote: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?
kerskine wrote: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.

Re: V5 Reversed Incremental continues to grow

Post by Alexey D. »

Kevin,

Here is further reading on VBK size:
Deletion of VMs if no longer present
Re: VBK Growth
Hope it helps.
kerskine
Novice
Posts: 3
Liked: never
Joined: Sep 30, 2009 10:19 am
Full Name: Kevin Erskine
Contact:

Re: V5 Reversed Incremental continues to grow

Post by 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?

Image
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: V5 Reversed Incremental continues to grow

Post by 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
VP, Product Management
Posts: 6009
Liked: 2842 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: V5 Reversed Incremental continues to grow

Post by 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
Novice
Posts: 3
Liked: never
Joined: Sep 30, 2009 10:19 am
Full Name: Kevin Erskine
Contact:

Re: V5 Reversed Incremental continues to grow

Post by 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
VP, Product Management
Posts: 6009
Liked: 2842 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: V5 Reversed Incremental continues to grow

Post by 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
Novice
Posts: 9
Liked: never
Joined: May 17, 2011 3:34 am
Contact:

Re: V5 Reversed Incremental continues to grow

Post by 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!
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 210 guests