Multi-Site Homelab

This is the last page in the guide, and fittingly the one where the gap between "what's technically possible" and "what's actually worth doing at home" is widest. Read it as a menu of how far you could take off-site redundancy, not a checklist you're behind on for not having already done.

The problem this actually solves

Disaster Recovery Planning assumed your off-site backup copy is genuinely off-site - a second location that a fire, flood, or theft at the primary site can't touch. For most homelabbers that's been "upload to Backblaze B2" since Backups 101, which is a completely valid off-site copy and, for most people, is where this should stay. A second physical site is for when you want that off-site copy to be infrastructure you control end to end, or when you want faster restore times than re-downloading everything from cloud storage.

The realistic version: a backup target, not a second cluster node

The practical, achievable version of multi-site is a second small machine at a location you trust (a relative's house, a friend's, a storage unit with power and internet - anything genuinely not the same building) whose only job is receiving replicated backups:

• Proxmox Backup Server, replicated from your primary PBS instance to the remote one on a schedule (see Proxmox Backups for the primary setup - PBS supports sync jobs between two PBS instances natively).
• ZFS send/receive over a WireGuard tunnel (see Remote Access) for replicating ZFS snapshots directly to a remote pool - efficient, since it only transfers the changed blocks since the last snapshot.
• restic to a remote target, same tool and pattern as Backups 101, just pointed at a machine you own instead of a cloud provider.

A Raspberry Pi or an old small-form-factor machine with a large enough drive is plenty of hardware for this - it's receiving and storing backups, not running services.

The aspirational version: real multi-site clustering

Extending an actual Proxmox cluster (see Proxmox Clustering and HA) across two physical sites, with quorum and live migration spanning both, is possible in principle - and a poor fit for almost every home internet connection in practice. Quorum and cluster networking assume low, consistent latency between nodes; a typical residential uplink's latency, jitter, and asymmetric (slow upload) bandwidth make a genuinely stretched cluster fragile in ways that undermine the reliability it's meant to provide. If this is specifically what you want to learn, treat it as a lab exercise you expect to fight with, not a resilience upgrade you can rely on.

Deciding if this is for you

Ask honestly: is the goal actually "protect my data from losing this building," or is it "I want to run more infrastructure"? The first is well solved by the backup-target pattern above, or by cloud storage alone - both are legitimate, low-maintenance answers. The second is a fine reason to build a second site, but it's worth naming as a learning project rather than a resilience requirement, the same honest framing this entire Advanced tier has tried to apply to clustering, orchestration, and everything else in it.

That's the guide

If you've worked through all three tiers, you've gone from one machine running Docker to a documented, backed-up, observable setup - virtualized, segmented, and as automated or as manual as you decided was actually worth it for your situation. That judgment call, repeated at every stage, is the real skill this guide was trying to build, more than any specific tool in it. Revisit the Glossary whenever a term resurfaces, or head back to the homepage to jump into a different tier.