sanoid/README.md

179 lines
7.1 KiB
Markdown
Raw Normal View History

2014-11-20 18:04:29 +01:00
<p align="center"><img src="http://www.openoid.net/wp-content/themes/openoid/images/sanoid_logo.png" alt="sanoid logo" title="sanoid logo"></p>
2014-11-20 17:50:15 +01:00
<img src="http://openoid.net/gplv3-127x51.png" width=127 height=51 align="right">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 <a href="http://openoid.net/transcend" target="_blank">functionally immortal</a>.
2016-07-04 22:28:31 +02:00
<p align="center"><a href="https://youtu.be/ZgowLNBsu00" target="_blank"><img src="http://www.openoid.net/sanoid_video_launcher.png" alt="sanoid rollback demo" title="sanoid rollback demo"></a><br clear="all"><sup>(Real time demo: rolling back a full-scale cryptomalware infection in seconds!)</sup></p>
2014-11-17 16:59:25 +01:00
2017-06-15 19:35:01 +02:00
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:
2014-11-17 16:59:25 +01:00
```
* * * * * /usr/local/bin/sanoid --cron
```
And its /etc/sanoid/sanoid.conf might look something like this:
```
[data/home]
use_template = production
[data/images]
2014-11-17 16:59:25 +01:00
use_template = production
recursive = yes
process_children_only = yes
[data/images/win7]
2014-11-17 16:59:25 +01:00
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.
2014-11-17 16:59:25 +01:00
2017-06-15 19:35:01 +02:00
##### Sanoid Command Line Options
+ --cron
This will process your sanoid.conf file, create snapshots, then purge expired ones.
+ --configdir
Specify a location for the config file named sanoid.conf. Defaults to /etc/sanoid
2017-06-15 19:35:01 +02:00
+ --take-snapshots
2017-06-15 21:47:32 +02:00
This will process your sanoid.conf file, create snapshots, but it will NOT purge expired ones. (Note that snapshots taken are atomic in an individual dataset context, <i>not</i> a global context - snapshots of pool/dataset1 and pool/dataset2 will each be internally consistent and atomic, but one may be a few filesystem transactions "newer" than the other.)
2017-06-15 19:35:01 +02:00
+ --prune-snapshots
This will process your sanoid.conf file, it will NOT create snapshots, but it will purge expired ones.
+ --monitor-snapshots
This option is designed to be run by a Nagios monitoring system. It reports on the health of your snapshots.
+ --monitor-health
This option is designed to be run by a Nagios monitoring system. It reports on the health of the zpool your filesystems are on. It only monitors filesystems that are configured in the sanoid.conf file.
+ --force-update
This clears out sanoid's zfs snapshot listing cache. This is normally not needed.
2017-06-15 19:35:01 +02:00
+ --version
This prints the version number, and exits.
+ --quiet
2017-06-15 19:35:01 +02:00
Supress non-error output.
2017-06-15 19:35:01 +02:00
+ --verbose
2017-06-15 19:35:01 +02:00
This prints additional information during the sanoid run.
2017-06-15 19:35:01 +02:00
+ --debug
This prints out quite alot of additional information during a sanoid run, and is normally not needed.
----------
# Syncoid
2014-11-17 16:59:25 +01:00
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.
2017-06-15 19:35:01 +02:00
##### Syncoid Command Line Options
+ --[source]
This is the source dataset. It can be either local or remote.
+ --[destination]
This is the destination dataset. It can be either local or remote.
+ -r --recursive
This will also transfer child datasets.
+ --compress <compression type>
Currently accepts gzip and lzo. lzo is fast and light on the processsor and is the default. If the selected compression method is unavailable on the source and destination, no compression will be used.
2017-06-15 19:35:01 +02:00
+ --source-bwlimit <limit t|g|m|k>
This is the bandwidth limit imposed upon the source. This is mainly used if the target does not have mbuffer installed, but bandwidth limites are desired.
+ --target-bw-limit <limit t|g|m|k>
This is the bandwidth limit imposed upon the target. This is mainly used if the source does not have mbuffer installed, but bandwidth limites are desired.
+ --nocommandchecks
Do not check the existance of commands before attempting the transfer. It assumes all programs are available. This should never be used.
+ --no-stream
2017-06-15 19:35:01 +02:00
This argument tells syncoid to use -i incrementals, not -I. This updates the target with the newest snapshot from the source, without replicating the intermediate snapshots in between. (If used for an initial synchronization, will do a full replication from newest snapshot and exit immediately, rather than starting with the oldest and then doing an immediate -i to the newest.)
2017-06-15 19:35:01 +02:00
+ --no-sync-snap
2017-06-15 19:35:01 +02:00
This argument tells syncoid to restrict itself to existing snapshots, instead of creating a semi-ephemeral syncoid snapshot at execution time. Especially useful in multi-target (A->B, A->C) replication schemes, where you might otherwise accumulate a large number of foreign syncoid snapshots.
2017-06-15 19:35:01 +02:00
+ --dumpsnaps
This prints a list of snapshots during the run.
+ --sshport
2017-06-15 19:35:01 +02:00
Allow sync to/from boxes running SSH on non-standard ports.
2017-06-15 19:35:01 +02:00
+ --sshkey
2017-06-15 19:35:01 +02:00
Use specified identity file as per ssh -i.
2017-06-15 19:35:01 +02:00
+ --quiet
2017-06-15 19:35:01 +02:00
Supress non-error output.
2017-06-15 19:35:01 +02:00
+ --debug
This prints out quite alot of additional information during a sanoid run, and is normally not needed.
+ --version
Print the version and exit.
+ --monitor-version
This doesn't do anything right now.
Note that the sync snapshots syncoid creates are not atomic in a global context: sync snapshots of pool/dataset1 and pool/dataset2 will each be internally consistent, but one may be a few filesystem transactions "newer" than the other. (This does not affect the consistency of snapshots already taken in other ways, which syncoid replicates in the overall stream unless --no-stream is specified. So if you want to manually zfs snapshot -R pool@1 before replicating with syncoid, the global atomicity of pool/dataset1@1 and pool/dataset2@1 will still be intact.)