Automating ZFS Replication Between Proxmox Servers Using Syncoid

⏱ 4 min read

In Part 2, we built a professional homelab storage layout:

  • Proxmox OS + VMs on a fast SSD
  • Large ZFS mirror (2× 8TB HDD) for data & backup
  • Optimized for performance, reliability, and future automation

Today, we take the next step:

Replicating ZFS datasets from your HDD mirror to Proxmox Backup Server (PBS) using Syncoid, ensuring off-host redundancy and automated backup workflows.

Replication is critical: it protects against disk failure, accidental deletion, and data corruption — all without touching your live VMs on the SSD.

Why ZFS Replication Matters

Snapshots protect your local data, but they only live on the same pool. If the pool dies, the snapshots are gone. Replication solves this:

Benefits of replication to PBS:

  • Off-host redundancy
  • Incremental transfers (saves bandwidth)
  • Easy disaster recovery
  • Integration with your automated snapshot policies

With Syncoid, replication is reliable, efficient, and easy to automate.

Key Takeaways

By the end of this guide, you’ll know:

  • How to prepare your ZFS HDD mirror for replication
  • How to install and configure Syncoid on your Proxmox host
  • How to automate replication to PBS with SSH keys
  • How to schedule and monitor replication jobs
  • Real-world pitfalls and best practices

Step 1 — Prepare the ZFS Mirror for Replication

Before replication:

  1. Ensure your ZFS mirror is healthy:
zpool status tank
zfs list
  1. Organize datasets for replication. Example structure:
tank/vms
tank/media
tank/backups

Each dataset can be replicated independently, allowing flexible retention policies.

  1. Confirm snapshots exist. Syncoid replicates snapshots incrementally:
zfs snapshot -r tank@initial

Step 2 — Install Syncoid

Syncoid is part of Sanoid, which handles snapshots + replication efficiently.

In the Smart ZFS Snapshot Automation on Proxmox Using Sanoid, we talked about how to install it, take a look.

Step 3 — Configure SSH Access to PBS

Replication requires passwordless SSH access.

  1. Generate an SSH key on the Proxmox host:
ssh-keygen -t ed25519 -C "replication_key"
  1. Copy the key to PBS server:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@PBS_SERVER_IP
  1. Test access:
ssh root@PBS_SERVER_IP

You should log in without a password. Syncoid depends on this for automated replication.

Step 4 — Replicate Datasets with Syncoid

Basic command structure:

syncoid tank/vms root@PBS_SERVER_IP:tank/vms

How It Works:

  • First run: full replication of all snapshots
  • Subsequent runs: incremental replication (only changes)
  • Syncoid preserves snapshot history, retention, and dataset structure

Example for multiple datasets:

syncoid tank/media root@PBS_SERVER_IP:tank/media
syncoid tank/backups root@PBS_SERVER_IP:tank/backups

Your PBS server now stores exact copies of the ZFS datasets, ready for disaster recovery.

Step 5 — Automate Replication with Cron

Create a script /root/replicate_to_pbs.sh:

#!/bin/bash
# Replicate datasets to PBS
syncoid tank/vms root@PBS_SERVER_IP:tank/vms
syncoid tank/media root@PBS_SERVER_IP:tank/media
syncoid tank/backups root@PBS_SERVER_IP:tank/backups

Make it executable:

chmod +x /root/replicate_to_pbs.sh

Add a cron job for daily replication at 2 AM:

crontab -e
0 2 * * * /root/replicate_to_pbs.sh >> /var/log/zfs_replication.log 2>&1

Step 6 — Monitoring and Alerts

Monitor replication logs:

tail -f /var/log/zfs_replication.log

Optional: integrate Telegram notifications (covered in Part 7) for:

  • Failures
  • Successful replication
  • Snapshot retention alerts

This ensures you never miss a backup issue.

Step 7 — Best Practices & Pitfalls

MistakeWhy It FailsCorrect Approach
Replicating without snapshotsSyncoid cannot do incremental replicationAlways create snapshots before replication
Using same pool for production and backupDisk failure destroys bothSeparate SSD (VMs) and ZFS HDD mirror
Overwriting datasets accidentallyData lossTest Syncoid commands with --no-sync dry run
Ignoring retentionPBS fills up fastUse consistent snapshot & replication retention policies

Step 8 — How This Fits Into Our Backup Architecture

Layered backup workflow:

  1. Layer 1 — ZFS Snapshots on HDD Mirror
    Fast local rollback for files & datasets
  2. Layer 2 — Syncoid Replication to PBS
    Off-host redundancy, incremental, bandwidth-efficient
  3. Layer 3 — PBS VM Backups
    Deduplicated VM images, disaster recovery-ready

This ensures triple protection: snapshots, replication, and PBS archives.

Summary

With Syncoid replication to PBS:

  • Your ZFS datasets are safe off-host
  • Incremental replication saves bandwidth
  • Snapshots + replication give a robust, automated backup system
  • Integrated with PBS, your VMs and data are disaster-recovery ready

Next Step

In Part 6, we’ll dive into backing up Proxmox VMs to PBS, combining deduplicated archives with our replication setup for a full enterprise-style homelab backup workflow.

Oh hi there 👋 It’s nice to meet you.

Sign up to receive awesome content in your inbox, every month.

We don’t spam! Read our privacy policy for more info.

Oh hi there 👋
It’s nice to meet you.

Sign up to receive awesome content in your inbox, every month.

We don’t spam! Read our privacy policy for more info.

Spread the love
0 0 votes
Article Rating
Subscribe
Notify of
guest
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback
19 hours ago

[…] Automating ZFS Replication Between Servers […]

1
0
Would love your thoughts, please comment.x
()
x