For this recipe, we want a formatted and active XFS filesystem. Please follow the recipe in Formatting an XFS filesystem before continuing.

For this, we will assume pg1 is our current primary node and VG_POSTGRES/LV_DATA is the principal data volume. Follow these steps as the root user to create and use an LVM snapshot:

Follow these steps as the root user to unmount and remove an LVM snapshot:

We can use the same lvcreate utility that helped us provision the PostgreSQL volume. We start the command with the -l parameter set to 100%FREE to use any unallocated space in the VG_POSTGRES volume group. While we can specify sizes in MB or GB with the -L setting, we really only need to do this if we plan on creating multiple snapshots.

The -s parameter makes this volume a snapshot, which causes LVM to base its contents on those of another volume. Thus, we specify VG_POSTGRES/LV_DATA as the origin volume group and volume we want to use for the snapshot. We also use the -n parameter to set the name of the new volume to snap, making our intentions more obvious.

With the volume created, we simply need to mount it to access the contents. A quick mkdir later, we have a location in /mnt/db_snap, where we can find the files after mounting.

The mount command itself contains the basic parts. We set the type to xfs with -t, while the last two parameters dictate the device and the location where it should be mounted. Since we are using an XFS filesystem, we also need to provide the nouuid mount option. By default, XFS will not allow the same filesystem to be mounted more than once. The nouuid option skips this check, allowing us to mount the snapshot.

At this point, the files in the /mnt/db_snap/pgdata directory will be the same as those in /db/pgdata. The primary difference between the two lies in the fact that /db/pgdata is our live database instance, and it has continued changing. The files at /mnt/db_snap/pgdata are frozen in time from when the lvcreate command was completed. If we view the snapshot volume with lvdisplay, we can see this in action:

Notice that LVM tells us that this is a snapshot volume and what the source volume is. We can also see that 8.27% of the snapshot space is used. This means that files have changed on the source volume, and the snapshot responded by storing the original blocks locally. When all of its space is consumed, the snapshot will be marked as invalid by LVM. Periodic checks with lvdisplay are important to determine the validity of the files we are using that reside on a snapshot.

When we are finished with the snapshot, it's good practice to destroy it. We start the process by unmounting the snapshot volume from /mnt/db_snap. Afterwards, we can use lvremove for the first time to destroy the snapshot volume. The lvremove command only requires the name of the volume we want to destroy, and it will confirm our intent before doing so. Once a volume is removed, there's no way to restore it.