This page clarifies common terms and explains how Zelta works. If you're new to ZFS replication or backup strategies, this is a great place to start.
The simplest Zelta commands look like this:
Compare two dataset trees:
zelta match source/endpoint target/endpoint
Create or update a backup:
zelta backup source/endpoint target/endpoint
Run multiple backup jobs automatically:
zelta policy
For quick help, use zelta usage to see available commands and options, or zelta help to view the full manual.
Zelta uses an SCP-like syntax to specify datasets and snapshots:
Format: [username@][hostname:]pool[/dataset][@snapshot]
Examples:
tank/dataserver10.biz:tank/filesbackup@server11.biz:pool/stufftwin@server12.biz:sink/log@todayUnderstanding these terms will help you get the most out of Zelta. For foundational ZFS concepts, see zfsconcepts(7) by running zfs help concepts to learn about snapshots, bookmarks, and the ZFS filesystem hierarchy.
/. For example, if replicating zroot/usr to backup/usr, a child at zroot/usr/local has a ds_suffix of /local. In scripting mode (-H), the top-level dataset has a ds_suffix of an empty string.zelta-clone(8).zfs help concepts) to import the user's modifications. This provides a facility for patching and feature updates using ZFS backup streams. (Coming soon)zfs rollback, this preserves your current state. See zelta-revert(8).zelta-rotate(8).To get the most out of Zelta, you should be familiar with:
ZFS Fundamentals:
Disaster Recovery Concepts:
Don't worry if you're new to these topics—Zelta's design makes many complex operations simple, and you'll learn as you go.
Zelta is designed around three core principles: safety, recursion, and remote operation.
zfs receive -F or forced rollbacks. Operations like zelta rotate preserve divergent versions rather than destroying them.readonly=on by default.inherit to prevent dangerous overlapping mounts.All Zelta commands work on entire dataset trees, not just individual datasets. When you replicate tank/data, you automatically get tank/data/logs, tank/data/cache, and everything underneath.
Every Zelta command works the same way whether datasets are local or remote:
# Local to local
zelta backup tank/source tank/backup
# Local to remote
zelta backup tank/source backup@storage.example.com:pool/backup
# Remote to remote (orchestrated from your workstation)
zelta backup user@server1:tank/data user@server2:pool/backup
You don't need to install Zelta on backup sources or targets. Using SSH keys and agent forwarding, you can manage all replication from a secure bastion host.
You never need to run Zelta as root. Using ZFS delegation (zfs allow) and SSH keys, you can safely replicate datasets without privileged access. This dramatically reduces your attack surface and makes Zelta ideal for regulated environments.
See ZFS Allow Delegation for setup instructions.
Zelta runs on any system with Bourne shell and AWK—no packages, no daemons, no additional configuration required. Zelta can remotely manage backups between hosts that do not have Zelta installed.
Replication decisions are based on ZFS metadata and available features, not naming conventions or assumptions about your infrastructure. This makes Zelta an outstanding recovery tool for complex, mixed environments.
Ready to try Zelta? Head over to Quick Start for practical examples.
For detailed command usage, run zelta help or explore the Zelta Wiki.