Replication Question

[Reimold]

Hello,

we are still evaluation Veeam Backup and while testing the replication the following question came up:

is it possible to use multiple Datastores for a replicated VM on the target server ?

We would like to repliacte a vm with 5 disks (each located on its own datastore) to a target-server wich does not have enough storage available on one single datastore.

Thanks

Dirk

[Vitaliy S.]

Hello Dirk,

Unfortunately, multiple destination targets are not supported in the current version of Veeam Backup and Replication, thank you for your feedback.

[darrellarbaugh]

I love the backup and replication product. As an engineer that has implemented both Veeam and Vizioncore, I have to say, the Backup and Replication product is very well designed. I agree that there needs to be an option for multiple datastores at the destination datastore level. Ideally it would be like VMWare converter, where you can choose advanced configuration of vmdk destination. Presently, your option for a VM with more than 2TB in use, would be to use an extent to create a datastore larger than 2 TB and replicate to that. In my opinion, this creates a performance deficiency.

In the current climate of data storage, archiving, etc., this feature would certainly be helpful. Is this functionality currently on the road map, or whiteboard?

[Gostev]

Hi Darrel, yes we definitely do keep this feature in mind for the future releases.

[tsightler]

Do you think it's possible to work around this limitation, for example with a symbolic link or something? I've never tested this, but might try it just to satisfy some curiosity. Perhaps even an NFS datastore with symbolic links pointing to two different VMFS datastores.

[Gostev]

Tom, I don't think NFS can have symbolic links to VMFS datastores - only to other NFS datastores.

[tsightler]

Well, I can certainly create symbolic links on the NFS datastore to the VMFS datastore, but I don't know it would work to trick replication.

[tsightler]

OK, so it looks like in a pinch you could use symbolic links with Veeam replication to replicate to two different datastores. I just tested this using a Windows 2003 VM, will call it "TESTVM", with two VMDK disks, a 20GB C: Drive, and a 50GB D: Drive that was replicated to our remote site with Veeam. When I started the entire VM was on a single VMFS datastore which we'll call DATASTORE1. I logged in to the replication target host (a full ESX 4 host) and simply use the 'mv' command to move the the VMDK file that hosted the C: drive to another VMFS datastore, DATASTORE2 using these steps:

First I created a directory on DATASTORE2 with the same name/path as Veeam was using on DATASTORE1.

Code: Select all

# ls -l /vmfs/volumes/DATASTORE1/VeeamBackup/
drwxrwxrwx 1 root root 2520 Feb  4 13:14 TESTVM(vm-12118)
# mkdir -p "/vmfs/volumes/DATASTORE2/VeeamBackup/TESTVM(vm-12118)

I did this more for consistency than anything as I suspect you could put the file anywhere.

Second, I moved the VMDK from DATASTORE1 to DATASTORE2 and created a symbolic link:

Code: Select all

# cd "/vmfs/volumes/DATASTORE1/VeeamBackup/TESTVM(vm-12118)"
# mv TESTVM-flat.vmdk "/vmfs/volumes/DATASTORE2/VeeamBackup/TESTVM(vm-12118)/."
# ln -s "/vmfs/volumes/DATASTORE2/VeeamBackup/TESTVM(vm-12118)/TESTVM-flat.vmdk"

That's really it. I ran a replication and it worked, the vbr is still created on DATASTORE1, the TESTVM-flat.vmdk is updated on DATASTORE2, and the TESTVM_1-flat.vmdk, which I left on DATASTORE1, still get's updated as well. I preformed a test failover and the snapshots work (both created on DATASTORE1) the VM powers up, and both drives are accessible. Reverted the failover, and ran another replication, everything was good.

Admittedly in this case the initial replication still had to fit on a single datastore, I'm not sure what you would have to do to preform the initial replication to two or more datastores (for example if you didn't have enough space on a single datastore to hold the VM). My guess is you could start a replication, then abort it, move the VMDK files you need to another datastore, create the symbolic links, and restart the replication to finish, but I'm not 100% sure this would work. You could also preform the initial replication using the "removable storage" option and then you can put the VMDK's wherever you want on the target side.

Anyway, this was just something I tried just to play with it. It seems to work, but I'm sure it's not supported by Veeam, and I certainly don't support it, so if you try it, and it breaks your system, you get to keep the pieces.

[Gostev]

Neat trick I think there is typo in the ln command above (source file missing)?

[tsightler]

Which command do you believe is wrong, I'm not seeing it? I "cd" to the source directory before running the "mv" command, the "mv" command has the source filename and target path, and the "ln" command defaults to creating a link in the current directory with the same name as the linked target. It all looks right to me.

[Gostev]

Nevermind, I thought ln has to have 2 parameters (ln -s file1 file2), I did not know it has this default behavior when only 1 parameter is specified. This command was not clear to me (without knowing these ln specifics), but now I understand.

[sixpack]

This is a cool trick, but it's not going to work in our case, where there isn't enough space to first copy over the whole VM. If there was we could just replicate the whole thing over then move the .VMDK's manually then re-add the disks and re-create the replication job.

Just to put in context it is a Exchange server which has to have its databases and log files, etc on different physical disks for performance.

If you could add this as a supported feature it would be more than greatly appreciated.

[tsightler]

I think you could probably work around the "not enough space for initial replication" issue easily enough, but I haven't tried it. I'll try to give it a spin later this week, but the idea is basically:

1. Assume you have an Exchange server with 3 VMDK files for OS, LOGS & STORE.
2. Determine which VMFS volume has enough space to replicate the largest VMDK file, typically the STORE
3. Create a "replication" job that excludes the "STORE" VMDK and replicates only the OS & LOGS VMDK files
4. After this initial replication completes, move the OS & LOGS VMDK files to an alternate location and create the symbolic links
5. Modify the replication job to no longer exclude the "STORE" VMDK, and run the replication again. This will update the OS & LOGS VMDK's in their new location, and now replicate the STORE VMDK

I haven't tried this, but I believe it would work. I agree that Veeam should add this as a feature though.

[darrellarbaugh]

Any idea on how far in the future. Is it on the roadmap for a near-future release? Say 4.1.2

[Gostev]

No, it is not in roadmap for 4.1.2