These are policy-driven snapshot management and replication tools which use OpenZFS for underlying next-gen storage. (Btrfs support plans are shelved unless and until btrfs becomes reliable.)
Go to file
Jim Salter 6eaa303327 1.4.6b - updated cipherlist for syncoid to chacha20-poly1305@openssh.com,arcfour 2016-05-27 18:24:27 -04:00
CHANGELIST 1.4.6b - updated cipherlist for syncoid to chacha20-poly1305@openssh.com,arcfour 2016-05-27 18:24:27 -04:00
INSTALL added INSTALL notes 2016-05-23 13:17:22 -04:00
LICENSE Initial commit 2014-11-17 09:34:31 -05:00
README.md poking at layout 2015-11-17 17:36:20 -05:00
VERSION added ==0 or die to all system calls in sanoid and syncoid that didn't already have them 2016-05-23 18:55:42 -04:00
findoid 1.4.6b - updated cipherlist for syncoid to chacha20-poly1305@openssh.com,arcfour 2016-05-27 18:24:27 -04:00
sanoid 1.4.6b - updated cipherlist for syncoid to chacha20-poly1305@openssh.com,arcfour 2016-05-27 18:24:27 -04:00
sanoid.conf process_children_only keeps sanoid from messing with empty parent datasets; improved docs in default conf files 2015-04-02 11:10:38 -04:00
sanoid.defaults.conf process_children_only keeps sanoid from messing with empty parent datasets; improved docs in default conf files 2015-04-02 11:10:38 -04:00
sanoid.spec Updated Change log 2016-03-08 10:48:40 -05:00
sleepymutex 1.4.5 changed shebang to '#!/usr/bin/env perl' for enhanced FreeBSD compatibility 2016-05-23 12:35:11 -04:00
syncoid 1.4.6b - updated cipherlist for syncoid to chacha20-poly1305@openssh.com,arcfour 2016-05-27 18:24:27 -04:00

README.md

sanoid logo

======

Sanoid is a policy-driven snapshot management tool for ZFS filesystems. When combined with the Linux KVM hypervisor, you can use it to make your systems functionally immortal.

More prosaically, you can use Sanoid to create, automatically thin, and monitor snapshots and pool health from a single eminently human-readable TOML config file at /etc/sanoid/sanoid.conf. (Sanoid also requires a "defaults" file located at /etc/sanoid/sanoid.defaults.conf, which is not user-editable.) A typical Sanoid system would have a single cron job:

* * * * * /usr/local/bin/sanoid --cron

And its /etc/sanoid/sanoid.conf might look something like this:

[data/home]
	use_template = production
[data/images]
	use_template = production
	recursive = yes
	process_children_only = yes
[data/images/win7]
	hourly = 4

#############################
# templates below this line #
#############################

[template_production]
        hourly = 36
        daily = 30
        monthly = 3
        yearly = 0
        autosnap = yes
        autoprune = yes

Which would be enough to tell sanoid to take and keep 36 hourly snapshots, 30 dailies, 3 monthlies, and no yearlies for all datasets under data/images (but not data/images itself, since process_children_only is set). Except in the case of data/images/win7-spice, which follows the same template (since it's a child of data/images) but only keeps 4 hourlies for whatever reason.

Sanoid also includes a replication tool, syncoid, which facilitates the asynchronous incremental replication of ZFS filesystems. A typical syncoid command might look like this:

syncoid data/images/vm backup/images/vm

Which would replicate the specified ZFS filesystem (aka dataset) from the data pool to the backup pool on the local system, or

syncoid data/images/vm root@remotehost:backup/images/vm

Which would push-replicate the specified ZFS filesystem from the local host to remotehost over an SSH tunnel, or

syncoid root@remotehost:data/images/vm backup/images/vm

Which would pull-replicate the filesystem from the remote host to the local system over an SSH tunnel.

Syncoid supports recursive replication (replication of a dataset and all its child datasets) and uses mbuffer buffering, lzop compression, and pv progress bars if the utilities are available on the systems used.