Learn Void Linux - Backup, Restore & Update

#Introduction

Data without a backup is just a request to lose it. Episode 16 covers a healthy backup, restore, and update strategy for a Void system: backing up files with rsync, instant rollback with Btrfs snapshots, tracking configuration changes with etckeeper, plus safe upgrade procedures and recovery from a rescue ISO.

Backup isn't about installing one tool; it's a combination of strategies for different kinds of data. System configuration, application data, and system snapshots each need a different approach.

Let's build layered backup.

#Backing Up with rsync

#Back Up Data to a Remote

rsync is the most flexible backup tool. To back up important directories to a remote server:

rsync -aAXv /etc /root/backup /home/ \
    --exclude='/var/cache' \
    user@backup-server:/srv/backup/voidlab

The rsync -aAXv command archives files with complete permissions and attributes. The --exclude option prevents unneeded directories from being copied.

#Incremental Backups

For an efficient rolling backup, use --link-dest so unchanged files aren't rewritten:

rsync -aAX --link-dest=/srv/backup/voidlab/latest \
    /home/ /srv/backup/voidlab/$(date +%F)

#Btrfs Snapshots

#Creating a Snapshot

If your root uses Btrfs from episode 10, you can create a snapshot before risky changes:

sudo btrfs subvolume snapshot -r /mnt/@root /mnt/.snapshots/@root-$(date +%F)

The btrfs subvolume snapshot -r command creates a read-only snapshot of the root subvolume. Store snapshots in a separate subvolume so they don't get snapshotted repeatedly.

#Viewing and Deleting Snapshots

List snapshots and delete those no longer needed:

sudo btrfs subvolume list /mnt
sudo btrfs subvolume delete /mnt/.snapshots/@root-2026-08-01

#etckeeper: Versioning /etc

#Initializing etckeeper

etckeeper tracks configuration changes in /etc with git. Install and initialize:

sudo xbps-install -S etckeeper
sudo etckeeper init
sudo etckeeper commit -m 'Initial commit'

Every time you change a configuration, commit the change:

sudo etckeeper commit -m 'Hardening SSH config'
sudo etckeeper vcs log --oneline | head

The etckeeper vcs log --oneline command shows the configuration change history — very useful for finding out what changed when the system misbehaves.

#Safe Upgrade Procedures

#Preparation Before an Upgrade

Don't just run xbps-install -Su on a production system. Prepare first:

sudo xbps-install -S
sudo xbps-pkgdb -a
df -h /

Make sure the repositories are synced, the database is healthy, and there's enough disk space before a big upgrade.

#Running the Upgrade

Run the upgrade with safe options:

sudo xbps-install -Su

If the upgrade involves a kernel, remember to regenerate GRUB and the initramfs as in episode 11. Keep a list of services that need to be restarted after the upgrade.

#Recovery with a Rescue ISO

#Booting the ISO and Mounting the System

If the system can't boot, use a live ISO to recover. Boot the ISO, then mount the system:

sudo mount /dev/sda3 /mnt
sudo chroot /mnt

The chroot /mnt command puts you inside the broken Void system. From here you can perform repairs like regenerating GRUB or rolling back packages.

#Rolling Back Packages

To roll back a single package to a previous version, the repository keeps old indexes:

xbps-query -R -p version <name>
xbps-install -R <name>-<version>

#Conclusion

Episode 16 built a Void backup and recovery strategy: backing up files with rsync, Btrfs snapshots for fast rollbacks, etckeeper for tracking configuration, safe upgrade procedures with initial checks, and recovery via a rescue ISO and chroot.

Key takeaways:

• rsync -aAX backs up files with complete attributes.
• Btrfs snapshots allow instant rollback before risky changes.
• etckeeper tracks /etc changes with git.
• Check the repository, database, and disk before xbps-install -Su.
• A rescue ISO and chroot rescue a system that fails to boot.
• Check available versions before rolling back a package.

In the next episode, episode 17, we will cover rolling release and the nonfree repo — understanding Void's continuous update model, using void-updates to wait for stable updates, and adding the nonfree repository for drivers and proprietary packages.