Backup and restore on Fedora: btrfs snapshots, tar and SELinux labels

The usual backup mistake is not “no backup” but a backup that will not restore. On Fedora there is an extra layer — SELinux labels — and a plain tar -cf throws them away.

Everything below was measured on F45.

First, decide what you are backing up

Layer	Contents	Method
System state	which packages, repository config	rpm -qa list plus config files
Files and data	/etc, /home, /var/lib	btrfs snapshot / tar / rsync
Whole-machine rollback	the entire root filesystem	btrfs snapshot

None replaces the others: a package list does not restore data, and a snapshot rollback is too blunt to fix “one wrong package”.

btrfs snapshots: placement matters more than the command

F45 defaults to btrfs (see storage), where snapshots are free — they only record copy-on-write references.

Look at the current layout:

findmnt -no FSTYPE /
sudo btrfs subvolume list /

btrfs

ID 256 gen 364 top level 5 path root
ID 257 gen 300 top level 5 path boot
ID 258 gen 368 top level 5 path home
ID 259 gen 368 top level 5 path var

The trap: a snapshot nested inside its own subvolume

Doing this directly:

sudo mkdir -p /snapshots
sudo btrfs subvolume snapshot -r / /snapshots/root-$(date +%Y%m%d)

puts the snapshot inside the root subvolume:

ID 260 gen 369 top level 256 path root/snapshots/root-20261027

top level 256 is the root subvolume. The next root snapshot therefore includes the previous one, and snapshot size snowballs.

The correct way: a separate top-level subvolume

sudo mkdir -p /mnt/top
sudo mount -o subvolid=5 /dev/sda3 /mnt/top          # mount the top level
sudo btrfs subvolume create /mnt/top/snapshots
sudo umount /mnt/top

Now snapshots land in snapshots, a sibling of root:

sudo btrfs subvolume snapshot -r / /mnt/top/snapshots/root-$(date +%Y%m%d-%H%M)
sudo btrfs subvolume list /mnt/top | grep snapshots

ID 261 gen 371 top level 5   path snapshots
ID 262 gen 371 top level 261 path snapshots/root-20261027-1747

top level 261 is the snapshots subvolume — no recursion.

Note

-r makes a read-only snapshot. It can be deleted with btrfs subvolume delete but not written to — exactly the state a backup should be in.

How much space they use:

sudo btrfs filesystem usage /

Overall:
    Device size:      19.90GiB
    Device allocated:       5.02GiB
    Device unallocated:    14.88GiB

A snapshot adds nothing to allocated until the original blocks are modified and diverge. A fresh snapshot costs almost nothing.

tar: without the right flags it drops SELinux labels

This is where Fedora backups break. One file, three states:

# create a file with a specific label
sudo mkdir -p /tmp/seltest/src
echo hi | sudo tee /tmp/seltest/src/file >/dev/null
sudo chcon -t httpd_sys_content_t /tmp/seltest/src/file

# archive it twice: plain, and with --selinux --xattrs
sudo tar -cf /tmp/seltest/no-selinux.tar -C /tmp/seltest/src .
sudo tar --selinux --xattrs -cf /tmp/seltest/with-selinux.tar -C /tmp/seltest/src .

# extract both and compare labels
sudo mkdir -p /tmp/seltest/a /tmp/seltest/b
sudo tar -xf /tmp/seltest/no-selinux.tar -C /tmp/seltest/a
sudo tar --selinux --xattrs -xf /tmp/seltest/with-selinux.tar -C /tmp/seltest/b
sudo ls -Z /tmp/seltest/src/file /tmp/seltest/a/file /tmp/seltest/b/file

original : unconfined_u:object_r:httpd_sys_content_t:s0
no-flag  : unconfined_u:object_r:user_tmp_t:s0
with-flag: unconfined_u:object_r:httpd_sys_content_t:s0

The middle line is the disaster: the label fell from httpd_sys_content_t to user_tmp_t, inherited from the destination directory. The content is intact; the service can no longer read it.

The correct pair of commands:

sudo tar --selinux --xattrs --acls -czf backup-etc.tar.gz -C / etc
sudo tar --selinux --xattrs --acls -xzpf backup-etc.tar.gz -C /mnt/restore

-p preserves permission bits. --selinux and --xattrs are both required — the first carries SELinux contexts, the second carries extended attributes (including capabilities).

Caution

--acls also has to be explicit. Miss any one of them and the restored system looks complete while services fail and permissions behave oddly — harder to diagnose than a missing file.

Package list: the only record of system state

rpm -qa | wc -l
rpm -qa --qf '%{NAME}\n' | sort > /var/backups/pkgs.txt

631

An F45 base system is 631 packages. To restore:

sudo dnf install $(cat /var/backups/pkgs.txt)

You also want the repository configuration and recent transactions:

cp /etc/yum.repos.d/*.repo /var/backups/ 2>/dev/null
ls /usr/share/dnf5/repos.d/ > /var/backups/repos-list.txt   # F45 packaged repos
sudo dnf history list | head -5

ID Command line                            Date and time       Action(s) Altered
10 dnf -y install dbus-daemon              2026-10-26 18:21:45                 1
 9 dnf -y install dbus-tools               2026-10-26 18:20:19                 1

Two things to do after restoring

One, restore SELinux labels (if they were not preserved, or the files went to a different path):

sudo restorecon -Rv /etc /var/www /home

Two, confirm services come back:

sudo systemctl daemon-reload
systemctl list-units --failed

Verify the backup — the most important step

An unverified backup is not a backup. The minimum set:

# 1) can the archive be read
tar -tzf backup-etc.tar.gz | wc -l

# 2) can it be extracted somewhere temporary
mkdir -p /tmp/verify && tar -xzpf backup-etc.tar.gz -C /tmp/verify

# 3) are the key files there and correct
diff -q /tmp/verify/etc/hostname /etc/hostname

# 4) are the labels intact
ls -Z /tmp/verify/etc/ssh/sshd_config

Verifying a btrfs snapshot is even more direct — mount it and look:

sudo mount -o ro,subvol=/snapshots/root-20261028-0300 /dev/sda3 /mnt/check
ls /mnt/check/etc | head
sudo umount /mnt/check

Scheduling backups

Use a systemd timer rather than cron (F45 minimal images ship no crontab); the pattern is in systemd services and timers:

/etc/systemd/system/backup-etc.timer

[Unit]
Description=Nightly etc backup

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

Put the tar --selinux --xattrs --acls ... line in the matching .service. Persistent=true makes a missed run catch up after boot.

Related pages

• Storage and filesystems — btrfs subvolumes, mounts and capacity
• SELinux — why labels matter and how to restore them
• systemd services and timers — writing the scheduled backup
• Upgrading to Fedora 45 — what to back up before upgrading
• Official: Btrfs