Learning Artix Linux - Backup, Restore & System Update

#Introduction

No system is immune to damage — especially a rolling-release system updated continuously. Episode 16 covers the most important preparation: backup with rsync and snapshots, and the pacman -Syu update procedure done safely, with a rollback plan if something goes wrong.

The principle is simple: backup isn't about storing data, it's about the ability to restore. You only have a backup when you've successfully recovered data from it. Let's build habits that guarantee that.

#Backup with rsync

#Synchronizing Data

rsync is the go-to tool for file synchronization. For local data backup, the combination of -a (archive), --delete (delete files gone from the source), and -P (progress) is standard:

rsync -aP --delete /home/devnull/Documents/ /mnt/backup/Documents/

rsync -aP --delete ensures the backup mirrors the source exactly. Be careful with --delete — pointing it the wrong way means data gets deleted, not backed up.

#Full System Backup

For a full system backup, use rsync with exclusions for directories that don't need to be copied:

sudo rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*"} / /mnt/backup/root/

Note the exclusion list: pseudo-filesystems like /dev, /proc, and /sys are recreated automatically at boot and must not be copied. The brace-enclosed --exclude order works like in the shell.

#Timeshift and Snapper

#Timeshift for Scheduled Snapshots

Timeshift creates system snapshots you can restore at boot. Install it and create your first snapshot:

sudo pacman -S timeshift
sudo timeshift --create --comments "before a major update"

timeshift --create creates a snapshot per the selected mode (Rsync or Btrfs). List snapshots with timeshift --list.

#Snapper as an Alternative

Snapper works primarily with Btrfs and offers automatic snapshots at intervals. Install and configure:

sudo pacman -S snapper
sudo snapper -c root create-config /

snapper create-config creates a timeline configuration for the root partition. Automatic snapshots are then made at intervals configured in /etc/snapper/configs/root.

#Btrfs Snapshots for Rollback

#Creating Manual Snapshots

If you use Btrfs (episode 10), you have the most reliable rollback tool: subvolume snapshots. Create a snapshot before any major change:

sudo btrfs subvolume snapshot -r /mnt/@root /mnt/@snap-pre-update

btrfs subvolume snapshot -r creates a read-only snapshot. List and inspect snapshots with:

sudo btrfs subvolume list /

The output of btrfs subvolume list / shows all subvolumes and snapshots. You'll use this list when rolling back.

#Restoring from a Snapshot

To restore the system to a snapshot, boot from the live ISO, mount, and swap the root subvolume with the snapshot:

mount /dev/vg0/root /mnt
mv /mnt/@root /mnt/@root.broken
btrfs subvolume snapshot /mnt/@snap-pre-update /mnt/@root
reboot

After restoring, the system returns to the state at snapshot time. Keep @root.broken until the system proves healthy, then remove it.

#The Safe pacman -Syu Procedure

#Full and Careful Updates

Updates on a rolling system can always introduce conflicts. The safe procedure: back up first, then run a full update — never -Sy without -u followed by partial installs:

sudo pacman -Syu

pacman -Syu synchronizes the database and upgrades all packages at once. Read the output carefully, especially WARNING messages about config files changed to .pacnew.

#Reading .pacnew Files

On update, config files you've modified aren't overwritten; pacman stores the new version as .pacnew. Compare and merge your changes:

sudo pacman -Qo /etc/nginx/nginx.conf.pacnew 2>/dev/null
diff -u /etc/nginx/nginx.conf /etc/nginx/nginx.conf.pacnew

diff -u shows the differences between the active config and the new version. Consider each change, then move things over as you decide. Ignoring .pacnew files long-term causes stale configurations.

#Handling Manual Conflicts

If an update asks for intervention over a file or package conflict, don't panic. Use pacman -Qkk to check integrity, then resolve things one by one. If in doubt, ask on the Artix forum with the full update output.

#The Rollback Plan

#When to Roll Back

Rollback is needed when the system can't boot or core services break after an update. Options in order: enter GRUB to another kernel, restore a Btrfs snapshot from the live ISO, or use timeshift from the boot menu. Snapshots are the fastest lifesaver.

#Practice: A Simulation

Train for the scenario before it happens: create a snapshot, make a deliberately breaking change, then restore. This habit makes the rollback procedure feel automatic in an emergency:

sudo timeshift --create --comments "practice"
sudo timeshift --list

timeshift --list shows the list of snapshots available for restore. You'll know exactly what to do when the system is unhealthy.

#Conclusion

Episode 16 built emergency readiness: rsync for data synchronization, timeshift and snapper for automatic snapshots, Btrfs snapshots for full rollback, the safe pacman -Syu procedure, and a practiced rollback plan.

Key takeaways:

• Backup means the ability to restore, not just copying data.
• rsync with -aP --delete for data; avoid pseudo-filesystems when backing up root.
• Timeshift and snapper provide restorable snapshots.
• Read-only Btrfs snapshots are the most reliable rollback tool.
• Run a full pacman -Syu and read WARNING messages and .pacnew files.
• Practice rollbacks periodically so they're automatic in an emergency.

In the next episode, episode 17, we'll cover rolling release and testing repositories — the continuous release model, the difference between world and world-testing, the base/world/galaxy repo structure, and mirror synchronization.