[DEV]

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.