Document navigation

Snapshot Management

ZSphere supports both Redirect-On-Write (ROW) and Copy-On-Write (COW) snapshot mechanisms.
  • For centralized storage: Local storage, NFS, and SAN storage use QCOW2 external snapshot, which is a type of ROW snapshot mechanism.
  • For distributed storage: Enterprise Ceph storage uses ROW snapshots. ZStone uses COW snapshots.

Centralized Storage Snapshot Mechanism

This section introduces QCOW2 external snapshots.

  1. Snapshot Chain and Snapshot Tree

    A disk typically has one snapshot chain and can have one snapshot tree. Each branch of the snapshot tree is a snapshot chain.

    See Figure 1 for an illustration.
    Figure 1. Snapshot Tree


    A snapshot tree includes the following information:
    • Snapshot Chain: A relational chain composed of a set of snapshots for a disk. Each branch of the snapshot tree is a snapshot chain.
    • Snapshot Node: An individual node in a snapshot chain, representing a single snapshot of the disk.
    • Snapshot Size: The storage space consumed by a snapshot. You can view the total size of all snapshots in the snapshot tree and the size of an individual snapshot node.
    Note:
    • For non-distributed storage, the system allows a maximum of 128 nodes per snapshot chain by default. For distributed storage, each disk supports up to 32 snapshots, including manual and automatic snapshots.
    • When a snapshot chain reaches its maximum length:
      • If you continue to create automatic snapshots, the system automatically deletes the earliest automatic snapshot.
      • If you continue to create manual snapshots, you must manually delete unneeded snapshots.
    • In production, keep the number of snapshots for each VM at five or fewer whenever possible. Excessive snapshots can affect VM performance, data security, and data storage capacity.
  2. Create Snapshots

    When an external snapshot is created, a new empty QCOW2 file is generated. This new file has its backing file pointed to the original QCOW2 file. The original QCOW2 file is set to read-only, effectively turning it into a snapshot itself. Subsequent data writes are directed only to the new QCOW2 file. The creation of an external snapshot involves creating a new blank qcow2 file.

    • Create a single snapshot chain based on a backing file.
      See Figure 2 for an illustration.
      Figure 2. Single Snapshot Chain


      Assume there is an original base image (Base). A virtual machine 1 is created using this base image as a template. Then, snapshot 1A and 1B are created sequentially for virtual machine 1.
      • Base Image: A pre-made disk image file containing a complete operating system and bootloader, serving as the Base (read-only).
      • VM 1: A new empty file, Overlay-1, is created. Its backing file points to Base. Base remains read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-1.
      • Snapshot 1A: A new empty file, Overlay-1A, is created. Its backing file points to Overlay-1. Overlay-1 is set to read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-1A.
      • Snapshot 1B: A new empty file, Overlay-1B, is created. Its backing file points to Overlay-1A. Overlay-1A is set to read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-1B. VM 1 uses the disk file corresponding to the last snapshot, Snapshot 1B, which is the active snapshot.
    • Create multiple snapshot chains based on backing files.
      See Figure 3 for an illustration.
      Figure 3. Multiple Snapshot Chains


      Assume that VM 1, VM 2, and VM 3 are created from an original base image (Base). Snapshot 1A and Snapshot 1B are then created for VM 1, Snapshot 2A for VM 2, and Snapshot 3A for VM 3.
      • Base Image: A pre-made disk image file containing a complete operating system and bootloader, serving as the Base (read-only).
      • Snapshot Chain 1:
        • Virtual Machine 1: A new empty file, Overlay-1, is created. Its backing file points to Base. Base remains read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-1.
        • Snapshot 1A: A new empty file, Overlay-1A, is created. Its backing file points to Overlay-1. Overlay-1 is set to read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-1A.
        • Snapshot 1B: A new empty file, Overlay-1B, is created. Its backing file points to Overlay-1A. Overlay-1A is set to read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-1B. VM 1 uses the disk file corresponding to the last snapshot 1B in snapshot chain 1, and snapshot 1B is Active.
      • Snapshot Chain 2:
        • Virtual Machine 2: A new empty file, Overlay-2, is created. Its backing file points to Base. Base remains read-only. Subsequent data is written only to Overlay-2.
        • Snapshot 2A: A new empty file, Overlay-2A, is created. Its backing file points to Overlay-2. Overlay-2 is set to read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-2A. VM 2 uses the disk file corresponding to the last snapshot 2A in snapshot chain 2, and snapshot 2A is Active.
      • Snapshot Chain 3:
        • Virtual Machine 3: A new empty file, Overlay-3, is created. Its backing file points to Base. Base remains read-only. Subsequent data is written only to Overlay-3.
        • Snapshot 3A: A new empty file, Overlay-3A, is created. Its backing file points to Overlay-3. Overlay-3 is set to read-only, thus becoming a snapshot. Subsequent data is written only to Overlay-3A. VM 3 uses the disk file corresponding to the last snapshot 3A in snapshot chain 3, and snapshot 3A is Active.
  3. Merge Snapshots

    External snapshots are interdependent, where each overlay file depends on its backing file. Each snapshot preserves its corresponding data, preventing the direct deletion of an individual snapshot to shorten the chain length. The chain length of external snapshots can be reduced through two methods: downward merging (Blockcommit) or upward merging (Blockpull).

    • Blockcommit

      Within the same snapshot chain, you can merge overlays into backing files.

      See Figure 4 for an illustration.
      Figure 4. Downward Merge (Blockcommit)


      Assume there is an original base image (Base). Virtual machine 1 is created based on Base, and three interdependent external snapshots are created for virtual machine 1: Snapshot 1A, Snapshot 1B, and Snapshot 1C. Now, Snapshot 1A and Snapshot 1B are merged downward into virtual machine 1. As a result, the backing file of Snapshot 1C (Active) points directly to virtual machine 1, so the snapshot chain is shortened. Snapshots 1A and 1B are no longer useful and can be deleted.

    • Blockpull

      Within the same snapshot chain, you can merge backing files into overlays.

      See Figure 5 for an illustration.
      Figure 5. Upward Merge (Blockpull)


      Assume there is an original base image (Base). Virtual machine 1 is created based on Base, and three interdependent external snapshots are created for virtual machine 1: Snapshot 1A, Snapshot 1B, and Snapshot 1C. Now, Snapshot 1A and Snapshot 1B are merged upward into Snapshot 1C (Active). As a result, the backing file of Snapshot 1C (Active) points directly to virtual machine 1, so the snapshot chain is shortened. Snapshots 1A and 1B are no longer useful and can be deleted.