Snapshot on Cloud
Each Cloud has its own snapshot approach. ##VMware VMware started this snapshot idea, while they used similar concept as what Google does, but in a less efficient way. When user delete a middle snapshot, the following snapshots won’t shrink, is more like a time freezer, it freezes the vm state at that snapshot moment.
It gives the worst user experience I’ve ever had. Migrating or managing volumes with HyperV vm that has snapshot on them is like a nightmare, you can’t move them if there’s a snapshot, you can’t change the disk size if there’s a snapshot…
User can do instance backup or volume backup. Instance Backup is using Glance to make current instance as image and store in the image repo. Volume Backup is using cinder feature to backup volumes. For example, if uderlay is running ceph-rdb, then cinder will use ceph’s backup function to make a volume backup. The snapshot strategy is same as Google and AWS, so I’ll use Goolg’s explaination below.
Google’s approach to managing snapshot is standard Cloud snapshot approach on the market.
- The first successful snapshot of a persistent disk is a full snapshot that contains all the data on the persistent disk.
- The second snapshot only contains any new data or modified data since the first snapshot. Data that hasn’t changed since snapshot 1 isn’t included. Instead, snapshot 2 contains references to snapshot 1 for any unchanged data.
- Snapshot 3 contains any new or changed data since snapshot 2 but won’t contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains references to blocks in snapshot 1 and snapshot 2 for any unchanged data.
- Any data that is required for restoring other snapshots is moved into the next snapshot, increasing its size.
- Any data that is not required for restoring other snapshots is deleted. This lowers the total size of all your snapshots.
- The next snapshot no longer references the snapshot marked for deletion, instead referencing the snapshot before it.