My configuration files for the btrbk backup tool. This configuration utilizes Btrfs to take hourly snapshots and incremental backups of specific subvolumes.
This repository contains the btrbk configuration files for my various systems. Devices that take snapshots of subvolumes, dubbed target devices, do so hourly via their configurations. Backups are handled from an isolated, remote system via a pull strategy over an SSH connection. The setup and configuration vary according to whether the device is a remote backup device or a system taking local snapshots of the important data. The instructions here describe how to configure everything to get this working for both the target and backup roles. It’s recommended that the backup systems be configured first, as this will produce the SSH public keys required to configure the target systems.
-
Install btrbk.
sudo rpm-ostree install btrbk
-
Reboot.
sudo systemctl reboot
-
Create the necessary subvolumes and directories.
- Backup
-
-
Create the target directories where the backups will reside.
sudo mkdir --parents /run/media/system/jwillikers_Backup_02/{meerkat,rockpro64}.jwillikers.io
-
- Target
-
-
Configure any Btrfs filesystems as necessary. The argument following the
volumesdirective denotes root of the particular Btrfs filesystem. In many cases, this might just be/if the root filesystem is Btrfs. My configurations for target devices have the home directory on its own disk and therefore its own Btrfs filesystem, which results involume /var/home. Get this part sorted out first by orchestrating the underlying disks, partitions, and filesystems as they should be. -
Ensure that any subvolumes mentioned in the configuration file exist. Either create new subvolumes or migrate any existing directories to be subvolumes. The following command creates the subvolume
/var/home/core/container-volumes.sudo btrfs subvolume create /var/home/core/container-volumes
-
Correct ownership of the subvolume as needed.
sudo chown --recursive core:core /var/home/core/container-volumes
-
Create the necessary
.snapshotssubvolumes where the snapshots will be stored. Each volume in the configuration must contain its own.snapshotssubvolume owned by the root user. For instance, when backing up a subvolume that is under the volume/run/media/system/JWillikers_Datacreate the/run/media/system/JWillikers_Data/.snapshotssubvolume.sudo btrfs subvolume create /run/media/system/JWillikers_Data/.snapshots
-
-
Configure SSH.
- Backup
-
-
Create a directory for storing the SSH key that will be used to access the target machine for creating backups.
sudo mkdir --parents /etc/backup/ssh
-
Generate the backup SSH key.
sudo ssh-keygen -t rsa -b 4096 -f /etc/backup/ssh/id_rsa -C $USER@(hostname) -N ""
-
Note the public key just created. This key will be placed in the
authorized_keysfile of thebackupuser.sudo cat /etc/backup/ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDU9d2LjH01...3dmTrNfJavtZ7Q62GqxnL0D6cjNNrxew== backup@rockpro64.jwillikers.io
-
Add the host keys of the target machine to the user’s
known_hostsfile on the machine carrying out the backups.sudo --user root ssh -i /etc/backup/ssh/id_rsa rockpro64.jwillikers.io
-
- Target
-
-
Create a dedicated
backupgroup for thebackupuser.sudo groupadd --gid 801 --system backup
-
Create a dedicated
backupuser account to allow Btrbk to login.sudo useradd \ --btrfs-subvolume-home \ --comment "Account used for remote backups." \ --create-home \ --gid backup \ --shell /usr/bin/bash \ --system \ --uid 801 \ backup -
Create a new sudoers policy file for the
backupuser.sudoedit /etc/sudoers.d/99-backup
-
Allow the backup user to run the necessary commands as root to manipulate Btrfs snapshots.
/etc/sudoers.d/99-backupCmnd_Alias BTRBK_BACKUP = /usr/sbin/btrfs, /usr/bin/readlink backup rockpro64.jwillikers.io=NOPASSWD:BTRBK_BACKUPℹ️Ensure that
btrfsis at the correct location, i.e./usr/sbin/btrfs, if using a different installation method. -
Create the
backupuser’s SSH directory.sudo --user backup mkdir --parents /home/backup/.ssh
-
Configure Btrbk’s SSH command filter so that only the relevant Btrfs commands can be executed from the backup machine. Replace the sample key used here with the public SSH key generated on the backup machine.
/home/backup/.ssh/authorized_keyscommand="/usr/share/btrbk/scripts/ssh_filter_btrbk.sh --sudo --source --target --delete --info --send --receive --restrict-path /run/media/system/JWillikers_Data" ssh-rsa AAAAB3NzaC1...hwumXFRQBL root@backup-01.jwillikers.ioThis uses the
--restrict-pathoption to restrict commands to operating only on paths at or below/btrfs_pool. Be sure to configure this appropriately so that access is only allowed for the necessary volumes in the system’s configuration. -
Make sure that the
backupuser’s.sshdirectory and included files have the correct ownership.sudo chown --recursive backup:backup /home/backup/.ssh
-
-
Make a
~/Projectsdirectory in which to clone the repository.mkdir --parents ~/Projects -
Clone this repository.
git -C ~/Projects clone git@codeberg.org:jwillikers/btrbk-config.git -
Change to the repository directory.
cd btrbk-config -
Copy the relevant config file to the
/etc/btrbk/directory asbtrbk.conf.sudo cp btrbk.rockpro64.conf /etc/btrbk/btrbk.conf
-
Edit the
btrbk.timersystemd unit to fire as often as you want.sudo systemctl edit btrbk.timer
I switch my timer to run hourly instead of daily using the configuration below.
/etc/systemd/system/btrbk.timer.d/override.conf[Unit] Description=btrbk hourly backup [Timer] OnCalendar=hourly -
Enable and start the systemd timer.
sudo systemctl enable --now btrbk.timer -
Start a tmux session in case the first sync takes a while to complete.
tmux
-
Manually run the
btrbk.serviceservice.sudo systemctl start btrbk.service
Please refer to the project’s Code of Conduct.