https://samirtech.org/tags/recovery/ Recent content in recovery on Samirtech Hugo -- gohugo.io en-us Mon, 14 Sep 2026 08:30:00 +0100 https://samirtech.org/posts/how-my-restic-backup-protects-the-homelab/ Mon, 14 Sep 2026 08:30:00 +0100 https://samirtech.org/posts/how-my-restic-backup-protects-the-homelab/ Restic is one layer of my backup plan. It is not the backup for every file on every server, and understanding that boundary matters. What this backup is for My Restic job protects the configuration needed to rebuild the surrounding homelab. That includes container definitions, stack files, service configuration and selected system settings such as scheduled jobs, mounts, remote-access configuration and security-related configuration. The purpose is simple: if the host has to be rebuilt, I should not have to remember how every service was assembled. <p>Restic is one layer of my backup plan. It is not the backup for every file on every server, and understanding that boundary matters.</p> <h2 id="what-this-backup-is-for">What this backup is for</h2> <p>My Restic job protects the configuration needed to rebuild the surrounding homelab. That includes container definitions, stack files, service configuration and selected system settings such as scheduled jobs, mounts, remote-access configuration and security-related configuration.</p> <p>The purpose is simple: if the host has to be rebuilt, I should not have to remember how every service was assembled. I can recover the documented configuration, reinstall the software and bring the services back in a controlled order.</p> <h2 id="what-it-does-not-replace">What it does not replace</h2> <p>This Restic backup is not a substitute for the Immich backup. Immich photos and videos, its PostgreSQL data and its application recovery material need to be protected as a related recovery set through their own backup layers.</p> <p>That distinction prevents a common mistake: seeing a successful configuration backup and assuming the important application data is included. A backup only protects the sources it actually reads.</p> <h2 id="why-restic-is-useful">Why Restic is useful</h2> <p>Restic provides encrypted, deduplicated, incremental backups. After the first run, later runs can reuse data already stored and upload only changed content. Encryption means the repository can be held on storage that is not itself trusted with readable copies of the configuration.</p> <p>The repository password is therefore part of the backup. Without it, the encrypted data is not a recovery plan. I keep the password and the recovery notes separately from the machine being backed up, with more than one protected copy.</p> <h2 id="recovery-is-the-test">Recovery is the test</h2> <p>A completed job is only evidence that a backup process ran. It does not prove that the repository can be opened or that the files needed for a rebuild are present.</p> <p>A useful test is to restore selected configuration into a temporary area, inspect the files, and confirm that the deployment notes are sufficient to identify the services, storage relationships and required secrets. I must not restore over live configuration while testing.</p> <p>For a real rebuild, I would restore the configuration first, reinstall the required applications, recover secrets through the protected process, and then restore each service&rsquo;s data from the backup designed for that service.</p> <h2 id="the-lesson">The lesson</h2> <p>Restic is valuable because it preserves the instructions and configuration around the data. It reduces rebuild time and removes guesswork, but it works best as one clearly labelled layer beside the Immich media backup, database backup, TrueNAS snapshots and encrypted off-site copy.</p>