Home Server Backup & Storage Strategy Research¶

Date: January 23, 2026
For: Proxmox home server with mixed drives

Executive Summary¶

Recommended Solution:

Google sync: rclone with automated snapshots
Storage: mergerfs + SnapRAID for mixed drives
Archives: Deduplicate with jdupes, store on server + external HDD offsite
Critical configs: Git + automated backup script
Expansion path: Add drives to mergerfs pool anytime

1. Google Drive/Photos Sync Tools¶

rclone (RECOMMENDED)¶

Status: Actively maintained, v1.72.1 (Dec 2025), 55.1k stars

Pros:¶

✅ Native Google Drive & Google Photos support built-in
✅ Snapshot-friendly: Use rclone sync or rclone copy with --backup-dir for versioning
✅ Automation: Easy systemd timers or cron jobs
✅ Encryption: Built-in crypt backend if needed
✅ Bandwidth control: Throttling, scheduling
✅ Bisync mode: Two-way sync (experimental but stable)
✅ Very active: 885 contributors, releases every few months
✅ Mount option: Can mount Google Drive as filesystem
✅ API limits handled: Built-in rate limiting and retry logic

Cons:¶

⚠️ Command-line only (but many GUI wrappers exist: RcloneView, rclone UI)
⚠️ Initial setup requires OAuth authentication
⚠️ Google Photos has some limitations (album structure not preserved)

Best Practices for Your Use Case:¶

# Daily snapshot of Google Drive work docs (600GB)
rclone sync gdrive:/ /mnt/storage/google-drive-backup \
  --backup-dir /mnt/storage/google-drive-backups/$(date +%Y-%m-%d) \
  --drive-skip-gdocs \
  --transfers 8 \
  --checkers 16

# Daily snapshot of Google Photos (400GB)
rclone sync gphotos:/ /mnt/storage/google-photos-backup \
  --backup-dir /mnt/storage/google-photos-backups/$(date +%Y-%m-%d) \
  --transfers 4

Cost: FREE, open source (MIT license)

Alternative: insync¶

Status: Commercial, $29.99 one-time per account

Pros:¶

✅ Native GUI application
✅ Selective sync
✅ Commercial support
✅ Windows, Mac, Linux

Cons:¶

❌ Not recommended for snapshots - designed for real-time sync
❌ Cost adds up ($60 for 2 accounts)
❌ Less flexible for automation

Verdict: Skip for your use case

Alternative: google-drive-ocamlfuse¶

Status: Linux only, less maintained

Cons:¶

❌ Mount-only solution, not backup-focused
❌ Performance issues with large files
❌ Less actively maintained than rclone
❌ No Google Photos support

Verdict: Skip, rclone is superior

2. Storage Strategy: Mixed Drives with Future Expansion¶

Recommended: mergerfs + SnapRAID¶

Why This Combo?¶

mergerfs (5.4k stars, v2.41.1 Nov 2025)

✅ Perfect for mixed drives: 4TB, 1TB, 1TB, 250GB SSDs - all usable as-is
✅ Add drives anytime: Just remount with new path
✅ Individual filesystem access: If mergerfs fails, access drives directly
✅ Near-native performance: Passthrough IO
✅ Flexible policies: Control where files are written (most-free-space, existing-path, etc.)
✅ No reformatting: Use existing ext4/xfs/btrfs drives

SnapRAID (v13.0, 2024)

✅ Parity protection: Up to 6 parity disks (1-2 recommended for home)
✅ Snapshot-based: Only scans changed files
✅ Data verification: Scrub to detect silent corruption
✅ Partial recovery: Loss limited to failed disks
✅ Low resource: Runs periodically, not real-time
✅ Flexible: Disks can be different sizes

Setup for Your Drives:¶

# 1. Format drives (if not already formatted)
sudo mkfs.ext4 -L data1 /dev/sdX  # 4TB Hitachi
sudo mkfs.ext4 -L data2 /dev/sdY  # 1TB WD Green
sudo mkfs.ext4 -L data3 /dev/sdZ  # 1TB WD Green (unused)
sudo mkfs.ext4 -L parity1 /dev/sdW # 4TB Maxtor external (for parity)

# 2. Mount individual drives
/dev/sdX /mnt/disk1 ext4 defaults 0 2
/dev/sdY /mnt/disk2 ext4 defaults 0 2
/dev/sdZ /mnt/disk3 ext4 defaults 0 2

# 3. mergerfs pool
mergerfs /mnt/disk1:/mnt/disk2:/mnt/disk3 /mnt/storage \
  -o allow_other,use_ino,cache.files=auto-full,moveonenospc=true,\
     category.create=mfs,dropcacheonclose=true

# 4. SnapRAID config (/etc/snapraid.conf)
parity /mnt/parity1/snapraid.parity
content /var/snapraid/snapraid.content
content /mnt/disk1/.snapraid.content
content /mnt/disk2/.snapraid.content
data d1 /mnt/disk1
data d2 /mnt/disk2
data d3 /mnt/disk3
exclude *.tmp
exclude /tmp/
exclude /lost+found/

# 5. Automate SnapRAID (daily script)
#!/bin/bash
# snapraid-runner.sh
snapraid diff
snapraid sync
snapraid scrub -p 8 -o 30  # Scrub 8% of data older than 30 days

Storage Layout Example:

4TB Hitachi: Archives (1TB) + Google Drive snapshots (600GB) + headroom
1TB WD #1: Google Photos snapshots (400GB) + Jellyfin cache
1TB WD #2: Jellyfin media library + torrents
4TB Maxtor USB: SnapRAID parity (external, always connected)
1TB HGST USB: Offsite rotation backup
SSDs: Proxmox OS + critical VMs/containers + databases

Why NOT ZFS for Your Setup?¶

ZFS Single Disk¶

❌ Major drawbacks:

Must use whole disk (no partition mixing)
Can't add space easily (need zpool replace with larger disk)
Single disk = no redundancy benefits
Memory overhead (1GB RAM per 1TB recommended)
Overkill for basic file storage

✅ Only good for:

Critical system data on SSDs with snapshots
Datasets that need CoW and compression

ZFS with Multiple Disks¶

❌ Your mixed drives don't work:

RAIDZ requires uniform disk sizes (4TB + 1TB = wasted space)
Can't add disks incrementally (need to rebuild vdev)
Expanding requires replacing ALL disks in vdev
RAM requirements scale with capacity

✅ Use ZFS IF:

You buy 3+ identical drives in future
Then create new pool: zpool create tank raidz /dev/sdX /dev/sdY /dev/sdZ

Future Path: Keep mergerfs+SnapRAID for now. If you buy 3x 8TB drives later, create ZFS pool separately and migrate critical data.

Alternative: LVM + ext4¶

Pros:

✅ Can span drives (LVM)
✅ Flexible resizing

Cons:

❌ No parity/redundancy without mdadm
❌ Single point of failure (LVM metadata)
❌ If one drive fails, whole LVM volume may be inaccessible
❌ Can't access individual drives easily

Verdict: mergerfs+SnapRAID safer and more flexible

3. Backup Strategy Without Cloud¶

The 3-2-1 Rule Adapted:¶

3 copies: Original + server snapshot + external offsite
2 media types: Internal drives + external USB HDD
1 offsite: Rotate external to parent's house/office

For YOUR Data:¶

Critical Data (Server configs, Docker, Proxmox)¶

Frequency: Daily
Method: Git + automated backup
Storage: Server + external offsite
Retention: Keep all versions (small size)

# /opt/backup/config-backup.sh
#!/bin/bash
BACKUP_DIR="/mnt/storage/config-backups"
DATE=$(date +%Y-%m-%d-%H%M)

# Proxmox configs
tar czf $BACKUP_DIR/proxmox-$DATE.tar.gz \
  /etc/pve/ \
  /etc/network/interfaces \
  /etc/hosts

# Docker compose files
tar czf $BACKUP_DIR/docker-$DATE.tar.gz \
  /opt/docker/ \
  /opt/stacks/

# Upload to Git repo (private GitHub/Gitea)
cd /opt/docker && git add -A && git commit -m "Auto backup $DATE" && git push

# Copy to external
rsync -av $BACKUP_DIR/ /mnt/offsite-backup/configs/

Important Data (Google Drive/Photos snapshots)¶

Frequency: Daily sync from Google, weekly to offsite
Method: rclone + rsync
Storage: Server (latest) + external (weekly)
Retention: Rolling 30 days on server, monthly on external

Archives (1TB static data)¶

Frequency: One-time migration + offsite copy
Method: Deduplicate, then rsync
Storage: Server + external offsite
Retention: Permanent

Non-critical (Jellyfin media)¶

Frequency: None
Method: N/A
Storage: Server only
Retention: Redownload if lost

Offsite Rotation Strategy¶

Equipment:

1TB HGST USB3 external (current)
Buy: 1x additional 2-4TB external (€60-80)

Schedule:

Week 1-2: External HDD #1 connected to server, continuous sync
Week 3: Swap HDD #1 with #2
Take HDD #1 to offsite location (parent's house, office locker)
Connect HDD #2, let sync run
Week 5: Retrieve HDD #1, swap back
Repeat

Automation:

# /opt/backup/offsite-sync.sh (run when external connected)
#!/bin/bash
EXTERNAL="/mnt/offsite-backup"
if [ -d "$EXTERNAL" ]; then
  # Critical configs (small, always)
  rsync -av --delete /mnt/storage/config-backups/ $EXTERNAL/configs/

  # Archives (full copy)
  rsync -av --delete /mnt/storage/archives/ $EXTERNAL/archives/

  # Google snapshots (weekly checkpoint)
  if [ $(date +%u) -eq 7 ]; then  # Sunday
    rsync -av /mnt/storage/google-drive-backup/ $EXTERNAL/google-drive-weekly/
    rsync -av /mnt/storage/google-photos-backup/ $EXTERNAL/google-photos-weekly/
  fi
fi

4. Archive Consolidation & Deduplication¶

Recommended Tool: jdupes (or fdupes)¶

jdupes (faster, maintained fork)

# Install
sudo apt install jdupes

# 1. Find duplicates across all sources
jdupes -r -S /mnt/hitachi-current /media/old-backups /mnt/google-drive-backup > duplicates.txt

# 2. Review and delete (careful!)
jdupes -r -d -N /mnt/hitachi-current /media/old-backups  # Delete dupes, keep first

# 3. Hard link duplicates to save space (safer)
jdupes -r -L /mnt/storage/archives/

Process:

Mount all old drives read-only
Run jdupes to map duplicates
Manually review critical files
Keep one copy on server + one on external
Delete Google Drive copies after verification

Alternative: rdfind¶

sudo apt install rdfind
rdfind -makehardlinks true /mnt/storage/archives/

Difference:

jdupes: Better control, more options, faster
rdfind: Auto-hardlink by default, simpler

Recommendation: jdupes for initial dedup, then organize manually

5. Config Backup Solutions (Critical Server Data)¶

What to Backup:¶

Proxmox VE:¶

/etc/pve/ - All VM/CT configs
/etc/network/interfaces - Network config
/etc/hosts, /etc/hostname
VM disks (if small): /var/lib/vz/images/
Proxmox Backup Server (PBS) if using

Docker/Containers:¶

All docker-compose.yml files
.env files
Bind mount directories (configs)
Named volumes (export with docker run --rm -v)

System:¶

/etc/ (selective)
Custom scripts in /opt/, /usr/local/bin/
SSH keys, SSL certificates
User cron jobs

Method 1: Git Repository (BEST for configs)¶

# Initialize
cd /opt/docker-configs
git init
git add .
git commit -m "Initial commit"
git remote add origin git@github.com:youruser/server-configs.git
git push -u origin main

# Automate (daily cron)
0 2 * * * cd /opt/docker-configs && git add -A && git commit -m "Auto backup $(date)" && git push

Pros:

✅ Full version history
✅ Easy to restore (just git clone)
✅ Can use private GitHub/Gitea/Forgejo
✅ Text files compress well

Cons:

⚠️ Don't commit secrets (use git-crypt or .env.example)

Method 2: Proxmox Backup Server (PBS)¶

If you have space for a VM:

# Install PBS in LXC container (lightweight)
pct create 100 /var/lib/vz/template/cache/debian-12-standard_12.0-1_amd64.tar.zst \
  --hostname pbs --memory 2048 --rootfs local:8

# Setup PBS, point backups to large drive
# Schedule automatic backups of VMs

Pros:

✅ Official Proxmox solution
✅ Deduplication, compression
✅ Incremental backups

Cons:

⚠️ Requires storage space (but can use external)
⚠️ More complex than simple scripts

Method 3: Simple Tar + Rsync (SIMPLEST)¶

#!/bin/bash
# /opt/backup/full-backup.sh
BACKUP_ROOT="/mnt/storage/server-backups"
DATE=$(date +%Y-%m-%d)

# Proxmox
tar czf $BACKUP_ROOT/proxmox-$DATE.tar.gz /etc/pve /etc/network

# Docker
tar czf $BACKUP_ROOT/docker-$DATE.tar.gz /opt/docker

# Rotate (keep 30 days)
find $BACKUP_ROOT -name "*.tar.gz" -mtime +30 -delete

# Sync to external
rsync -av $BACKUP_ROOT/ /mnt/offsite-backup/server-backups/

Recommendation: Use Git for configs + tar for VM disks

6. Future Expansion Strategies¶

Scenario A: Add One Big Drive (e.g., 8TB)¶

With mergerfs + SnapRAID:

# 1. Format new drive
sudo mkfs.ext4 -L data4 /dev/sdNEW

# 2. Add to mergerfs
mergerfs /mnt/disk1:/mnt/disk2:/mnt/disk3:/mnt/disk4 /mnt/storage

# 3. Update SnapRAID config
data d4 /mnt/disk4

# 4. Rebuild parity
snapraid sync

Effort: 5 minutes, zero downtime

Scenario B: Buy 3x Identical Drives (e.g., 3x 8TB)¶

Option 1: Add to mergerfs+SnapRAID

# Just add to existing pool, keep flexibility
mergerfs /mnt/disk1:/mnt/disk2:/mnt/disk3:/mnt/disk4:/mnt/disk5:/mnt/disk6 /mnt/storage

Option 2: Create ZFS RAIDZ1

# New pool for critical data
zpool create tank raidz /dev/sd{NEW1,NEW2,NEW3}
# Usable space: ~16TB (2 drives worth)
# Can survive 1 drive failure

Recommendation:

Keep mergerfs for bulk storage
Use ZFS pool for critical data (Proxmox VMs, databases)

Scenario C: Replace SnapRAID Parity Drive¶

When 4TB Maxtor external dies or you need more parity:

# Add second parity drive (6-drive protection)
# Edit /etc/snapraid.conf
parity /mnt/parity1/snapraid.parity
2-parity /mnt/parity2/snapraid.2-parity

# Rebuild
snapraid sync

Cost: ~€80 for 4TB external

7. Complete Setup Checklist¶

Phase 1: Initial Setup (Day 1-2)¶

Install mergerfs: sudo apt install mergerfs
Install SnapRAID: Download from snapraid.it
Format and mount data drives to /mnt/disk{1,2,3}
Configure mergerfs pool to /mnt/storage
Create SnapRAID config at /etc/snapraid.conf
Run initial snapraid sync (may take hours for 1TB)

Phase 2: Archive Consolidation (Day 3-5)¶

Mount all old drives
Install jdupes: sudo apt install jdupes
Run deduplication report: jdupes -r /mnt/disk1 > dupes.txt
Review and delete duplicates
Copy deduplicated archives to server
Copy to external HDD for offsite

Phase 3: Google Sync (Week 1)¶

Install rclone: curl https://rclone.org/install.sh | sudo bash
Configure Google Drive remote: rclone config
Configure Google Photos remote: rclone config
Test manual sync: rclone sync gdrive:/ /mnt/storage/gdrive-test --dry-run
Create backup scripts with --backup-dir for snapshots
Setup daily cron jobs

Phase 4: Critical Backup (Week 2)¶

Create Git repo for configs
Commit Proxmox configs: /etc/pve, /etc/network
Commit all docker-compose.yml files
Setup automated git push (daily cron)
Test restore: Clone repo on different machine
Create tar backup script for VM disks

Phase 5: Offsite Rotation (Week 3)¶

Buy second external HDD (2-4TB)
Create initial offsite sync: rsync -av /mnt/storage/ /mnt/external/
Label HDDs clearly: "HDD-1 Server Backup Week X"
Take HDD-1 to offsite location
Setup automated sync for HDD-2

Phase 6: Automation & Monitoring (Week 4)¶

Create SnapRAID runner script with email alerts
Setup daily SnapRAID diff/sync (2am cron)
Setup weekly SnapRAID scrub (Sunday 3am)
Create monitoring script for drive health: smartctl -a /dev/sdX
Setup email alerts for failures
Document restore procedures

8. Cost Breakdown¶

Item	Cost	Purpose
Already Own	€0	6x drives + Google One
External 4TB HDD #2	€70	Offsite rotation
Total Initial	€70

Future Costs
Additional data drives	€60-120/each	Expansion when full
Parity drive upgrade	€80	If parity disk fails
Google One (keep)	€100/year	Daily cloud access

Comparison if using cloud backup (NOT recommended):

Backblaze B2: 2TB = $10/month = $120/year
Total with B2: €220/year ongoing 😱

Your solution: €70 one-time + €100/year Google (already paying)

9. Maintenance Schedule¶

Daily (Automated)¶

✅ rclone sync Google Drive → server (2am)
✅ rclone sync Google Photos → server (3am)
✅ Git commit server configs (4am)
✅ SnapRAID diff check (5am)

Weekly (Automated)¶

✅ SnapRAID full sync (Sunday 2am)
✅ SnapRAID scrub 8% of data (Sunday 4am)
✅ Snapshot to offsite HDD (when connected)
✅ Email status report

Monthly (Manual - 15 min)¶

🔍 Review SnapRAID scrub reports
🔍 Check disk health: sudo smartctl -a /dev/sd*
🔍 Verify offsite HDD integrity
🔍 Review Google sync logs
🔍 Test restore one random file

Quarterly (Manual - 30 min)¶

🔧 Update SnapRAID, rclone, mergerfs
🔧 Review storage usage, plan expansion
🔧 Rotate offsite HDDs
🔧 Test full config restore from Git

Yearly (Manual - 2 hours)¶

🧹 Clean up old snapshots (keep 1/month after 1 year)
🧹 Review and delete unnecessary data
🧹 Full drive diagnostics
🧹 Document any infrastructure changes

10. Disaster Recovery Procedures¶

Scenario 1: Single Data Drive Fails¶

Remove failed drive
Mount replacement drive
Add to mergerfs pool: mergerfs /mnt/disk1:/mnt/disk2:/mnt/diskNEW
Restore from SnapRAID: snapraid fix -d dX
Rebuild parity: snapraid sync

Downtime: Minutes (mergerfs keeps running), rebuild overnight
Data loss: None (SnapRAID recovery)

Scenario 2: Parity Drive Fails¶

Replace parity drive
Update /etc/snapraid.conf
Full sync: snapraid sync (may take 6-12 hours)

Downtime: None (data still accessible)
Data loss: None (parity only)

Scenario 3: Multiple Drives Fail (>1)¶

If >1 drive fails, SnapRAID can't recover
Restore critical data from offsite HDD
Re-sync Google Drive/Photos from cloud

Downtime: Hours to days
Data loss: Only data on failed drives not on offsite backup

Scenario 4: Complete Server Failure¶

Install Proxmox on new hardware
Clone config Git repo
Restore docker-compose files
Attach old data drives (ext4 readable on any Linux)
Re-setup mergerfs pool

Downtime: 4-8 hours
Data loss: None (if drives intact)

Scenario 5: House Fire/Theft (Total Loss)¶

Retrieve offsite HDD from parent's house
Buy new hardware
Restore critical configs from offsite HDD
Re-sync Google Drive/Photos from cloud (still in Google)
Accept loss of: Jellyfin media (redownload), recent snapshots

Downtime: Days
Data loss:

❌ Media library (not critical)
❌ Last 1-2 weeks of changes (between offsite rotations)
✅ All critical configs (on offsite)
✅ Archives (on offsite)
✅ Google data (still in cloud)

11. Pros and Cons Summary¶

Recommended Setup (mergerfs + SnapRAID + rclone)¶

Pros:¶

✅ Use existing drives as-is - no reformatting
✅ Mixed sizes supported - 4TB + 1TB + 1TB + 250GB all usable
✅ Add drives anytime - no rebuild needed
✅ Individual access - if mergerfs fails, access drives directly
✅ Parity protection - survive 1 drive failure (or 2 with 2^nd parity)
✅ No cloud costs - one-time €70 for extra HDD
✅ Flexible - stop using anytime, no data lock-in
✅ Low power - only spin disks when accessed
✅ Simple restore - configs in Git, data on ext4 drives
✅ Future expansion - can migrate to ZFS later without breaking this

Cons:¶

⚠️ Not real-time parity - SnapRAID is snapshot-based (run daily)
⚠️ Manual offsite rotation - need to physically swap HDDs
⚠️ If >1 drive fails simultaneously - data loss (rare)
⚠️ Relies on Google - if Google account banned, need offsite HDD
⚠️ Command-line heavy - no fancy GUI (but stable once set up)

Alternative: ZFS RAIDZ¶

Pros:¶

✅ Real-time parity
✅ Snapshots, compression, dedup
✅ Self-healing on scrub

Cons:¶

❌ Can't use your mixed drives - need uniform sizes
❌ Expansion painful - must replace all disks in vdev
❌ RAM hungry - 1GB per TB recommended
❌ Complex - harder to recover if things break
❌ All or nothing - if pool breaks, harder to access data

When to reconsider: If you buy 3+ identical drives in future

12. Quick Reference Commands¶

Daily Operations¶

# Check SnapRAID status
snapraid status

# Check mergerfs mount
df -h /mnt/storage

# Manual Google Drive sync
rclone sync gdrive:/ /mnt/storage/google-drive-backup --progress

# Check disk health
sudo smartctl -H /dev/sda

Emergency¶

# Restore single file from SnapRAID
snapraid fix -f /mnt/disk2/path/to/file

# Check which drive has file
find /mnt/disk* -name "filename"

# Manual offsite sync
rsync -av --progress /mnt/storage/ /mnt/offsite-backup/

Expansion¶

# Add new drive to mergerfs (no downtime)
# 1. Mount new drive: /mnt/diskN
# 2. Update mergerfs mount in /etc/fstab
# 3. Remount: sudo mount -a
# 4. Update SnapRAID config: data dN /mnt/diskN
# 5. Rebuild parity: snapraid sync

13. Additional Resources¶

Official Documentation¶

rclone: https://rclone.org/docs/
mergerfs: https://trapexit.github.io/mergerfs/
SnapRAID: https://www.snapraid.it/manual
Proxmox Backup: https://pbs.proxmox.com/docs/

Community Resources¶

/r/DataHoarder: Best practices for home storage
/r/homelab: Server setup discussions
/r/selfhosted: Docker/service configs

Tools¶

jdupes: https://github.com/jbruchon/jdupes
smartmontools: Monitor drive health
ncdu: Disk usage analyzer (ncdu /mnt/storage)

Conclusion¶

Your setup is ideal for mergerfs + SnapRAID:

Mixed drive sizes ✅
Future expansion needs ✅
Budget-conscious ✅
No desire for more cloud services ✅

Start with:

mergerfs pool of your 4TB + 2x1TB drives
SnapRAID parity on 4TB external USB
rclone daily Google snapshots
Git repo for critical configs
Buy one more external HDD for offsite rotation

Total cost: €70 one-time

Time investment:

Setup: 1 weekend
Maintenance: 15 min/month
Offsite rotation: 10 min every 2 weeks

Peace of mind: Priceless 🎯

Research compiled January 23, 2026
Tools verified as actively maintained and production-ready