Restic 0.11.0

Restic 0.11.0 was released today! For downloading the new release and to see a more detailed list of important changes, please head over to GitHub. If you already have restic (0.9.4 or later), you can use the self-update command to automatically download and verify the new release.

This is a companion discussion topic for the original entry at

Thanks for the work! Appreciate the early release with this feature. It would be great to support LVM snapshots for Linux.

Generic snapshot support for Linux is not going to be straightforward at all. There are multiple snapshot types each with their own caveats.

  • LVM snapshots
    • LVM operates at the block level. It is possible for one filesystem to be spread across multiple LVs (uncommon but useful in some cases) and for multiple filesystems to exist on the same LV (very uncommon). Detecting which LVs must be snapshotted for a given filesystem is not trivial.
    • There can be layers between the filesystem and the LV, such as crypto, md-raid, loopback, and other device-mapper mappings. It may not be possible to instantiate these layers on top of the snapshot automatically.
    • The VG needs free space to create a snapshot.
    • The size of the snapshot needs to be specified (this is the reservation for COW’d blocks).
    • The snapshots need to be mounted somewhere.
  • btrfs snapshots
    • There is no sane automatic way to determine where to put the snapshot. Within the subvolume being backed up would be the most straightforward approach but has its own potential issues.
  • ZFS snapshots
    • I lack the expertise to give details, though I assume it would mostly be similar to btrfs snapshots.
  • Probably some others.

This all gets way more complicated when multiple filesystems are involved:

  • For LVM, all of the issues are amplified: now we need to determine a set of distinct LVs that must be snapshotted and we need to create snapshots for each, specifying the size. It may not be possible to automatically determine sane sizes for each snapshot as this will depend on the expected write patterns to the LV during the backup. Each snapshot is itself atomic, but all snapshots together are not atomic with respect to each other.
  • For btrfs, subvolume snapshots are not recursive; any child subvolumes have to be snapshotted separately. Similar to LVM snapshots, each btrfs snapshot is itself atomic, but many snapshots cannot be made atomically as a group.

The simplest cases can probably be covered by adding restrictions:

  • No more than one filesystem is backed up (backup-with-snapshot would imply --one-file-system).
  • For LVM snapshots, the filesystem being backed up must exist directly on a LV; there cannot be any intermediate layers. A snapshot size or % of free space would need to be specified.

In all cases, paths would need to be adjusted to match the original path, and whatever was created would need to be torn down before restic terminates.

I would submit that it would be far better for restic to provide some example scripts that manage these processes (I could provide one for LVM and btrfs) and let system administrators adapt them to their own systems, for the following reasons:

  • Linux doesn’t have a VSS equivalent, meaning that applications don’t have a chance to make their on-disk data consistent before the snapshot is taken. Ideally this shouldn’t be necessary; if an application can survive an unexpected power down, it should be able to survive a snapshot. Nevertheless, without giving applications a chance to make their on-disk data consistent, the snapshot is “dirty.”
  • The system administrator really needs to understand what is going on under the hood, especially for the case where restic is unable to clean up the snapshot environment due to a hard crash or a power cut. There is no automatic LVM/btrfs snapshot cleanup on Linux; this has to be done manually. Blindly using such a feature leaves the sysadmin unaware of what must be done in this scenario. Failing to clean up snapshots can lead to the disk filling up (btrfs) or wasted reserved space (LVM) which could cause backups (or the whole system) to unexpectedly malfunction at a later date.
1 Like