Data is backed up to multiple destinations so a single failure is not catastrophic. Local and remote copies exist, and backup failures are surfaced through alerts.
This keeps restores practical and reduces risk from hardware or site-level issues.
Backups are part of the platform, not an afterthought. The NAS is the primary local landing zone, but it is not the only protection layer. Important data should have a clear source, a clear backup target, and a realistic restore path.
The most important recovery cases are databases, game worlds, app configuration, Nextcloud data, and Wiki content. A service can usually be redeployed from Git, but its state needs a backup. That is why the backup strategy focuses on both Git-defined service configuration and the data those services depend on.
Primary local target: Unraid NAS
Remote copy: Google Drive
Secondary onsite copy: second NAS
| Service | Role |
|---|---|
backrest |
Web UI for managing Restic backup jobs. |
restic-runner |
General backup runner. |
restic-database-runner |
Database backup runner. |
restic-game-servers-runner |
Game-server backup runner. |
restic-game-servers-shared-runner |
Shared game-server backup runner. |
| Data type | Recovery path |
|---|---|
| Swarm app config | Restore app directory from Restic/Backrest, then redeploy the stack from Git. |
| Shared databases | Restore the relevant database dump or repository snapshot, then restart dependent services. |
| Game worlds | Restore the world folder to the expected game-server path before starting the server. |
| Nextcloud data | Restore files and database together so file metadata stays consistent. |
| Wiki content | Restore from Git first; restore Wiki.js database only if page metadata or UI-only edits are missing. |