Date: Sun, 02 Feb 2014 17:37:15 -0500 From: Allan Jude <freebsd@allanjude.com> To: freebsd-doc@FreeBSD.org Subject: Re: Fwd: Re: svn commit: r43697 - projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs Message-ID: <52EEC89B.5000403@allanjude.com> In-Reply-To: <52EC0C48.7060507@FreeBSD.org> References: <alpine.GSO.1.10.1401311412520.27579@multics.mit.edu> <52EC0C48.7060507@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vMbdMPT7S7XBSvALFXOgTC5gmoFXxlamg
Content-Type: multipart/mixed;
boundary="------------060605020303020203050600"
This is a multi-part message in MIME format.
--------------060605020303020203050600
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 2014-01-31 15:49, Benedict Reuschling wrote:
> Hi Allan,
>=20
> how are you? Judging from BSDnow, you're doing fine. :)
>=20
> Can you help me with the ZFS send via SSH part for the ZFS chapter
> rewrite below? Benjamin Kaduk remarked that he does not understand
> what needs to be done on each side. I think this needs more work and I
> don't know exactly what needs to be set for root to be able to do this
> (on each system). Plus, if you know some ports or other software that
> does that, we could mention that in the paragraph as well.
>=20
> I also need to look up the newer ZFS send stuff (hole-less send, the
> bookmark-based resume feature, etc.) so that we can reflect this in
> the handbook right from the start. If you have some time, I'd be glad
> for a patch or some paragraphs that I can put into DocBook.
>=20
> While on the subject: a while back you mentioned a port that does
> grandfather, father, son snapshots and rotates them automatically.
> What was the name of that port? I can't recall, but I want to try it
> out at work and it would also be a good addition for the snapshot part.=
>=20
> Thanks and keep up the good work with BSDnow and all your other BSD
> activities.
>=20
> Cheers
>=20
> Benedict
>=20
>=20
>=20
> -------- Original-Nachricht --------
> Betreff: Re: svn commit: r43697 -
> projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs
> Datum: Fri, 31 Jan 2014 14:32:11 -0500 (EST)
> Von: Benjamin Kaduk <kaduk@mit.edu>
> An: Benedict Reuschling <bcr@freebsd.org>
> Kopie (CC): doc-committers@freebsd.org, svn-doc-projects@freebsd.org
>=20
> On Thu, 30 Jan 2014, Benedict Reuschling wrote:
>=20
>> + + <listitem> + <para>The <literal>root</literal> user needs
>> to be able to + log into the receiving system because only
>> that user can + send streams from the pool. SSH should be
>> configured so + that <literal>root</literal> can only
>> execute + <command>zfs recv</command> and nothing else to
>> prevent + users that might have hijacked this account from
>> doing + any harm on the system.</para>
>=20
> This paragraph is a little confusing about what happens on the sending
> and
> receiving systems. (For example, at first I was confused by the first
> sentence, thinking that it was saying that the receiving system would b=
e
> sending streams from the pool.) Do both the send and receive have to
> happen as root on the respective machines? I also think that the
> restriction to 'zfs recv' should apply only to the particular ssh key
> which is doing the automated backups; it would be absurd to prevent roo=
t
> login from one server to another just because there is a backup
> relationship in place.
>=20
>> + </listitem> + </itemizedlist> + + <para>After these security
>> measures have been put into place + and <literal>root</literal>
>> can connect passwordless via SSH
>=20
I have made a first pass on this. It still needs some more work. I am
not sure if it fits best in this section or the delegation section, but
it would be good to document how to do it without root, as it is much
safer than having unencrypted root keys laying around, and it is only 2
or 3 extra commands (zfs allow snapshot/send on one side and zfs
receive/create etc on the other plus 1 sysctl (usermount))
In a future pass I'll update the screen sections to be more consistent
as well
--=20
Allan Jude
--------------060605020303020203050600
Content-Type: text/plain; charset=windows-1252;
name="zfs.send.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="zfs.send.patch"
Index: chapter.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- chapter.xml (revision 43727)
+++ chapter.xml (working copy)
@@ -1250,7 +1250,7 @@
<sect2 xml:id=3D"zfs-zfs-send">
<title>ZFS Replication</title>
=20
- <para>Keeping the data on a single pool in one location exposes
+ <para>Keeping data on a single pool in one location exposes
it to risks like theft, natural and human disasters. Keeping
regular backups of the entire pool is vital when data needs to
be restored. ZFS provides a built-in serialization feature
@@ -1268,7 +1268,7 @@
<para>The following examples will demonstrate the functionality
of ZFS replication using these two pools:</para>
=20
- <screen>&prompt.root; <userinput>zpool list</userinput>
+ <screen>&prompt.root; <command>zpool list</command>
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
backup 960M 77K 896M 0% 1.00x ONLINE -
mypool 984M 43.7M 940M 4% 1.00x ONLINE -</screen>
@@ -1277,36 +1277,38 @@
primary pool where data is written to and read from on a
regular basis. A second pool,
<replaceable>backup</replaceable> is used as a standby in case
- the primary pool becomes offline. Note that this is not done
+ the primary pool becomes unavailable. Note that this is not done
automatically by ZFS, but rather done by a system
- administrator in case it is needed. First, a snapshot is
+ administrator in case it is needed. First, a snapshot must be
created on <replaceable>mypool</replaceable> to have a copy
- of the current state of the data to send to the pool
- <replaceable>backup</replaceable>.</para>
+ of the current state of the data to send to the=20
+ <replaceable>backup</replaceable> pool. ZFS only replicates
+ snapshots, changes since the most recent snapshot will not
+ be replicated.</para>
=20
- <screen>&prompt.root; <userinput>zfs snapshot <replaceable>mypool<=
/replaceable>@<replaceable>backup1</replaceable></userinput>
-&prompt.root; <userinput>zfs list -t snapshot</userinput>
+ <screen>&prompt.root; <command>zfs snapshot <replaceable>mypool</r=
eplaceable>@<replaceable>backup1</replaceable></command>
+&prompt.root; <command>zfs list -t snapshot</command>
NAME USED AVAIL REFER MOUNTPOINT
mypool@backup1 0 - 43.6M -</screen>
=20
<para>Now that a snapshot exists, <command>zfs send</command>
can be used to create a stream representing the contents of
- the snapshot locally or remotely to another pool. The stream
+ the snapshot, which can be stored as a file, or received by another poo=
l. The stream
must be written to the standard output, otherwise ZFS will
- produce an error like in this example:</para>
+ produce an error:</para>
=20
- <screen>&prompt.root; <userinput>zfs send <replaceable>mypool</rep=
laceable>@<replaceable>backup1</replaceable></userinput>
+ <screen>&prompt.root; <command>zfs send <replaceable>mypool</repla=
ceable>@<replaceable>backup1</replaceable></command>
Error: Stream can not be written to a terminal.
You must redirect standard output.</screen>
=20
- <para>The correct way to use <command>zfs send</command> is to
- redirect it to a location like the mounted backup pool.
- Afterwards, that pool should have the size of the snapshot
- allocated, which means all the data contained in the snapshot
- was stored on the backup pool.</para>
+ <para>To backup a dataset with <command>zfs send</command>,
+ redirect to a file located on the mounted backup pool. First
+ ensure that the pool has enough free space to accommodate the size of t=
he snapshot,
+ which means all the data contained in the snapshot, not
+ only the changes in the snapshot.</para>
=20
- <screen>&prompt.root; <userinput>zfs send <replaceable>mypool</rep=
laceable>@<replaceable>backup1</replaceable> > <replaceable>/backup/backu=
p1</replaceable></userinput>
-&prompt.root; <userinput>zpool list</userinput>
+ <screen>&prompt.root; <command>zfs send <replaceable>mypool</repla=
ceable>@<replaceable>backup1</replaceable> > <replaceable>/backup/backup1=
</replaceable></command>
+&prompt.root; <command>zpool list</command>
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
backup 960M 63.7M 896M 6% 1.00x ONLINE -
mypool 984M 43.7M 940M 4% 1.00x ONLINE -</screen>
@@ -1314,98 +1316,100 @@
<para>The <command>zfs send</command> transferred all the data
in the snapshot called <replaceable>backup1</replaceable> to
the pool named <replaceable>backup</replaceable>. Creating
- and sending these snapshots could be done automatically by a
- cron job.</para>
+ and sending these snapshots could be done automatically with a
+ &man.cron.8; job.</para>
=20
+ <para>Instead of storing the backups as archive files,
+ <acronym>ZFS</acronym> can receive them as a live file system,
+ allowing the backed up data to be accessed directly.
+ To get to the actual data contained in
+ those streams, the reverse operation of <command>zfs
+ send</command> has to be used to transform the streams
+ back into files and directories. The command is
+ <command>zfs receive</command>. The example below combines
+ <command>zfs send</command> and <command>zfs
+ receive</command> using a pipe to copy the data from one
+ pool to another. This way, the data can be used directly on
+ the receiving pool after the transfer is complete. A
+ dataset can only be replicated to an empty dataset.</para>
+
+ <screen>&prompt.root; <command>zfs snapshot <replaceable>mypool</r=
eplaceable>@<replaceable>replica1</replaceable></command>
+&prompt.root; <command>zfs send -v <replaceable>mypool</replaceable>@<re=
placeable>replica1</replaceable> | zfs receive <replaceable>backup/mypool=
</replaceable></command>
+send from @ to mypool@replica1 estimated size is 50.1M
+total estimated size is 50.1M
+TIME SENT SNAPSHOT
+
+&prompt.root; <command>zpool list</command>
+NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
+backup 960M 63.7M 896M 6% 1.00x ONLINE -
+mypool 984M 43.7M 940M 4% 1.00x ONLINE -</screen>
+
<sect3 xml:id=3D"zfs-send-incremental">
<title>ZFS Incremental Backups</title>
=20
- <para>Another feature of <command>zfs send</command> is that
- it can determine the difference between two snapshots to
- only send what has changed between the two. This results in
- saving disk space and time for the transfer to another pool.
+ <para><command>zfs send</command> can also
+ determine the difference between two snapshots and
+ only send the changes between the two. This results in
+ saving disk space and transfer time.
For example:</para>
=20
- <screen>&prompt.root; <userinput>zfs snapshot <replaceable>mypool</repl=
aceable>@<replaceable>backup2</replaceable></userinput>
-&prompt.root; <userinput>zfs list -t snapshot</userinput>
+ <screen>&prompt.root; <command>zfs snapshot <replaceable>mypool</replac=
eable>@<replaceable>replica2</replaceable></command>
+&prompt.root; <command>zfs list -t snapshot</command>
NAME USED AVAIL REFER MOUNTPOINT
-mypool@backup1 5.72M - 43.6M -
-mypool@backup2 0 - 44.1M -
-&prompt.root; <userinput>zpool list</userinput>
+mypool@replica1 5.72M - 43.6M -
+mypool@replica2 0 - 44.1M -
+&prompt.root; <command>zpool list</command>
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
backup 960M 61.7M 898M 6% 1.00x ONLINE -
mypool 960M 50.2M 910M 5% 1.00x ONLINE -</screen>
=20
<para>A second snapshot called
- <replaceable>backup2</replaceable> was created. This second
+ <replaceable>replica2</replaceable> was created. This second
snapshot contains only the changes on the ZFS filesystem
- between now and the last snapshot,
- <replaceable>backup1</replaceable>. Using the
- <literal>-i</literal> flag to <command>zfs send</command>
- and providing both snapshots, an incremental snapshot can be
- transferred, containing only the data that has
+ between now and the previous snapshot,
+ <replaceable>replica1</replaceable>. Using the
+ <literal>-i</literal> flag of <command>zfs send</command>
+ and indicating the pair of snapshots, an incremental replica
+ stream can be generated, containing only the data that has
changed.</para>
=20
- <screen>&prompt.root; <userinput>zfs send -i <replaceable>mypool</repla=
ceable>@<replaceable>backup1</replaceable> <replaceable>mypool</replaceab=
le>@<replaceable>backup2</replaceable> > <replaceable>/backup/incremental=
</replaceable></userinput>
-&prompt.root; <userinput>zpool list</userinput>
+ <screen>&prompt.root; <command>zfs send -v -i <replaceable>mypool</repl=
aceable>@<replaceable>replica1</replaceable> <replaceable>mypool</replace=
able>@<replaceable>replica2</replaceable> | zfs receive <replaceable>/bac=
kup/mypool</replaceable></command>
+send from @replica1 to mypool@replica2 estimated size is 5.02M
+total estimated size is 5.02M
+TIME SENT SNAPSHOT
+
+&prompt.root; <command>zpool list</command>
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
backup 960M 80.8M 879M 8% 1.00x ONLINE -
mypool 960M 50.2M 910M 5% 1.00x ONLINE -
-&prompt.root; <userinput>ls -lh /backup</userinput>
-total 82247
-drwxr-xr-x 1 root wheel 61M Dec 3 11:36 backup1
-drwxr-xr-x 1 root wheel 18M Dec 3 11:36 incremental</screen>=
=20
+&prompt.root; <command>zfs list</command>
+NAME USED AVAIL REFER MOUNTPOINT
+backup 55.4M 240G 152K /backup
+backup/mypool 55.3M 240G 55.2M /backup/mypool
+mypool 55.6M 11.6G 55.0M /mypool
+
+&prompt.root; <command>zfs list -t snapshot</command>
+NAME USED AVAIL REFER MOUNTPO=
INT
+backup/mypool@replica1 104K - 50.2M -
+backup/mypool@replica2 0 - 55.2M -
+mypool@replica1 29.9K - 50.0M -
+mypool@replica2 0 - 55.0M -</scre=
en>
+
<para>The incremental stream was successfully transferred and
- the file on disk is smaller than any of the two snapshots
- <replaceable>backup1</replaceable> or
- <replaceable>backup2</replaceable>. This shows that it only
+ only the data that has changed was replicated, rather than
+ the entirety of
+ <replaceable>replica1</replaceable> and
+ <replaceable>replica2</replaceable> with both contain mostly the same=
data. This shows that it only
contains the differences, which is much faster to transfer
and saves disk space by not copying the complete pool each
time. This is useful when having to rely on slow networks
or when costs per transferred byte have to be
considered.</para>
- </sect3>
=20
- <sect3 xml:id=3D"zfs-send-recv">
- <title>Receiving ZFS Data Streams</title>
-
- <para>Up until now, only the data streams in binary form were
- sent to other pools. To get to the actual data contained in
- those streams, the reverse operation of <command>zfs
- send</command> has to be used to transform the streams
- back into files and directories. The command is called
- <command>zfs receive</command> and has also a short version:
- <command>zfs recv</command>. The example below combines
- <command>zfs send</command> and <command>zfs
- receive</command> using a pipe to copy the data from one
- pool to another. This way, the data can be used directly on
- the receiving pool after the transfer is complete.</para>
-
- <screen>&prompt.root; <userinput>zfs send <replaceable>mypool</replacea=
ble>@<replaceable>backup1</replaceable> | zfs receive <replaceable>backup=
/backup1</replaceable></userinput>
-&prompt.root; <userinput>ls -lh /backup</userinput>
-total 431
-drwxr-xr-x 4219 root wheel 4.1k Dec 3 11:34 backup1</screen>=
-
- <para>The directory <replaceable>backup1</replaceable> does
- contain all the data, which were part of the snapshot of the
- same name. Since this originally was a complete filesystem
- snapshot, the listing of all ZFS filesystems for this pool
- is also updated and shows the
- <replaceable>backup1</replaceable> entry.</para>
-
- <screen>&prompt.root; <userinput>zfs list</userinput>
-NAME USED AVAIL REFER MOUNTPOINT
-backup 43.7M 884M 32K /backup
-backup/backup1 43.5M 884M 43.5M /backup/backup1
-mypool 50.0M 878M 44.1M /mypool</screen>
-
- <para>A new filesystem, <replaceable>backup1</replaceable> is
- available and has the same size as the snapshot it was
- created from. It is up to the user to decide whether the
- streams should be transformed back into filesystems directly
- to have a cold-standby for emergencies or to just keep the
- streams and transform them later when required. Sending and
+ <para>A new filesystem, <replaceable>backup/mypool</replaceable> is
+ available and has all of the files and data from the pool
+ <replaceable>mypool</replaceable>. Sending and
receiving can be automated so that regular backups are
created on a second pool for backup purposes.</para>
</sect3>
@@ -1428,14 +1432,17 @@
encrypted, <application>SSH</application> can be used.
Since ZFS only requires the stream to be redirected from
standard output, it is relatively easy to pipe it through
- SSH.</para>
+ SSH. If you wish the contents of your
+ <acronym>ZFS</acronym> file system to remain encrypted,
+ consider using <link
+ xlink:href=3D"http://wiki.freebsd.org/PEFS">PEFS</link>.</para>;
=20
<para>A few settings and security precautions have to be made
before this can be done. Since this chapter is about ZFS
and not about configuring SSH, it only lists the things
required to perform the encrypted <command>zfs
- send</command> operation. The following settings should
- be made:</para>
+ send</command> operation. The following configuration is
+ required:</para>
=20
<itemizedlist>
<listitem>
@@ -1450,7 +1457,10 @@
that <literal>root</literal> can only execute
<command>zfs recv</command> and nothing else to prevent
users that might have hijacked this account from doing
- any harm on the system.</para>
+ any harm on the system. Using the <link
+ linkend=3D"zfs-zfs-allow">delegation</link> system it is
+ possible to perform replication without requiring
+ root access.</para>
</listitem>
</itemizedlist>
=20
@@ -1460,8 +1470,8 @@
encrypted stream can be sent using the following
commands:</para>
=20
- <screen>&prompt.root; <userinput>zfs snapshot -r <replaceable>mypool/ho=
me</replaceable>@<replaceable>monday</replaceable></userinput>
-&prompt.root; <userinput>zfs send -R <replaceable>mypool/home</replaceab=
le>@<replaceable>monday</replaceable> | ssh <replaceable>backuphost</repl=
aceable> zfs recv -dvu <replaceable>backuppool</replaceable></userinput><=
/screen>
+ <screen>&prompt.root; <command>zfs snapshot -r <replaceable>mypool/home=
</replaceable>@<replaceable>monday</replaceable></command>
+&prompt.root; <command>zfs send -R <replaceable>mypool/home</replaceable=
>@<replaceable>monday</replaceable> | ssh <replaceable>backuphost</replac=
eable> zfs recv -dvu <replaceable>backuppool</replaceable></command></scr=
een>
=20
<para>The first command creates a recursive snapshot (option
<literal>-r</literal>) called
--------------060605020303020203050600--
--vMbdMPT7S7XBSvALFXOgTC5gmoFXxlamg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS7sigAAoJEJrBFpNRJZKf7SQP/idxZEWJiGbZAyA0UGxgotL/
t398BisJ3Vmk9Ns+qeggTthKf+ZFg3VfGNb5pV3UKkwLABgr/0h1XnuXSFFqIkaU
aA30LvuAQJLzCyTgIJqos9G6bMJKpGBEETkVT+yIEVYyDNJ/VlnfPfSv1Atd9e6l
kxpzJRLrwz2FSdREaWPpwFi9XWwCfyXSm0fhIews1+xlbLlorhp7/pmmJrbTpwi8
Jf6zmXIo8dCfU76kySiZUb0CAupTErdvS7UKy27CXvXfX5zNH1iNHH0ZP3mtQJNz
SMFi6p0r1WdZ8Z/7z/ZqZf776tjZZcHWV4hNj2fP5n5mi+tPqlPCqRcepY2aoEPA
499deB+qr6eY3bGkH1EfmErEeTrklphEZymaaiglIlZUL0WNL7xe/wipSLseb39p
WFYjiMwOwPSWu8/2YfA75a0HShc306RhbYpp61KxOFyGM9woB2r5+KjMqHbtBqv6
oA39dmP8hXUT9/Pp7FTK9o0riJXOscePKe4xrca2BMRmDJNFH+l1Jr0/BACL4rhx
DyfdKXvASYw/a2Lj1zbHcitX+nqAaLKbGmgX5XrbyFvBTFQUJiHN5AGfpIHAr4Wj
sv4orD6RDLdcTyeRVCSr7pFhLTkquWwXukaMtrU0zcYg//0rBFXc5WvrdQvQb9kE
VOl6dUM+LiRflTrq71gN
=sz/y
-----END PGP SIGNATURE-----
--vMbdMPT7S7XBSvALFXOgTC5gmoFXxlamg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52EEC89B.5000403>