Backup size larger than

[siziegler]

Hello

I am backing up a VM with 100 GB HD size using VEEAM 6.5. Inside the guest OS (Server 2012) I can see in Explorer that 27 GB of 100 GB is actually used. Interestingly an active full backup of this VM reports:

Size:100 GB
Read: 59.9 GB
Transferred: 49.3 GB

How is it possible that there is more data transferred than what is actually shown in the guest OS? I have two more VM's that behave correctly, means less data is transferred than what is see in the guest OS (also Server 2012).

-Silvio

[Vitaliy S.]

Hi Silvio,

Most likely you already had some data written on this disk before, that's is why Veeam has to read 59.9 GB of data. Please be aware that with NTFS, when you write data to the disk and then delete it, the data doesn't actually get removed from the disk, so virtual disk blocks still contain the same dirty data blocks. If you want to make your full backups smaller, then you should sdelete your virtual disks. Please search these forums for existing topics describing how to use this utility.

Thanks!

[siziegler]

sdelete -z did the trick! Thanks for quick reply.

-Silvio

[veremin]

You’re welcome. Should any other questions arise, don’t hesitate to contact us. Thanks.

[BogBeast]

Hi, I am new to VEEAM, I am dabbling at home prior to getting the 'proper' test environment going at work.

I am targeting my virtual WHS 2011 (server 2008R2 really) for backup and using the Exclusions button to only select the first two disks for backup (the remaining 3rd has data on I don't need to backup).



The disks are a thick 60GB boot with 28GB used + thin 500GB with 65GB used.

Have done that and clicking recalculate I end up with a large figure that:

- Does not match the size of the two disks I want to backup.
- Does not match the size of the whole VM (VEEAM report 795GB - my calculation is 642 for all the data on all the disks)

Ignoring that, I go ahead and compete a backup and end up with file on the repository that is 213Gb and a log:



It seems to have detected the correct sizes of the two disks to be backed up (561) but some how has read 285GB from 96GB on the disks

If I go to restore the VM files i can see the correct files are stored:



and If i do a file level restore I can see that only 96 is stored as files:



I must be doing something stupid to turn 96Gb into 213 in one backup (I have tried it a couple of times with different settings, both incremental and reverse) - can someone point me in the right direction ???

Many thanks...

[Gostev]

Same cause... dirty virtual disk data blocks belonging to the deleted files.

[BogBeast]

Thanks Gostev, I will try Sdelete, however the 500Gb was a newly created had disk so I am nor sure why it would have have data remnants in it.

[Dima P.]

Paul,

Please let us know about the results of the sdelete procedure!
Thank you

[foggy]

Please also keep in mind that running sdelete against a thin disk will inflate it to its maximum provisioned size.

[BogBeast]

Thanks for the advice. I am aware of the inflation issue, I decided to go with UberAlign

http://nickapedia.com/2011/11/03/straig ... uberalign/

Worked with no problem and seems to have done the trick on my backup sizes:



although the duration has gone up quite alot !

Many thanks...

[veremin]

although the duration has gone up quite alot !

I’m wondering whether CBT was used in this case or not – you can check it in the job statistics window, looking for “[CBT]” metric. Also, there is an existing discussion regarding similar issue; might be useful.

In addition, what about incremental runs – does VB&R still read the whole VM image or only the portion of data that is known to have changed since the last run?

Thanks.

[mrstorey]

Hi,

I'm new to Veeam and this forum so go easy on me!

I wondered if any of you knew why a recent successful full backup of a server has ended up larger than the apparent data stored on it?

ESXi 5.0 U1, vCenter 5.1, Veeam B&R 6.5, backing up to a Windows 2008 R2 repository using a reverse incremental job. This is the first, and therefore full backup.

Server in question is a 2008 R2 VM with 3 VMDK's / Disks:

C:\ - Size 40gb, Used 16.4gb
E:\ - Size 60gb, Used 46.4gb
F:\ - Size 836gb, Used 195gb.

Total Used = 257.8gb

But the backup report for the server gives me these figures:

Size - 937gb (Correct)
Read - 907.6gb (Hmm...why is this? Most of it is just empty space?)
Transferred - 553.7gb (Over double the used space)

My guess is that Veeam is 'seeing' some additional data which isn't showing in the OS - I've cleared the recycle bin, but can't see where Veeam is finding this extra data?

Any ideas? Happy to log a support call, but it seems most of the Veeam support guys live on this forum anyway!

Thanks in advance,
Alex

[foggy]

Alex, please review the topic you've been merged into for the answer. If you still have any questions, feel free to ask here. Thanks.

[mrstorey]

Aha - apologies. I didn't search the forums properly - apologies!

Will give it a whirl now, thanks.

[mrstorey]

Ok - looks like Sdelete Will indeed do the job....but unless I'm missing something, it highlights a potential risk which we'll have to think about managing - here's the hypothetical scenario I'm thinking...:

- I have a server, with a 500gb disk, 100gb is used.
- I defrag it, sdelete -z to zero it and take a nice efficient full backup.
- Someone comes along and writes 395gb data temporarily, and immediately deletes it.
- The next incremental is +395gb (although a bit less thanks to dedupe)
- Someone writes a different bunch of data and leaves it there
- The next incremental is again, +395gb

...and so on.....

The only way I see to mitigate this is to ensure users have don't use (or use Veeam to backup) VM's with large temp / scratch storage, or we risk filling our backup repositories with 'dead' data?

Have I understood this correctly?

[foggy]

Yes, your understanding is generally correct. However, I would say that this type of activity (copying and immediately removing large amounts of data) is not very typical. However, to avoid space issues in such cases you can schedule sdelete to reclaim unused blocks prior to running active full.

[mrstorey]

Ok great - thanks. Unfortunately these servers were originally built with large (and empty) vmdk's so I'm actually working to migrate the data to disks of more sensible sizes now we're using Veeam, and just increase them where necessary.

Although the scenario I detailed was an edge case with such large amount of data, I guess it feels strange to me that Veeam has no way of differentiating between linked and unlinked blocks of data. I can't see a scenario why we'd ever want to back deleted data up?

Maybe this could be a feature request for upcoming versions? What do you think?

Thanks for the advice - all very useful.

[veremin]

Hi, Alex.

As mentioned, this problem isn't something related to Veeam but rather to NTFS and the way the latter works with deleted data.

Thanks.

[foggy]

Yes, this comes down to NTFS design. Veeam B&R is a block-level image-based solution that cares only about changed blocks, but not their contents. If the block has changed (though it was then marked as free) since last backup, it will be backed up.

[mrstorey]

Absolutely, I understand - I don't want you to think I was suggesting it's Veeam's 'fault'. I just was thinking how we could overcome this operational drawback.

I guess this 'wouldn't it be nice if?' feature request wouldn't be possible to implement, since I imagine there's no way easy way to determine at a block level which was live data, and backup only the blocks which contained this live data.

....and I guess even if you could, it probably wouldn't create a backup that could restore an entire disk or virtual machine ..!

Thanks for all your help - much appreciated.

[foggy]

....and I guess even if you could, it probably wouldn't create a backup that could restore an entire disk or virtual machine ..!

You've got it exactly!

[mv43]

First full backup is 303GB of which the total disk space is 323GB and total used space is only 58GB!! All my guests are on local storage and this same server also has Veeam installed which has an iSCSI connection/volume to my NAS. None of my other guests have this issue.. any reason why this is happening?

[foggy]

Michael, please see the explanations given in this topic. Basically, the reason is most likely the dirty virtual disk data blocks belonging to the deleted files. Feel free to ask additional questions if you need further clarification. Thanks.

[rct]

Hi,

I have a problem with my backup size: it don't fit on my media.
I deleted about 500GB of data on a filer VM but the synthetic full has produced a vbk of the same size.

What will be the best thing to do to get the appropriate space?

Thanks
Romain

[dellock6]

Veeam is an image-based backup solution, not file based. So even if you delete files inside the VM the backup will still have the same size.
The only way to shrink backups is to first run sdelete inside the VM, move it into another datastore via storage vmotion and choosing to convert it to thin (or keeping it thin if it was already), and then run a new active full backup in Veeam.

Luca.

[rct]

Hello,

Thanks for your answer I had seen this kind of solution but it will be rather long for our VM (3.4TB of data) to do it :
- zeroing all the free space (dd here because on Linux)
- Create multiple VMFS3 datastores
- Storage VMotion disks individually with thin provionning
- Storage VMotion back to the initial VMFS5 datastore

I was looking to a easier solution :'(

Romain

[dellock6]

I should go and check to be sure, but as far as I remember from a certain version of vSphere you do not need anymore to jump from VMFS5 to 3 and back in order to shrink a thin disk, so at least it would be only 3 steps and not 4.

Luca.

[rct]

I'll check this and report it back for my version.

[rct]

Tested: I confirm that you need to have a datastore with different block size in order to reclaim disk space.
My versions: vCenter 5.1.x/vSphere 5.1.x.

And the theory: http://kb.vmware.com/selfservice/micros ... Id=2004155

[dellock6]

Thanks for confirmation, I was not sure as I said
Looking at the KB, you can also leverage vmkfstools without the need to have two datastores, obviously the cons is you need to power off the VM while with Storage vMotion you can do it live.
I really hope SE sparse disks will become more and more spread...

Luca.