`--use-fs-snapshot` for ZFS

[ShadowJonathan]

Output of restic version

restic 0.12.1 compiled with go1.16.6 on linux/arm64

What should restic do differently? Which functionality do you think we should add?

I'm currently using ZFS, which has native snapshotting functionality, and it'd help somewhat if i could simply be able to denote --use-fs-snapshot, and restic will handle creating/destroying the underlying ZFS snapshot(s) of the filesystems im trying to back up.

What are you trying to do? What problem would this solve?

This'll simplify the process of automatically creating ZFS snapshots massively, as currently its a bunch of commands and change-directory tricks to get a right name for my backup

[rawtaz]

Yeah. It's pretty simple; For this to exist, someone has to extend the --use-fs-snapshot feature (which currently only supports Windows' VSS) to also support/use ZFS snapshots on relevant platforms, including some proper code and tests and documentation for it, then it needs to be reviewed and tested.

[Trumeet]

Supporting ZFS is great, but it could be better it it supports other CoW filesystem snapshoting as well (e.g. Btrfs).

[MichaelEischer]

There's an example wrapper script for BTRFS in the forum: https://forum.restic.net/t/creating-btrfs-snapshot-before-runnning-restic-backup/4725/3 . I guess that could also be adapted to other filesystems.

[Freaky]

I wrote this script for use with Borg - it recursively nullfs/bind mounts ZFS snapshots into a directory, with flags to exclude or pass-through filesystems read/write, mount /dev etc.

I chroot my backup script into it using the execute subcommand without any issue. Should be fine with restic too.

[cyounkins]

While this would be nice, it's pretty easy to do yourself. Here's another example in bash:

#! /usr/bin/env bash

# Exit on error. Append "|| true" if you expect an error.
set -o errexit

# Destroy old snapshot, if any
zfs destroy tank@snap || true

# Create snapshot
zfs snapshot tank@snap

# Backup read-only snapshot via its mount point
restic backup /tank/.zfs/snapshot/snap/

# Destroy the snapshot
zfs destroy tank@snap

[dekimsey]

I played with implementing this, but I ran into a few issues with the architecture.

1. restic wants to snapshot the entire fs starting at /. The VFS layer doesn't know what is being targeted (so it's unable) correctly snapshot only the relevant datasets.
2. VFS snapshot doesn't have any good way to determine what FS volumes it should be snapshotting. On a system that has say both btrfs and zfs, it wouldn't be able to handle that gracefully I don't think.
3. And the known issues of the absolute pathing. If there was a way to instead resolve the path to the underlying system volume, that might work better (at least in ZFS).

This may have been in part due to the fact that it's walking the tree from /. But zfs volumes tend to be placed elsewhere. In my testing, when I tried backing up /tank0/ds0/archive the VFS calls referenced / (which is on the zroot pool).

# setenv RESTIC_REPOSITORY /tmp/test
# setenv RESTIC_PASSWORD a-test-password
# rm -rf $RESTIC_REPOSITORY; ./restic backup --use-fs-snapshot --no-scan --verbose /tank0/ds0/archive/a-folder
open repository
repository 0de655a8 opened (version 2, compression level auto)
lock repository
using parent snapshot bee7349b
load index files
start backup on [/tank0/ds0/archive/a-folder]
creating VSS snapshot for [/]
successfully created snapshot for [/]
mountpoints in snapshot volume [/]:
  - ...

In my testing I worked around this by simply recursively snapshotting the entire FS, but that seemed like a kludge.

(I also noticed that a failure to snapshot does not stop the backup operation!)

I'd be happy to share my WIP if that'd help discussion. Just let me know!