Eight steps for a dependable disaster recovery plan
- Details
- Published: Wednesday, 15 May 2019 08:20
Disaster recovery (DR) is an essential part of any business protocol, but each year we see numerous organizations fall short. By following these eight basic principles, Rod Harrison says that businesses can ensure that they have a complete DR plan that will provide full business continuity...
Make a thorough DR plan and keep it updated
Although it sounds like the obvious starting point, making a DR plan and keeping it updated is critical. While most businesses have some form of a plan in place, many fail to keep it regularly updated – leaving them vulnerable should a disaster strike.
Businesses should also work out how quickly they must recover, as this will influence the overall strategy. Different data sets will likely need to be recovered more quickly than others. Although everyone’s ideal objective is to recover immediately with zero downtime, the reality is that the more quickly you need to recover the more expensive it will be to implement. Therefore, it’s important to balance the cost with other requirements. For some businesses, it could be that a few hours or days of downtime will have limited impact, but for others the need to regain operations within a matter of seconds or even micro-seconds is critical.
Consider structured and unstructured data separately
Structured data mostly refers to information that is organized and easy to search and navigate - it will usually include numbers/dates, for example. Unstructured data is information that typically does not fall into easy and straight-forward pattern/navigation and will usually include text such as emails, word documents and videos.
Structured data often has a complex replication scheme where you have to focus on each database; and often the recovery time of this data is strict. All of this makes structured data complicated, and the larger the environment, the harder it makes it to recover. But, if you can take the unstructured data out of the equation, and use a different paradigm, for example an archive device that replicates the data between sites, organizations can simplify the overall problem of DR, as the unstructured data will simply take care of itself.
Evaluate the data change rate
Organizations should be cognizant of their data change rate. Replication is a workload amplifier and in some cases the wide area network (WAN) can’t keep up, which affects the recovery time. By understanding the data rate, businesses will be in a better position to identify whether synchronous or asynchronous replication is the best option – in some cases synchronous replication is satisfactory and this reduces the pressure on the WAN.
Select appropriate replication technology
Businesses should select the appropriate replication technology. Storage arrays can typically offer replication features and sometimes they are included for free. As part of this, businesses should automate failover/failback while paying close attention to the data integrity by running audits and tests.
Keep legalities in mind
In a perfect world, DR sites would be thousands of miles apart, but increasingly, the movement of Personally Identifiable Information (PII) from one region to another is becoming regulated. Having data in multiple regions multiplies civil risks of discovery and the penalties for exposure. Therefore, take the time to evaluate the laws in each region and identify concerns of additional requirements. A DR site should have at least the same level of security as a primary site.
Backups alone won’t cut it
The real issue here is just using backup – for example, if you backup a server to the cloud, but that’s all you do for DR, then the recovery time could be a problem. A full-scale DR experiment/test will enable businesses to identify the issues. A lot of backup packages claim to have the ability to run Virtual Machines (VMs) directly from the backup image, and this is great for a smaller number of VMs, and it can be a very useful feature. However, if you actually try to spin-up the entire environment the typical backup targets of backup appliances don’t have the IOPS (input and output) necessary to run a lot of VMs.
Testing becomes important as organizations will be able to directly discover any limitations of the technology used. A replicated archive for the static unchanged data will be able to reduce the overall time to recovery problem allowing businesses to get back up and running as quick as possible.
Consider the failback planning
One of the things about disasters is clearly knowing when to do the failback. More often than not, the disaster doesn’t have a specific end point in terms of IT - things start coming back online slowly. It’s important to have criteria in place to decide when you will start the failback process.
Drill, drill, drill
Less than 20 percent of organizations do a full DR test more than once per year, and 20 percent never do a DR test at all. An untested DR plan will more than likely not work – it’s imperative for business continuity to not only know if your DR plan will work, but how it will work.
With an effective DR strategy, organizations can not only reap the benefits of business continuity, but it enables a more agile and adaptable workload structure. Creating a dependable DR plan will not only safeguard the company reputation and bottom line, but it allows businesses to understand their data and its value. Not only is DR an essential tool but it makes good business sense.
The author
Rod Harrison is CTO of StorCentric, parent company of Nexsan and Drobo.
Rod came to StorCentric via its acquisition of Drobo in 2018, where he was the CTO and had been with the company since its formation in 2005. He was part of the original BeyondRAID design team and has contributed significantly in all areas, from architectural design to coding at the deepest levels. Rod has 30 years of operating system, embedded and RAID systems experience gained through senior engineering roles at Veritas, Sun Microsystems, Wind River, SCO, Madge Networks, and others. He has been part of several industry standards groups, including iSCSI and I2O. Rod holds a BSc (Hons) Computer Science degree from the University of London and has authored four patents, all at Drobo. He currently lives in London, UK.
