Problem: When a patch process goes amiss, it would be nice if rollback options, when possible, were documented and available easily, documented from the Filr side.

By default, if the filesystems in use are using Btrfs and do not have Copy-on-Write (CoW) disabled, snapshots are an option. Tools like zypper automatically take pre and post snapshots when applying a set of RPMs, meaning that determining the changes implemented by a patch, including the ability to rollback the filesystems that have snapshots, is very fast and easy, allowing a system to be restored very quickly.

Some upgrades may implement changes that are in filesystems that do not have snapshots, for example if the database is changed in a destructive way, or if the Lucene datastore is reworked for an upgrade. If the changes are destructive, for example removing a column, changing a column in a non-backward-compatible way, or changing data types, then a rollback may not be valid at all, but if the changes are non-destructive, e.g. adding a column to a database or not reworking the Lucene files entirely, then rollback could work.

For the case of non-destructive patches, having the documentation show how to perform rollbacks would be helpful to avoid large amounts of downtime during limited maintenance windows. This would be much faster than using snapshots at a virtualization layer (when virtualization is used). It may also be valuable to have a patch's readme include whether or not a patch is known to cause destructive (to rollbacks) changes, or even delete snapshots once everything is done to discourage attempting to use those snapshot.

by: Aaron B. | over a year ago | Virtual Appliance