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 3280856d6f minor fix - add a 2>&1 to get rid of the 'Exit request sent.' noise at the end when killing the ssh master 2015-09-18 12:14:54 -04:00
CHANGELIST minor fix - add a 2>&1 to get rid of the 'Exit request sent.' noise at the end when killing the ssh master 2015-09-18 12:14:54 -04:00
LICENSE Initial commit 2014-11-17 09:34:31 -05:00
README.md Update README.md 2015-09-16 17:29:02 -04:00
VERSION 1.4.3 - added SSH persistence - speeds up SSH overhead by 300%+ 2015-09-18 12:03:25 -04:00
findoid 1.4.3 - added SSH persistence - speeds up SSH overhead by 300%+ 2015-09-18 12:03:25 -04:00
sanoid 1.4.3 - added SSH persistence - speeds up SSH overhead by 300%+ 2015-09-18 12:03:25 -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
sleepymutex tested new mutex checking in sanoid snapshot thinning. added sleepymutex tool for future dev use in testing. 2014-11-17 10:33:51 -05:00
syncoid minor fix - add a 2>&1 to get rid of the 'Exit request sent.' noise at the end when killing the ssh master 2015-09-18 12:14:54 -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.