From owner-freebsd-doc@FreeBSD.ORG Sun Feb 2 22:37:22 2014 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC06472E; Sun, 2 Feb 2014 22:37:22 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 7D08C16AD; Sun, 2 Feb 2014 22:37:21 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id AC1FA57CD9; Sun, 2 Feb 2014 22:37:20 +0000 (UTC) Message-ID: <52EEC89B.5000403@allanjude.com> Date: Sun, 02 Feb 2014 17:37:15 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-doc@FreeBSD.org Subject: Re: Fwd: Re: svn commit: r43697 - projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs References: <52EC0C48.7060507@FreeBSD.org> In-Reply-To: <52EC0C48.7060507@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vMbdMPT7S7XBSvALFXOgTC5gmoFXxlamg" X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 22:37:22 -0000 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 > An: Benedict Reuschling > Kopie (CC): doc-committers@freebsd.org, svn-doc-projects@freebsd.org >=20 > On Thu, 30 Jan 2014, Benedict Reuschling wrote: >=20 >> + + + The root 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 root can only >> execute + zfs recv and nothing else to >> prevent + users that might have hijacked this account from >> doing + any harm on the system. >=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 >> + + + + After these security >> measures have been put into place + and root >> 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 @@ ZFS Replication =20 - Keeping the data on a single pool in one location exposes + 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 @@ The following examples will demonstrate the functionality of ZFS replication using these two pools: =20 - &prompt.root; zpool list + &prompt.root; zpool list 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 - @@ -1277,36 +1277,38 @@ primary pool where data is written to and read from on a regular basis. A second pool, backup 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 mypool to have a copy - of the current state of the data to send to the pool - backup. + of the current state of the data to send to the=20 + backup pool. ZFS only replicates + snapshots, changes since the most recent snapshot will not + be replicated. =20 - &prompt.root; zfs snapshot mypool<= /replaceable>@backup1 -&prompt.root; zfs list -t snapshot + &prompt.root; zfs snapshot mypool@backup1 +&prompt.root; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT mypool@backup1 0 - 43.6M - =20 Now that a snapshot exists, zfs send 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: + produce an error: =20 - &prompt.root; zfs send mypool@backup1 + &prompt.root; zfs send mypool@backup1 Error: Stream can not be written to a terminal. You must redirect standard output. =20 - The correct way to use zfs send 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. + To backup a dataset with zfs send, + 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. =20 - &prompt.root; zfs send mypool@backup1 > /backup/backu= p1 -&prompt.root; zpool list + &prompt.root; zfs send mypool@backup1 > /backup/backup1= +&prompt.root; zpool list 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 - @@ -1314,98 +1316,100 @@ The zfs send transferred all the data in the snapshot called backup1 to the pool named backup. Creating - and sending these snapshots could be done automatically by a - cron job. + and sending these snapshots could be done automatically with a + &man.cron.8; job. =20 + Instead of storing the backups as archive files, + ZFS 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 zfs + send has to be used to transform the streams + back into files and directories. The command is + zfs receive. The example below combines + zfs send and zfs + receive 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. + + &prompt.root; zfs snapshot mypool@replica1 +&prompt.root; zfs send -v mypool@replica1 | zfs receive backup/mypool= +send from @ to mypool@replica1 estimated size is 50.1M +total estimated size is 50.1M +TIME SENT SNAPSHOT + +&prompt.root; zpool list +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 - + ZFS Incremental Backups =20 - Another feature of zfs send 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. + zfs send 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: =20 - &prompt.root; zfs snapshot mypool@backup2 -&prompt.root; zfs list -t snapshot + &prompt.root; zfs snapshot mypool@replica2 +&prompt.root; zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT -mypool@backup1 5.72M - 43.6M - -mypool@backup2 0 - 44.1M - -&prompt.root; zpool list +mypool@replica1 5.72M - 43.6M - +mypool@replica2 0 - 44.1M - +&prompt.root; zpool list 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 - =20 A second snapshot called - backup2 was created. This second + replica2 was created. This second snapshot contains only the changes on the ZFS filesystem - between now and the last snapshot, - backup1. Using the - -i flag to zfs send - and providing both snapshots, an incremental snapshot can be - transferred, containing only the data that has + between now and the previous snapshot, + replica1. Using the + -i flag of zfs send + and indicating the pair of snapshots, an incremental replica + stream can be generated, containing only the data that has changed. =20 - &prompt.root; zfs send -i mypool@backup1 mypool@backup2 > /backup/incremental= -&prompt.root; zpool list + &prompt.root; zfs send -v -i mypool@replica1 mypool@replica2 | zfs receive /bac= kup/mypool +send from @replica1 to mypool@replica2 estimated size is 5.02M +total estimated size is 5.02M +TIME SENT SNAPSHOT + +&prompt.root; zpool list 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; ls -lh /backup -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= =20 +&prompt.root; zfs list +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; zfs list -t snapshot +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 - + The incremental stream was successfully transferred and - the file on disk is smaller than any of the two snapshots - backup1 or - backup2. This shows that it only + only the data that has changed was replicated, rather than + the entirety of + replica1 and + replica2 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. - =20 - - Receiving ZFS Data Streams - - 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 zfs - send has to be used to transform the streams - back into files and directories. The command is called - zfs receive and has also a short version: - zfs recv. The example below combines - zfs send and zfs - receive 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. - - &prompt.root; zfs send mypool@backup1 | zfs receive backup= /backup1 -&prompt.root; ls -lh /backup -total 431 -drwxr-xr-x 4219 root wheel 4.1k Dec 3 11:34 backup1= - - The directory backup1 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 - backup1 entry. - - &prompt.root; zfs list -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 - - A new filesystem, backup1 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 + A new filesystem, backup/mypool is + available and has all of the files and data from the pool + mypool. Sending and receiving can be automated so that regular backups are created on a second pool for backup purposes. @@ -1428,14 +1432,17 @@ encrypted, SSH can be used. Since ZFS only requires the stream to be redirected from standard output, it is relatively easy to pipe it through - SSH. + SSH. If you wish the contents of your + ZFS file system to remain encrypted, + consider using PEFS. =20 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 zfs - send operation. The following settings should - be made: + send operation. The following configuration is + required: =20 @@ -1450,7 +1457,10 @@ that root can only execute zfs recv and nothing else to prevent users that might have hijacked this account from doing - any harm on the system. + any harm on the system. Using the delegation system it is + possible to perform replication without requiring + root access. =20 @@ -1460,8 +1470,8 @@ encrypted stream can be sent using the following commands: =20 - &prompt.root; zfs snapshot -r mypool/ho= me@monday -&prompt.root; zfs send -R mypool/home@monday | ssh backuphost zfs recv -dvu backuppool<= /screen> + &prompt.root; zfs snapshot -r mypool/home= @monday +&prompt.root; zfs send -R mypool/home@monday | ssh backuphost zfs recv -dvu backuppool =20 The first command creates a recursive snapshot (option -r) 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--