Possible DR approach (not realtime)

[opg70]

Hello,

We're evaluating the possibility of using Veeam to replace our SAN replication, but with certain constraints - we would like to reduce the impact on our storage environment. Would the following approach be workable using Veeam?

- we backup with Veeam to a fast storage (reduced backup window, possibility to do fast restores and surebackup, etc.)
- backup gets copied to deduplication device (DataDomain DD2500 or Dell DR4100 with around 50TB of capacity)
- changes get replicated to second dedup device on the DR site - this should keep bandwidth to a minimum, since dedup devices have huge history of chunks so long term very little should be replicated over the WAN line.
- on the DR side, a script periodically checks the modification of the data on the dedup device and modifies a standby VM with the latest data

Has anyone implemented something similar to this?

The reasons we're thinking that using the replication function might be problematic are several fold:
- large numbers of VM's needing to be replicated
- low WAN speed (imposed) with high latency
- not wanting to snapshot storage environment several times (once for the regular backup, once for the replication - which can last a long time)

Any possibility this approach might work, or is there something better that might?

Thanks

[veremin]

The replica restore points are stored as VM snapshots, so, I'm not sure how the script will be able to address it. The script will take latest backup restore point from dedupe device, restore it, and then what? Thanks.

[opg70]

Well, the VM should be on standby until it is required to be activated (in case of failover, only if there is a catastrophic failure of the main site).

[Vitaliy S.]

If you're not going to use replication jobs, then all functions such as RE-IP, failback etc. will not be available in the backup console. As to the script, then I'm not sure how it should look like, comparing compressed and deduped VM image vs. a stand-by VM looks a bit complex to me.

[veremin]

Well, the VM should be on standby until it is required to be activated (in case of failover, only if there is a catastrophic failure of the main site).

The point was how you're going to merge incremetal deltas contained in the backup files into the replica VMs. Thanks.

[opg70]

We were told it might be possible to use scripting (http://forums.veeam.com/powershell-f26/ ... t4028.html) to restore the machine on the DR end. Though I'm wondering if it is really practical with many VM's - my guess based on your answer v.Eremin is that this is an unusual way to go about it (and not recommended).

Otherwise, the problem with using replication is that it uses the host SAN for its data sources, so it snapshots and then commits at the end of the transfer. Is that not correct? Which is currently proven problematic on our system due to the change rate and WAN performance. Also, it wouldn't take advantage of the deduplication devices bandwidth reduction. Basically, the dedup devices would just keep the backup data on the DR site but it wouldn't actually help with the DR itself as that data would be static and unused (unless we decided at one point to restore onto the DR SAN from it, but with many TB that will take a long time if starting from scratch).

[veremin]

We were told it might be possible to use scripting (http://forums.veeam.com/powershell-f26/ ... t4028.html) to restore the machine on the DR end. Though I'm wondering if it is really practical with many VM's - my guess based on your answer v.Eremin is that this is an unusual way to go about it (and not recommended).

Of course, it should be possible to restore given VM using PowerShell snapin. However, the problem will appear when you decide to insert incremental changes to already restored VM - the issue that I don't think can be addressed with the custom script. The only possible solution I can think of is to delete previously restored VM completely, and, then, start restoration procedure anew using the most recent restore point.

Thanks.