Skip to content

ADR-015 — Backup Strategy Deep Dive

Generated: 2026-04-07 Updated: 2026-04-07 (added PBS boot research, Backrest vs Kopia comparison, 18TB external drive strategy)

Table of Contents

  1. Current Infrastructure Inventory
  2. What Needs Backing Up
  3. Proxmox Backup Server (PBS)
  4. PBS Boot Drive: Flash Drive vs USB SSD
  5. Backrest (Restic) vs Kopia — Direct Comparison
  6. Self-Hosted Backup Tools — Simple to Complete
  7. Database-Specific Backup Tools
  8. Docker Volume Backup Tools
  9. Cloud / Online Backup Solutions & Pricing
  10. 18TB External Drive Strategy
  11. Device Backups (macOS, Steam Deck, Retroid Pocket 6) (shelved)
  12. Whole LXC vs Targeted Backups
  13. Recommended Strategy
  14. Sources

1. Current Infrastructure Inventory

Proxmox Host (chizuru — 192.168.1.125)

Storage Layout: | Device | Size | Type | Mount | Usage | |--------|------|------|-------|-------| | nvme0n1 | 232GB | NVMe SSD | / (68GB root), swap (8GB), LVM thin pool (137GB) | OS + LXC disks | | sdf | 931GB | HDD | ZFS pool zpool | ZFS pool: media (482GB used), LXC subvolumes | | sda | 10.9TB | HDD | /mnt/filedump | Filedump storage (mostly empty) | | sdb | 1.8TB | HDD | /mnt/seedbox | Seedbox downloads (1.4TB used / 80%) | | sdc | 3.6TB | HDD | /mnt/all-might | All-might media (900GB used) | | sde | 465GB | SSD | /mnt/pve/ollama-disk | Ollama models (88GB used) | | sdg | 465GB | SSD | (unmounted) | Available | | sdh | 465GB | SSD | (unmounted) | Available | | sdd | 1.8TB | HDD | (unmounted) | Available |

ZFS Pool: - zpool — 928GB total, 491GB used (52%), single disk (sdf), ONLINE - Contains: zpool/media (482GB), plus subvolumes for LXCs 109, 110, 111, 115, 116

LXC Containers (20 total)

VMID Name IP Disk Role
100 alpine-forgejo 192.168.1.69 2GB (LVM) Git server
101 forgejo-runner 192.168.1.211 8GB (LVM) CI/CD runner
102 filedump — 4GB (LVM) File sharing
103 docker-host 192.168.1.22 60GB (LVM) Main Docker host (~30 containers)
104 homebridge — 4GB (LVM) Smart home bridge
105 caddy 192.168.1.200 4GB (LVM) Reverse proxy
106 vault — 8GB (LVM) HashiCorp Vault
107 ollama 192.168.1.107 External SSD LLM inference
108 observability 192.168.1.108 30GB (LVM) Grafana + Loki + Prometheus
109 minecraft 192.168.1.109 20GB (ZFS) Minecraft server
110 gluetun 192.168.1.110 4GB (ZFS) VPN gateway
111 seedbox 192.168.1.111 8GB (ZFS) Torrent client
112 mediamanager — 4GB (LVM) Media management
113 mediabot 192.168.1.113 50GB (LVM) MediaManager + Prowlarr + Jackett + qBittorrent
114 jellyfin 192.168.1.114 50GB (LVM) Media server
115 netbird 192.168.1.115 16GB (ZFS) VPN mesh
116 all-might 192.168.1.116 16GB (ZFS) Shoko + MariaDB + RomM + Grimmory
117 karakeep 192.168.1.217 32GB (LVM) Bookmark manager + Meilisearch
208 tailscale — 4GB (LVM) VPN
1022 docker-smb — 4GB (LVM) SMB share

No QEMU VMs currently running.

Databases Inventory

Database Type Location Service
forgejo.db SQLite LXC 100: /var/lib/forgejo/db/ Forgejo
database.sqlite SQLite LXC 103: docker volume n8n_n8n-data n8n
webui.db SQLite LXC 103: docker volume open-webui_open-webui-data Open WebUI
db.sqlite3 SQLite LXC 103: docker volume vaultwarden_vaultwarden-data Vaultwarden
pocket-id.db SQLite LXC 103: docker volume pocketid_pocketid-data PocketID
homeserver.db SQLite LXC 103: docker volume matrix_synapse-data Matrix Synapse
gatus.db SQLite LXC 103: docker volume gatus_gatus-data Gatus
qbitwebui.db SQLite LXC 103: docker volume qbitwebui_qbitwebui-data qBitWebUI
cache.db SQLite LXC 103: docker volume ntfy_ntfy_cache Ntfy
PostgreSQL 17 PostgreSQL LXC 113: docker volume postgres_data MediaManager
MariaDB 11.4 MariaDB LXC 116: docker volume mariadb_config Grimmory, RomM, Shoko
Meilisearch Meilisearch LXC 117: docker volume meilisearch Karakeep
Vault data Raft storage LXC 106: /opt/vault/data/ HashiCorp Vault
Redis Redis (in-memory) LXC 116: docker volume romm_redis_data RomM

Docker Volumes (LXC 103 — main docker-host)

code-server_code-server-config
code-server_code-server-workspace
gatus_gatus-data
matrix_synapse-data
n8n-data / n8n_n8n-data
ntfy_ntfy_cache
observability-agents_alloy-data
open-webui_ollama-data
open-webui_open-webui-data
pocketid_pocketid-data
qbitwebui_qbitwebui-data
synapse-data
the-lounge_thelounge-data
vaultwarden_vaultwarden-data

IaC Repos (on laptop + Forgejo)

  • ~/git/homelab — Ansible playbooks, Forgejo workflows, service configs, compose files
  • ~/git/homelab-docs — MkDocs documentation
  • ~/git/homelab-notes — Research and planning notes

2. What Needs Backing Up

Tier 1: Critical (data loss = significant pain)

What Why Estimated Size
Vault data (LXC 106) All secrets, tokens, SSO config < 100MB
Vaultwarden database All passwords < 50MB
Forgejo database + repos All IaC code, git history < 500MB
PocketID database SSO identity data < 50MB
n8n database Automation workflows < 200MB
Proxmox host config /etc/pve/, network config, hook scripts < 50MB
LXC configs Container definitions < 10MB

Tier 2: Important (annoying to rebuild)

What Why Estimated Size
MediaManager PostgreSQL Media library metadata, download history < 1GB
MariaDB (all-might) Grimmory/RomM/Shoko databases < 1GB
Karakeep + Meilisearch Bookmarks, search index < 2GB
Open WebUI data Chat history, settings < 500MB
Matrix Synapse DB Chat history < 500MB
Grafana dashboards Dashboard JSON, datasource configs < 100MB
Prometheus data Metrics history ~5-10GB
Loki data Log history ~5-10GB
Docker compose configs Already in git, but runtime state matters < 50MB
Caddy config + certs Reverse proxy config, TLS certs < 10MB

Tier 3: Nice to have (can be regenerated)

What Why Estimated Size
Ollama models Can re-pull from registry ~88GB
Gatus data Uptime history, can rebuild < 100MB
The Lounge data IRC history < 100MB
Alloy configs Already in git < 1MB

Tier 4: Media (large, different strategy)

What Size Location
zpool/media 482GB ZFS on sdf
Seedbox downloads 1.4TB /mnt/seedbox
All-might media 900GB /mnt/all-might
Filedump ~empty /mnt/filedump (10.9TB)

3. Proxmox Backup Server (PBS)

Overview

PBS is a dedicated backup solution built by Proxmox for backing up VMs, containers, and host configs. It understands Proxmox's storage format natively and does incremental, deduplicated backups at the block level.

Key Features

  • Incremental backups — after initial full backup, only changes are sent
  • Deduplication — chunks shared across backups; 10 backups of the same VM don't use 10x space (5:1+ dedup ratios common)
  • Retention automation — rules like "keep 7 daily, 4 weekly, 6 monthly"
  • Verification jobs — periodically confirms backups are readable
  • Granular restore — recover specific files/directories without full VM restore
  • Optional encryption — for remote/untrusted locations
  • S3 support (v4.0+) — native S3-compatible object storage as backup target (tech preview as of 2026)
  • Sync operations — replicate backups between PBS instances
  • Web UI — integrated into Proxmox VE interface

Hardware Requirements (for the small PC)

Minimum: - 64-bit CPU, 2+ cores - 4GB RAM minimum (+ 1GB per TB of backup storage) - Small SSD for OS - Larger HDD/SSD for datastore

For your 2x 1TB drives: - Install PBS on one drive, use the other as datastore - OR: Software RAID-1 (mirror) for redundancy, but halves capacity - Best approach: PBS OS on a small partition of drive 1, rest of both drives as ZFS mirror for the datastore (gives ~1TB usable with redundancy) - With ZFS mirror: aim for 8GB+ RAM (4GB base + 1GB per TB × 2)

What PBS Is Good For

  • Full LXC container backups (all 20 containers)
  • Nightly incremental backups with low overhead
  • Quick restores (5-minute restore to previous state)
  • Testing restores by restoring to a new VMID

What PBS Is NOT Good For

  • Large media libraries (40TB+ — use NAS with redundancy instead)
  • Cold archives (use glacier-style cloud storage)
  • Non-Proxmox systems (macOS, Steam Deck, etc.)
  • Application-level backups (database dumps, config exports)

PBS + S3 Offsite (v4.0)

PBS 4.0 (released Aug 2025) added native S3 storage targets. You can keep a local copy on PBS and have an offsite copy synced to Backblaze B2/Wasabi/etc. Still in tech preview but functional.

Recommendation

PBS is the right choice for your Proxmox infrastructure. Install it on the small PC with the 2x 1TB drives. It's purpose-built for exactly this use case and integrates seamlessly with your existing Proxmox setup. For Tier 1-3 data (configs, databases, container state), this is the simplest path with the most complete coverage.

4. PBS Boot Drive: Flash Drive vs USB SSD

The Question

Can you boot PBS from a USB flash drive to free both 1TB drives entirely for backup data?

Answer: No — Use a USB SSD Instead

USB flash drives will fail in production. Proxmox/PBS continuously writes logs, graph data, metadata, and filesystem journals. Standard USB flash drives: - Use the cheapest NAND flash available - Lack wear leveling, DRAM cache, garbage collection, and power-loss protection - Go read-only after weeks to months of continuous writes - Known failure mode: the drive silently becomes read-only, and PBS stops functioning

The Proxmox forum consensus: "You can install Proxmox onto USB flash drives. The result is exactly as useful as installing ESXi on a USB flash drive." — i.e., it technically works until it doesn't, and when it fails, you lose the whole server.

A proper SSD (even a tiny 64-128GB one) in a USB-C enclosure has: - Wear leveling and TRIM support - Proper DRAM controller - Power-loss protection - Write endurance measured in hundreds of TBW vs flash drives' single-digit TBW

Options (cheapest to best): | Option | Cost | Notes | |--------|------|-------| | 64-128GB M.2 SATA SSD + USB enclosure | ~$15-25 total | Best value; reuse any old M.2 SSD | | Samsung T7 Shield 256GB portable SSD | ~$30 | Plug-and-play, durable | | Internal M.2/SATA slot (if PC has one) | ~$10-15 for small SSD | Best option — no USB involved |

Check first: Does the small PC have an internal M.2 or SATA slot? If so, use that for the OS and skip USB entirely.

Storage Layout with USB SSD Boot

Small PC:
├── USB SSD (64-128GB) → PBS OS (Debian + PBS services)
├── 1TB Drive A ─┐
│                ├── ZFS Mirror → PBS Datastore (~1TB usable)
├── 1TB Drive B ─┘
└── 18TB External USB → Secondary datastore (PBS sync + media backups)

This gives you: - ~1TB of ZFS-mirrored, deduplicated backup storage (PBS primary) - 18TB of overflow/offsite-rotation storage - All data on redundant storage (ZFS mirror protects against single drive failure)

Alternative: No Mirror (2TB usable, no redundancy)

If you'd rather maximize capacity over redundancy: 

├── 1TB Drive A → PBS Datastore 1
├── 1TB Drive B → PBS Datastore 2 (or single 2TB pool, no mirror)
Less safe, but with PBS syncing to the 18TB external you still have a copy.

5. Backrest (Restic) vs Kopia — Direct Comparison

Feature Comparison

Feature Backrest (wraps Restic) Kopia
Architecture Restic engine + Backrest web UI (2 projects) All-in-one (engine + UI + server)
Web UI Clean, functional Built-in, slightly more polished
CLI Full restic CLI underneath Full Kopia CLI
Server mode restic rest-server (separate component) Built-in — manage multiple machines from one dashboard
Performance Fast (100-300 MB/s) Faster (parallel uploads + default zstd compression)
Deduplication Content-defined chunking Content-defined chunking (similar quality)
Compression zstd (since restic 0.16) zstd, s2, gzip, pgzip (more options)
Encryption Always-on AES-256 AES-256 + HMAC-SHA256
Cloud backends S3, B2, Azure, GCS, SFTP, REST, rclone S3, B2, Azure, GCS, SFTP, WebDAV, rclone
Append-only Yes (rest-server --append-only flag) Yes
Notifications Discord, Slack, Gotify, Shoutrrr, ntfy Webhooks (less built-in options)
Retention Via restic forget + Backrest policies Built-in granular retention policies
Docker Official images for both components Official Docker images
Maturity Restic: 2015, battle-tested (20k+ stars). Backrest: 2023 Kopia: 2019, rapidly maturing (8k+ stars)
IaC-friendly Restic: CLI flags/env vars. Backrest: JSON config Kopia: JSON config + CLI (all-in-one)
Restore Browse snapshots in UI, FUSE mount Browse in UI, FUSE mount
Database hooks Pre/post scripts (via Backrest hooks) Pre/post snapshot actions

Performance Benchmarks (2026 data)

  • Initial backup speed: Kopia leads due to parallel uploads
  • Incremental backup: Both similar; Kopia slightly faster with compression
  • Restore speed: Similar; both support parallel restore
  • Storage efficiency: Nearly identical dedup ratios
  • Memory usage: Restic uses more; Kopia more efficient

Recommendation

Kopia is the better fit for this homelab because: 1. All-in-one — no juggling restic + backrest + rest-server as separate components 2. Server mode — centralized backup management for multiple LXCs from one dashboard 3. Faster with better compression out of the box 4. Built-in scheduling — no cron dependency 5. IaC-friendly — single JSON config, fully CLI-driven setup, Docker-native

Backrest (Restic) wins if: 1. Native ntfy notification support is a priority (Backrest has it built-in) 2. You want the larger restic community and ecosystem 3. Simpler mental model (restic is just a tool, Backrest is just a UI) 4. You value battle-tested maturity over newer features

IaC Considerations

Both are deployable via Docker Compose and configurable via JSON/YAML. For Forgejo Actions CI/CD: - Kopia: kopia repository connect, kopia policy set, kopia snapshot create — all CLI-driven - Backrest: Backrest config is JSON, restic repos configured via environment variables

6. Self-Hosted Backup Tools — Simple to Complete

Tier 1: Simplest Solutions

rsync + cron

  • What: File-level sync/copy via SSH
  • Complexity: Minimal — one cron job, one rsync command
  • Pros: Already available everywhere, no new software, fast incremental copies
  • Cons: No encryption, no deduplication, no retention management, no versioning
  • Best for: Quick-and-dirty file copies to the backup server, one-off scripts
  • Example: rsync -avz [email protected]:/var/lib/forgejo/ /backup/forgejo/

rclone

  • What: Swiss-army knife for syncing files to any storage backend (S3, SFTP, local, WebDAV, Google Drive, etc.)
  • Complexity: Low — single binary, config file
  • Pros: 40+ backends, encryption, bandwidth limiting, already familiar from your homelab
  • Cons: Not a backup tool per se — no deduplication, limited retention, snapshots need scripting
  • Best for: Syncing specific directories to cloud storage
  • Website: https://rclone.org/

Tier 2: Backup-Specific CLI Tools

  • What: Fast, secure, deduplicated backup tool
  • Language: Go (single static binary)
  • Encryption: AES-256 (full repo encryption, always on)
  • Deduplication: Content-defined chunking
  • Compression: None built-in (relies on dedup for space savings)
  • Backends: Local, SFTP, REST server, S3, B2, Azure, GCS, Wasabi, MinIO
  • Immutable repos: Yes (append-only mode)
  • Scheduling: Manual (cron) — or use Backrest/Autorestic for orchestration
  • Docker: Single binary, no Docker needed; restic/rest-server for a centralized repo
  • Performance: 100-300 MB/s on modern hardware
  • Best for: Most homelabbers — widest use case coverage with least friction
  • Website: https://restic.net/

BorgBackup (Borg)

  • What: Deduplicating archiver with compression and authenticated encryption
  • Language: Python/Cython
  • Encryption: AES-256 (full or authenticated)
  • Deduplication: Global chunk-level (unmatched dedup across repos)
  • Compression: lz4, zstd, zlib (zstd is excellent balance of speed/ratio)
  • Backends: Local, SSH/SFTP only (needs rclone for cloud)
  • Immutable repos: Yes (append-only mode)
  • Scheduling: Manual — use Borgmatic for orchestration
  • Performance: Very fast — ~250 CPU seconds where Restic needs ~696 for similar workloads
  • Best for: Linux-focused setups where storage efficiency matters and targets are SSH-accessible
  • Website: https://www.borgbackup.org/

Duplicati

  • What: Backup client with web GUI, encrypted incremental compressed backups
  • Language: C#
  • Encryption: AES-256 (data only)
  • Deduplication: Block-level
  • Compression: Multiple algorithms
  • Backends: 20+ (local, SMB, SFTP, FTP, WebDAV, S3, B2, Google Drive, OneDrive, Dropbox, Wasabi)
  • Scheduling: Built-in (web UI)
  • Interface: Web GUI + CLI
  • Best for: Beginners who want a GUI, or exotic cloud targets (Google Drive, OneDrive)
  • Website: https://www.duplicati.com/

Kopia ⭐ (Rising star)

  • What: Cross-platform backup with built-in web UI, server mode, fast performance
  • Language: Go
  • Encryption: AES-256 + HMAC-SHA256
  • Deduplication: Content-defined chunking (65-82% dedup ratios)
  • Compression: Multiple algorithms including zstd
  • Backends: Local, SFTP, S3, B2, Azure, GCS, WebDAV, rclone
  • Server mode: Yes — manage backups for multiple machines from one dashboard
  • Scheduling: Built-in
  • Interface: CLI + Web UI
  • Best for: Self-hosters who want a modern all-in-one (replaces restic + backrest)
  • Website: https://kopia.io/

Duplicacy

  • What: Cloud backup tool with global cross-machine deduplication
  • Language: Go
  • Deduplication: Global (all clients sharing storage share chunks) — unique killer feature
  • Backends: S3, B2, Google Drive, Azure, Dropbox, SFTP, WebDAV, local
  • Best for: Fleets of similar servers/containers (Docker hosts, VPSes)
  • Note: CLI is open source, Web UI requires commercial license
  • Website: https://duplicacy.com/

Tier 3: All-in-One / Server Solutions

Backrest (Web UI for Restic) ⭐

  • What: Web-accessible orchestrator built on top of restic
  • Features: Create repos, schedule backups, browse/restore snapshots, retention policies, notifications (Discord, Slack, Gotify, Shoutrrr)
  • Interface: Clean web UI
  • Deployment: Single Go binary or Docker
  • Best for: Making restic user-friendly with a dashboard
  • Website: https://garethgeorge.github.io/backrest/

Borgmatic (Orchestrator for Borg)

  • What: Configuration-driven wrapper around BorgBackup
  • Features: YAML config, scheduled backups, pruning, monitoring hooks, database dump hooks (PostgreSQL, MariaDB, SQLite)
  • Docker: Official borgmatic-collective/docker-borgmatic image
  • Best for: Automating Borg with pre/post hooks for database dumps
  • Website: https://torsion.org/borgmatic/

UrBackup

  • What: Client/server network backup for Windows, macOS, and Linux
  • Features: File + image backups, web UI, deduplication, continuous monitoring, bare-metal restore
  • Pros: Automatic client discovery, background operation, incremental is very fast
  • Cons: High system requirements, database needs fast SSD, limited cloud options compared to restic/borg
  • Best for: Mixed Windows/Mac/Linux networks with multiple endpoints
  • Website: https://www.urbackup.org/

Zerobyte (GUI for Restic)

  • What: Open-source backup automation platform wrapping Restic
  • Features: Modern dashboard, repository management, scheduled jobs, snapshot monitoring
  • Backends: Local, S3, GCS, MinIO, Wasabi, DigitalOcean Spaces
  • Best for: Visual management of restic backups
  • Website: https://github.com/nicotsx/zerobyte

Minarca

  • What: Client-server backup platform with centralized web console
  • License: AGPL-3.0
  • Best for: Centralized backup management for multiple clients
  • Website: https://minarca.org/

Comparison Matrix

Tool GUI Cloud Backends Dedup Compression Encryption Docker Scheduling Complexity
rsync No No No No No (SSH) N/A cron Trivial
rclone No 40+ No No Yes N/A cron Low
Restic No* S3/B2/Azure/GCS/SFTP Yes No Always on Optional cron Low-Medium
Borg No* SSH only Best Yes (zstd) Yes Optional cron Medium
Duplicati Web UI 20+ Yes Yes Yes Yes Built-in Low
Kopia Web UI S3/B2/Azure/GCS/SFTP Yes Yes (zstd) Yes Yes Built-in Low-Medium
Duplicacy CLI/Web$ S3/B2/GDrive/Azure Global Yes Yes No Built-in Medium
Backrest Web UI (via restic) (via restic) (via restic) (via restic) Yes Built-in Low
Borgmatic No (via borg) (via borg) (via borg) (via borg) Yes Built-in Medium
UrBackup Web UI Limited Yes Yes Yes Yes Built-in Medium
PBS Web UI S3 (v4+) Yes Yes Yes No Built-in Medium

* = Backrest/Borgmatic/Zerobyte add GUIs on top

7. Database-Specific Backup Tools

Databasus

  • What: PostgreSQL, MySQL, MariaDB, MongoDB backup tool with web UI
  • Features: Automated scheduling, multiple storage destinations, encryption, real-time notifications, health monitoring
  • Docker: Yes
  • License: Apache-2.0
  • Best for: Your MediaManager PostgreSQL and all-might MariaDB
  • Website: https://databasus.com/

Databasement

  • What: Self-hosted database backup manager with web UI
  • Databases: MySQL, PostgreSQL, MariaDB, MongoDB, SQLite, Redis
  • Features: Schedule, backup, restore to S3/SFTP/local, SSH tunnel support, GFS retention
  • Best for: Comprehensive database coverage including SQLite (covers most of your databases)
  • Website: https://github.com/David-Crty/databasement

Portabase

  • What: Backup and restore tool with agent architecture
  • Databases: PostgreSQL, MySQL, MariaDB, MongoDB (Redis coming)
  • Features: Central server + lightweight agents, encrypted transfer
  • License: Apache-2.0
  • Website: https://portabase.io/

Barman (PostgreSQL-specific)

  • What: Backup and Recovery Manager for PostgreSQL
  • Features: Point-in-time recovery, WAL archiving, parallel backup/restore
  • Best for: If you need enterprise-grade PostgreSQL backup beyond simple dumps
  • Website: https://pgbarman.org/

Simple Approach: pg_dump + mysqldump + sqlite3 .backup

For your scale, a cron job with dump commands may be sufficient: 

# PostgreSQL (MediaManager)
docker exec mediamanager_db pg_dump -U user dbname > /backup/mediamanager-$(date +%F).sql

# MariaDB (all-might)
docker exec mariadb mariadb-dump --all-databases -u root -p > /backup/mariadb-$(date +%F).sql

# SQLite (various)
sqlite3 /path/to/db.sqlite3 ".backup '/backup/service-$(date +%F).db'"
Then let restic/borg handle versioning and offsite copy of these dumps.

8. Docker Volume Backup Tools

docker-volume-backup (offen) ⭐

  • What: Lightweight companion container for recurring Docker volume backups
  • Destinations: Local, S3, WebDAV, Azure Blob, Dropbox, Google Drive, SSH
  • Features:
  • Pre/post hooks (run mysqldump before backup, etc.)
  • Can stop/restart containers for consistency
  • GPG encryption
  • Notifications (email, Slack, etc.)
  • Rotation/pruning of old backups
  • Best for: Your Docker-heavy LXC 103 setup
  • Website: https://github.com/offen/docker-volume-backup

Resticker (Docker + Restic)

  • What: Run restic backups via a Docker container with cron scheduling
  • Best for: Automating restic inside Docker environments
  • Website: https://github.com/djmaze/resticker

docker-vackup

  • What: Simple script to backup and restore Docker volumes
  • Best for: Quick manual volume exports
  • Website: https://github.com/BretFisher/docker-vackup

9. Cloud / Online Backup Solutions & Pricing

Pricing Comparison (per TB/month)

Provider Storage $/TB/mo Egress Min Duration Free Tier S3 Compatible Notes
Backblaze B2 $6.00 $0.01/GB (3x free via CDN partners) None 10GB Yes Best general-purpose; free egress via Cloudflare
Wasabi $6.99 Free (1:1 ratio cap) 90 days None Yes 1TB minimum billing; no API charges
Cloudflare R2 $15.00 Free (always) 30 days (IA) 10GB Yes Zero egress ever; great for frequent restores
Hetzner Storage Box ~€3.20/TB (BX11) Free (unlimited) None None No (SFTP/Borg/Restic) EU-based; native Borg+Restic support
IDrive e2 ~$4.00 Free (3x ratio) None None Yes Cheapest S3-compatible; 1TB min
AWS S3 Glacier ~$5.00 $0.09/GB (!!) 90 days None Yes Cheap storage, brutal egress costs
Backblaze Personal $9/mo unlimited Included None None No (client app) macOS/Windows only, unlimited per machine

Hetzner Storage Box Plans (EU-based, excellent for Borg/Restic)

Plan Storage Price/mo Snapshots Connections
BX11 1 TB ~€3.20 10 10
BX21 5 TB ~€10.40 20 10
BX31 10 TB ~€20.80 30 10
BX41 20 TB ~€39.90 40 10
  • Supports: FTP, FTPS, SFTP, SCP, Samba/CIFS, BorgBackup, Restic, Rclone, rsync, HTTPS, WebDAV
  • No minimum contract, cancel anytime, hourly billing capped monthly
  • Optional Germany or Finland location

Backblaze Personal Backup (for macOS laptop)

Plan Price Storage Attached Drives
Monthly $9/mo Unlimited Included free
Annual $99/yr Unlimited Included free
2-Year $189/2yr Unlimited Included free
  • Backs up everything automatically, < 1% CPU usage
  • External drives included at no extra cost
  • macOS and Windows only

Cost Estimates for Your Setup

Scenario A: Configs + databases only to cloud (~50GB) | Provider | Monthly Cost | |----------|-------------| | Backblaze B2 | ~$0.30 | | IDrive e2 | ~$5.00 (1TB min) | | Hetzner BX11 | ~€3.20 | | Cloudflare R2 | ~$0.75 |

Scenario B: All Tier 1-3 + some media (~500GB) | Provider | Monthly Cost | |----------|-------------| | Backblaze B2 | ~$3.00 | | Wasabi | ~$6.99 (1TB min) | | Hetzner BX11 | ~€3.20 (1TB) | | Cloudflare R2 | ~$7.50 |

Scenario C: Full media archive offsite (~3TB) | Provider | Monthly Cost | |----------|-------------| | Backblaze B2 | ~$18.00 | | Wasabi | ~$20.97 | | Hetzner BX31 | ~€20.80 (10TB) | | IDrive e2 | ~$12.00 |

10. 18TB External Drive Strategy

Connection Options

Approach Pros Cons
Connected to PBS small PC Always available, PBS sync jobs auto-copy, IaC-friendly Another USB device on small PC
Connected to Proxmox (chizuru) Direct access to all data USB drives cause known issues: host lockups when full, unreliable auto-mount, can't use with PBS passthrough
Connected to macOS laptop Portable, native Finder/rsync, easy media management Manual process, drive offline when disconnected

Recommendation: Connect to PBS Small PC

Why: This avoids the Proxmox USB issues you've experienced before, and PBS can automatically sync its datastores to the external drive. The small PC becomes your dedicated backup appliance.

Known Proxmox USB issues (confirmed by forum reports): - USB drives can lock up the entire host when they fill up - Auto-mount after reboot is unreliable (needs manual fstab workaround) - PBS cannot back up passthrough devices - Multi-disk USB enclosures are especially problematic with xhci driver failures

Partition Layout (18TB)

18TB External HDD (connected to PBS small PC)
├── Partition 1: 8TB ext4 → PBS secondary datastore (sync from primary)
├── Partition 2: 8TB ext4 → Media backup target (rsync from chizuru)
└── Partition 3: 2TB ext4 → Device/laptop backups, misc

Or single partition if you prefer simplicity: 

18TB External HDD → single ext4 partition
├── /mnt/external/pbs-sync/     → PBS secondary datastore
├── /mnt/external/media/        → rsync media from chizuru
├── /mnt/external/devices/      → Laptop/device backups
└── /mnt/external/misc/         → General purpose

Single partition is more flexible (no pre-allocated sizes) but less organized.

PBS → 18TB Sync

PBS supports creating a secondary datastore on the external drive and running sync jobs from the primary ZFS mirror datastore: 1. Format and mount the drive on the PBS PC 2. Create a new PBS datastore pointing to the external mount 3. Configure a sync job (e.g., weekly) from primary → external datastore 4. Can filter which VMs/LXCs get synced and set different retention 5. Before unplugging: set datastore offline in PBS UI, wait for tasks to finish

Media Backup from Chizuru → 18TB

Since the drive is on the PBS PC (not chizuru), rsync over the network: 

# Run from PBS PC (or via cron/systemd timer)
rsync -avh --progress [email protected]:/mnt/all-might/ /mnt/external/media/all-might/
rsync -avh --progress [email protected]:/zpool/media/ /mnt/external/media/zpool-media/
rsync -avh --progress [email protected]:/mnt/seedbox/ /mnt/external/media/seedbox/

Gigabit LAN between chizuru and PBS PC = ~100 MB/s. First full sync of ~2.8TB ≈ 8-9 hours. Incremental syncs are fast.

If You Prefer macOS-Connected (for portability)

Format: exFAT for cross-platform compatibility (macOS + Linux readable). Downside: no Linux file permissions, no symlinks, no hardlinks — worse for restic/borg repos.

Better: Two partitions — one exFAT (macOS-accessible media browse), one ext4 (Linux backup tools). macOS can read ext4 with macFUSE + ext4fuse but can't write.

rsync GUI for macOS: | App | Price | Notes | |-----|-------|-------| | RsyncUI | Free, open source | SwiftUI, actively maintained (v2.9.3, March 2026). Best option. | | RsyncGUI | Free, open source | Modern RsyncOSX alternative, SwiftUI | | Sync App | Free | Clean native UI, exclusion patterns, preview mode | | Truck.app | $11.99 | Polished commercial option |

RsyncUI: https://rsyncui.netlify.app/ — recommended for macOS rsync with a GUI.

IaC for External Drive

The mount, sync jobs, and rsync cron can all be managed via Ansible: - Playbook to configure fstab entry, mount point, PBS datastore - Systemd timer for rsync media sync - PBS sync job configured via PBS API or config files

11. Device Backups (macOS, Steam Deck, Retroid Pocket 6)

Status: Shelved — will revisit after local backup infrastructure is established.

macOS Laptop

Option 1: Time Machine to Linux Server (Self-Hosted) ⭐

  • Set up Samba on the small backup PC with Time Machine-compatible share
  • Requires vfs_fruit module with fruit:time machine = yes
  • macOS discovers it automatically via mDNS/Bonjour
  • Encrypted, versioned, zero-effort after setup
  • Docker image available: mbentley/docker-timemachine
  • Pros: Native macOS integration, automatic, versioned
  • Cons: Requires Samba configuration; no cloud component

Option 2: Restic/Kopia on macOS

  • Install via Homebrew: brew install restic or brew install kopia
  • Back up to the small PC (restic rest-server) or directly to B2/R2
  • Schedule with launchd (macOS cron equivalent)
  • Pros: Deduplicated, encrypted, cloud-compatible, same tool as server backups
  • Cons: No bare-metal restore; need separate strategy for macOS system recovery

Option 3: Backblaze Personal Backup ($9/mo)

  • Unlimited backup of entire Mac including external drives
  • Zero configuration — install and forget
  • Cloud-only — restore via web or shipped hard drive ($189 for USB drive)
  • Pros: Simplest possible solution, unlimited storage
  • Cons: Cloud-only, closed source, restore can be slow for large datasets

Option 4: Time Machine + Restic (Belt and Suspenders)

  • Time Machine to backup PC for quick local restores
  • Restic to Backblaze B2 for offsite/disaster recovery
  • Best approach for comprehensive coverage

Steam Deck

Save Data Only

Option A: Syncthing (Recommended) ⭐ - Install Syncthing on Steam Deck (Flatpak or manual) - Sync /home/deck/Emulation/saves and /home/deck/Emulation/states to your homelab - Can run on a Raspberry Pi, NAS, or Docker container as the always-on relay - Near-real-time sync (configurable interval) - Also syncs non-Steam game saves - Note: After Google removed Syncthing from Play Store, use Catfriend1's fork on F-Droid for Android devices

Option B: EmuDeck Cloud Saves - Built into EmuDeck (supporters only) - Sync saves across devices - Less flexible than Syncthing

Option C: rsync/rclone manual backup - SSH into Steam Deck (enable SSH in settings) - rsync -avz deck@steamdeck:/home/deck/Emulation/saves/ /backup/steamdeck/ - Simple but manual

Full System Backup

Clonezilla (Full disk image) - Boot from USB, create full disk image - ~2 hours for 512GB drive - Requires USB-C dock + keyboard + external drive - Good for before major updates or SSD upgrades - Restore takes ~30 minutes

dd (block-level copy) - If you have a Linux PC with an M.2 slot: dd if=/dev/nvme0n1 of=/path/to/backup.img bs=4M - Fastest but requires disassembly

Retroid Pocket 6 (Android)

Save Data

Option A: Syncthing ⭐ - Install Syncthing fork from F-Droid - Sync RetroArch /saves and /states folders - Also sync standalone emulator save directories - Works over WiFi to your homelab Syncthing relay - Guide: https://retrogamecorps.com/2024/08/11/guide-using-syncthing-with-retro-handhelds/

Option B: SD Card + Manual Backup - Keep ROMs, saves, configs on microSD card - Periodically back up the SD card to your PC/NAS - Simple but manual and easy to forget

Option C: ADB Backup - Connect via USB, use adb backup (deprecated but functional) - Can backup app data, saves, configs - Seedvault (Android backup app) uses same APIs — more user-friendly but limited

Emulator Save Locations (Retroid Pocket 6)

Emulator Save Path
RetroArch /RetroArch/saves/ and /RetroArch/states/
Dolphin Built-in user data exporter
Standalone emulators Varies — check each app's settings

Cross-Device Sync Strategy

Syncthing is the clear winner for syncing saves across Steam Deck, Retroid Pocket 6, and your homelab:

  1. Run Syncthing relay on Docker (LXC 103 or small backup PC)
  2. Install on Steam Deck, Retroid Pocket 6
  3. Configure folders: emulation saves, states, configs
  4. All devices stay in sync automatically
  5. The relay server acts as the always-on backup

12. Whole LXC vs Targeted Backups

Comparison

Whole LXC (PBS/snapshot) Targeted (config + DB dumps)
Restore speed Fast — spin up and it just works Slow — recreate LXC, reinstall services, restore configs, import DB dumps, verify
Restore reliability High — exact state, no missed dependencies Risky — did you capture everything? env vars, permissions, cron jobs, Docker state?
Storage cost Large — full filesystem including images, layers, caches Small — just the data that matters (often 1-10% of LXC size)
Backup frequency Expensive to run often Cheap to run hourly
Dedup potential High with PBS (block-level dedup, 5:1+ common) Already small, not much to dedup
Granularity All or nothing per LXC Can restore just one DB or one config

What are you protecting against?

Scenario Best approach
Disk dies, need full recovery Whole LXC — back in 5 min, not rebuilding for hours
Bad config change broke a service Targeted — restore just that config, don't roll back everything
Corrupted database Targeted — restore the DB dump, keep everything else
Total host failure Whole LXC to a new Proxmox host
Migrating to new hardware Whole LXC

Decision: Both, at different tiers

Tier 1 — Whole LXC snapshots (PBS, nightly) - Covers disaster recovery — disk failure, host failure, migration - PBS dedup makes this cheap: ~108GB actual data across 20 LXCs, with dedup a week of nightly backups might only use ~150-200GB - This is the "everything is broken, bring it all back" safety net

Tier 2 — Targeted DB dumps + config exports (cron, hourly or daily) - Small, fast, portable — doesn't depend on Proxmox to restore - Can version-control configs (git), ship DB dumps offsite cheaply - This is the "I broke one thing, fix just that thing" tool - Also the "rebuild from scratch on different infra" insurance

Why both? - Whole LXC backup of docker-host is 35GB. If you just need vaultwarden's 305KB SQLite, restoring 35GB is wasteful - Conversely, if the disk dies and you only have DB dumps, you're spending hours recreating LXCs, installing Docker, pulling images, setting up networking, fixing permissions — and you will miss something - Targeted backups also prove you understand what state each service actually needs

Impact on disk layout: - With PBS nightly backups, losing a single disk means you lose at most ~24hrs of data, and restore takes minutes - This makes a no-mirror disk layout viable — redundancy comes from backups instead of from disk mirroring - A mirror's value drops from "prevents data loss" to "prevents downtime" (no restore needed, just keeps running) - For a single-operator homelab, PBS restore is acceptable — and you get full use of all 3 disks

Architecture Overview

┌─────────────────────────────────────────────────────────┐
│                    BACKUP TARGETS                        │
├──────────────────┬──────────────────┬───────────────────┤
│  Small PC (PBS)  │  Cloud (B2/R2)   │  External HDD     │
│  2x 1TB drives   │  Offsite copy    │  Full media dump   │
│  ZFS mirror      │  Configs+DBs     │  Quarterly         │
└────────┬─────────┴────────┬─────────┴─────────┬─────────┘
         │                  │                   │
    ┌────┴────┐      ┌──────┴──────┐    ┌───────┴───────┐
    │   PBS   │      │Restic/Kopia │    │  rsync/rclone │
    │ Nightly │      │   Daily     │    │   Manual      │
    │ LXC/VM  │      │ DB dumps    │    │   Media       │
    └────┬────┘      │ Configs     │    └───────────────┘
         │           │ Device sync │
    ┌────┴────┐      └──────┬──────┘
    │Proxmox  │             │
    │  Host   │      ┌──────┴──────┐
    │ chizuru │      │   Devices   │
    └─────────┘      │ Mac/Deck/RP │
                     └─────────────┘

Phase 1: Foundation (Week 1)

Install PBS on small PC: - Install Proxmox Backup Server on drive 1 - Create ZFS mirror datastore with both 1TB drives (~1TB usable) - Add PBS as storage target in Proxmox VE - Schedule nightly backup of all 20 LXC containers - Retention: keep 7 daily, 4 weekly, 2 monthly - Enable verification job (weekly)

Set up database dump scripts: - Cron job on each database host to dump daily: - pg_dump for MediaManager PostgreSQL - mariadb-dump for all-might MariaDB - sqlite3 .backup for all SQLite databases - Store dumps in a known location that PBS will capture

Phase 2: Offsite + File Backups (Week 2)

Install Restic or Kopia: - Choose one: - Restic + Backrest if you want battle-tested + clean web UI - Kopia if you want all-in-one with built-in UI and server mode - Deploy on small PC (or as Docker container on LXC 103) - Configure repos: one local (small PC), one cloud (Backblaze B2 or Hetzner Storage Box) - Back up database dumps, configs, Vault data daily to both targets - Use append-only mode for ransomware protection

Cloud storage selection: - Budget option: Backblaze B2 ($6/TB/mo) — for Tier 1-2 data (~50-100GB = ~$0.60/mo) - EU option: Hetzner BX11 (€3.20/mo for 1TB) — native Borg/Restic support, GDPR - Zero egress: Cloudflare R2 ($15/TB/mo but free egress) — if you'll restore frequently

Phase 3: Device Backups (Week 3)

macOS laptop: - Set up Samba Time Machine share on small PC (Docker: mbentley/docker-timemachine) - OR: Install restic via Homebrew, back up to small PC + B2 - Consider Backblaze Personal ($9/mo) for zero-effort unlimited cloud backup

Steam Deck + Retroid Pocket 6: - Deploy Syncthing relay as Docker container - Configure save folder sync on all devices - Steam Deck: sync /home/deck/Emulation/saves/ and /home/deck/Emulation/states/ - Retroid: sync RetroArch saves/states folders

Phase 4: Media + Full Coverage (Month 2)

Media backup to external HDD: - Quarterly manual backup of zpool/media (482GB), seedbox (1.4TB), all-might (900GB) to external HDD - Use rsync for incremental copies: rsync -avh --progress /source/ /mnt/external/ - Store external HDD offsite (friend's house, safe deposit box, etc.)

Optional: Media to cloud (expensive but comprehensive): - If you want offsite media copies, Backblaze B2 at ~3TB = ~$18/mo - Consider IDrive e2 (~$12/mo for 3TB) as cheaper alternative

Phase 5: Automation & Monitoring (Ongoing)

Notifications: - Backrest/Kopia → ntfy for backup success/failure alerts - PBS → email or webhook notifications - Integrate with Grafana for backup status dashboard

Testing restores: - Monthly: restore one random LXC backup to a test VMID - Monthly: restore one database dump and verify data integrity - Quarterly: verify cloud backup can be downloaded and decrypted

Quick-Start Decision Matrix

If you want... Use this
Simplest possible Proxmox backup PBS on small PC
Database backups with web UI Databasement or Databasus
File/config backup with dedup + encryption Restic + Backrest or Kopia
Docker volume backup docker-volume-backup (offen)
macOS backup (zero effort) Backblaze Personal ($9/mo)
macOS backup (self-hosted) Time Machine → Samba on small PC
Gaming device save sync Syncthing
Cheapest cloud offsite IDrive e2 or Backblaze B2
Full media offsite External HDD (quarterly rsync)

14. Sources

Proxmox Backup Server

Backup Tool Comparisons

Backup Tools

Database Backup Tools

Cloud Storage Pricing

Device Backups

rsync GUI for macOS