From owner-svn-doc-projects@FreeBSD.ORG Fri Jan 31 20:55:49 2014 Return-Path: Delivered-To: svn-doc-projects@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 3368F83E; Fri, 31 Jan 2014 20:55:49 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E440185F; Fri, 31 Jan 2014 20:55:49 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id s0VKtm1c097840; Fri, 31 Jan 2014 20:55:48 GMT (envelope-from bcr@svn.freebsd.org) Received: (from bcr@localhost) by svn.freebsd.org (8.14.7/8.14.7/Submit) id s0VKtmDb097839; Fri, 31 Jan 2014 20:55:48 GMT (envelope-from bcr@svn.freebsd.org) Message-Id: <201401312055.s0VKtmDb097839@svn.freebsd.org> From: Benedict Reuschling Date: Fri, 31 Jan 2014 20:55:48 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r43709 - projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs X-SVN-Group: doc-projects MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 20:55:49 -0000 Author: bcr Date: Fri Jan 31 20:55:48 2014 New Revision: 43709 URL: http://svnweb.freebsd.org/changeset/doc/43709 Log: Minor corrections and wording fixes. The section on zfs send over SSH needs to be more clear about what exactly needs to happen on each system for this to work. This will be done in a separate commit. Submitted by: bjk@ Modified: projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml Modified: projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml ============================================================================== --- projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml Fri Jan 31 18:43:29 2014 (r43708) +++ projects/zfsupdate-201307/en_US.ISO8859-1/books/handbook/zfs/chapter.xml Fri Jan 31 20:55:48 2014 (r43709) @@ -1251,16 +1251,16 @@ tank custom:costcenter - ZFS Replication Keeping the data on a single pool in one location exposes - it to risks like theft, natural and human desasters. Keeping + 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 that can send a stream representation of the data to standard output. Using this technique, it is possible to not only store the data on another pool connected to the local system, but also to send it over a network to another system that runs - ZFS. To achieve this replication, ZFS uses the filesystem + ZFS. To achieve this replication, ZFS uses filesystem snapshots (see the section on ZFS snapshots on how they + linkend="zfs-zfs-snapshot">ZFS snapshots for how they work) to send them from one location to another. The commands for this operation are zfs send and zfs receive, respectively. @@ -1280,7 +1280,7 @@ mypool 984M 43.7M 940M 4% 1.00x the primary pool becomes offline. 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 - created on mypool to have a backup + created on mypool to have a copy of the current state of the data to send to the pool backup. @@ -1291,7 +1291,7 @@ mypool@backup1 0 - 43. Now that a snapshot exists, zfs send can be used to create a stream representing the contents of - the snapshot locally or remote to another pool. The stream + the snapshot locally or remotely to another pool. The stream must be written to the standard output, otherwise ZFS will produce an error like in this example: @@ -1324,7 +1324,7 @@ mypool 984M 43.7M 940M 4% 1.00x 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. - The following example demonstrates this: + For example: &prompt.root; zfs snapshot mypool@backup2 &prompt.root; zfs list -t snapshot @@ -1455,9 +1455,10 @@ mypool 50.0M 878M 44. After these security measures have been put into place - and root can connect passwordless via SSH - to the receiving system, the encrypted stream can be sent - using the following commands: + and root can connect via passwordless via + SSH to the receiving system, the + encrypted stream can be sent using the following + commands: &prompt.root; zfs snapshot -r mypool/home@monday &prompt.root; zfs send -R mypool/home@monday | ssh backuphost zfs recv -dvu backuppool