0–10 min: choose service and recovery point
Identify exact config, DB, data, identity, secrets, and version needed.
Success checkRestore set is explicit before touching backups.
Home server backup and recovery checklist · Updated 2026-07-05
Home Server Backup & Recovery Checklist: Config, Databases, App Data, Media Libraries, Secrets, Upgrades, and Restore Drills
A practical backup and disaster-recovery checklist for CasaOS, Umbrel, Nextcloud, YunoHost, RomM, and other home-server stacks.
A home server backup is not one folder and recovery is not reinstalling the dashboard. Real self-hosted systems combine platform configuration, app manifests, databases, user files, media libraries, permissions, secrets, schedulers, and external integrations.
This checklist separates irreplaceable data from reproducible software, defines restore order, requires off-device copies and retention, and treats clean-machine restore drills as the real proof of backup quality.
RepoDaily verdict
Do not call a home server backed up until a clean machine can restore one representative service with users, configuration, database state, files, permissions, scheduled jobs, and external references intact. Keep at least one copy outside the server and treat unsupported downgrade paths as restore problems, not rollback buttons.
Quick matrix
| Asset class | Examples | Backup rule | Restore proof |
|---|---|---|---|
| System configuration | Network, mounts, domains, reverse proxy | Export or document separately from app data | Fresh host reaches the same services without ad hoc reconstruction |
| App configuration | Compose, manifests, config directories | Version with secrets separated | App starts with expected paths, ports, and integrations |
| Database | SQLite, MariaDB, PostgreSQL | Use app-consistent dump or supported snapshot | Schema loads and app passes integrity checks |
| User data | Files, photos, uploads | Back up authoritative data plus metadata dependencies | Users, shares, and file references behave correctly |
| Media library | ROMs, videos, artwork | Separate irreplaceable media from regenerable caches | Library rescans without losing manual curation |
| Identity and permissions | Users, groups, ACLs, sharing rules | Include identity and permission metadata | Normal users retain correct access and no extra privilege |
| Secrets | API keys, app secrets, TLS keys, backup keys | Encrypt and keep recovery path separate | Service can reconnect without stale credentials |
| Schedulers | Cron, background jobs, notifications | Inventory job definitions and dependencies | Jobs resume once without duplicate side effects |
| External references | DNS, OAuth, object storage, SMTP | Document IDs, endpoints, and owners | Restored service reconnects or fails with clear remediation |
| Backup catalog | Snapshots, archives, DB dumps | Keep inventory and retention policy | Operator can choose the correct restore point quickly |
Backup and recovery readiness scorecard
Score recoverability, not backup file count.
| Control | 0 points | 1 point | 2 points | Owner question |
|---|---|---|---|---|
| Coverage | Files only | Most app data | Config + DB + data + identity + jobs + external refs mapped | What would still be missing? |
| Off-device copy | Same disk | Second local disk | Separate device/location or cloud plus tested credentials | What survives total device loss? |
| Consistency | Live copy with no plan | Manual service stop | Documented app-consistent dump/snapshot process | Can writes race with backup? |
| Encryption and keys | Sensitive archive unencrypted | Encrypted backup | Encrypted backup plus separately recoverable key | Can restore proceed without the failed server? |
| Retention | Latest only | Several copies | Risk-based daily/weekly/monthly history | How far back can corruption be escaped? |
| Restore order | Unknown | Operator memory | Written dependency order with health checks | Which service comes first and why? |
| Restore drill | Never | Partial file restore | Clean-host full-service recovery exercised | When was recovery last proven? |
| Upgrade rollback | Hope | Snapshot only | Pre-upgrade backup + compatibility plan + tested restore path | Can schema migration be recovered? |
60-minute home server recovery drill
A fast proof that one important service can be rebuilt from current backup material.
10–20 min: verify independence
Confirm backup and decryption path remain available if the primary server disappears.
Success checkNo critical restore dependency exists only on failed host.
20–35 min: restore cleanly
Install compatible base and restore DB/config/data in documented order while staying non-public.
Success checkApplication starts without improvising paths or credentials.
35–45 min: test users
Login as admin and normal user; inspect files/media, permissions, shares, search, and one write.
Success checkOwnership and access behavior match expectations.
45–55 min: test jobs and integrations
Run a background job, notification, metadata refresh, or scheduled workflow once.
Success checkJobs resume without duplicates or stale references.
55–60 min: record gaps
Capture elapsed time, missing files, manual commands, stale docs, and data-loss window.
Success checkRunbook and backup coverage improve.
Home server backup and recovery flow
- Inventory every service and classify each asset as irreplaceable data, reconstructable configuration, database state, identity/permissions, secrets, cache, or disposable runtime state.
- Write the minimum restore set per app. Collaboration clouds may require config, database, and data directory together; media services need the library plus database and curation state; multi-app platforms also need platform-level users and domains.
- Choose a consistency method per data store: service-aware export, database dump, maintenance mode, application backup command, filesystem snapshot, or coordinated service stop.
- Keep backup storage independent from the service host, with retained history that protects against disk failure, theft, accidental deletion, ransomware, and bad updates.
- Protect backup encryption keys separately and document how a replacement operator retrieves them without relying on the failed machine.
- Define restore order: base host and mounts, platform configuration, databases, app config, user data, identity/permissions, jobs, then external integrations and public exposure.
- Restore first into an isolated environment and verify ownership, shares, database health, versions, paths, jobs, notifications, and external connectors before reopening access.
- Run recurring clean-host drills and record recovery time, missing steps, manual actions, and data-loss window.
Scenario table
| Scenario | Backup emphasis | Recovery trap |
|---|---|---|
| CasaOS home server | Platform config, app config, volumes, user files, drive mount map | Dashboard returns but app paths and mounts differ |
| Umbrel appliance | OS/app config, persistent app data, identity-sensitive data, storage map | Assuming every app has one universal backup path |
| Nextcloud collaboration cloud | Config, data directory, database, custom apps/themes where used | Restoring only files without matching DB/config state |
| YunoHost multi-app server | System config, users/domains, app backups, mail/data, restore scripts | Archive exists but destination packaging cannot restore cleanly |
| RomM media library | ROM/media library, DB, config, users/sharing, manual metadata | Backing up only DB or only the authoritative library |
| Bad application upgrade | Pre-upgrade consistent backup and version compatibility notes | Trying unsupported downgrade against migrated DB |
| Ransomware or compromised admin | Historical independent copies and clean-room recovery | Restoring poisoned config or attacker credentials |
Backup and recovery risks
Single-disk backup
A backup folder on the same physical disk does not protect against device failure, theft, corruption, or destructive admin access.
Files without database
Many apps keep ownership, shares, metadata, and jobs in databases. User files alone may not reconstruct a working service.
Database without files
A perfect dump is useless if uploads, media, object storage, or external mount targets are missing.
Untested archive
Checksums prove bytes were copied, not that the app can restore, migrate, authenticate users, and resume jobs.
Backup key dependency
Encrypted backups become unrecoverable when the only decryption key is on the failed server.
Public restore too early
Do not expose a half-restored service while credentials, migrations, permissions, and updates remain unresolved.
Schema downgrade assumption
Some apps do not support downgrading after schema migration; recovery may require fresh install plus restore.
Backup and recovery patterns
Service manifest
Record version, config paths, data paths, DB, secret refs, mounts, ports, dependencies, backup method, and restore order for every app.
Independent retained copies
Keep multiple copies across independent storage and at least one separate location, adjusted to data value and recovery objectives.
DB dump plus filesystem snapshot
Coordinate database export and referenced files so metadata and content belong to the same recovery point.
Pre-upgrade recovery point
Before major upgrades, create a verified restore point and record exact source and destination versions.
Clean-host drill
Restore into a blank VM, spare device, or isolated machine rather than validating only in-place rollback commands.
Recovery evidence pack
Keep restore logs, timings, checksums, health checks, user-access tests, and manual fixes discovered during drills.
FAQ
Short answers for home-server operators.
Is a full disk image enough?
Useful, but not sufficient alone. App-aware exports and documented restore steps make selective restore and clean-room recovery easier.
What is the minimum for Nextcloud?
Treat configuration, database, and data directory as one recovery set; preserve custom apps and themes when used.
Should media and metadata be backed up together?
Protect authoritative media first, then preserve the database and manual curation needed to reconstruct the same library experience.
How often should restore be tested?
After major architecture changes and on a recurring cadence that matches data value and acceptable recovery risk.
Can snapshots replace backups?
Snapshots help with fast rollback but may share the same failure domain. Independent retained copies are still needed.
What should happen before a major upgrade?
Create an app-consistent recovery point, record versions, verify compatibility, and know whether recovery means rollback, fresh install plus restore, or forward fix.
Related radar
Related RepoDaily briefs
CasaOS: The Open-Source Personal Cloud That Turns Any Device Into a Home ServerIceWhaleTech/CasaOS · Self-hosted appUmbrel Explained: A Polished Home-Server OS for Personal Clouds and Self-Hosted Appsgetumbrel/umbrel · Self-hosted appNextcloud Explained: Self-Hosted Files, Groupware, and Collaboration Cloudnextcloud/server · Self-hosted appYunoHost Explained: Multi-App Self-Hosting with Users, Domains, Backups, and App PackagingYunoHost/yunohost · Self-hosted appRomM: A Self-Hosted ROM Library Manager With Browser Playback and Access Controlsrommapp/romm · Security tool
Sources
- Nextcloud Backup documentation
- Nextcloud Restore documentation
- Nextcloud Upgrade documentation
- YunoHost Backups documentation
- YunoHost Backup strategies
- YunoHost Filesystem snapshot documentation
- CasaOS official repository
- Umbrel official repository
- RomM official repository
- RepoDaily CasaOS vs Umbrel vs Nextcloud vs YunoHost
Feedback
Did this page help you make a decision?
Anonymous feedback helps RepoDaily improve what is actually useful.