Wiki Wiki Web

Sovereign Cloud – Backup Strategy

(Low-cost, realistic, home-centered – 2026)

Guiding Principles

  1. 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.
  2. A good backup is encrypted, deduplicated, and compressed – Never store your most important data unprotected. Deduplication saves space when identical files exist across devices.
  3. 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 rsync or rclone.

Simplified Architecture

CopyLocationToolFrequencyEncrypted
1Original (VPS)LivePartial
2Home 2 TB SSDRestic → rsyncDailyYes
3Off-site / USBRestic / rsyncWeeklyYes

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

ScenarioRecommended ApproachMonthly Cost (200GB)Notes
Current (1-5GB)Instance disk only€0Free tier or small instance
Adding photos (→200GB)Hybrid: local + S3€0.80Photos on S3, thumbnails local
Performance-critical appsVolumes for hot data€8+Fast access where needed
Backup repositoriesObject Storage€0.80Perfect for Restic/Borg repos

For most users growing beyond 50GB:

  1. Keep apps/configs on instance disk (5-20GB)
  2. Store photos/media in Object Storage (cheap)
  3. Use Restic to backup everything → Object Storage bucket
  4. Pull Restic repos home via rsync for 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:

AspectAll Object Storage (Cheapest)Hybrid (Recommended)All Volumes (Fastest)
200GB storage cost€0.80/mo€0.80 (S3) + €1-2 (small volumes)€8/mo
PerformanceSlow (API-based)Fast where needed (DB, cache)Excellent
Backup simplicityRestic → S3 directlyLocal Restic repo → S3 syncLarger backups needed
Best forArchives, cold dataMost personal setupsHigh-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 no in /etc/ssh/sshd_config + restart sshd. Brute-force attacks are still extremely common in 2026.
  • Disable root login over SSH PermitRootLogin no (or prohibit-password if 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. backup user 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) with g+rx permissions
    • SSH access for this user should be key-only
  • Keep the restic repository path non-obvious /backups/restic is very common → /var/lib/abcdef123-restic-repo or 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.