Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Replication Is a Complement to a Well-Thought DR Plan, Not a Replacement

DZone's Guide to

Replication Is a Complement to a Well-Thought DR Plan, Not a Replacement

It is simply not true that replicating a distributed database is a replacement for having a solid disaster recovery plan or backup system.

· Database Zone
Free Resource

Read why times series is the fastest growing database category.

Many people believe that replicating a distributed database is a replacement for having a solid disaster recovery (DR) plan or backup system. While there are certainly elements of truth to this, this is missing the mark. Replication is a complement to a well-thought DR plan, not a replacement.

What Is Replication?

Replication is the act of copying data from one database server or data center to another database server or data center. In other words, replication creates an exact copy of the data in a different storage array. Replication always copies exactly what is in your database. This is important because if your data is corrupt or if somehow bad data has gotten into your system, then you are basically just replicating garbage.

What Is Backup?

Backups, on the other hand, are creating a point in time snapshot of the operational state, architecture, and stored data in the database. This distinction is incredibly important given that a backup could be the difference between restoring good data or bad data into your database to recover from an outage (or even just bad data). Backup is also important from a regulatory standpoint. Many organizations have contractual clauses in their Master Service Agreements (MSAs) that require a vendor to have backups. While this certainly in the best interest of the vendors to do anyway, this is a function of how organizations are attempting to protect themselves from externalities that they have little control over. Many of the backups requested are ones that fall under the regulatory requirements of things like HIPAA or Sarbanes-Oxley, which have important requirements such as the following:

  • Data must be backed up offsite frequently and be fully recoverable at a point in time.
  • Backed up data must be encrypted at rest and transported in an encrypted fashion.
  • Backups must be stored in multiple locations and each location must be deemed physically safe.
  • Backups must be tested regularly for validity.

What Is the Difference Between Replication and Backup?

Replication can and sometimes does handle parts of the backup solution. Data is stored and transported in an encrypted fashion between physical locations. The location of the data is spread out and your servers are likely in locations that are deemed physically safe. Most importantly, with replication, your data is available in another location almost instantly. However, replication also means that any errors or corruption issues are also propagated across all replicas. Thus, replication cannot be used to hedge against issues such as logical corruption, application schema corruption, ransomware, fat finger mistakes, operator errors, compliance and so on.

After all this, there is a caveat that one version of replication comes very close to backups: CDP, or continuous data protection. This is where backups and replication meet. CDP logs the changes in the data and ships them off to a secondary storage location in near real-time. This allows for point in time recovery, one of the reasons that backups are so important.

Backups and Replication Are Not Interchangeable

They are complementary processes that are components of having a complete disaster recovery plan. Knowing when to take proper advantage of each type is important when setting up your application and your organization for success.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

Topics:
replication ,disaster recovery ,database ,backup ,distributed database

Published at DZone with permission of Eric Lubow, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}