GitHub user RyanP-Testing added a comment to the discussion: What does
Snapshots, Backups, and Incremental Snapshots mean in CloudStack
Hi Davi,
This is a very useful discussion, especially because the terms “snapshot” and
“backup” can easily get mixed together when looking at CloudStack from an
operational or SLA perspective.
>From a practical CloudStack perspective, I think it helps to separate the
>concepts into three areas:
**1. Volume Snapshot**
A CloudStack volume snapshot represents the state of a volume at a particular
point in time. It is primarily useful for rollback, cloning, recovery, or
creating a new volume from a previous state.
However, the actual storage behavior is dependent on the underlying storage
provider. A CloudStack snapshot should therefore not automatically be
interpreted as a traditional array-level snapshot or as a standalone
disaster-recovery backup.
**2. Backup**
A backup is better viewed as a copy intended for longer-term retention and
recovery, preferably on storage that is independent from the primary
workload/storage environment.
This distinction becomes important operationally. If the underlying storage is
lost or the storage system itself becomes unavailable, a snapshot located on
that same storage infrastructure may not provide the same protection as an
independent backup.
**3. Incremental Volume Snapshots in CloudStack 4.22**
The new incremental snapshot capability makes the distinction even more
interesting.
Instead of repeatedly transferring the entire volume for every snapshot,
subsequent snapshots can represent only the data that has changed since the
previous snapshot. This can significantly reduce the amount of data transferred
and stored.
The important point, however, is that “incremental” describes how the changed
data is captured/stored; it does not automatically mean that the resulting
snapshot should be treated as a complete independent backup.
For example, conceptually:
```text
Full/Base Snapshot
|
+---- Changes 1
|
+---- Changes 2
|
+---- Changes 3
```
The complete point-in-time state may depend on the base data plus the required
incremental changes.
For **KVM + NFS**, I would therefore avoid describing CloudStack snapshots
simply as “full backups” or “incremental backups” without considering the
underlying implementation and storage provider.
The other important distinction is **retention and failure domain**.
A snapshot can be extremely useful for:
* Quick rollback
* Recovering from an application or configuration change
* Creating a new volume
* Short-term recovery
A backup is generally intended for:
* Long-term retention
* Disaster recovery
* Protection against storage failure
* Compliance requirements
* Recovery when the primary storage is unavailable
So, from an operational perspective, I would use the following rule of thumb:
**Snapshot = convenient point-in-time recovery**
**Backup = independent recovery copy**
**Incremental snapshot = optimized way of maintaining point-in-time states by
tracking changed data**
There is certainly some overlap between these concepts, but they should not be
treated as interchangeable when designing an SLA or disaster-recovery strategy.
It would also be useful to document the behavior separately for each storage
backend, because the implementation details can differ significantly between
KVM/NFS, Ceph, local storage, and other storage providers.
That would make the documentation much clearer and prevent administrators from
assuming that a CloudStack snapshot automatically provides the same protection
as an independent backup.
Regards,
Ryan P.
**DevOps Engineer & *
**AccuWeb.Cloud**
GitHub link:
https://github.com/apache/cloudstack/discussions/12475#discussioncomment-18084192
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
