Last reviewed: April 2026Retention: day-basedRestore model: procedural
Logical MariaDB dump for database recovery
Project archive for configuration and application files
Runtime-state snapshots for Grafana and Uptime Kuma databases
Optional restic offsite sync when repository credentials are configured
Day-based retention to protect disk on a 40 GB host
Cron-based execution with local log files
Why this choice
For a single VM, readable restore steps are more valuable than another backup product. The aim is to recover
calmly and predictably, not to hide the process behind more tooling.
The restore model stays procedural on purpose. A small environment benefits more from readable restore steps
than from another management layer.
Restore Focus
What recovery is expected to achieve.
Goal: restore application state, platform files, and key operational data without guessing where critical files live.
Included: database dumps, project tree archives, and selected runtime data used by monitoring and status tooling.
Operational limit: this is a single-host strategy, not multi-site disaster recovery.
Practice: restore scripts exist because backup quality only matters if restore remains understandable.
Failure Modes
What this strategy still does not solve on its own.
A single-host backup strategy is still vulnerable if the VM and its local backup storage disappear together.
Offsite sync is prepared, but it still depends on external repository credentials being configured.
Short-retention observability data is intentionally not treated as long-term archival data.