Every company needs to have a business continuity plan (BCP) in which it imagines various scenarios that could affect its business and documents steps that need to be taken to recover from those scenarios as quickly and effectively as possible. Part of this BCP is what to do if the data center is damaged or if any data is lost. Data loss can be caused by a natural or unnatural disaster (explosives), hardware failure, human error (files being deleted by accident), data corruption, data theft, and much more. There needs to be a plan in place to get that data back online and available–particularly customer-facing data. In addition to copies of data being required for recovery purposes, they are usually needed for compliance with various regulations.
Data Recovery of Yesteryears
I remember the times when data was backed up on tapes, and keeping those tapes/cartridges in a fire-safe server room was the norm. Obviously, that was not a great idea if the server room was damaged or lost in a disaster. I also remember having a reciprocal agreement with another local company, taking our tapes over to their site, and bringing theirs to ours. That was better, but it still only allowed us to recover to the last full backup. In our case, it was the previous weekend. You can already see the problem with that arrangement–we could, potentially, lose up to seven days’ worth of data if a disaster happened just before a new full backup took place. I keep saying disaster, which also includes events such as ransomware or malware attacks.
The next step was to take full backups every week and incremental backups every day. That meant we could recover to the previous night–a maximum of around 24 hours. Even so, incremental backups were generally kept ‘safely’ onsite. Clearly, this wouldn’t be satisfactory in an environment with data that could be changing all the time–like a bank. If I have put money into my account one day, I wouldn’t want that cash to vanish from my account just because the bank recovered the previous night’s backup of the files!
This is where offsite data replication comes into the picture as a viable solution.
Learn More: Where Does Data Replication Fit Within the Business Analyst’s Toolkit?Â
Offsite Data Replication and Its Advantages
The solution to this issue is data replication. This is the process by which data is copied and stored somewhere else. The replication process is usually synchronous or near-synchronous, although it can be asynchronous. The ‘somewhere else’ can be another data center that is some distance away, or perhaps, more likely, these days, can be a public cloud or virtual private cloud. Data that is replicated is an exact copy (or replica) of the data originally stored on the network. And that’s why it is so easy to restore it in the event a disaster occurs.
The obvious advantage of this is that up-to-the-minute copies of data are available, allowing recovery to include the latest changes that took place just before the disaster happened. So, in my example, as soon as processing starts again, my payment in my bank account would still show as being there. The other advantage is that replication gives users access to applications and data all the time, making recovery much easier.
Many data centers go for a hybrid solution. With this strategy, they replicate their data to a remote server and copy it to the cloud. For organizations, if the original data gets corrupted somehow, it can be restored from the replicated data. It goes without saying that being offsite means that it shouldn’t be lost in any disaster that affects the data center, such as a fire or flood. The replicated data is almost always encrypted before being sent offsite so that it cannot be intercepted and read in transit or while being stored in the cloud.
The other advantage data replication has over backups is that it can provide extremely granular recovery points. This means that several recovery points are available for recovering data, and these recovery points can be close together in time. The advantage of this is in situations where data gets corrupted. Recovery can be to a point in time just before the corruption occurred. Also, restoring from replicated data is much quicker than restoring from tapes. Another advantage of replication over backups is that it does not drain resources on the server in the same way that backups can.
Replication is usually measured using a recovery time objective (RTO) and a recovery point objective (RPO).
Learn More: Is Your Backup Strategy Putting Data at Risk? 13 Essential Questions to AskÂ
Recovery time objective (RTO)
A recovery time objective (RTO) is the best guess at how long it should take to restore a business process to an acceptable level of service following some kind of disruption. If the actual recovery time is any longer than the RTO specified, there can be unacceptable consequences to the business.
The timing is a ‘best guess’ and the value is usually specified and documented during the business impact analysis (BIA) process. The value will be decided by the person responsible for the business process and the IT team.
Recovery point objective (RPO)
Recovery point objective (RPO) is again documented in the business recovery plan. It is the maximum amount of time allowed during which transaction data might be lost following some kind of disaster. It is not a measure of how much data might be lost. In effect, it is the maximum amount of time since the start of the last backup that can be used in the recovery process.
So, for example, let’s assume that the last backup took place 16 hours ago, and an incident has just happened. If the RPO for the business process is 24 hours, then everything is okay. This would be a business process that would not be as important as the bank transaction example given above.
Putting It All Together
There are still many data centers that are using backups. For them, their RTO will have to include accessing their backup tapes and restoring files from the backup. As their backups are taken overnight, the backup will gradually get further and further out of sync as the following day passes.
In the event that the data center itself has been affected by a flood or any other disaster, offsite backups will have to be used and will need to be restored at some other data center. This will definitely extend the length of the recovery time.
On the other hand, if an organization moves to offsite replication, its RPO is much shorter because of the granularity of the replication. Also, if there has been any corruption, an earlier point in time can be used for the backup. Basically, the RPO time is much shorter, which is much better for more critical applications (like banking).
In Conclusion
Because the values for RTOs and RPOs are getting shorter in a world where people expect everything to be always on, it’s getting more and more important for IT teams to ensure business processes are available at all times. And that means, in the event of a problem occurring, files and applications need to be restored and running as soon as possible. Backups can’t do this, which makes offsite data replication the best way to meet recovery time objectives.
Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.