💾 Backup & Maintenance¶
A private cloud is only as good as its backup plan — if the SSD fails and there's no copy elsewhere, "self-hosted" quietly becomes "self-deleted." This page covers what to back up, how often, and the small routine maintenance habits that keep the server healthy long-term.
🏆 Sponsored by
Supported by Brunel Cybersecurity Society 🎓 and the CyberTutor Platform 💻🔐.
🎯 The 3-2-1 rule, applied to this build¶
The standard backup guideline is 3 copies of your data, on 2 different types of storage, with 1 copy off-site. Mapped onto this project:
| Copy | Where | Covers |
|---|---|---|
| 1 (live) | The SSD attached to the Pi | Day-to-day working copy |
| 2 (local backup) | A separate external drive or a second SD card | Protects against SSD failure |
| 3 (off-site) | Cloud storage, a drive kept at another location, or a family member's house | Protects against theft, fire, or the Pi itself failing |
A single-disk private cloud with no backup isn't "risky" — it's a matter of when, not if, something gets lost. The whole point of self-hosting is owning your data; that only holds if a drive failure can't take it all with it.
🗂️ What actually needs backing up¶
Nextcloud on this build has three things worth protecting, in order of importance:
- The data directory — the actual files: photos, documents, everything users uploaded. This is irreplaceable.
- The database — file metadata, share links, user accounts, calendar/contacts data. Without it, the raw files exist but Nextcloud doesn't know how they fit together.
- The config — trusted domains, Tailscale settings, app configuration. Annoying to lose, but rebuildable by hand if needed (see Requirements and Network & Remote Access).
🔁 Recommended backup routine¶
Weekly: back up Nextcloud's data and config¶
sudo nextcloud.occ maintenance:mode --on
sudo tar -czvf ~/nextcloud-backup-$(date +%F).tar.gz \
/var/snap/nextcloud/common/nextcloud/data \
/var/snap/nextcloud/current/nextcloud/config
sudo nextcloud.occ maintenance:mode --off
Putting Nextcloud into maintenance mode first avoids backing up files mid-write. This produces a single dated archive that can be copied off the Pi.
Weekly: back up the database¶
sudo nextcloud.export -abd
Nextcloud's snap package includes a built-in export command that dumps the database alongside the app data — the simplest way to get a consistent database backup without hand-writing mysqldump/pg_dump commands.
Copy backups off the Pi¶
A backup that lives on the same SSD as the data it's protecting isn't a real backup — it protects against nothing if that drive fails. Copy the archive somewhere else, for example over the Tailscale network:
scp pi@picloud:~/nextcloud-backup-*.tar.gz ~/Backups/
Run this from the laptop (or wherever the off-site copy lives) rather than on the Pi itself.
🛠️ Routine maintenance checklist¶
| Frequency | Task | Command |
|---|---|---|
| Weekly | Back up data + database (above) | — |
| Monthly | Update system packages | sudo apt update && sudo apt upgrade -y |
| Monthly | Update Nextcloud | sudo snap refresh nextcloud |
| Monthly | Check disk space headroom | df -h |
| Monthly | Check Tailscale is healthy | tailscale status |
| Quarterly | Test restoring a backup | See below |
🧪 An untested backup is just a hope
A backup that's never been restored isn't verified — it's a guess. Every few months, actually restore the latest archive somewhere (a spare SD card, a test folder) and confirm the files open. This is the step almost everyone skips, and the one that matters most when a real failure happens.
🩺 Quick health check¶
Before and after any maintenance, a fast sanity check:
sudo snap services nextcloud # Nextcloud services all "active"?
df -h # Enough free space on the SSD?
tailscale status # Pi still connected to the tailnet?
sudo nextcloud.occ status # Nextcloud reports "installed: true"
This page pairs with Operations & Troubleshooting for the broader command playbook, and with Connection Scale for how the server stays reachable day to day.