Comprehensive data protection for all workloads
Post Reply
hasayeretFMG
Enthusiast
Posts: 37
Liked: 2 times
Joined: Jun 16, 2017 1:18 pm
Full Name: Rotem Ben
Contact:

Onsite replications - why?

Post by hasayeretFMG »

Hi guys,

Currently we're running off hours backups with no replications.
We do not have a DR site at the moment and all of our production VMs, as well as our VM server are onsite.
Any reason to have a during-the-day replication jobs or any replication jobs at all since we're not replicating offsite or are we better sticking with our off-hours backups?
If the answer is "yes" then my next question would be: why during-the-day replications and not backups?

Thanks a million! :)
DGrinev
Veteran
Posts: 1943
Liked: 247 times
Joined: Dec 01, 2016 3:49 pm
Full Name: Dmitry Grinev
Location: St.Petersburg
Contact:

Re: Onsite replications - why?

Post by DGrinev »

Hi Ben,

It depends on your RTO (Recovery time objective)\RPO (Recovery point objective).
Replication provides you with ability to failover most business critical services in a few minutes to the DR site in case of disaster/outage at the production site.
When the production site become back online you can initiate failback process to get back from the VM replica to the original VM.

Since all backups are stored on site, in case of disaster the downtime will last until the issue resolved. Thanks!
hasayeretFMG
Enthusiast
Posts: 37
Liked: 2 times
Joined: Jun 16, 2017 1:18 pm
Full Name: Rotem Ben
Contact:

Re: Onsite replications - why?

Post by hasayeretFMG »

Thank you for your answer!
Since everything is onsite is there any point even going with replications?
tsightler
VP, Product Management
Posts: 6035
Liked: 2860 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Onsite replications - why?

Post by tsightler » 3 people like this post

There can still be use cases for onsite replication, it's all about the RPO. For example, if I have systems which I consider critical, I may want to replicate them from one storage to another, or one cluster to another, that way, if a system gets damaged, perhaps a Windows update gone awry, or ransomeware, or just a complete storage system failure, you can failover that VM to the other system right away. I've even seen customers replicate VMs on the same machine in some cases, just to have a very quick way to recover if something were to damage the running VM beyond repair.

Backup + Instant Recovery can get a similar RPO/RTO, but then you still have to move the system back to production storage so and, for larger VMs, or VMs with high I/O requirements, the performance loss might not be acceptable. Replicas don't have this issue, they are just another VM and can be powered on and running from the same or different production storage immediately.

So it's really all about what your requirements are. Can you live with the time it takes to restore your VMs, or is the performance of running your VMs from instant restore acceptable? If so, then backups alone are probably OK, but if not, then having a local replica can really be useful, generally being able to return a system, regardless of size, back to full production status in a matter of a few minutes.
stamm
Novice
Posts: 7
Liked: 3 times
Joined: Oct 21, 2014 1:37 pm
Full Name: Pat Stammer
Contact:

Re: Onsite replications - why?

Post by stamm » 2 people like this post

We just started doing this very thing for one reason: we want to have an onsite copy of our data in the event that we get smacked with ransomware. We presently run our Veeam backups to onsite storage, running backup copies through Veeam Cloud Connect to our cloud provider, and then decided that neither of those solutions seem to be ransomware-proof. We decided to implement a retired backup device as a target for yet another backup copy on a monthly basis, then cut off all network access to that device until it's time to run the next backup copy. This is what we're treating as our air-gapped copy. It's not 100% foolproof either but we don't want to dive back into the world of tape backups for the purposes of air gapping, since going to the cloud was going to eliminate all of our tape problems :mrgreen:. The good news is that it's onsite and the worst we would lose is a month's worth of data.
daniel.farrelly
Influencer
Posts: 15
Liked: 5 times
Joined: Feb 29, 2016 5:16 pm
Full Name: Daniel Farrelly
Contact:

Re: Onsite replications - why?

Post by daniel.farrelly » 1 person likes this post

We decided to implement a retired backup device as a target for yet another backup copy on a monthly basis, then cut off all network access to that device until it's time to run the next backup copy

We do same on a weekly basis.
Post Reply

Who is online

Users browsing this forum: 00ricbjo, Baidu [Spider], d.artzen, Google [Bot], ottl05, ThomasIKL51 and 146 guests