Restic backups for coworking systems

This guide scopes Restic to one non-critical self-hosted coworking service with an application-consistent source, offsite repository, monitored jobs, independent credential custody, and a clean-host restore. It is not runtime evidence.

1. Coworking outcome

Recover a usable coworking service after source-host loss or operator error. Restic augments encrypted snapshot creation and checking; it does not understand database consistency, business priority, or application correctness.

2. Pilot scope

Back up one service’s approved database dump/state, files, and secret-free configuration nightly for seven days; induce one safe visible failure; check the repository; and restore a named snapshot to clean isolated infrastructure. Keep the old backup system.

3. Fit

Good fit: technically operated systems with official consistency procedures, a documented remote backend, approved recovery objectives/retention, least-privilege credentials, two password custodians, monitoring, and witnessed restore drills.

4. Non-fit and alternatives

Poor fit: crash-copying live databases, the only repository beside the source, one-person key custody, snapshots treated as legal archives, or no restore capacity. Prefer application-native or managed backup services when they provide safer consistency and ownership.

5. Coworking use cases

• Protect an internal booking, knowledge, or document service’s prepared state.
• Retain rebuild configuration without embedding secrets.
• Recover from host/storage loss into isolated infrastructure.
• Preserve separate business-portable exports for future migration.

High-risk payment, access-control, identity, video, or health workloads require separate expert design.

6. Tasks reduced or augmented

Restic can automate encrypted snapshots, listing, checks, retention execution, copy, and restore. It cannot prepare a transactionally consistent application, select exclusions/retention, judge restored records, repair safely without review, or authorize production overwrite/deletion.

7. Human decisions and approvals

The application owner approves consistency/scope and restored usability; operations approves objectives/retention; security approves target/key access; the backup operator runs jobs; a second custodian proves recovery; and an independent witness signs drills. Destructive commands need separate approval.

8. Owners and RACI

Name application/data, database, backup, target/provider, security/key-custody, monitoring, recovery, and incident owners. Keep at least one recovery path independent of the source host/account and unattended write credential.

9. Prerequisites

Inventory data/database/files/configuration, official prepare/restore methods, external dependencies, source paths/exclusions, change rate, target location/terms, scheduler, monitoring, retention, recovery objectives, two custodians, clean restore capacity, and existing backups.

10. Skills and effort boundary

The pilot needs operating-system/filesystem, scheduler/shell, database/application backup, backend/IAM, secrets, monitoring, capacity/cost, and restore skills. Setup can be short, but consistency engineering, initial transfer, full checks, and application acceptance can dominate. No duration is verified.

11. Deployment choice

Restic is self-hosted open-source software used with a selected local/remote supported backend. Pin the Restic version and verify the backend’s current official access, location, retention, availability, egress, and support. This guide verifies no provider, scheduler, wrapper, GUI, or immutable-storage service.

12. Architecture and dependencies

Map application consistency/export, prepared paths, Restic execution host/cache, repository backend, repository credential, separate repository password, monitoring outside the source host, clean restore infrastructure, database tooling, and regenerated secrets. Separate source, target, and recovery failure domains.

13. License and edition boundary

Restic is OSI-approved open source under BSD-2-Clause. Re-check the repository license and terms/licenses for the operating system, scheduler, backend, secret store, monitoring, and support. The software itself provides no storage or operational SLA.

14. Total cost boundary

Annual true cost = target storage + requests/transfer/egress + backup/restore compute + monitoring + setup/consistency labor + daily review + integrity checks + restore drills + key/retention administration + incident/support + exit copy. Model measured low/base/high cases; deduplication and egress are not free assumptions.

15. Data map

Data	Preparation	Snapshot input	Recovery proof
Database	Official dump/quiesce method	Prepared artifact	Integrity and sample records
Application files	Owner-approved state	Fixed reviewed paths	Files and app workflow
Configuration	Secret-free recovery copy	Fixed reviewed paths	Service starts after secret injection
Snapshot metadata/data	Restic	Repository	snapshots, ls, check, restore
Credentials/password	Separate custody	Never snapshot/evidence values	Witnessed independent retrieval

Snapshots inherit the highest personal, financial, access, and operational sensitivity of their sources.

16. Privacy and retention

Apply source retention and deletion/legal-hold decisions to backups with qualified review; restrict restore access; minimize logs/path leakage; and document backend location, deletion, versioning, immutability, and account closure. Encryption does not remove privacy/breach obligations.

17. Security baseline

Use pinned binaries, least-privilege target credentials, a separate strong repository password, two-custodian recovery, restricted configuration/logs/cache, protected transport, target-side deletion protection where designed, and monitored access. Assume a compromised source host can misuse any writable target credential it holds.

18. Compliance and expert review

Obtain database expertise for consistency/PITR, security expertise for immutability or compromise, privacy/legal/records review for regulated retention/deletion, and experienced Restic/backend help before corruption repair, only-repository migration, or workloads beyond the team’s tested recovery capability.

19. Integration boundary

No backend, scheduler, secret store, monitor, or source-application command is catalog-verified. Treat preparation and restore commands as integrations with versions, owners, exit codes, timeouts, cleanup, and failure behavior. Select only a backend documented by current Restic docs.

20. Configuration baseline

Record Restic version/source, repository type/reference (not secrets), credential method, password custody, source paths/exclusions, host/tags, preparation command, scheduler identity, timeouts, cache/log handling, monitoring, retention/forget policy, prune approval, check depth/cadence, and recovery objectives.

21. Smallest useful experiment

Prepare one low-risk service using its official method, create seven nightly snapshots in an offsite repository, demonstrate a failure alert, run an approved check, and restore a specific snapshot to a clean host without source-host credentials.

22. Implementation sequence

1. Approve owners, source consistency, scope, objectives, retention, and exclusions.
2. Pin Restic and verify backend/cost/security from official sources.
3. Provision target access and independent password recovery.
4. Run preparation and one manual backup; inspect snapshot paths.
5. Schedule seven jobs plus failure/staleness/capacity monitoring.
6. Execute planned repository checks.
7. Restore to clean infrastructure and obtain owner/witness sign-off.

23. Migration and rollout

Run alongside the existing backup process through an accepted restore and approved retention overlap. Reconcile newest/oldest recovery points, included data, alert ownership, and measured objectives before removing old copies. Add applications one at a time with separate consistency procedures.

24. Required test plan

Test preparation failure, source-path absence, backend outage, job exit handling, stale-snapshot alert, capacity warning, snapshot/path inventory, structural and approved data-integrity check, credential recovery without source host, selected/full restore, ownership/permissions, database integrity, application startup, representative records, and elapsed recovery.

25. Acceptance criteria

Failed preparation cannot signal success; expected paths exist and exclusions are correct; a forced failure alerts a named person; repository check passes; two custodians can recover access; the selected snapshot restores cleanly; database/files/permissions/service workflow pass; and measured recovery is accepted. Any unexplained check error blocks rollout.

26. Success metrics

Track prepared-state and snapshot age, job duration/bytes/errors, repository growth/capacity, check coverage/status, oldest/newest recovery point, credential-recovery result, clean restore time, business-test defects, and drill closure. Snapshot count or deduplication ratio alone is not recovery evidence.

27. Monitoring and alerting

Alert on preparation failure, missing schedule, unhandled exit, stale snapshot, backend/credential failure, lock errors, capacity/retention anomalies, check failure, and expired restore/key drill. Route alerts outside the protected host to a named operator and escalation owner.

28. Operating cadence

Review job status according to approved data-loss objectives, capacity/growth monthly, retention before destructive execution, checks on a risk/bandwidth-based schedule, and witnessed clean restores on an approved cadence. Re-test after source layout/database, backend, credentials, Restic series, or scheduler changes.

29. Failure modes and response

Plan for inconsistent source, omitted path, lost password, expired/compromised credential, backend outage, full target, stale lock/cache, corrupt repository, bad retention filter, interrupted in-place restore, and incompatible binary/repository format. Stop prune/repair/migration on unexplained integrity errors, preserve another copy where possible, and involve experts.

30. Backup procedure

Complete and validate the application’s official consistency step; run the pinned reviewed Restic job against fixed paths; capture exit status, snapshot ID, duration, and bytes; resume/clean prepared state only after result; and alert any failed stage. Keep portable application exports separately where exit matters.

31. Restore drill

Provision clean isolated infrastructure, recover backend/password without source-host assumptions, run the approved check, select an exact snapshot, restore to a new target, restore database through its official tool, inject secrets separately, start the service, and run business acceptance. Official docs warn interrupted in-place restore can leave partial state; do not test against production. No runtime evidence exists yet.

32. Upgrade, rollback, and exit

Read release notes, pin/test a new binary against a copied/test repository, check and restore, and retain the prior binary. Repository-format migration is explicit and may raise the minimum Restic version; preserve an independent copy/tooling and do not assume downgrade. Exit by restoring portable data or officially copying snapshots with full bandwidth/egress modeled, validating replacement independently, retaining compatible tools while snapshots survive, then approving credential/repository disposal.

33. Sources, evidence, and unknowns

Reviewed 2026-07-18: homepage, repository/license, documentation, backup, repositories/checks, and restore.

Evidence is documentation review only. Untested: runtime/package, source consistency, backend access/guarantees/location/cost, snapshot contents, scheduler/alerts, key recovery, checks/repair, retention/prune, restore fidelity/time, repository migration/copy, support, and compliance. Treat each as an open gate.