% zelta-policy(8) | System Manager's Manual
zelta policy - execute a list of zelta backup operations from a policy configuration
zelta policy [backup-override-options] [site|host|dataset] ...
zelta policy reads from a simple YAML-style configuration file containing parameters for zelta backup. Running zelta policy without parameters will iterate through the entire configuration file. Override options for either zelta policy or zelta backup can be provided on the command line, for example, adding --json will cause that parameter to be passed to all zelta backup calls. Subsequent undashed parameters will be matched against a user-defined site name, host name, or dataset, and the backup processes will be limited to that group or item.
In the zelta policy configuration file, you may override zelta backup's default parameters as defined in zelta-backup(8). For the complete list of Zelta configuration options, see zelta-options(7). The following parameters are specific zelta policy:
--retry
: Retry failed syncs the indicated number of times.
--jobs
: Run the indicated number of policy jobs concurrently, one for each Site in the configuration.
--backup-root
: The relative target path for the target job. For example 'bkhost:tank/Backups' would place backups below that dataset (if not overridden).
--host-prefix
: Include the source hostname as a parent of the synced target, for example, 'tank/Backups/source.host/backup-dataset'.
--ds-prefix
: Similar to 'zfs recv -d' and '-e', include the indicated number of parent labels for the target's synced name. See 'zelta help backup' for more detail.
Policy files may use import: to insert another local policy fragment before parsing. Import paths are resolved relative to the file that contains the import: line, which allows a policy directory to be moved as a unit.
SITE0:
host1.example:
options:
import: targets/vault1.yaml
import: rules/hostbackup.yaml
datasets:
import: sources/host1.example.yaml
Imported files are textual fragments, not independent policy files. The indentation of the import: line is prepended to each imported line, so fragments should usually contain only the lines needed inside the current context. For example, a dataset inventory fragment can contain only list items:
- tank/vm/app1
- tank/vm/app2
Imports are expanded recursively up to a fixed depth limit, and recursive import loops are rejected. Later options override earlier options, but unspecified options remain in effect within the current policy context.
Without additional parameters, zelta policy will run a zelta backup job for each dataset in the configuration file. Providing one of the following will limit the backup job.
site Run a backup job only for the site listed. A site is a user defined top-level parameter in the configuration file representing a list of one or more hosts.
host Run a backup job only for the host listed. Hosts must be accessible via SSH private-key authentication or localhost.
dataset Run a backup job only for the dataset listed. Note this parameter can match the source or target dataset, e.g., requesting zroot would run the replication for any matching dataset on any host.
host:dataset Specify a source or backup dataset endpoint name, equivalent to the parameters of zelta backup.
dataset_pattern Specify the final source or target dataset label. For example, vm would run all backup jobs with datasets ending in /vm.
For detailed documentation of the zelta policy configuration see zelta.conf.example.
/usr/local/etc/zelta/zelta.conf
: The default configuration file location.
For detailed documentation of the zelta environment variables see zelta help options.
Returns 0 on success, non-zero on error.
See zelta-options(7) for environment variables and zelta.env configuration.
zelta(8), zelta-clone(8), zelta-backup(8), zelta-options(7), zelta-match(8), zelta-revert(8), zelta-rotate(8), zelta-snapshot(8), ssh(1), zfs(8), zfs-list(8)
Daniel J. Bell <bellhyve@zelta.space>