We upgraded our Dev environment to 4.22, and we are testing instance and volume snapshots to visualize the incremental portion.

I can confirm thatinstance snapshots sometimes use QCOW2'sinternal snapshots.

Tablevm_snapshots

Note: I had to include memory because the instance snapshots could (in that occasion) only be taken when the instance is in the Running state. Please correct me if I am wrong. This instance was deployed from an ISO.

Then, for no apparent reason on another instance that was deployed from a template to a unlinked sparse provisioning, it "decided" to take external snapshots.

It can also be observed on the XML Dump of the instance.

If you know what logic is used to define if the snapshot will be used for snapshots (internal or external), please comment below.

When working withvolume snapshots, the behavior is very different from what one might expect.

Tablesnapshot_store_ref

Each consecutive snapshot creates a new file inSecondary Storage, and every one of these files has exactly thesame size and the same hash.

Therefore, I conclude thatvolume snapshots are effectivelystandalone full backups that are sent to Secondary Storage each time.

Even the status uses the workBackup.

Moreover, in thesnapshots table (see below), I found some references to different snapshot types (from 0 to 7, I guess).

And, I came across this documentation page that mentions snapshot types:https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots

However, the information there is not detailed enough for me to fully understand the differences, so I would appreciate a more thorough explanation.

Volume Snapshots (aka Instance Volume Snapshot)

When attached to a running instance, the buttonTake Snapshot of the volume is not available by default.

If the global settingKvm snapshot enabled (kvm.snapshot.enabled) is set to true...

…theTake Snapshot button becomes available even while the VM is running.

I understand that taking a snapshot of a volume attached to a running VM is potentially can compromise filesystem and application-level data consistency. This issue is solved by capturing the memory with the disk into the snapshot.

There is a confusion caused but the name Instance Volume Snapshot because it is in fact a Volume Snapshot technically is a Backup. In summary, I recommend changing the name to justBackup orVolume Backup.

Instance Snapshot

Volumes in CloudStack can be linked or unlinked, and it’s important to understand the difference.

Linked Volumes

• These volumes are externally linked to the template image.
• Essentially, the volume acts as an overlay on top of the template, similar to an external snapshot backed by the template.

Example: Linked Volume deployed from Thin Provisioning offer.

Here, the instance’s volume file is layered on the template image.

Example: Linked Volume deployed from Thin Provisioning offer and 2 Instance Snapshots.

Unlinked Volumes

These volumes are standalone files, independent of any template.

Example: Unlinked Volume deployed from ISO

Example: Unlinked Volume deployed from Sparse Provisioning.

Example: Unlinked Volumes with Internal Snapshot

Note: Mixing internal and external snapshots is not recommended.

This is where the ROOT disk provisioning type is typically configured, at theCompute Offering:

And also at theAdd Disk Offering creation:

Provisioning types explained

• Thin Provisioning - Linked Clone
  • Instances are created as linked clones.
  • The template cannot be removed while instances depend on it.
  • If the template becomes corrupted or inaccessible,ALL dependent instances will also fail.
• Sparse Provisioning - Full Copy (Lazy Thick)
  • A full copy of the original image is created (not linked).
  • Disk space is allocated, but zero blocks are written on demand.
  • Faster to create than Fat provisioning.
• Fat Provisioning - Full Copy (Eager Thick)
  • A full copy of the original image is created (not linked).
  • All disk blocks are fully zeroed at creation time.
  • Slower to create, but disk is fully initialized upfront.

@daviftorres there are pro and con for the different snapshot and backup options. Find them here:

Instance snapshot:

• is stored on the primary storage
• is no backup; just to freeze a certain state if you do changes
• is using qcow2 functionality
• does snapshot of the entire VM including all disks
• can include memory as well
• can have differential snapshots
  Volume snapshot:
• is copied to the secondary storage
• is individual to each volume
• can be differential
• you won't get a consistent snapshot across all volumes of a VM for the same point in time
• can be copied to other zones automatically
• can be restored in other zones without the need of template now
  NAS backup:
• does backup the entire VM to an external location
• can be restored to other zones with access to this backup storage
• does full backup only at the moment - differential backup is hopefully to come soon

I hopefully have covered most of the important criteria to be considered.

Can this be used for Linstor primary storage ?

@bilalinamdar What exactly to do you want to do on the Linstor storage?

@bilalinamdar see this article from@rajujith:

https://www.shapeblue.com/nas-backup-and-recovery-plugin/

The NAS Backup and Recovery Plugin currently supports NFS (Network File System) and operates as a straightforward B&R recovery provider, making it both storage and vendor-agnostic. This enables administrators to do efficient backups of running instances,regardless of their source storage. It also can be used to create backups of stopped instancesstored on both NFS and local primary storage. However, please note thatrestore operations are currently supported only for NFS and local primary storage.