Comprehensive data protection for all workloads
Post Reply
opg70
Influencer
Posts: 24
Liked: 3 times
Joined: Oct 06, 2013 8:48 am
Contact:

Possible DR approach (not realtime)

Post by 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
Product Manager
Posts: 20415
Liked: 2302 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Possible DR approach (not realtime)

Post by 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
Influencer
Posts: 24
Liked: 3 times
Joined: Oct 06, 2013 8:48 am
Contact:

Re: Possible DR approach (not realtime)

Post by 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.
VP, Product Management
Posts: 27377
Liked: 2800 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Possible DR approach (not realtime)

Post by 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
Product Manager
Posts: 20415
Liked: 2302 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Possible DR approach (not realtime)

Post by 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
Influencer
Posts: 24
Liked: 3 times
Joined: Oct 06, 2013 8:48 am
Contact:

Re: Possible DR approach (not realtime)

Post by 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
Product Manager
Posts: 20415
Liked: 2302 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Possible DR approach (not realtime)

Post by 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.
Post Reply

Who is online

Users browsing this forum: Bing [Bot], FrancWest, Google [Bot], Semrush [Bot] and 72 guests