Qumulo’s Distributed File System

Replication Snapshot

Replication Snapshot

Replication Snapshot provides the ability to set up snapshot retention on the replication disaster recovery target according to well-defined organizational policy. Qumulo enables customers to set up and manage snapshot policy and retention both on source and target from the same page. These target-side snapshots snapshots contain a valid point-in-time consistent copy of their data and it is quick and easy to recover that data from those snapshots.

Replication Snapshot enables:

  • Maintaining point-in-time-copies on both source and target clusters providing two product ready clusters
  • Aging snapshots on the target freeing up space on the source
  • Keeping incremental copies of their data forever in lieu of a fully functional backup solution

Replication Snapshot provides assurance of recoverability from data loss or corruption on the source cluster that has been inadvertently replicated to the target by an automatic replication policy. This could occur under any number of scenarios, such as:

  • Malware that has infected the source data
  • Accidental or malicious deletion of data from the source
  • Corruption of data on the source due to product or application bugs

While many of these scenarios could conceivably be recovered from directly on the source cluster with an appropriate source-side snapshot policy, Replication Snapshot provides a mature backup or disaster recovery product to provide an additional level of data protection should recovery from the target be necessary. Additionally, differences in performance and capacity between the source and target clusters – replicating from a production all-NVMe source to a slower nearline archive DR target, for example – might make the target amenable to a more aggressive snapshot retention policy than the source.

For specifying a retention policy on snapshots, users can decide between different frequencies like hourly, weekly, monthly, etc. at different times of day, days of week, etc. All of these would be specified within a single policy. For instance, there could be a policy with daily snapshots retained for a week, weekly snapshots retained for a month, and monthly snapshots retained for a year. This is a more fine-grained solution than what is available for single snapshot policies.

A user could also specify a snapshot policy on the target system while using a scheduled or “semi-synchronous” (like continuous) replication policy to replicate data from source to target. Since it’s volume and block replication, the target can be viewed as point in time consistent until the running replication has completed where a cutover to the new baseline can happen. Then, a target-scheduled snapshot policy can be running to maintain the user’s desired data retention.

Want to learn more?

Give us 10 minutes of your time, and we’ll show you how to rethink storage data.