Cumulus Linux supports the ability to take snapshots of the complete file system as well as the ability to roll back to a previous snapshot. Snapshots are performed automatically right before and after you upgrade Cumulus Linux using package install, and right before and after you commit a switch configuration using NCLU. In addition, you can take a snapshot at any time. You can roll back the entire file system to a specific snapshot or just retrieve specific files.
The primary snapshot components include:
- btrfs — an underlying file system in Cumulus Linux, which supports snapshots.
- snapper — a userspace utility to create and manage snapshots on demand as well as taking snapshots automatically before and after running
apt-get upgrade|install|remove|dist-upgrade. You can use
snapperto roll back to earlier snapshots, view existing snapshots, or delete one or more snapshots.
- NCLU — takes snapshots automatically before and after committing network configurations. You can use NCLU to roll back to earlier snapshots, view existing snapshots, or delete one or more snapshots.
Install the Snapshot Package
If you are upgrading from a version of Cumulus Linux earlier than version 3.2, you need to install the
cumulus-snapshot package before you can use snapshots.
Take and Manage Snapshots
Snapshots are taken automatically:
- Before and after you update your switch configuration by running the NCLU
- Before and after you update Cumulus Linux by running
apt-get upgrade|install|remove|dist-upgrade, via
You can also take snapshots as needed using the
snapper utility. Run:
For more information about using
snapper --help or
View Available Snapshots
You can use both NCLU and
snapper to view available snapshots on the switch.
net show commit history only displays snapshots taken when you update your switch configuration. It does not list any snapshots taken directly with
snapper. To see all the snapshots on the switch, run the
sudo snapper list command:
View Differences between Snapshots
To see a line by line comparison of changes between two snapshots, run the
sudo snapper diff command:
You can view the diff for a single file by specifying the name in the command:
For a higher level view; for example, to display the names of changed, added, or deleted files only, run the
sudo snapper status command:
You can remove one or more snapshots using NCLU or snapper.
Take care when deleting a snapshot. You cannot restore a snapshot after you delete it.
To remove a single snapshot or a range of snapshots created with NCLU, run:
To remove a single snapshot or a range of snapshots using
Snapshot 0 is the running configuration. You cannot roll back to it or delete it. However, you can take a snapshot of it.
Snapshot 1 is the root file system.
snapper utility preserves a number of snapshots and automatically deletes older snapshots after the limit is reached. It does this in two ways.
snapper preserves 10 snapshots that are labeled important. A snapshot is labeled important if it is created when you run
apt-get. To change this number, run:
NUMBER_LIMIT_IMPORTANT an even number as two snapshots are always taken before and after an upgrade. This does not apply to
NUMBER_LIMIT, described next.
snapper also deletes unlabeled snapshots. By default,
snapper preserves five snapshots. To change this number, run:
You can prevent snapshots from being taken automatically before and after running
apt-get upgrade|install|remove|dist-upgrade. Edit
/etc/cumulus/apt-snapshot.conf and set:
Roll Back to Earlier Snapshots
If you need to restore Cumulus Linux to an earlier state, you can roll back to an older snapshot.
For a snapshot created with NCLU, you can revert to the configuration prior to a specific snapshot listed in the output from
net show commit history by running
net rollback SNAPSHOT_NUMBER. For example, if you have snapshots 10, 11 and 12 in your commit history and you run
net rollback 11, the switch configuration reverts to the configuration captured by snapshot 10.
You can also revert to the previous snapshot by specifying last by running
net rollback last.
If you provided a description when you committed changes, mentioning a description rolls the configuration back to the commit prior to the specified description. For example, consider the following commit history:
net rollback description turtle rolls the configuration back to the state it was in when you ran
net commit description rocket.
Roll Back with snapper
For any snapshot on the switch, you can use
snapper to roll back to a specific snapshot. When running
snapper rollback, you must reboot the switch for the rollback to complete:
You can revert to an earlier version of a specific file instead of rolling back the whole file system:
You can also copy the file directly from the snapshot directory:
Configure Automatic Time-based Snapshots
You can configure Cumulus Linux to take hourly snapshots. Enable
TIMELINE_CREATE in the snapper configuration:
Caveats and Errata
You might notice that the root partition is mounted multiple times. This is due to the way the
btrfs file system handles subvolumes, mounting the root partition once for each subvolume.
btrfs keeps one subvolume for each snapshot taken, which stores the snapshot data. While all snapshots are subvolumes, not all subvolumes are snapshots.
Cumulus Linux excludes a number of directories when taking a snapshot of the root file system (and from any rollbacks):
|This directory is excluded to avoid user data loss on rollbacks.|
The log file and Cumulus support location. These directories are excluded from snapshots to allow post-rollback analysis.
There is no need to rollback temporary files.
Third-party software is installed typically in
This directory contains data for HTTP and FTP servers. Exclude this directory to avoid server data loss on rollbacks.
This directory is used when installing locally built software. Exclude this directory to avoid re-installing this software after rollbacks.
Exclude this directory to avoid loss of mail after a rollback.
This is the default directory for libvirt VM images. Exclude this directory from the snapshot. Additionally, disable Copy-On-Write (COW) for this subvolume as COW and VM image I/O access patterns are not compatible.
The GRUB kernel modules must stay in sync with the GRUB kernel installed in the master boot record or UEFI system partition.