2. FreeBSD Doc
  3. books_handbook
  4. Spanish
  5. Translate

Translation

(itstool) path: sect3/para
A second snapshot called <replaceable>replica2</replaceable> was created. This second snapshot contains only the changes that were made to the file system between now and the previous snapshot, <replaceable>replica1</replaceable>. Using <command>zfs send -i</command> and indicating the pair of snapshots generates an incremental replica stream containing only the data that has changed. This can only succeed if the initial snapshot already exists on the receiving side.
0/4710
Context English Spanish State
Keeping data on a single pool in one location exposes it to risks like theft and natural or human disasters. Making regular backups of the entire pool is vital. <acronym>ZFS</acronym> 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. Snapshots are the basis for this replication (see the section on <link linkend="zfs-zfs-snapshot"><acronym>ZFS</acronym> snapshots</link>). The commands used for replicating data are <command>zfs send</command> and <command>zfs receive</command>.
These examples demonstrate <acronym>ZFS</acronym> replication with these two pools:
<prompt>#</prompt> <userinput>zpool list</userinput>
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 960M 77K 896M - - 0% 0% 1.00x ONLINE -
mypool 984M 43.7M 940M - - 0% 4% 1.00x ONLINE -
The pool named <replaceable>mypool</replaceable> is the 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 unavailable. Note that this fail-over is not done automatically by <acronym>ZFS</acronym>, but must be manually done by a system administrator when needed. A snapshot is used to provide a consistent version of the file system to be replicated. Once a snapshot of <replaceable>mypool</replaceable> has been created, it can be copied to the <replaceable>backup</replaceable> pool. Only snapshots can be replicated. Changes made since the most recent snapshot will not be included.
<prompt>#</prompt> <userinput>zfs snapshot <replaceable>mypool</replaceable>@<replaceable>backup1</replaceable></userinput>
<prompt>#</prompt> <userinput>zfs list -t snapshot</userinput>
NAME USED AVAIL REFER MOUNTPOINT
mypool@backup1 0 - 43.6M -
Now that a snapshot exists, <command>zfs send</command> can be used to create a stream representing the contents of the snapshot. This stream can be stored as a file or received by another pool. The stream is written to standard output, but must be redirected to a file or pipe or an error is produced:
<prompt>#</prompt> <userinput>zfs send <replaceable>mypool</replaceable>@<replaceable>backup1</replaceable></userinput>
Error: Stream can not be written to a terminal.
You must redirect standard output.
To back up a dataset with <command>zfs send</command>, redirect to a file located on the mounted backup pool. Ensure that the pool has enough free space to accommodate the size of the snapshot being sent, which means all of the data contained in the snapshot, not just the changes from the previous snapshot.
<prompt>#</prompt> <userinput>zfs send <replaceable>mypool</replaceable>@<replaceable>backup1</replaceable> &gt; <replaceable>/backup/backup1</replaceable></userinput>
<prompt>#</prompt> <userinput>zpool list</userinput>
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 960M 63.7M 896M - - 0% 6% 1.00x ONLINE -
mypool 984M 43.7M 940M - - 0% 4% 1.00x ONLINE -
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 can be done automatically with a <citerefentry><refentrytitle>cron</refentrytitle><manvolnum>8</manvolnum></citerefentry> job.
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, <command>zfs receive</command> is used to transform the streams back into files and directories. 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. 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>#</prompt> <userinput>zfs snapshot <replaceable>mypool</replaceable>@<replaceable>replica1</replaceable></userinput>
<prompt>#</prompt> <userinput>zfs send -v <replaceable>mypool</replaceable>@<replaceable>replica1</replaceable> | zfs receive <replaceable>backup/mypool</replaceable></userinput>
send from @ to mypool@replica1 estimated size is 50.1M
total estimated size is 50.1M
TIME SENT SNAPSHOT

<prompt>#</prompt> <userinput>zpool list</userinput>
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 960M 63.7M 896M - - 0% 6% 1.00x ONLINE -
mypool 984M 43.7M 940M - - 0% 4% 1.00x ONLINE -
Incremental Backups
<command>zfs send</command> can also determine the difference between two snapshots and send only the differences between the two. This saves disk space and transfer time. For example:
<prompt>#</prompt> <userinput>zfs snapshot <replaceable>mypool</replaceable>@<replaceable>replica2</replaceable></userinput>
<prompt>#</prompt> <userinput>zfs list -t snapshot</userinput>
NAME USED AVAIL REFER MOUNTPOINT
mypool@replica1 5.72M - 43.6M -
mypool@replica2 0 - 44.1M -
<prompt>#</prompt> <userinput>zpool list</userinput>
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 960M 61.7M 898M - - 0% 6% 1.00x ONLINE -
mypool 960M 50.2M 910M - - 0% 5% 1.00x ONLINE -
A second snapshot called <replaceable>replica2</replaceable> was created. This second snapshot contains only the changes that were made to the file system between now and the previous snapshot, <replaceable>replica1</replaceable>. Using <command>zfs send -i</command> and indicating the pair of snapshots generates an incremental replica stream containing only the data that has changed. This can only succeed if the initial snapshot already exists on the receiving side.
<prompt>#</prompt> <userinput>zfs send -v -i <replaceable>mypool</replaceable>@<replaceable>replica1</replaceable> <replaceable>mypool</replaceable>@<replaceable>replica2</replaceable> | zfs receive <replaceable>/backup/mypool</replaceable></userinput>
send from @replica1 to mypool@replica2 estimated size is 5.02M
total estimated size is 5.02M
TIME SENT SNAPSHOT

<prompt>#</prompt> <userinput>zpool list</userinput>
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 960M 80.8M 879M - - 0% 8% 1.00x ONLINE -
mypool 960M 50.2M 910M - - 0% 5% 1.00x ONLINE -

<prompt>#</prompt> <userinput>zfs list</userinput>
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>#</prompt> <userinput>zfs list -t snapshot</userinput>
NAME USED AVAIL REFER MOUNTPOINT
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. Only the data that had changed was replicated, rather than the entirety of <replaceable>replica1</replaceable>. Only the differences were sent, which took much less time to transfer and saved 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 must be considered.
A new file system, <replaceable>backup/mypool</replaceable>, is available with all of the files and data from the pool <replaceable>mypool</replaceable>. If <option>-P</option> is specified, the properties of the dataset will be copied, including compression settings, quotas, and mount points. When <option>-R</option> is specified, all child datasets of the indicated dataset will be copied, along with all of their properties. Sending and receiving can be automated so that regular backups are created on the second pool.
Sending Encrypted Backups over <application>SSH</application>
Sending streams over the network is a good way to keep a remote backup, but it does come with a drawback. Data sent over the network link is not encrypted, allowing anyone to intercept and transform the streams back into data without the knowledge of the sending user. This is undesirable, especially when sending the streams over the internet to a remote host. <application>SSH</application> can be used to securely encrypt data send over a network connection. Since <acronym>ZFS</acronym> only requires the stream to be redirected from standard output, it is relatively easy to pipe it through <application>SSH</application>. To keep the contents of the file system encrypted in transit and on the remote system, consider using <link xlink:href="https://wiki.freebsd.org/PEFS">PEFS</link>.
A few settings and security precautions must be completed first. Only the necessary steps required for the <command>zfs send</command> operation are shown here. For more information on <application>SSH</application>, see <xref linkend="openssh"/>.
This configuration is required:
Passwordless <application>SSH</application> access between sending and receiving host using <application>SSH</application> keys
Normally, the privileges of the <systemitem class="username">root</systemitem> user are needed to send and receive streams. This requires logging in to the receiving system as <systemitem class="username">root</systemitem>. However, logging in as <systemitem class="username">root</systemitem> is disabled by default for security reasons. The <link linkend="zfs-zfs-allow">ZFS Delegation</link> system can be used to allow a non-<systemitem class="username">root</systemitem> user on each system to perform the respective send and receive operations.
On the sending system:
<prompt>#</prompt> <userinput>zfs allow -u someuser send,snapshot <replaceable>mypool</replaceable></userinput>
To mount the pool, the unprivileged user must own the directory, and regular users must be allowed to mount file systems. On the receiving system:
<prompt>#</prompt> <userinput>sysctl vfs.usermount=1</userinput>
vfs.usermount: 0 -&gt; 1
<prompt>#</prompt> <userinput>echo vfs.usermount=1 &gt;&gt; /etc/sysctl.conf</userinput>
<prompt>#</prompt> <userinput>zfs create <replaceable>recvpool/backup</replaceable></userinput>
<prompt>#</prompt> <userinput>zfs allow -u <replaceable>someuser</replaceable> create,mount,receive <replaceable>recvpool/backup</replaceable></userinput>
<prompt>#</prompt> <userinput>chown <replaceable>someuser</replaceable> <replaceable>/recvpool/backup</replaceable></userinput>
The unprivileged user now has the ability to receive and mount datasets, and the <replaceable>home</replaceable> dataset can be replicated to the remote system:
<prompt>%</prompt> <userinput>zfs snapshot -r <replaceable>mypool/home</replaceable>@<replaceable>monday</replaceable></userinput>
<prompt>%</prompt> <userinput>zfs send -R <replaceable>mypool/home</replaceable>@<replaceable>monday</replaceable> | ssh <replaceable>someuser@backuphost</replaceable> zfs recv -dvu <replaceable>recvpool/backup</replaceable></userinput>

Loading…

User avatar None

New source string

FreeBSD Doc / books_handbook — Spanish

New source string a year ago
Browse all component changes

Glossary

English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Source string location
book.translate.xml:41879
String age
a year ago
Source string age
a year ago
Translation file
books/es_ES/handbook.po, string 6881