I've searched around this forum and can't seem to get any ideas on this:
I have a VM guest where the VMDK size is 350GB and there was about 300GB used space. Naturally the backup size would be 300GB or a little under.
I deleted around 250GB of data (and yes, I emptied the Recycle Bin), so now the used space is around 50GB in the 350GB VMDK, so naturally, a full backup should now be around 40-50GB. The problem is, that the backup size is still over 300GB, so it seems that it is backing up a whole load of zeros and not compressing it/removing the zeros accordingly???
1. Please go to "backups" node of B&R console and take a look at properties of your VM. What is the compression ratio? Deduplication ratio?
2. When you delete data inside your guest OS, normally it doesn't get wiped from disk. The blocks which were occupied by data were just marked as 'free'.
From the point of view of B&R, almost nothing was changed in VM's image, that's why you're still getting that size. As a workaround, I would recommend you to run any utility which can fill unused disk blocks with zeroes. As the result, B&R will skip that blocks which will lead to smaller backup.
Could you please clarify if we are talking about just initiated full backup (after removing 300GB of used data) or you're comparing the size for the old one?
You can use sdelete for that. This utility wipes unused blocks with zeroes, making the blocks zeroed so that Veeam Backup can drop those from processing. Remember that deleting a file in NTFS only updates file allocation table records, but does not wipe content from disk blocks backing the deleted file. Other file systems do wipe the blocks (for example, Linux ext3 file system).
So Veeam doesn't actually check if the block is in use on the file table (the MFT in windows). That explains one of our backups where 10GB - 12GB gets deleted then added every night.
Is there a lighter program than sdelete that will give similar results in Veeam but not perform DOD level deletes?
sdelete is very light-weight, does single-pass wipe and works really fast (just use it with -c key, this was specifically designed for virtual machine disks wipe).
Generally speaking however, there is little point in doing this. It is hard to imagine server workload where files are only deleted, there is no such application or use case in the world. In more real-life scenarios, at least in server world, blocks backing deleted files are almost immediately reused by new data. Actually why server world only - I do see the same on all of my desktops too... constantly running out of disk space. So, why worry about wiping at all?
Moreover, arguably wiping does more bad than good in many cases. As it was explained above, if you delete a file, this does not touch the content of disk blocks backing the file. So, CBT will not see any changes and reversed incremental backup size will be minimal. But as soon as you wipe guest, it introduces those changes to disk, makes CBT pick up changed blocks, which only slows down incremental backup run because of increased VRB size. But just a few hours later the content of those wiped blocks gets stuffed with the new data, and CBT picks up the same blocks yet again. So whether you are using reversed incremental backup mode, or regular incremental backup mode with transform - you have just increased your backup window for no good reason...
The tool is still useful in some cases though. I am using it to prepare tiniest possible VMware Workstation images so that I can share them more easily.
Create VM with thin disks > Install OS > Defrag guest > Wipe guest > Shrink VM
When backing up Linux the whole drive, not just the data is being backed up. So, instead of 9 gig of data it is backing up the whole allocated 250gig virtual drive! This is taking absolutely ages so does anyone know why and if we can change this please? With our Microsoft drives it's only backing up the data and nothing else!
Most likely your Linux box is full of "dirty" blocks, which are treated as occupied ones. You should wipe unused blocks with zeroes to make this VM backup faster.
