Volume snapshot inheritance and its consequences on EO-Lab

While not as good as a dedicated backup, performing a volume snapshot is a common form of securing your data against loss. While there are no inherent problems with snapshots themselves, there can be unforeseen consequences.

To illustrate these, we will use an example: We have created a volume called “Volume A”.

../_images/volsnap1.png

Next we create “SA”, a snapshot of “Volume A” (VA).

../_images/volsnap2.png

Using the OpenStack dashboard we can create new volumes “Volume B” and “Volume C” based on the previously created snapshot “Snapshot A”.

../_images/volsnap3.png

At that moment we have two new volumes based on “Snapshot A”. Let’s assume, at some point in the future, we no longer need “Volume A” and want to delete it.

../_images/volsnap4.png

Unfortunately, its deletion will not be possible directly because to delete a given volume, we have to delete its snapshots.

../_images/volsnap5.png

So we must first delete “Snapshot A” and afterwards “Volume A”.

However, this will also be impossible because “Snapshot A” has been used as the the source for 2 new volumes, “Volume B” and “Volume C”.

To delete a volume whose snapshot/s were used to create additional volumes, we must first delete all snapshots of said volume.

In conclusion, when creating new volumes from a snapshot, please remember inheritance. “Snapshot A” is the parent of the volumes “Volume B” and “Volume C” (aka children) and if we want to delete “Volume A”, we have to start with the “youngest” generation (Volume B and C).

Backups are another solution. They do not create inheritance chains like this and will exist even after the deletion of the original volume. For more information on backups, see How to Backup an Instance and Download it to the Desktop on EO-Lab OpenStack Hosting.