How to make vDR 'redundant'??

[tlyczko]

We're using vDR 1.2.1 (whatever is the newest version) to back up several important small VMs.

vDR backs them up to a network share with its own IP address.

vDR has been running several weeks now, so it's quite fast now and a lot of incrementals have built up etc.

How can I make vDR be redundant such that I have two local vDR backups that are as alike as possibly can be??

We'd like to have two locally redundant backups -- ideally one mirrored from the other -- but any solution will do toward having two local vDR backups that are as alike as possible.

Then we want to back up one of the locally redundant copies to an offsite NAS -- this remains to be tested.

Overall we went locally redundant vDR backups, either one of which could be used for a restore, one of which could be backed up offsite somehow.

Do I make vDR back up to 2 different NFS datastores??
Do I rsync the vDR backup to another NFS datastore??

Ideally we want to be able to recover from either locally redundant vDR backup.

Thank you, Tom

[AndreTheGiant · Accepted solution]

Using two destination could be a simple solution...

But also a rsync may work, if you be sure that datarecovery service is stopped during this replication.

Andre

[tlyczko]

Hi Andre,

You got mass points because I hit "Correct answer" instead of "Reply."

Anyway, can anyone comment if I have two destinations, I imagine the destinations' backup contents would be slightly or quite different but the restore from either destination would produce the desired result of the exact same VM??

With two destinations and one vDR appliance, I'd have two backups, one to each destination??

Regarding your rsync comment, what data recovery service are you talking about?? I don't see one within our vCenter server. Where is it??

Thank you, Tom

[DSTAVERT]

I don't know what the issues might be but I would do some testing before even considering implementing this. Since this relies on change block tracking I can't imagine two vDR appliances being able to use the same cbt file. You probably wouldn't want to have them fire off at the same time against the same VMs.   rsync might be a safer way to do this but again I would do some testing. Actually I would test anything before implementing it simply to understand what issues you might encounter.

[DSTAVERT]

Regarding your rsync comment, what data recovery service are you talking about?? I don't see one within our vCenter server. Where is it??

You would want to shut down the vDR appliance or shut down the service from within the appiliance before running rsync

[tlyczko]

Thank you, good points.

I was thinking one vDR backing up to two different NAS boxes, separate backup jobs.

I understand the backups might not be "alike," but the restore from either backup should be "alike," leaving aside any 'time differences'??

Regarding rsync, thank you for clarifying, is this done to keep the vDR appliance from changing anything, to cause the vDR data to be "at rest" while the rsync is happening??

Thank you for mentioning testing...easy to forget this...

Thank you, Tom

[DSTAVERT]

The virtual machines don't end up being single files in the backup disk but rather a whole lot of pointers to bits of data (not a particularly technical description of the disk layout but . . .). Anything out of place may render the disk worthless.

CBT is a record of the changes since the last vDR backup run. As a block is changed in the VMDK file it is also written to the cbt file. There is a performance penalty since there are two writes for every change. I don't know if there are two backup jobs of the same VM if there is a second cbt file or not. Haven't tried it and since if there is a second cbt file there would be a a penalty for both files and I for one would not want that extra penalty. I am going to see what happens since I don't even know whether it is possible. 

[tlyczko]

I know the VMs are not single files and that between two separate backups from one vDR appliance to 2 different destinations the multiple files comprising the backups would not be alike between the destinations.

However since the vDR is backing up the SAME virtual machines – a restore from either destination should give the same result – intuitively this is my first thought.

I can’t speak to the penalty etc. since both backups I don’t see occurring simultaneously, though they probably could if one wanted to. I’m okay with the backups 15-30 minutes apart.

I appreciate your additional and wise thinking about this.

Thank you, Tom

[DSTAVERT]

The penalty I am referring to is the change block tracking file. The CBT file is created when you set up a VM for backup with the vDR appliance. Once the first full backup is created only the changes are recorded by the vDR. The VMDK file for your VM will have a cbt file that records the same changes that are written to the VMDK.   The documentation suggests that it is possible to backup from two vDR appliances although the context of that reference isn't about how to do it but that it may be the result of a mistake.

[tlyczko]

I don't know what I am doing to confuse things etc.

I don't want two vDR appliances.

I want one vDR appliance backing up the same data to two different destination datastores...probably as separate backup jobs.

I must test this but this should result in a successful restore from either destination datastore, provided the vDR appliance is working properly.

I use vDR to back up three VMs because esXpress can't yet cope well with two of our VMs that vApps and it can't back up its own phd-backup appliance.

I'm pursuing this same topic/idea on the phdVirtual forum.

Thank you, Tom

[DSTAVERT]

It doesn't matter whether there is one or two vDR appliances. The CBT file is used to track changes. If a new cbt file is created by each job fine. If not the cbt file will not match the changes that have occurred since the last individual vDR backup job.

[DSTAVERT]

The CBT file is NOT the vDR destination disk. It is in the folder with the VM.

[DSTAVERT]

It does appear that there is a CBT file created for each backup job so there shouldn't be an issue with doing the backup twice. There is however the write penalty since there will be three write operations per block change on the VM between backup jobs. If the VMs are very active it may have a noticeable effect.

[rtnewton]

I think you are better off getting a second NAS and having a hardware solution that replicates from one NAS to the secondary NAS. There are solutions in the marketplace of NAS that provide that capability. We do that. Our entire VDR Store is replicated.