Skip to main content
  • EN

In the realm of data protection and recovery, the term "snapshot" often emerges, lauded for its efficiency and speed in capturing point-in-time states. However, it's crucial to dispel a common misconception:

snapshots are not synonymous with backups

They serve distinct purposes and possess fundamental differences that impact their reliability and comprehensive data protection capabilities.

 

Key Differences

  1. Dependency: Snapshots are often reliant on the original data source. If the primary data encounters issues, such as corruption or failure, snapshots tied directly to it may become compromised. In contrast, backups maintain independence from the original source, reducing the risk of losing data due to primary system issues.
  2. Data Retention: Snapshots are typically short-term solutions for immediate recovery needs. They may not suffice for long-term data retention or compliance purposes. Backups, on the other hand, are designed to retain data for extended periods, adhering to regulatory requirements and archival needs.
  3. Recovery Scope: While snapshots excel in rapidly restoring a system to a recent state, they might not encompass all necessary data elements, such as application states – here especially transactional integrity of databases. Backups provide a more comprehensive recovery scope by encompassing a broader range of data elements critical for holistic system restoration. Backup applications can be configured to communicate with applications to set them in a defined state to stare a consistent state that is recoverable.

 

Limitations of Snapshots

Snapshots, despite their advantages, carry several limitations:

  1. Limited Scope of Protection: Snapshots primarily safeguard against data loss caused by software issues or accidental deletion. They are effective for immediate recovery within the same system but aren't designed for comprehensive data protection against all types of threats.
  2. Inadequate Protection Against Deletion or Malware: In scenarios involving accidental deletion, malicious attacks, or ransomware, snapshots might not provide the necessary safeguard. Since snapshots are closely tied to the original data, they can be susceptible to deletion or encryption alongside the primary data, leaving no unaffected copy for recovery.
  3. Retention Period Constraints: Snapshots often have limited retention periods. After a certain point, older snapshots might be automatically deleted to free up storage space. If an issue goes unnoticed and requires data from a longer time ago, those snapshots might not be available.
  4. Lack of Portability: Snapshots are usually tied to the system or platform where they were created. Moving snapshots between different environments or platforms can be challenging, making it difficult to recover data in case of a complete system failure or migration.
  5. Limited Coverage of Data Corruption: While snapshots excel in capturing a specific moment in time, they often lack comprehensive coverage against various forms of data corruption. For instance, if data becomes corrupted gradually over time without being immediately noticed, the snapshot might also retain this corrupted state, rendering it ineffective for recovery purposes.
  6. Compliance and Legal Issues: Depending solely on snapshots might not comply with certain regulatory requirements or legal standards for data protection and retention. Some regulations mandate the use of specific backup solutions with defined characteristics like off-site storage and encryption.

 

Comprehensive Data Protection Strategies

A reliable data protection strategy involves multiple layers of protection by combining the advantages of both approaches to ensure data integrity, availability, and recoverability. It should address a range of scenarios including accidental deletion, hardware failures, cyber attacks, and natural disasters.

  1. Rapid restore: Use snapshots to provide users with a self-service restore for data they have accidentally deleted shortly before.
  2. Backup Frequency: Establish a backup schedule that aligns with data importance and change frequency, ensuring regular and consistent backups.
  3. Off-site and Redundant Storage: Store backups in off-site or redundant locations to mitigate risks associated with on-premises failures, theft, or natural disasters.
  4. Immutability: Use immutable Storage to prevent accidental or malicious deletion or corruption of your backup data.
  5. Encryption and Security Measures: Apply encryption to backups to protect sensitive information from unauthorized access. This is crucial, especially when data is stored off-site or in cloud-based backup solutions.
  6. Testing and Validation: Regularly validate both snapshots and backups by performing test restores to confirm their reliability and integrity.
     

Conclusion

Snapshots undoubtedly offer advantages in capturing system states swiftly, but they do not encompass the comprehensive protection that backups provide. Understanding the differences between snapshots and backups is crucial in formulating a robust data protection strategy. Leveraging both technologies in tandem allows organizations to achieve a balance between rapid recovery and comprehensive data resilience, ensuring a resilient defense against data loss scenarios.

In summary, while snapshots serve as valuable tools for immediate recovery needs, they should not be mistaken for backups. Embrace a holistic approach that incorporates both snapshots and backups to fortify your data protection arsenal, safeguarding your critical information against unforeseen threats and system failures.

Though 99% of the time this is true (and I agree with everything stated here), with Storage systems, there is a time where a Snapshot is actually a backup, as it’s a full copy of original data - when the snap is replicated to a remote partner appliance. This is the only time (I can think of) any kind of snapshot is a backup.

Great writeup btw @JMeixner !

… Outstanding explanation! I hope this piece resonates with some administrators, as there are still individuals who believe that a snapshot is sufficient.

Really great writeup here comparing and contrasting the differences.  I also agree with Shane as there will be that 1% where it is a backup based on your architecture and configuration.

Though 99% of the time this is true (and I agree with everything stated here), with Storage systems, there is a time where a Snapshot is actually a backup, as it’s a full copy of original data - when the snap is replicated to a remote partner appliance. This is the only time (I can think of) any kind of snapshot is a backup.

Great writeup btw @JMeixner !

😎 ok, that's a middle thing between backup and snnpshot…

But I think, I will fo another article about the topic “Why Replication is no Backup”.

Thank you @JMeixner very useful post.

@JMeixner , 

This is a very clear and concise explanation for everyone in the Data security an especially in IT world.

Thank you for sharing this great article. 

Great write up.

I use snapshots, and replicate them to another site. This is IBM’s GMCV (Global Mirror with Change Volumes) It’s a great way to have replicated volumes and keep things consistent with even low bandwidth.  SRM works very will with it and it will flip directions after you fail to the other site.


I still don’t consider this a backup. If something bad happens to a VM, it will eventually get put in the next snapshot and replicated over.

Snapshots can work as a “Temporary” point in time “Backup” to revert changes, but for me, the term backup means I am protected. That includes a SAN failure, or an attack. 

Great write up.

I use snapshots, and replicate them to another site. This is IBM’s GMCV (Global Mirror with Change Volumes) It’s a great way to have replicated volumes and keep things consistent with even low bandwidth.  SRM works very will with it and it will flip directions after you fail to the other site.


I still don’t consider this a backup. If something bad happens to a VM, it will eventually get put in the next snapshot and replicated over.

Snapshots can work as a “Temporary” point in time “Backup” to revert changes, but for me, the term backup means I am protected. That includes a SAN failure, or an attack. 

Exactly @Scott, there are many concepts out there and many of them are working really good.

As you say, the downfall of SRM is the propagation of errors. And the snapshots are on the partner system of the primary system - in the same domain, with the same access methods, in worst case with the same accounts, so when you are attacked there is high possibility to loose both systems.

For a short-term option to bring individual files or VMs to a previous status, snapshots and replication are a good solution. But not as protection against machine damage and attacks.

Comment


Terms & Conditions