Building a Disaster Recovery Site - Part 3
Whether you are outsourcing your Disaster Recovery program or keeping it in-house, the steps recommended to implement it are critical. With this series, we’ve drafted an outline of methods to enhance an online Disaster Recovery site to your IT. With our previous articles one and two, we detailed steps 1 through 5:
Determine the company requirements for RTO and RPO
Determining the appropriate location
Acquire and / or build the best platform on the Disaster Recovery location
Virtualization of the primary and backup environments and production systems
Moving the data
In this final installment, we’re investigating the last three steps:
6. Synchronizing your data
7. Creating the failover environment
8. Testing the program
Synchronizing the Data
The only way to synchronize the info is to implement software or hardware to control the process. The software application or hardware platform you choose to install will sit inside your primary server environment and it'll keep an eye on all your data, continually monitoring it for changes. When it sees a difference, it knows to send the alteration into the Disaster Recovery site.
This action typically occurs on what’s known as a “block level.” Block storage is normally abstracted using a file system or database management system in order to use by applications and prospects. A block of internet data is exactly what your disk system writes. Consider such as this: Your operating system provides a database that houses all your data. When you hit “file à open” in Microsoft Word, after this you find the file you want, and you’re telling your computer system to open the file. Laptop computer translates this activity to a disk location where the information you have is stored internally, than the computer and file system move the read check out that location and it starts reading the information - and voila, it pulls in the file in your screen.
The process of synchronizing knowledge is an activity of monitoring every discrete storage destination for changes. After you save your file with revisions, your os in this handset sees there is a “dirty block” plus it saves the new file back in the redundant system on its next update (here’s where your RTO and RPO become important). The synchronization piece watches for changes, marks them as dirty, moves them for a set schedule and after that you’re done.
Unfortunately, software program that you apply to synchronize your data isn’t off-the-shelf software you could purchase at your local Best Buy, you’ll have to purchase an enterprise class software application or perhaps a hardware solution from the of the a number of providers within this space. One example of such a simple solution which GDV uses is Falconstor. On the hardware side, we also implement HP LeftHand SANs to facilitate the method.
Creating the failover environmentSimply because you’ve replicated the information, doesn’t mean it should take off and work. If only it were so simple! Given that you’ve replicated crucial computer data to a different Disaster Recovery environment, you must be competent to operate your entire systems made by this new Disaster Recovery environment.Obviously, all of your Disaster Recovery information is now on a new IP location. The redundant systems have to be told to go into production and where new data and transactions will be recorded. All the access from the outside should be pointed for the new Disaster Recovery site, and also the redundant systems have to be informed that they’re the live copy now, all before you’re operational again.
Pointing the access to the new Disaster Recovery site could be as simple as switching domains. You are able to move a web server exactly like you would move something as simple as a WordPress blog. The web figures out the site is at a different address. The final user still goes toward the main website, but they're now accessing the live Disaster Recovery site. Usually, a domain name represents an Internet Protocol (IP) resource, for instance a pc used to access the web, a server computer hosting a web site, or the web site itself or any other service communicated via the Internet. An example of a domain name is “www.google.com”.
Larger enterprises with web based applications institute what’s called BGP Routing, that is a Border Gateway Protocol. This allows them to update their routing quickly if any kind of their infrastructure goes off line. They seamlessly look at to their Disaster Recovery site because the Internet routing happens with the speed of sunshine. This scenario known as “active-active.” The failover environment is easily ready; RTO and RPO are nearly non-existent.There are numerous ways to accomplish the failover, two common strategies repointing your domain names or even a more sophisticated route like BGP active-active scenario.
Testing the program
Now that you have your Disaster Recovery site built and the failover in position, you have to check it on a regular basis. If it’s no longer working correctly, you risk losing data and business resources.
At Global Data Vault, we test all of our customer’s sites every three months - of course, if you’re building your own Disaster Recovery site, we recommend you need to do the same. Test environments will be different based on what system you’ve implemented. For our protocol, we pull-up the most recent data replica for that client by using them log into a designated portal. The portal takes the customer to their systems that reside on Global Data Vault’s data centers, so they view and test the timeliness of the information. We have the customer record a transaction while they’re there to assure its working. If the RTO and RPO are just right, then we can relax.
As you can see from the 8 detailed steps in our three articles, developing a remote Disaster Recovery site is no small feat. It’s mired with complexity that varies for each business and its requirements. For information on how Global Data Vault can assist with building your Disaster Recovery site, please contact us today.
Please visit: http://www.globaldatavault.com/blog/how-to-build-a-disaster-recovery-site-part-3/