Feature Request: Add Support for BTRFS Snapshots

[ei8ht187]

I'm using OpenSUSE and therefore BTRFS with Snapper. Therefore it would be nice to have an integration for snapper and btrfs snapshots in Vorta.
Idea:
When Backup starts, Vorta creates a Snapshot of the Filesystem via either snapper or direct btrfs command. After the snapshot is created, Vorta creates the backup automatically from this snapshot.

[Hofer-Julian]

Hi!
Thanks for your feature request.
Unfortunately, this is out of Vorta's scope.
I see there is https://github.com/ricardomv/snapper-gui. Unfortunately it hasn't seen much activity in the past two years.

[mischaelschill]

Maybe this helps: what you want to do can be done with custom shell commands. I do something similar for my vm backups, although I run borgmatic for backing up and vorta only for viewing:

#!/bin/bash
for dir in `find /var/lib/libvirt/images/ -mindepth 1 -maxdepth 1 -type d`
do
	vm=`basename "$dir"`
	pushd "$dir"
	snap=`ls .snapshots | sort -n | tail -n1`
	path=".snapshots/$snap/snapshot"
	backuppath="/var/lib/libvirt/backup/$vm"
	echo mounting $path to $backuppath
	mount -o bind "$path" "$backuppath"
	popd
done

borgmatic --create | logger -t borg

umount -q /var/lib/libvirt/backup/*

This script finds the latest snapshot and bind-mounts them to another path. I ignored the images path so that borg does not backup images of currently running vms. I see no reason why this couldn't be turned into two shell scripts for pre/post in vorta, although you may need to setuid them.

[mauromol]

I was going to open a feature request just like this, to support btrfs snapshots and LVM snapshots, when available.

It's really sad to know it's out of Vorta's scope: I think source consistency is a really important aspect in a backup application, too often underestimated. Also, I think that conceptually this is as simple as creating snapshots of source folders before running borg create, properly adapt exclusion rules to the new source locations, run borg create on the snapshot mount points and finally unmount the snapshots at the end.

I really hope you can reconsider. IMHO, it would be an excellent and valuable "plus" feature for Vorta.

[Hofer-Julian]

I still think that this shouldn't be part of Vorta, but I am curious what this would help you.
Why don't you backup the folders you want directly, instead of creating a snapshot beforehand. The result should be the same.

[mauromol]

I won't be the same unless no write activity is in progress on those files. If borg could back it up instantly, then yes, it would be the same. But if it takes, say, 5 minutes to terminate the job (start on t0, end on t1) and files are changed between t0 and t1, the final archive will neither reflect the state of your source at t0, nor possibly the state at t1.
Please see: https://borgbackup.readthedocs.io/en/stable/quickstart.html#important-note-about-files-changing-during-the-backup-process
There, LVM and ZFS are mentioned. BTRFS of course is another file system which supports snapshotting like ZFS.

[Hofer-Julian]

Okay, that is indeed a valid point

[Foosec]

Id just like to add that most backup solutions for example windows use volume shadow copy, which is esentially a BTRFS snapshot. And i believe MacOS offers a similar feature.

[real-yfprojects]

So what about #829 (comment), can this be done with a pre and post backup script? In that case we could add a How-To to our docs saving the efford of adding a new feature.

[NICHOLAS85]

Hello all. I ran into this discussion while researching this topic and figured out a solution I'm satisfied with. As has been pointed out, running a backup on your live home directory could lead to an inconsistent backup, as Borg is not instant. To avoid this, I've created a pre-backup script that snapshots home, lets Vorta create a backup from this snapshot, then a post-backup script that deletes the snapshot, utilizing BTRFS.

This was tested on the latest stable Aurora-dx image (42.20250727.1).

First, decide where you want the snapshot to reside. I've created a $HOME/.snapshots directory for this.

$ mkdir $HOME/.snapshots

Next, you must allow your user to run the btrfs snapshot commands without authentication if you want this to be seamless. Exercise caution, as you don't want to delete the wrong subvolume. Ensure you replace /var/home and /var/home/nicholas with your system's actual values:

# visudo -f /etc/sudoers.d/50-btrfs-snapshot-cmd
%wheel ALL=(ALL) NOPASSWD: /usr/bin/btrfs subvolume snapshot -r /var/home/ /var/home/nicholas/.snapshots/home-snapshot
%wheel ALL=(ALL) NOPASSWD: /usr/bin/btrfs subvolume delete -c /var/home/nicholas/.snapshots/home-snapshot

Lastly, you configure Vorta.
Under the sources tab, you will backup your snapshot instead of $HOME, in my case /var/home/nicholas/.snapshots/home-snapshot/nicholas
Under Schedule > Shell Commands you'll add the snapshot commands. Since I installed Vorta as a flatpak, I must prefix my commands with /usr/bin/flatpak-spawn --host to run them on the host system. If Vorta is installed directly, you can likely drop the prefix.
Pre-backup:

/usr/bin/flatpak-spawn --host sudo btrfs subvolume snapshot -r /var/home/ /var/home/nicholas/.snapshots/home-snapshot

Post-backup:

/usr/bin/flatpak-spawn --host sudo btrfs subvolume delete -c /var/home/nicholas/.snapshots/home-snapshot

Done! From now on, every time Vorta runs, it'll make a snapshot of $HOME, create a backup from this snapshot, and then delete the snapshot when it's complete. I'm sure you could easily adapt this to other snapshotting filesystems.
A heads up: Vorta doesn't seem to log the actual output of the shell commands it runs, so if you're running into issues or aren't sure they're running, run Vorta from your command line, and you'll see the actual output.

[goebbe]

@NICHOLAS85 Thank you! This is very useful and contains a lot of useful information!
I would like to add a word of caution, though:
Depending on the Linux distribution, different ways to set up and mount btrfs-filesystems are used. So if somebody wants to apply this, he/she should do some research, first. ;-)

[m3nu]

Interesting. We should document this.

[Foosec]

For anyone searching for a block device level solution; https://github.com/datto/dattobd