Preparations for your next disaster can’t start next week, next month or right before the disaster. It has to start now. There are a lot of things you must think about and implement before the disaster strikes. You need to decide on the type of site you will use, the location of that site, how to seed data to that site and update it when data changes, how long to use that secondary site and how to return operations to the original data center.
The first step is to decide what type of location to use for the secondary site. Will the site be a remote office, a remote data center or a cloud provider? Each of these options have pros and cons. A secondary data center is most ideal. But many organization don’t have one and creating one is expensive. A remote office may be the least expensive but the organization needs to think long term. Is this site suitable to host both critical applications as well as the organization’s personnel? The cloud is the newest option on the table but the organization has to make sure it can seed the cloud provider and keep it updated.
The second step is to get the initial seed of data to the DR site. Updating the site is less of a concern than in years past, thanks to technologies like block-based data replication and deduplication that only transfer unique changed segments of data. The initial seed though will not benefit from these technologies; it ALL has to move. Given the bandwidth of the typical connection between remote sites, the public cloud or even a secondary data center, the time to get the DR site seeded with data could take weeks.
Organizations facing this situation should consider a solution that will allow either data to be transferred by tape to the DR site, or allow for the DR backup device to first be installed at the primary data center. Once updated the device can be moved to the secondary site and quickly synchronized with changed data.
The need to move bulk data is the biggest challenge facing organizations that want to use public cloud providers. Most public cloud providers have no ability to accept external hardware to tape media. Some providers can supply with a large NAS that data can be transferred to. If the organization chooses to go that route, they need to make sure that their backup or replication provider supports those devices.
Another consideration is how long will the DR site be a viable secondary data center? If the organization had a formal secondary data center then it is safe to assume it should be able to sustain operations for as long as needed. If the organization plans on using a remote office, then it may not be suitable for the task. It needs to have a part of its plan where operations move to a more data center ready secondary site, if the primary site may be out for more than a few weeks. The public cloud, assuming all data and applications are easily accessible remotely, should be able to sustain operations for a considerable period of time.
It is important that the organization resume data protection tasks while at the DR site. Often forgotten, once operations resume in the DR site, data changes and must be protected!
The final consideration is how the return to the primary data center will occur. Most disaster declarations are precautionary and no significant damage is done to the primary data center. If this is the case, then the organization needs to make sure its data protection applications and reverse the data movement process, only moving data that has changed while at the recovery site.
Of course there are situations where there is a complete data center wipe-out. In this case, when the data center is suitable ALL data must return to the primary data center. This process and challenges are then very similar to the initial seeding process described above.
Preparing your disaster site is a critical step in the recovery process and the type of site available typically impacts the next series of decisions. Seeding the secondary site is typically the most challenging step in this process and the type of DR site dictates how to prepare that site.
Sponsored by Commvault