linux-backup-system 4.0.2 — proof of concept confirmed

linux-backup-system 4.0.2 — proof of concept confirmed

This release carries the 4.0 milestone forward: the suite is proven to work end
to end — back up a real machine, restore it onto a different, blank disk with
the suite's own restore scripts, and boot the restored disk into a fully working
system — verified on bare metal, with the original disks proven untouched.

Four bare-metal restores have now passed on real hardware, on four different
distros and four very different layouts:

• Manjaro — btrfs root on LUKS2 (sd-encrypt), systemd-boot + UKIs,
  Secure Boot with sbctl keys (2019 ASUS ZenBook UX534FTC).
• Linux Mint 22.3 — ext4 on LVM-on-LUKS2 with a keyfile, encrypted LUKS2
  argon2id /boot opened by GRUB 2.14 (EFI), SELinux relabel boot; on a
  2014 ASUS X750JN, a 3-SSD triple boot with Linux Mint, Fedora and
  EndeavourOS. testbed.sh collect: VERDICT: PASS.
• Fedora 44 Workstation — btrfs root and home subvolumes on LUKS2 argon2id
  unlocked by dracut, vfat XBOOTLDR /boot + ESP at /efi, systemd-boot +
  kernel-install UKIs, SELinux enforcing; the same X750JN, its Fedora SSD
  restored. testbed.sh collect: VERDICT: PASS, 99.99% of 587,637 files
  restored with the archived size, system state running.
• EndeavourOS — ext4 root on LUKS2 argon2id unlocked by dracut, vfat
  XBOOTLDR /boot + ESP at /efi, systemd-boot Type #1 entries for linux and
  linux-lts, KDE Plasma 6.7 on Wayland; the same X750JN, its EndeavourOS SSD
  restored. testbed.sh collect: VERDICT: PASS, 99.96% of 583,535 files
  restored with the archived size, system state running.

None of these machines is "factory standard": custom GRUB builds, unusual
encryption layouts, multi-boot disks and years of leftovers. That is exactly
what the suite has to survive, and it is why every result is proven per setup
and recorded in the README's Tested / untested tables — every successful test
on real hardware is recorded and documented there.

A passing verdict is not the end of a test. Forensic inspection of the first
restored Fedora drive found two directory-ownership faults every automated
check had passed: ~/.local and ~/.local/share restored with the wrong
ownership and permissions (root:root 700), because a folder kept inside an
excluded tree was archived without its parent directories; and the cache
directories packages create under /var/cache (lightdm, akmods) missing or
root-owned. 4.0.2 archives the parents of every kept folder and the first
level of /var/cache, the restore repairs directories older archives left
root-owned, and the test bed's boot report now flags root-owned directories in
a home. A second restore re-verified the ownership fix.

The EndeavourOS run tested the test bed itself. Its first test boot logged in to
a desktop with no panel, no launcher and no terminal: the functional test
archive kept ~/.config but not ~/.local/share, where Plasma keeps its panel
theme, plasmoids, color schemes and icons. The same boot unlocked the host's SD
card, because the restored crypttab and its keyfile came back with the restore.
Neither was a fault in the restore scripts: the test archive now keeps a home's
desktop state, and the test drive no longer unlocks or mounts the host's other
disks. A second restore booted into the full desktop and passed.

The same run fixed the leftovers a long-lived system carries (4.0.1): unified
kernel images of removed kernels, a rescue image no generator rebuilds, a dead
ESP GRUB stub, a GRUB font that made grub-mkconfig abort, and files labelled
with an SELinux type whose policy module was gone — named on the live system by
backup-verify.sh section 7 and repaired by --fix.

What 4.0 does not claim: a setup whose rows are still ⚠️ or ❌ has not been
restored and booted yet. Following 4.x releases will fill those rows in —
shim Secure Boot, Limine, rEFInd, restore
from a live USB, Raspberry Pi, GRUB legacy BIOS — each turning green only when
its own test-bed run passes, together with ongoing code improvements found
along the way. openSUSE and the distros the package map does not know wait on
contributions.

Until every row describing your machine is ✅, use the suite for testing only.