Because zfs send
and zfs
recv
use streams to exchange data, you can use them to
replicate information from one system to another by combining
zfs send
, ssh
, and
zfs recv
.
For example, if a snapshot of the opt
filesystem has been created and this needs to be copied to a new
system or filesystem called slavepool
. You
would use the following command, combining the snapshot of
opt
, the transmission to the slave machine
(using ssh), and the recovery of the snapshot
on the slave using zfs revc:
root-shell> zfs send opt@snap1 |ssh mc@slave pfexec zfs recv -F slavepool
The first part, zfs send opt@snap1
, streams the
snapshot, the second, ssh mc@slave
, and the
third, pfexec zfs recv -F slavepool
, receives
the streamed snapshot data and writes it to slavepool. In this
instance, I've specified the -F
option which
forces the snapshot data to be applied, and is therefore
destructive. This is fine, as I'm creating the first version of my
replicated filesystem.
On the slave machine, the replicated filesystem contains the exact same content:
root-shell> ls -al /slavepool/ total 23 drwxr-xr-x 6 root root 7 Nov 8 09:13 ./ drwxr-xr-x 29 root root 34 Nov 9 07:06 ../ drwxr-xr-x 31 root bin 50 Jul 21 07:32 DTT/ drwxr-xr-x 4 root bin 5 Jul 21 07:32 SUNWmlib/ drwxr-xr-x 14 root sys 16 Nov 5 09:56 SUNWspro/ drwxrwxrwx 19 1000 1000 40 Nov 6 19:16 emacs-22.1/
Once a snapshot has been created, to synchronize the filesystem
again, you need to create a new snapshot, and then use the
incremental snapshot feature of zfs send
to
send the changes between the two snapshots to the slave machine
again:
root-shell> zfs send -i opt@snapshot1 opt@snapshot2 |ssh mc@192.168.0.93 pfexec zfs recv slavepool
Without further modification, this operation will fail. The reason
is that the filesystem on the slave machine can currently be
modified, and you can't apply the incremental changes to a
destination filesystem that has changed. It is the metadata that
has changed. The metadata about the filesystem, like the last time
it was accessed - in this case, it will have been our
ls
that caused the problem.
To prevent changes on the slave filesystem, you must set the filesystem on the slave to be read-only:
root-shell> zfs set readonly=on slavepool
Setting readonly
means that you cannot change
the filesystem on the slave by normal means, including the
filesystem metadata. Operations that would normally update
metadata (like our ls
) will silently perform
their function without attempting to update the filesystem state.
In essence, the slave filesystem is nothing but a static copy of the original filesystem. However, even when configured to to be read-only, a filesystem can have snapshots applied to it. Now the filesystem is read only, re-run the initial copy:
root-shell> zfs send opt@snap1 |ssh mc@slave pfexec zfs recv -F slavepool
Now you can make changes to the original filesystem and replicate them to the slave.
User Comments
Add your own comment.