U3 / 5 guides
Backups and restore
A backup only counts once it has been restored. Each guide here restores to a clean machine and verifies the result with checksums or application checks, and clocks every step.
- 2026-11-010.19.1restic vs borg vs kopia: measured on 6 GBOn this dataset restic made the smallest repository (3.86 GB against 5.01 GB for borg and 5.02 GB for kopia) and restored in 14 s; kopia's default restore took 140 s. All three restored all 42,011 files with matching SHA-256 checksums in every run.
- 2026-11-021.37.4Vaultwarden restore drill in 29.1 s, and live SQLite copiesA stopped-container restic backup of the Vaultwarden volume restored into a brand-new VM and all 2,000 items decrypted correctly through the API, 29.1 s after the fresh VM started booting (one run, Docker preinstalled, backup disk attached at boot). In 40 copies of a live 32,000-item database under write load, a copy of db.sqlite3 without its -wal file failed PRAGMA integrity_check 10 of 10 times, while copying the whole directory with restic or rsync, and sqlite3 .backup, each passed 10 of 10. An earlier run in which the database kept growing to about 700,000 items did produce failed restic and rsync copies, so database size may matter; use sqlite3 .backup or stop the container.
- 2026-11-0218.6Postgres in Docker: four backups taken under loadOn this test every method (pg_dump plain and custom, pg_basebackup, and a raw cp -a of the running data directory) restored to a database whose row counts, balance invariant and amcheck all passed in 3 of 3 runs. That does not make the raw copy safe: it survived by crash recovery, which PostgreSQL's documentation says you cannot rely on without a shutdown or an atomic snapshot.
- 2026-11-012.2.2-0ubuntu9.5ZFS vs Btrfs snapshots: cost, rollback, send/receiveBoth filesystems took a snapshot of a 5 GiB tree in well under a second even during a 4k random-write load (median 325 ms for ZFS, 173 ms for Btrfs), and a snapshot held about 537 MB when 255 of 2,048 files were overwritten or deleted. The practical differences were behavioral:
zfs rollback -ris a single command that destroys newer snapshots, Btrfs's subvolume documentation lists no rollback command (the test deleted the subvolume and snapshotted the base instead), and that deletion left 5 to 12 s of background cleanup (median 11 s). - 2026-11-012.2.2-0ubuntu9.5ZFS mirror disk failure: offline, dd corruption, replaceOn a two-disk ZFS mirror (OpenZFS 2.2.2 from Ubuntu's packages), taking a disk offline, overwriting 256 MiB of one side with random bytes, and replacing a faulted disk all ended with every file matching its SHA-256 in 6 of 6 runs. Scrub repaired 127 MiB to 129 MiB of damage at 4 GiB of data, and replacing the disk took a median of 10.8 s for 4 GiB. This simulates failures with virtual disks; it is not a test of real disk failure.