Sovereign Cloud – Backup Strategy
(Low-cost, realistic, home-centered – 2026)
Guiding Principles
- Backups require ongoing attention – A setup that works today may fail in a month. Plan to review and verify your backups a few hours per year. "Set and forget" works for days, not years.
- A good backup is encrypted, deduplicated, and compressed – Never store your most important data unprotected. Deduplication saves space when identical files exist across devices.
- A practical home-friendly approach – Use Restic on your cloud server to create regular, encrypted backups, then rsync over SSH to pull them to your local home machine—preferably to both an internal NVMe and an external USB SSD.
Recommended Setup
- Primary Backup: Always-on home Linux machine with a 2 TB SSD (8–10 W idle)
- Secondary Backup: External USB SSD (rotated occasionally) or a cheap cloud service (Hetzner Storage Box, Backblaze B2, pCloud lifetime)
- Restic – Simple, deduplicated, encrypted, with excellent cloud integration.
- BorgBackup – Also excellent, slightly more complex, with superior deduplication.
- Use Restic on your VPS/server to create backups, then pull them home via
rsyncorrclone.
Simplified Architecture
| Copy | Location | Tool | Frequency | Encrypted |
|---|---|---|---|---|
| 1 | Original (VPS) | – | Live | Partial |
| 2 | Home 2 TB SSD | Restic → rsync | Daily | Yes |
| 3 | Off-site / USB | Restic / rsync | Weekly | Yes |
Typical Capacity After 2–3 Years
- Nextcloud / files: 200–800 GB
- Immich library: 300–1000 GB
- VPS snapshots: 50–300 GB
- Mail, configs, git: 10–70 GB
Total: ~600 GB – 1.8 TB (fits comfortably on 2 TB)
Cloud Storage Strategy: Volumes vs. Object Storage
Most cloud providers offer two storage options with significant cost differences:
- Volumes (Block Storage) – Mounted on server as a local hard drive; fast, direct filesystem access; costs ~€0.04/GB/month (Hetzner); ideal for databases, applications, and performance‑critical data.
- Object Storage (S3‑compatible) – Accessed via API; stores files in “buckets”; slower but far cheaper at ~€0.004/GB/month (10× less than volumes); best for backups, photos, videos, and archives.
Decision Guide for Growing Storage Needs
| Scenario | Recommended Approach | Monthly Cost (200GB) | Notes |
|---|---|---|---|
| Current (1-5GB) | Instance disk only | €0 | Free tier or small instance |
| Adding photos (→200GB) | Hybrid: local + S3 | €0.80 | Photos on S3, thumbnails local |
| Performance-critical apps | Volumes for hot data | €8+ | Fast access where needed |
| Backup repositories | Object Storage | €0.80 | Perfect for Restic/Borg repos |
For most users growing beyond 50GB:
- Keep apps/configs on instance disk (5-20GB)
- Store photos/media in Object Storage (cheap)
- Use Restic to backup everything → Object Storage bucket
- Pull Restic repos home via
rsyncfor local copy
Restic tagging: restic can apply tags while archiving at directory level, it can then taylor backup frequencies --tag level-high # small data, critical: passwords --tag level-medium # large amounts: photos, documents --tag level-low # less critical --tag replaceable # docker images, build artifacts
Cost-Optimized vs Performance-Optimized Table:
| Aspect | All Object Storage (Cheapest) | Hybrid (Recommended) | All Volumes (Fastest) |
|---|---|---|---|
| 200GB storage cost | €0.80/mo | €0.80 (S3) + €1-2 (small volumes) | €8/mo |
| Performance | Slow (API-based) | Fast where needed (DB, cache) | Excellent |
| Backup simplicity | Restic → S3 directly | Local Restic repo → S3 sync | Larger backups needed |
| Best for | Archives, cold data | Most personal setups | High-performance apps |
When to consider Object Storage for Restic:
- Your storage needs exceed free instance disk
- You want to backup directly to cloud (3-2-1 strategy)
- Cost becomes a concern (>50GB storage)
- You're storing large media libraries
Pictures/Immich specific advice:
- Store original photos in Object Storage (cheap)
- Keep thumbnails/metadata on local disk/volume (fast)
- Restic can backup both from their respective locations
Computer Security
Backups and self-hosted services change your threat model. Once you have an internet-facing server, even a low-skill ransomware worm or opportunistic attacker can become a realistic concern. The following items are not advanced opsec — they are basic hygiene that experienced self-hosters treat as non-negotiable.
- Your home computer is now part of the security perimeter If your main PC / laptop gets compromised (malware, keylogger, browser extension, cracked game/software), the attacker often gets your SSH keys → full access to the VPS. Treat your daily-use computer as a weak link.
- Disable password authentication for SSH – use keys only
PasswordAuthentication noin/etc/ssh/sshd_config+ restart sshd. Brute-force attacks are still extremely common in 2026. - Disable root login over SSH
PermitRootLogin no(orprohibit-passwordif you must). Use a normal user +sudo. - Restrict SSH access to known IP addresses whenever possible
- Best: allow only your home IP (or mobile hotspot range).
- Good: use a WireGuard / Tailscale / Zerotier VPN tunnel and only allow SSH over the VPN.
- Acceptable: use
ufw/iptables/ cloud firewall to limit SSH to your current IP(s). - Use a very strong, unique passphrase for the restic repository
- Minimum: 5–7 diceware words (~25+ characters).
- Better: 6–8 diceware words or 20+ truly random characters.
- Never store this passphrase on the VPS itself — keep it in your password manager or on paper.
- Use a separate, non-privileged user for backups Create e.g.
backupuser that can only read the data directories and write to the restic repo. Services (Nextcloud, Vaultwarden) should never run as this user. - For pull-style off-site copies (recommended):
- Create a second read-only user (e.g.
bkp-ro) - This user has read + execute (but no write) access to the restic repository
- Usually implemented via a shared group (
restic-read) withg+rxpermissions - SSH access for this user should be key-only
- Keep the restic repository path non-obvious
/backups/resticis very common →/var/lib/abcdef123-restic-repoor similar is slightly better against casual ransomware enumeration. - Prefer pull-based backups (home pulls from server) Servers should almost never push backups anywhere — this greatly reduces attack surface.
- Enable immutability / Object Lock on your cloud copy Backblaze B2, Wasabi, Hetzner Storage Box snapshots, etc. — make at least one copy impossible to delete/encrypt for weeks or months.
- Rotate / air-gap at least one backup copy External USB drive that is only connected during backup and then stored offline is still one of the strongest ransomware defences.
- Test restores periodically A backup you cannot restore is worthless. At minimum: check that you can list snapshots and restore a single file once every 3–6 months.
- Keep your VPS software updated automatically if possible Unattended upgrades (Debian/Ubuntu) or equivalent significantly reduce exploit risk.
Maintenance Checklist
- Weekly: Check that backups are running (logs, disk space).
- Monthly: Verify one restore (dry-run or test extract).
- Every 3–6 months: Confirm off-site copy is up to date.
- Yearly: Full restore test and review of retention policies.
Summary
A minimal, sovereign-friendly backup strategy in 2026:
- Use Restic on servers for encrypted, deduplicated backups.
- rsync them home daily to a 2 TB SSD.
- Keep a weekly copy off-site (cloud or rotated USB drive).
- Review regularly—backups are a living system, not a one-time setup.
- As you grow: Consider Object Storage for cost-effective bulk storage while keeping performance-critical data local.