-
- Enthusiast
- Posts: 37
- Liked: 2 times
- Joined: Jun 16, 2017 1:18 pm
- Full Name: Rotem Ben
- Contact:
Onsite replications - why?
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!
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!
-
- 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?
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!
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!
-
- Enthusiast
- Posts: 37
- Liked: 2 times
- Joined: Jun 16, 2017 1:18 pm
- Full Name: Rotem Ben
- Contact:
Re: Onsite replications - why?
Thank you for your answer!
Since everything is onsite is there any point even going with replications?
Since everything is onsite is there any point even going with replications?
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Onsite replications - why?
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.
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.
-
- Novice
- Posts: 7
- Liked: 3 times
- Joined: Oct 21, 2014 1:37 pm
- Full Name: Pat Stammer
- Contact:
Re: Onsite replications - why?
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 . The good news is that it's onsite and the worst we would lose is a month's worth of data.
-
- Influencer
- Posts: 15
- Liked: 5 times
- Joined: Feb 29, 2016 5:16 pm
- Full Name: Daniel Farrelly
- Contact:
Re: Onsite replications - why?
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.
We do same on a weekly basis.
Who is online
Users browsing this forum: Amazon [Bot], Bing [Bot], Google [Bot], massimiliano.rizzi, NightBird and 123 guests