It’s a common and costly mistake to treat RAID, ZFS snapshots, or a second NAS as “backup” when really they’re redundancy — protection against a single drive failing, not against accidental deletion, ransomware, fire, or a mistake that replicates itself instantly across every redundant copy. A proper backup strategy needs genuine independence between copies, which is what the classic 3-2-1 rule is designed to enforce.
The rule
3 copies of any important data. 2 different storage media types. 1 copy offsite.
Applied across my homelab, this looks like:
Copy 1 (primary): TrueNAS ZFS pool — where data actually lives day to day
Copy 2 (local backup): Synology NAS — separate physical device, separate pool
Copy 3 (offsite): SharePoint Online — Microsoft 365 tenant, different building entirely
Two different media types are satisfied by spinning HDDs in the Synology versus SSD/NVMe on the TrueNAS side. The offsite copy protects against the scenario that redundancy and local backups can’t — total site loss, whether that’s fire, flood, theft, or a ransomware attack that reaches every device on the network simultaneously.
Why SharePoint over a dedicated cloud backup provider
I already run a Microsoft 365 tenant day to day, so rather than paying for and managing a separate cloud storage provider purely for backups, SharePoint Online gives me an offsite copy that comes with a lot of enterprise-grade functionality already included in the subscription:
- Version history — every file change is retained automatically, so a ransomware event that encrypts files in place can be rolled back file-by-file to a known-good version, not just restored from a single backup snapshot
- Retention policies — configurable at the document library level, enforcing how long deleted or modified content is recoverable regardless of what happens to the source
- Recycle bin depth — a two-stage recycle bin (site collection + admin-level) giving up to 93 days of recovery for accidentally or maliciously deleted files
- Compliance and eDiscovery tooling — already available if it’s ever needed, without any extra configuration
- No additional storage cost — sitting within existing Microsoft 365 storage allowances rather than a new line-item bill
What actually gets backed up
Not everything needs this level of protection — the striped gaming pool covered in the high-performance storage writeup is deliberately excluded, since it’s disposable, replaceable data. What does get the full 3-2-1 treatment:
- Family photos and documents
- Layer 8 blog content and configuration
- Proxmox VM/LXC backups (config + critical data)
- Password manager vault export
- Any irreplaceable personal data
TrueNAS → Synology replication
The first hop from primary storage to local backup uses TrueNAS’s built-in ZFS replication, sending incremental snapshots to the Synology over the network on a schedule:
Task: Periodic Snapshot Task
Dataset: tank/important
Schedule: Every 4 hours
Retention: 7 days of hourly, 4 weeks of daily
Task: Replication Task
Source: tank/important
Destination: synology-nas:/volume1/backups/truenas
Schedule: Daily at 2am
Transport: SSH
Because this is snapshot-based replication rather than a simple file copy, only the changed blocks transfer each time — keeping the nightly replication window short even as the dataset grows.
Synology → SharePoint offsite sync
From the Synology, Cloud Sync (Synology’s built-in package) handles the offsite leg, syncing directly to a dedicated SharePoint document library using the Microsoft 365 connector:
Setup, via Package Center → Cloud Sync → Add a connection → SharePoint Online:
Tenant: yourtenant.sharepoint.com
Site: /sites/HomelabBackup
Document library: Backups
Authentication: OAuth via Entra ID app registration
Sync direction: Upload only (one-way, Synology → SharePoint)
Schedule: Daily at 3am, after TrueNAS replication completes
Setting an app registration in Entra ID specifically for this connection (rather than using a personal account’s credentials directly) keeps the permission scope tightly limited to just the one document library, and means the connection can be revoked centrally from the tenant admin side if the Synology is ever compromised, without touching any user account.
App registration permissions (Microsoft Graph):
Sites.Selected — scoped to the single Backups site only
Sites.Selected is the important piece here — rather than granting broad SharePoint access, it restricts the app registration to only the specific site it’s been explicitly granted access to via Add-PnPSiteCollectionAppCatalog or Graph API site permission assignment, following the principle of least privilege even for an automated backup connection.
Proxmox VM/LXC backups
Separately from file-level data, Proxmox’s own backup system handles full VM and LXC image backups, scheduled independently:
# Proxmox Backup Server job, configured via the web UI
Schedule: Daily at 1am
Target: Local PBS datastore, then synced to Synology
Retention: 7 daily, 4 weekly, 6 monthly
This means a full VM or container can be restored to a specific point in time, not just the data inside it — important for anything where the configuration and installed state matter as much as the data itself, like the Windows Server AD environment.
Testing restores
An untested backup isn’t a backup — it’s a hope. On a recurring basis (roughly quarterly), a genuine test restore gets performed: downloading a file or two directly from the SharePoint document library to confirm both the sync integrity and that version history is behaving as expected, and occasionally a full VM restore from a Proxmox Backup Server snapshot into an isolated test environment — confirming the whole chain actually works end to end rather than assuming it does because no errors showed up in a log somewhere.
Result
Any critical file or VM exists in three genuinely independent places — the primary pool, a separate local device, and an offsite copy in SharePoint Online — surviving anything short of a truly catastrophic, simultaneous, multi-location failure. Using SharePoint for the offsite leg means the backup strategy also inherits enterprise version history, retention policies, and recovery tooling that would otherwise need building or paying for separately. RAID and snapshots still matter for uptime and quick recovery from a single drive failure, but they were never the backup — this is.