VDR - Reclaiming space on the destination

[Vodder]

We haev a1 TB disk attached to one of our VDR appliances, the free space has now reached 0. I have deleted a number of restore points by marking them for deletion and then running integrity check yet the free space is still 0.

I've read that this shouldn't necessarily cause jobs to fail as it works off "slabs" rather than just the amount of free disk space and that by removing restore points won't necessarily increase free space due to the way de-dupe works but I would expect some space to come back, no?

I presume reclaim should free up some space but so far it hasn't. Is it possible to run a reclaim manually? Or is there something else you can do?

[glynch42]

see this thread: http://communities.vmware.com/thread/257591?start=15&tstart=0

and this techdoc: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=102760...

I have hit the same issue, and also after following the above paths, I am getting error messages with tune2fs command.

("tune2fs: Bad magic number in super-block while trying to open /dev/sdb  Couldn't find valid filesystem superblock." That this is happening on both (unmounted) volumes, even though the second volume is accepting new backups from VDR just fine.)

I am interested to see what your experience with the above links is, and if maybe other members have more generalized advice for space issues with VDR. Are there other backup solutions we should be looking at? I see comments in posts from last fall that suggest that VDR is simply not mature enough to handle anything but small office datacenters. Is this essentailly an unfixable problem, and we should be away blowing these dedupe stores and starting from scratch with new ones? I also see comments from VMWare developers repeatedly explaining the same points about slabs and minimum block sizes, whcih all seems clear. Except that my deduplication stores fail to allow more backups even though I've marked tons of restore points for deletion and successfully run reclaim and integrity check operations.

[MKguy]

When the physically available free space on the filesystem reached about less 1GB, we ran into said issue and applied the tune2fs workaround. This worked for a few backups until we ran into the same issue again.

The "deduplicated size" value indicated that we should still have 80+GB free somewhere in those slabfiles that were occupying the filesystem, but backups still didn't work until we extended the dedupe store so it got more free space on the filesystem.

So after running into this twice (with the latest VDR 1.2.1), we finally opened a ticket with VMware support.

The bottom line is, they acknowledge the issue and already have an internal VMware Engeneering Bug number assigned and they will fix it with the next major version of VDR.

Until then, your only option seems to be extending the dedupe store manually. Another "workaround" would be creating a new dedupe store and backing up to there until this is full too, then wiping the previous store and rotating destinations like this.

[mdgunther]

In my experience, the reuse of space problem does not seem to be infinite.

I ran out of space a couple of times with one of my two backup destinations and, as described, deleting old backups didn't help.  So I ended up extending the size and reducing the number of backups kept.  That helped for a little bit before it filled up again.  I added more space and it looks like I have found a happy medium for the troublesome set.  It has been at the 30-40GB free range for well over a month.  The other set is around 80GB free and stable.

The first resize was thwarted by a VMFS blocksize limiting the VMDKs to 256GB.  I used svmotion to move them off, reformat, and move them back.

Initially with this problem I did start from scratch to clear everything out, but I quickly realized it was going to keep happening.  I've had to reformat once or twice since, but that's because the integrity check was consistently crashing the datarecovery process.  But that's a topic for another thread...

[Vodder]

Update - We opened a support request with VMware and was told that the current version doesn't correctly report "free" space and that even if it says full the drive could still have space available. This, I was told, had been listed as a future "feature request".

[glynch42]

Outstanding, thank you for the updates. Your experiences are enlightening.

More stores are clearly in order, but how many? I wish I knew the magic formula for X number of VMs of Y size over Z snapshots = 500Gb dedupe store. But now I feel like I have a handle on the process, and can optimize over time in a trial and error kind of way.

Thanks again, guys.

[quangspk]

hello,

I'm using VDR 2.0.0.1861 and i got the same problem.

Deleted backup (all backup locate on that destination) and then check integrity the that destination but the free space is not increase?

Help me!