Companies, big and small, that heavily rely on IT, know very well that backup is not a luxury but a requirement. Whether it is your internal documents, or customer-facing marketing information, or fast-changing transactional data – it needs to be protected. Losing data is a disaster by itself, and can cause even more disastrous consequences if it is not restored in reasonable time.
An analogy to help illustrate the issue would be to imagine if the IT was your car that enables your business, and your data were the wheels. If your car has a flat tire, you can replace a wheel with a spare from the trunk (i.e., restore your data from the backup). That assumes the rest of your car is fine and can run. Assuming your spare tire is exactly the same as your primary (and not a mini-spare), you can use them interchangeably.
Another use case for backup, which brings it even closer to DR, is bare metal recovery. In this scenario, you back up the entire system image (a VM in a virtualized environments). If your server is out of commission you can load that image onto a different server (of a similar hardware configuration) and spin it up. One issue with this approach is that you need to have that extra server (a host) available to you, or build it fast enough. Another issue is that your people must be skilled and available to do the job, and in the event of a real disaster that is not necessarily the case.
When we talk about disaster recovery, however, we usually mean more than simply backing up the data, or even taking a snapshot of the system image.
The basic litmus test for backup vs. DR goes like this: if you lose some or all of your data, but your computing environment is fine, backup function will allow you to bring your data back and load it onto your systems, and get your IT service back on track. But if your IT environment itself is not available you have nowhere to bring the saved data back to. This means that having your data protected is not good enough in cases when you have lost your environment, whether it is power, hardware, software, or network. Sothe difference between backup and disaster recovery is simple:
- Backup takes care of your data by periodically saving it in a secure location (on-site or off-site), and bringing it back to you when you need it.
- Disaster recovery is a function that replicates your entire computing environment – data, systems, networks, and applications – and makes it available when your primary environment is unavailable.
Ultimately, the Disaster Recovery function provides you with a complementary, redundant environment “on-demand” where you not only can load your data, but can rebuild and run your entire IT service until your primary system is back. Following our earlier analogy with a car, think of it as a rental car or a loaner when your own vehicle is in the shop (or, you don’t know where it is).
This recovery environment can be both local and remote relative to your primary data center. Not all disasters require a remote environment, though. For example, if you have experienced an individual server failure, but otherwise your data center is intact, you can safely failover onto a locally-hosted piece of hardware and use it as if it were your primary server for a while. When your entire power supply has been significantly disrupted, or your data center has been flooded or damaged by fire, you will find yourself in a situation when you need to failover to a remote data center unaffected by the same calamity. How fast that can happen depends on your requirements and the capabilities of the DR provider. Concepts like cold, warm, or hot recovery help us distinguish between three models of how your recovery actually happens:
- Cold – your data is preserved and backed up, and your systems have been replicated in the form of system images (or VMs) and stored locally and/or remotely. Nothing is loaded onto the recovery servers. When requested, the servers and data are loaded and started. This, of course, may take a while depending on the size of your computing environment and data.
- Warm – similar to cold except your servers (VMs) are loaded onto their allocated hosts and configured. All you need to do is load the data and spin up the servers. This process is much faster. In both cold and warm recoveries, usually you can select the data snapshot that you want to load, and it’s not necessarily the latest one if you want to mitigate a major data corruption issue.
- Hot – your redundant environment is up and running in parallel to your primary, with data constantly being synced-up. Sometimes this is part of the high-availability function of mission-critical applications like email or active directories, or but it also can be simply a duplicate copy of your primary environment (often called “active”).
Each option offers different Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), but also a different price point.
Another important point to keep in mind: you don’t need to wait for a disaster to benefit from a DR solution. Here are a few scenarios where DR can become handy:
- Testing software upgrades, patches, or new use cases. Best-of-breed DR providers will offer you a virtual private cloud – a “sand-box” type of an environment where you can boot-up and play with your system without touching your live data or recovery environment. Just like you may consider renting a car when you have more people to carry, or try out a new rout, or… for whatever other reason, you can use a DR environment for tests.
- Suppose your IT environment is fine, but you have experienced a significant data loss or corruption. In this case it may be easier to failover to a warm recovery environment for the benefit of a faster RTO/RPO rather than shipping huge volumes of data back to your primary data center.
- We have seen customers using a DR environment to temporarily host their applications and services while they are doing planned maintenance, migrations, or training exercises. Think of a situation when your teenage child is learning how to drive, and you don’t want him to subject your favorite family car to this cruel punishment. So you rent a car for a day or two and sleep better at night.
- And finally, often times your DR solution can double as your backup solution – like an all-in-one solution. Disasters happen less often than the need for a lost piece of data, and therefore having a solution that offers both can be very helpful.
By now you may have a better idea about when a Disaster Recovery solution is needed. But if you find yourself short of resources and funds for your disaster recovery strategy, the idea of scraping together a “do-it-yourself” solution can be tempting. Proceed with caution. The DIY approach to disaster recovery is riddled with hidden issues and costs. The 5 Pitfalls of DIY IT Disaster Recovery white paper outlines the risks in DIY DR and shows how you can avoid them. Don’t be afraid to shop around for paid solutions. Advances in cloud technologies make it possible to get an all-in-one backup and disaster recovery solution.