Discussion on:
View:
Show:
Can you actually rely on the one you're handing the recovery service to, or are your lawyers better than theirs?
Are we talking about using cloud services to give us DR for our land-based enterprise systems?
Or are we accepting that the organization already runs their IT in the cloud, and therefore the recovery plan would basically involve having a SECOND cloud provider?? (Thus impacting the overall cost savings gained when going to the cloud to begin with
.)
And of course, what management was told-and-sold about the cloud is that it's so triple-fault-tolerant and distributed, that it's unsinkable, too big to fail, and simply a magical land where unicorns dance joyfully in the data center and disasters don't happen.
In even the most simple and uncomplicated IT shop, doing DR that actually works as intended the old-fashioned way is more of an art than a science. Life would be easy if DR only meant deciding where your backups exist and knowing how to restore your mission critical apps. In order for DR to actually work when it's needed, the level of precision and detail goes light-years beyond the level of cooperation and coordination typically found in even the best third-party relationship.
If there is even a moderate degree of complexity, DR only works if the recovery site remains in perfect harmony and sync with critical production systems, and it's been tested, and tested, and tested. But all that is a monumental challenge, and is much more difficult if you involve a third party and the cloud.
In a true DR scenario, you cannot predict what will fail and how it will fail. This the flexibility to adapt to real DR scenarios is where Cloud-based DR could fall short.
And the 10,000 lb elephant in the middle of the room is the fact that the cloud adds a multitude of different risks that people have not even thought of yet, and thus adding a cloud-based DR into the mix may bring up even more inherent risks of it's own.
'DR in the cloud' puts the customers of such a service in the same boat.
So, a severed regional weather event, for example could cause a shift of an epic amount of data and processing power over to one or more cloud-based DR providers. If there are, lets say, 1,000 companies all having to declare a disaster at the same time, this DR provider may not be able to handle the load, nor could their network, or perhaps even parts of the Internet where their sites are based.
The grand irony here is, theoretically, when an organization goes '100% cloud and they have an empty and dark data center with no IT staff', the best DR site for the cloud is at the organization itself......thus the best plan would be to buy back all the infrastructure they sold on eBay and hire some IT people to manage it
Or are we accepting that the organization already runs their IT in the cloud, and therefore the recovery plan would basically involve having a SECOND cloud provider?? (Thus impacting the overall cost savings gained when going to the cloud to begin with
.)And of course, what management was told-and-sold about the cloud is that it's so triple-fault-tolerant and distributed, that it's unsinkable, too big to fail, and simply a magical land where unicorns dance joyfully in the data center and disasters don't happen.
In even the most simple and uncomplicated IT shop, doing DR that actually works as intended the old-fashioned way is more of an art than a science. Life would be easy if DR only meant deciding where your backups exist and knowing how to restore your mission critical apps. In order for DR to actually work when it's needed, the level of precision and detail goes light-years beyond the level of cooperation and coordination typically found in even the best third-party relationship.
If there is even a moderate degree of complexity, DR only works if the recovery site remains in perfect harmony and sync with critical production systems, and it's been tested, and tested, and tested. But all that is a monumental challenge, and is much more difficult if you involve a third party and the cloud.
In a true DR scenario, you cannot predict what will fail and how it will fail. This the flexibility to adapt to real DR scenarios is where Cloud-based DR could fall short.
And the 10,000 lb elephant in the middle of the room is the fact that the cloud adds a multitude of different risks that people have not even thought of yet, and thus adding a cloud-based DR into the mix may bring up even more inherent risks of it's own.
'DR in the cloud' puts the customers of such a service in the same boat.
So, a severed regional weather event, for example could cause a shift of an epic amount of data and processing power over to one or more cloud-based DR providers. If there are, lets say, 1,000 companies all having to declare a disaster at the same time, this DR provider may not be able to handle the load, nor could their network, or perhaps even parts of the Internet where their sites are based.
The grand irony here is, theoretically, when an organization goes '100% cloud and they have an empty and dark data center with no IT staff', the best DR site for the cloud is at the organization itself......thus the best plan would be to buy back all the infrastructure they sold on eBay and hire some IT people to manage it
We're about to move to a hybrid backup/DR service comprising an onsite backup appliance (that can also act as a DR system for one or more failed servers), plus online backup, with the option of running complete VMs remotely via VPN in the event of a complete site disaster.
I wouldn't want to have backup completely online because of the speed and convenience when restores are required. But the online part creates essential extra DR protection. This seems to be the best of both worlds.
(Strictly our online backup isn't "cloud" as we know exactly which data centre it'll be in, but the principle's the same.)
I wouldn't want to have backup completely online because of the speed and convenience when restores are required. But the online part creates essential extra DR protection. This seems to be the best of both worlds.
(Strictly our online backup isn't "cloud" as we know exactly which data centre it'll be in, but the principle's the same.)
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
