Guide Off-Site Linux Backups with Restic: Build and Test a Recovery Plan - Printable Version +- AdminsForum (https://adminsforum.com) +-- Forum: Security and performance (https://adminsforum.com/Forum-security-and-performance) +--- Forum: Backups and recovery (https://adminsforum.com/Forum-backups-and-recovery) +--- Thread: Guide Off-Site Linux Backups with Restic: Build and Test a Recovery Plan (/Thread-guide-off-site-linux-backups-with-restic-build-and-test-a-recovery-plan)

Off-Site Linux Backups with Restic: Build and Test a Recovery Plan - DEV - 10-07-2026 Recovery workflow: a backup is proven by an isolated restore and application test. A backup job is useful only if you can recover the right data in time. This guide builds a small recovery exercise before you automate retention or depend on a provider snapshot. 1. Define the recovery target Write down which sites, files, databases and configuration must return. Set a recovery point target (acceptable data loss) and recovery time target. Keep a rebuild inventory separately from the VPS. Provider snapshots are convenient rollback points, but an account failure can remove the server and its snapshots together. Choose off-site storage and a maintained backup tool such as restic. Install from a trusted supported source and read the documentation for your version/backend. Keep repository credentials and the encryption password in a recoverable secret store; losing the password can make the backup unusable. 2. Capture a consistent source Do not copy a running database's data directory and assume it is consistent. Use a supported database dump or coordinated snapshot/backup method. Include uploads, application configuration, required secrets and rebuild information. Exclude temporary/cache data deliberately and document exclusions. A missing upload directory can matter more than a perfect OS snapshot. For a repository already configured through protected environment/credential files, these are illustrative restic commands: Code:Copy restic snapshots restic backup /srv/app-data /srv/database-dumps restic check Replace the paths with the actual consistent source. Initialize a new repository only after confirming the destination; do not overwrite or repurpose one you do not understand. Run with the least privileges that can read the intended data, and examine exit codes and unreadable-file errors. 3. Restore somewhere safe Choose an explicit snapshot from the inventory rather than assuming the newest one contains the desired state. Restore to a new empty directory on an isolated test machine: Code:Copy restic restore SNAPSHOT_ID --target /srv/restore-test This is a placeholder command: substitute the actual snapshot ID and a reviewed target with enough disk. Never target the production root filesystem for a practice restore. Check file contents, ownership, permissions and symlinks. Load a database dump only into an isolated test database with compatible software, then start the application and test a meaningful workflow. 4. Verify integrity and automate cautiously A repository structural check is different from reading every stored data block, and neither replaces an application restore. Consider a scheduled data-read integrity check using the options supported by your restic release. Account for backend read/egress cost and runtime. Record backup duration, restore duration, snapshot ID and observed data loss. Monitor the last successful backup time and check status, not just whether a scheduled process started. Send failure alerts outside the VPS. Test recovery credentials from a clean environment. Retention warning: Forget/prune operations can permanently remove recovery points. Define retention only after restore tests, retain independent copies and review the tool's dry-run output before applying cleanup. A compromised production credential should not be able to erase every copy where the backend supports immutability or separated access. Troubleshooting: If backups are unexpectedly small, inspect exclusions and read errors. If a restore fails, preserve the repository and read the exact error before repair or deletion. Check free space, credentials, network access and tool versions. Do not share repository passwords or unredacted file listings publicly. References: Restic documentation and backup behavior and checks.