Welcome to Zelta! This guide will help you quickly get started with Zelta for ZFS replication, offering step-by-step instructions for installation, basic usage, and initial replication tasks. Whether you're managing local backups or overseeing extensive replication jobs across multiple systems, Zelta streamlines the process with an emphasis on safety and efficiency.
Zelta is quickly approaching it's 1.0 release version but has not yet landed or is out of date in OS package repositories. Until Q3 of 2024, we recommend installing directly from Zelta's GitHub repository:
git clone https://github.com/bellhyve/zelta.git
cd zelta
./install.sh
For a user-only installation, run as a non-root user and follow the instructions to set up Zelta's environment for your shell's run control script. For a system-wide installation, run the installer as root, e.g., sudo ./install.sh.
Zelta shell wrapper (/usr/local/bin/ or ~/bin) must be in your shell's PATH.
Before you run your first Zelta command, keep its defaults in mind:
[username@][hostname:]pool[/dataset][@snapshot]zelta backup detects unwritten data, it will take a snapshot.To perform a basic replication between two pools on your system:
zelta backup pool1 pool2/pool1-backup
This command backs up pool1 in pool2, in a new dataset called pool1-backup. When creating a new replica, the target (pool2/pool1-backup) must not already exist. The target will be set as read-only, mountpoints will be reset to avoid conflicts.
Subsequent backups can be performed with exactly the same command, updating the target.
To compare two datasets, use:
zelta match pool1 pool2/pool1-backup
This command describes the relationship between a dataset tree and its replica.
Although many users will find that scheduling zelta backup is sufficient for their backup needs, managing numerous replication tasks with zelta policy greatly simplifies the process. To set it up view the default policy configuration, usually in /usr/local/etc/zelta/zelta.conf. A simple configuration might look like this, with a backup job named "LetsGo."
LetsGo:
zelta-test-1:
ztank1: backuptank/ztank1
zelta-test-2:
ztank2/vm: backuptank/ztank2-vm
LetsGo is the name of the backup job, or "Site."
zelta-test-1 and zelta-test-2 are source hostnames.
ztank1 and ztank2/vm are source dataset names.
backuptank/ztank1 and backuptank/ztank2-vm will become their local target replicas.
To run the backup job, run (or schedule):
zelta policy
This method is ideal for automating backups across multiple datasets and systems, providing clarity and control over replication jobs.
You can run zelta usage with no arguments for point-of-use documentaiton.
Zelta uses ssh to run commands and stream backups. We recommend creating a backup operator user on all systems. On the target system, create an ssh key for the backup user (ssh-keygen), and install it on each source system ssh-copy-id sourcehost.
Performing ZFS replication with Zelta does not require root privileges if zfs allow permissions are set. The minimal required permissions are:
Source Systems:
zfs allow -u backupuser send,snapshot,hold dataset/name
Target Systems:
zfs allow -u backupuser receive,mount,create,readonly backuppool
You will likely want more permissions on the target system. For more details see the wiki section on ZFS Allow.
For more in-depth information, advanced usage, and troubleshooting tips, explore the following resources:
Community and Support:
Installation & Configuration: Detailed setup instructions.
Advanced Usage and Case Studies: Guides for more advanced techniques and real-world applications of Zelta.
Troubleshooting: Our FAQ, which includes troubleshooting tips to help resolve common issues.
For professional collaboration or to engage with Zelta designers and integrators, visit Bell Tower.