Short answers to common operator questions. How-to workflows live under Guides; flags live in the manual pages.
: in its name, how can I replicate it with Zelta?The first colon (before a / or space) is treated as the host separator. Prefix with localhost:, for example localhost:my:pool:name, and Zelta will do the right thing.
Yes. For most user-local installs, use the web installer as the target user:
curl -fsSL https://zelta.space/web-install.sh | sh
You can also run the source installer from a checkout:
./install.sh
The installer shows proposed directories before installing. Override locations with environment variables and rerun ./install.sh. For development from a checkout:
export PATH="$(pwd)/bin:$PATH"
export ZELTA_SHARE="$(pwd)/share/zelta"
No. Zelta only needs standard ZFS tools and SSH on the endpoints. You can orchestrate from a bastion that has no ZFS at all. See SSH Configuration.
No. Use zfs allow and SSH keys so backup and twin users run with least privilege. Recipes: ZFS Allow Delegation.
Yes. Zelta does not require a naming convention. Match and backup use ZFS metadata (GUIDs), not name patterns. You can still filter with --include / --exclude if you only want certain names on a given job.
By default, zelta backup preserves intermediate snapshots so the target keeps a usable history. That is safer for recovery and costs more transfer and space. To limit what is sent, use snapshot filters (for example --include='@daily*') or intermediate-skip options documented in zelta-options(7). See also Simple Backups.
Zelta prefers raw send when appropriate so encrypted datasets stay encrypted in transit and on the backup. Grant send:raw (not only plain send) for backup users on encrypted trees. Details: ZFS Allow Delegation and zelta-backup(8).
zelta and zprune?Commands that start with zelta are nondestructive. zprune is deliberately separate because it destroys snapshots after zelta prune plans them. If something goes wrong, you should never have to say “Zelta deleted my data.” See Rollback & Recovery.
| Goal | Command | Guide |
|---|---|---|
| Writable inspection copy | zelta clone |
Recovery |
| Rewind live dataset, keep broken state | zelta revert |
Recovery |
| Diverged source/target, keep both histories | zelta rotate |
Recovery |
| Promote a read-only twin | zelta failover |
Failover, Twin |
Two dataset trees that back each other up so either side can become active. It is an asynchronous cluster pattern built from ordinary backup and failover commands, not a separate product. See Zelta Twin.
Safe defaults: replicas are readonly=on, new filesystems get canmount=noauto, and child mountpoints inherit so backups do not overlay production paths. That is intentional. Promote or clone when you need a writable tree.
zelta.env — defaults for all commands (shell KEY=value)zelta.conf — policy jobs for zelta policy (YAML-like, import: fragments)