ZFS autobackup is used to periodicly backup ZFS filesystems to other locations. No additional tools of libraries or config files needed.
This is a tool I wrote to make replicating ZFS datasets easy and reliable.
You can either use it as a backup tool, replication tool or snapshot tool.
You can select what to backup by setting a custom
ZFS property. This makes it easy to add/remove specific datasets, or just backup your whole pool.
Other settings are just specified on the commandline: Simply setup and test your zfs-autobackup command and fix all the issues you might encounter. When you're done you can just copy/paste your command to a cron or script.
Since its using ZFS commands, you can see what its actually doing by specifying
--debug. This also helps a lot if you run into some strange problem or error. You can just copy-paste the command that fails and play around with it on the commandline. (something I missed in other tools)
An important feature thats missing from other tools is a reliable
--testoption: This allows you to see what zfs-autobackup will do and tune your parameters. It will do everything, except make changes to your system.
zfs-autobackup tries to be the easiest to use backup tool for zfs.
The recommended way on most servers is to use pip:
[[email protected] ~]# pip install --upgrade zfs-autobackup
This can also be used to upgrade zfs-autobackup to the newest stable version.
On older servers you might have to use easy_install
[[email protected] ~]# easy_install zfs-autobackup
In this example we're going to backup a machine called
server1to a machine called
zfs-autobackup needs passwordless login via ssh. This means generating an ssh key and copying it to the remote server.
On the backup-server that runs zfs-autobackup you need to create an SSH key. You only need to do this once.
ssh-keygencommand and leave the passphrase empty:
[email protected]:~# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:McJhCxvaxvFhO/3e8Lf5gzSrlTWew7/bwrd2U2EHymE [email protected] The key's randomart image is: +---[RSA 2048]----+ | + = | | + X * E . | | . = B + o o . | | . o + o o.| | S o .oo| | . + o= +| | . ++==.| | .+o**| | .. [email protected]| +----[SHA256]-----+ [email protected]:~#
Now you need to copy the public part of the key to
ssh-copy-idcommand is a handy tool to automate this. It will just ask for your password.
[email protected]:~# ssh-copy-id [email protected] /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'" and check to make sure that only the key(s) you wanted were added.
This allows the backup-server to login to
server1as root without password.
Its important to choose a unique and consistent backup name. In this case we name our backup:
On the source zfs system set the
autobackup:offsite1zfs property to true:
[[email protected] ~]# zfs set autobackup:offsite1=true rpool [[email protected] ~]# zfs get -t filesystem,volume autobackup:offsite1 NAME PROPERTY VALUE SOURCE rpool autobackup:offsite1 true local rpool/ROOT autobackup:offsite1 true inherited from rpool rpool/ROOT/server1-1 autobackup:offsite1 true inherited from rpool rpool/data autobackup:offsite1 true inherited from rpool rpool/data/vm-100-disk-0 autobackup:offsite1 true inherited from rpool rpool/swap autobackup:offsite1 true inherited from rpool ...
ZFS properties are
inheritedby child datasets. Since we've set the property on the highest dataset, we're essentially backupping the whole pool.
Because we don't want to backup everything, we can exclude certain filesystem by setting the property to false:
[[email protected] ~]# zfs set autobackup:offsite1=false rpool/swap [[email protected] ~]# zfs get -t filesystem,volume autobackup:offsite1 NAME PROPERTY VALUE SOURCE rpool autobackup:offsite1 true local rpool/ROOT autobackup:offsite1 true inherited from rpool rpool/ROOT/server1-1 autobackup:offsite1 true inherited from rpool rpool/data autobackup:offsite1 true inherited from rpool rpool/data/vm-100-disk-0 autobackup:offsite1 true inherited from rpool rpool/swap autobackup:offsite1 false local ...
The autobackup-property can have 3 values: *
true: Backup the dataset and all its children *
false: Dont backup the dataset and all its children. (used to exclude certain datasets) *
child: Only backup the children off the dataset, not the dataset itself.
Only use the zfs-command to set these properties, not the zpool command.
Run the script on the backup server and pull the data from the server specified by --ssh-source.
[[email protected] ~]# zfs-autobackup --ssh-source server1.server.com offsite1 backup/server1 --progress --verbose
[Source] Datasets on: server1.server.com [Source] Keep the last 10 snapshots. [Source] Keep every 1 day, delete after 1 week. [Source] Keep every 1 week, delete after 1 month. [Source] Keep every 1 month, delete after 1 year. [Source] Send all datasets that have 'autobackup:offsite1=true' or 'autobackup:offsite1=child'
[Target] Datasets are local [Target] Keep the last 10 snapshots. [Target] Keep every 1 day, delete after 1 week. [Target] Keep every 1 week, delete after 1 month. [Target] Keep every 1 month, delete after 1 year. [Target] Receive datasets under: backup/server1
[Source] rpool: Selected (direct selection) [Source] rpool/ROOT: Selected (inherited selection) [Source] rpool/ROOT/server1-1: Selected (inherited selection) [Source] rpool/data: Selected (inherited selection) [Source] rpool/data/vm-100-disk-0: Selected (inherited selection) [Source] rpool/swap: Ignored (disabled)
[Source] rpool: No changes since offsite1-20200218175435 [Source] rpool/ROOT: No changes since offsite1-20200218175435 [Source] rpool/data: No changes since offsite1-20200218175435 [Source] Creating snapshot offsite1-20200218180123
Sending and thinning
[Target] backup/server1/rpool/ROOT/[email protected]: receiving full [Target] backup/server1/rpool/ROOT/[email protected]: receiving incremental [Target] backup/server1/rpool/ROOT/[email protected]: receiving incremental [Target] backup/server1/rpool/ROOT/[email protected]: receiving incremental [Target] backup/server1/rpool/ROOT/[email protected]: receiving incremental [Target] backup/server1/rpool/[email protected]: receiving full [Target] backup/server1/rpool/data/[email protected]: receiving full ...
Note that this is called a "pull" backup: The backup server pulls the backup from the server. This is usually the preferred way.
Its also possible to let a server push its backup to the backup-server. However this has security implications. In that case you would setup the SSH keys the other way around and use the --ssh-target parameter on the server.
Now every time you run the command, zfs-autobackup will create a new snapshot and replicate your data.
Older snapshots will eventually be deleted, depending on the
--keep-targetsettings. (The defaults are shown above under the 'Settings summary')
Once you've got the correct settings for your situation, you can just store the command in a cronjob.
Or just create a script and run it manually when you need it.
You can use zfs-autobackup to only make snapshots.
#### Source settings [Source] Datasets are local [Source] Keep the last 10 snapshots. [Source] Keep every 1 day, delete after 1 week. [Source] Keep every 1 week, delete after 1 month. [Source] Keep every 1 month, delete after 1 year. [Source] Selects all datasets that have property 'autobackup:test=true' (or childs of datasets that have 'autobackup:test=child')
#### Selecting [Source] testsource1/fs1: Selected (direct selection) [Source] testsource1/fs1/sub: Selected (inherited selection) [Source] testsource2/fs2: Ignored (only childs) [Source] testsource2/fs2/sub: Selected (inherited selection)
#### Snapshotting [Source] Creating snapshots test-20200710125958 in pool testsource1 [Source] Creating snapshots test-20200710125958 in pool testsource2
#### All operations completed successfully (No target_path specified, only operated as snapshot tool.) ```
This also allows you to make several snapshots during the day, but only backup the data at night when the server is not busy.
The thinner is the thing that destroys old snapshots on the source and target.
The thinner operates "stateless": There is nothing in the name or properties of a snapshot that indicates how long it will be kept. Everytime zfs-autobackup runs, it will look at the timestamp of all the existing snapshots. From there it will determine which snapshots are obsolete according to your schedule. The advantage of this stateless system is that you can always change the schedule.
Note that the thinner will ONLY destroy snapshots that are matching the naming pattern of zfs-autobackup. If you use
--other-snapshots, it wont destroy those snapshots after replicating them to the target.
When a dataset has been destroyed or deselected on the source, but still exists on the target we call it a missing dataset. Missing datasets will be still thinned out according to the schedule.
The final snapshot will never be destroyed, unless you specify a deadline with the
In that case it will look at the last snapshot we took and determine if is older than the deadline you specified. e.g:
--destroy-missing 30dwill start destroying things 30 days after the last snapshot.
When the deadline is passed, all our snapshots, except the last one will be destroyed. Irregardless of the normal thinning schedule.
The dataset has to have the following properties to be finally really destroyed:
The default thinning schedule is:
The schedule consists of multiple rules separated by a
A plain number specifies how many snapshots you want to always keep, regardless of time or interval.
The format of the other rules is:.
Since this might sound very complicated, the
--verboseoption will show you what it all means:
[Source] Keep the last 10 snapshots. [Source] Keep every 1 day, delete after 1 week. [Source] Keep every 1 week, delete after 1 month. [Source] Keep every 1 month, delete after 1 year.
A snapshot will only be destroyed if it not needed anymore by ANY of the rules.
You can specify as many rules as you need. The order of the rules doesn't matter.
Keep in mind its up to you to actually run zfs-autobackup often enough: If you want to keep hourly snapshots, you have to make sure you at least run it every hour.
However, its no problem if you run it more or less often than that: The thinner will still keep an optimal set of snapshots to match your schedule as good as possible.
If you want to keep as few snapshots as possible, just specify 0. (
If you want to keep ALL the snapshots, just specify a very high number.
We will give a practical example of how the thinner operates.
Say we want have 3 thinner rules:
So far we have taken 4 snapshots at random moments:
For every rule, the thinner will divide the timeline in blocks and assign each snapshot to a block.
A block can only be assigned one snapshot: If multiple snapshots fall into the same block, it only assigns it to the oldest that we want to keep.
The colors show to which block a snapshot belongs:
zfs-autobackup will re-evaluate this on every run: As soon as a snapshot doesn't belong to any block anymore it will be destroyed.
Snapshots on the source that still have to be send to the target wont be destroyed off course. (If the target still wants them, according to the target schedule)
--debugif something goes wrong and you want to see the commands that are executed. This will also stop at the first error.
readonlyproperty of the target filesystem to
on. This prevents changes on the target side. (Normally, if there are changes the next backup will fail and will require a zfs rollback.) Note that readonly means you cant change the CONTENTS of the dataset directly. Its still possible to receive new datasets and manipulate properties etc.
--clear-refreservationto save space on your backup server.
--clear-mountpointto prevent the target server from mounting the backupped filesystem in the wrong place during a reboot.
If you have a large number of datasets its important to keep the following tips in mind.
To get some idea of how fast zfs-autobackup is, I did some test on my laptop, with a SKHynix_HFS512GD9TNI-L2B0B disk. I'm using zfs 2.0.2.
I created 100 empty datasets and measured the total runtime of zfs-autobackup. I used all the performance tips below. (--no-holds, --allow-empty, ssh ControlMaster)
To be bold I created 2500 datasets, but that also was no problem. So it seems it should be possible to use zfs-autobackup with thousands of datasets.
If you need more performance let me know.
NOTE: There is actually a performance regression in ZFS version 2: https://github.com/openzfs/zfs/issues/11560 Use --no-progress as workaround.
You can make zfs-autobackup generate less work by using --no-holds and --allow-empty.
This saves a lot of extra zfs-commands per dataset.
You can make your ssh connections persistent and greatly speed up zfs-autobackup:
On the backup-server add this to your ~/.ssh/config:
Host * ControlPath ~/.ssh/control-master-%[email protected]%h:%p ControlMaster auto ControlPersist 3600
Thanks @mariusvw :)
The correct way to do this is by creating ~/.ssh/config:
Host smartos04 Hostname 184.108.40.206 Port 1234 user root Compression yes
This way you can just specify "smartos04" as host.
Also uses compression on slow links.
Look in man ssh_config for many more options.
Here you find all the options:
[[email protected] ~]# zfs-autobackup --help usage: zfs-autobackup [-h] [--ssh-config SSH_CONFIG] [--ssh-source SSH_SOURCE] [--ssh-target SSH_TARGET] [--keep-source KEEP_SOURCE] [--keep-target KEEP_TARGET] [--other-snapshots] [--no-snapshot] [--no-send] [--min-change MIN_CHANGE] [--allow-empty] [--ignore-replicated] [--no-holds] [--strip-path STRIP_PATH] [--clear-refreservation] [--clear-mountpoint] [--filter-properties FILTER_PROPERTIES] [--set-properties SET_PROPERTIES] [--rollback] [--destroy-incompatible] [--ignore-transfer-errors] [--raw] [--test] [--verbose] [--debug] [--debug-output] [--progress] backup-name [target-path]
zfs-autobackup v3.0-rc12 - Copyright 2020 E.H.Eefting ([email protected])
positional arguments: backup-name Name of the backup (you should set the zfs property "autobackup:backup-name" to true on filesystems you want to backup target-path Target ZFS filesystem (optional: if not specified, zfs-autobackup will only operate as snapshot-tool on source)
optional arguments: -h, --help show this help message and exit --ssh-config SSH_CONFIG Custom ssh client config --ssh-source SSH_SOURCE Source host to get backup from. ([email protected]) Default None. --ssh-target SSH_TARGET Target host to push backup to. ([email protected]) Default None. --keep-source KEEP_SOURCE Thinning schedule for old source snapshots. Default: 10,1d1w,1w1m,1m1y --keep-target KEEP_TARGET Thinning schedule for old target snapshots. Default: 10,1d1w,1w1m,1m1y --other-snapshots Send over other snapshots as well, not just the ones created by this tool. --no-snapshot Don't create new snapshots (useful for finishing uncompleted backups, or cleanups) --no-send Don't send snapshots (useful for cleanups, or if you want a serperate send-cronjob) --min-change MIN_CHANGE Number of bytes written after which we consider a dataset changed (default 1) --allow-empty If nothing has changed, still create empty snapshots. (same as --min-change=0) --ignore-replicated Ignore datasets that seem to be replicated some other way. (No changes since lastest snapshot. Useful for proxmox HA replication) --no-holds Don't lock snapshots on the source. (Useful to allow proxmox HA replication to switches nodes) --strip-path STRIP_PATH Number of directories to strip from target path (use 1 when cloning zones between 2 SmartOS machines) --clear-refreservation Filter "refreservation" property. (recommended, safes space. same as --filter-properties refreservation) --clear-mountpoint Set property canmount=noauto for new datasets. (recommended, prevents mount conflicts. same as --set- properties canmount=noauto) --filter-properties FILTER_PROPERTIES List of properties to "filter" when receiving filesystems. (you can still restore them with zfs inherit -S) --set-properties SET_PROPERTIES List of propererties to override when receiving filesystems. (you can still restore them with zfs inherit -S) --rollback Rollback changes to the latest target snapshot before starting. (normally you can prevent changes by setting the readonly property on the target_path to on) --destroy-incompatible Destroy incompatible snapshots on target. Use with care! (implies --rollback) --ignore-transfer-errors Ignore transfer errors (still checks if received filesystem exists. useful for acltype errors) --raw For encrypted datasets, send data exactly as it exists on disk. --test dont change anything, just show what would be done (still does all read-only operations) --verbose verbose output --debug Show zfs commands that are executed, stops after an exception. --debug-output Show zfs commands and their output/exit codes. (noisy) --progress show zfs progress output (to stderr). Enabled by default on ttys.
When a filesystem fails, zfs_backup will continue and report the number of failures at that end. Also the exit code will indicate the number of failures.
You forgot to setup automatic login via SSH keys, look in the example how to do this.
This usually means you've created a new snapshot on the target side during a backup. If you restart zfs-autobackup, it will automaticly abort the invalid partially received snapshot and start over.
This means files have been modified on the target side somehow.
You can use --rollback to automaticly rollback such changes.
Note: This usually happens if the source-side has a non-standard mountpoint for a dataset, and you're using --clear-mountpoint. In this case the target side creates a mountpoint in the parent dataset, causing the change.
In some cases (Linux -> FreeBSD) this means certain properties are not fully supported on the target system.
Try using something like: --filter-properties xattr
Restoring can be done with simple zfs commands. For example, use this to restore a specific SmartOS disk image to a temporary restore location:
[email protected]:/home/psy# zfs send fs1/zones/backup/zfsbackups/smartos01.server.com/zones/[email protected]_fs1-20160110000003 | ssh [email protected] "zfs recv zones/restore"
After that you can rename the disk image from the temporary location to the location of a new SmartOS machine you've created.
You can monitor backups by using my zabbix-jobs script. (https://github.com/psy0rz/stuff/tree/master/zabbix-jobs)
Put this command directly after the zfs_backup command in your cronjob:
zabbix-job-status backup_smartos01_fs1 daily $?
This will update the zabbix server with the exit code and will also alert you if the job didn't run for more than 2 days.
Due to the nature of proxmox we had to make a few enhancements to zfs-autobackup. This will probably also benefit other systems that use their own replication in combination with zfs-autobackup.
All data under rpool/data can be on multiple nodes of the cluster. The naming of those filesystem is unique over the whole cluster. Because of this we should backup rpool/data of all nodes to the same destination. This way we wont have duplicate backups of the filesystems that are replicated. Because of various options, you can even migrate hosts and zfs-autobackup will be fine. (and it will get the next backup from the new node automatically)
In the example below we have 3 nodes, named pve1, pve2 and pve3.
No preparation is needed, the script will take care of everything. You only need to setup the ssh keys, so that the backup server can access the proxmox server.
TIP: make sure your backup server is firewalled and cannot be reached from any production machine.
I use ~/.ssh/config to specify how to reach the various hosts.
In this example we are making an offsite copy and use portforwarding to reach the proxmox machines: ``` Host * ControlPath ~/.ssh/control-master-%[email protected]%h:%p ControlMaster auto ControlPersist 3600 Compression yes
Host pve1 Hostname some.host.com Port 10001
Host pve2 Hostname some.host.com Port 10002
Host pve3 Hostname some.host.com Port 10003 ```
I use the following backup script on the backup server.
Adjust the variables HOSTS TARGET and NAME to your needs.
HOSTS="pve1 pve2 pve3" TARGET=rpool/pvebackups NAME=prox
zfs create -p $TARGET/data &>/dev/null for HOST in $HOSTS; do
echo "################################### RPOOL $HOST"
ssh $HOST "zfs set autobackup:rpool_$NAME=child rpool/ROOT"
#backup rpool to specific directory per host zfs create -p $TARGET/rpools/$HOST &>/dev/null zfs-autobackup --keep-source=1d1w,1w1m --ssh-source $HOST rpool_$NAME $TARGET/rpools/$HOST --clear-mountpoint --clear-refreservation --ignore-transfer-errors --strip-path 2 --verbose --no-holds [email protected]
zabbix-job-status backup_$HOST""rpool$NAME daily $? >/dev/null 2>/dev/null
echo "################################### DATA $HOST"
ssh $HOST "zfs set autobackup:data_$NAME=child rpool/data"
#backup data filesystems to a common directory zfs-autobackup --keep-source=1d1w,1w1m --ssh-source $HOST data_$NAME $TARGET/data --clear-mountpoint --clear-refreservation --ignore-transfer-errors --strip-path 2 --verbose --ignore-replicated --min-change 200000 --no-holds [email protected]
zabbix-job-status backup_$HOST""data$NAME daily $? >/dev/null 2>/dev/null
This script will also send the backup status to Zabbix. (if you've installed my zabbix-job-status script https://github.com/psy0rz/stuff/tree/master/zabbix-jobs)
This project was sponsorred by: