Data Recovery full virtual machine or only snapshots ?

[sm4rtins]

Hi folks,

I'm really in doubt about it.

I've started a backup job with about 20 virtual machines, and after some time, when it finished I've checked the size ocupied by the backup.Then I get surprised because the entire backup size was only 64GB, and the total storage space occupied by all virtual machines is about 1TB.

So how can I perform a full vm backup ?

Example/Question : If I lost the entire datastore where my vm's are running(a really disaster), will I can restore my vm's with data recovery(with backups stored in other datastore) ?

regards,

sm4rtins.

[a_p_]

So how can I perform a full vm backup ?

The disk space used on the backup store depends on the deduplication ratio. If your VM's are e.g. running the same OS, the deduplication ration might be very high and the 64GB used disk space may be all that's needed. I'd suggest you take a look at the Restore tab (or the log files) to see whether the backup reports the correct size of the VMs.

Example/Question  : If I lost the entire datastore where my vm's are running(a really  disaster), will I can restore my vm's with data recovery(with backups  stored in other datastore) ?

Yes, that's actually the puropse of Backup and Restore.

André

[sm4rtins]

Thank you André.

I know deduplicantion can save a lot of space, but in this case I have 2 virtual machines with more than 200GB in their database(different data) each.
I've checked the restore tab and logs, every vm backed up shows the right size there.

Now I perform an integrity check and it has found damaged restore points.

Any sugestion ?

Thanks.

[PakChan]

Not sure about the damaged recovery points, but to provide some stats, my VDR appliance is currently storing 28.5TB of backups in about 505GB, yielding a compression ratio of over 98%, albeit with multiple daily/weekly/monthly backups of each server which increases the effective compression ratio. This is helped by standardising on a single operating system (Windows Server 2008 R2 SP1) for most VMs, though we do have a variety of Linux and older Windows VMs as well.

At the moment, adding a new VM increases the deduplication size by 0-2GB at most, which is much smaller than the "normal" monthly fluctuations in the deduplication size of our store (varies by up to 70GB - no idea why it fluctates so much). Even large databases seem to deduplicate well, though I would be slightly suspicious of 400GB of databases plus operating systems fitting into 64GB on the initial backup (depending on what the contents of the databases looked like).

[sm4rtins]

Yeah PakChan, that's the main reason to my question.Reading all the Data Recovery  Administrator Guide it was clear that vDR is a full vm backup solution.But I started to thing that I was missing something when I did the comparison between the virtual machines data size and the space ocupied by the final backup(considering dedeplication of course).Then after integrity check run just 5 of 20 virtual machiches have been backed up correctly, other vms was with damaged restore points.

The deduplication storage is nfs, presented by an esxi host, and then attached to vDR as a virtual disk.

I'm still getting damage restore points for the majority vm's after integrity check.I'll post any progress.

Any suggestion will be appreciated.

Thank's

[PakChan]

I'm not sure how much help I can be, given that my main experience with VDR is peppered with bouts of frustration. It could have been a reasonable product, but it seems to be crippled deliberately, and though version 2 is a lot more stable than than version 1.x (we're only experiencing corrupt restore points about once a month or so, rather than about twice a week), it's still making us nervous.

The only thing I would say is that we're using fast SAN storage for the destinations. VDR does appear to be sensitive to disk I/O speeds, and my hypothesis is that we get a corrupt restore point when the disk I/O on the SAN is high (the SAN is shared with about 40 VMs and several physical servers that use it for clustered database storage). We don't have the data to back up this hypothesis (still trying to get a handle on how I would get the I/O stats to prove this), but I can't really think of what else it could be (other than the product simply being buggy, which could be the case).

Could you move your destination store from NFS to a faster SAN, just to see whether the error rate drops?

[sm4rtins]

Thank you PakChan, sorry for delayed answer.

That's exactly what I did.Changing to a SAN my my problem was solved, no damaged points using a fast SAN.
Now I moved the backups from SAN to my NFS server(physical server)manualy, and then reattached the nfs to the vDR, and there was all my vm's backups.The problem is that I've runned the integrity check(now in nfs) and it found damaged points.

Now I'm trying to find the tricky to move from san to nfs(need to have a security copy there for a soon operation).

[PakChan]

Interesting. Is the NFS store on a quiet/dedicated gigabit network? That might also resolve your issue; it might be network traffic rather than disk speeds that is causing the problem.

As for the copy process, good luck with it.

Just out of interest, what were the figures in the SAN store after the successful backup?