Automating VPS backups: when cron and restic stop being enough

Restic is a strong encrypted backup engine, but the repository is only useful when it sits outside the VPS failure domain and the recovery password survives loss of the server. Decide who owns the storage account, where recovery credentials live, and how access is regained during an incident.

A local scheduler also needs credentials, yet those secrets should not appear in process arguments, logs, or a world-readable configuration. Designing that boundary is operational work, not a one-time installation command.

A usable job backs up the intended files and creates database-aware artifacts where live application state cannot be copied safely. It rejects overlap, preserves the previous recovery point when preparation fails, and reports which stage failed.

Retention is a separate destructive operation. Apply it only after a valid new recovery point exists, monitor its result independently, and leave enough history for failures that are discovered days or weeks later.

Cron is reasonable for one stable host when another system checks the result. Systemd timers integrate with service status and the journal, and a timer configured as persistent can catch an activation missed while the host was down. Both schedulers still remain local to the machine they protect.

That creates a blind spot: a deleted schedule, dead host, expired credential, or broken wrapper may produce no failed command at all. An external system must notice that the last successful recovery point is becoming stale.

A backup that runs longer than its interval can collide with the next activation or with repository maintenance. Define whether the second run waits, exits, or is skipped, and make that outcome visible. Concurrency control must cover the full workflow, including database preparation and cleanup, rather than only the final repository write.

After a reboot or network interruption, confirm whether a new recovery point was actually committed. Do not remove repository locks merely because a job appears old; first establish that no active process still owns the work. Earlier snapshots may remain healthy even when the expected new one is absent.

Automation needs both immediate failure reporting and stale-success detection. Keep those signals outside the VPS and make them identify the affected host, backup set, last valid recovery point, and owner.

Restore rehearsals should use an isolated target and the same credentials an incident responder would have. Record duration and application validation, because a successful upload does not prove the service can be recovered in time.

Most broken cron backups come from a few recurring mistakes.

The threshold is not a particular server count. Local scheduling becomes expensive when nobody can answer, without logging into each host, which services are covered, how old their newest recovery points are, who owns failures, and when each restore was last rehearsed.

That can happen on one complicated server or remain manageable across several simple ones. Review the operational load after staff changes, new databases, tighter recovery targets, or repeated alert gaps. The migration trigger should be loss of reliable evidence, not frustration with cron syntax.

One server and one local scheduler can be manageable. Across several servers, the cron-and-grep approach stops scaling: ownership drifts, logs stay local, recovery passwords scatter, and nobody can quickly prove the newest recovery point for every service.

Rested provides the missing operating layer around restic: enrolled servers, database-aware backup recipes, schedules, centralized run history, failure visibility, retention, and guided restores to storage you control. The value is the maintained system, not a shell script copied onto every host.