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

Translation

(itstool) path: sect3/para
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"/>.
0/2470
Context English Spanish State
<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>
A recursive snapshot called <replaceable>monday</replaceable> is made of the file system dataset <replaceable>home</replaceable> that resides on the pool <replaceable>mypool</replaceable>. Then it is sent with <command>zfs send -R</command> to include the dataset, all child datasets, snapshots, clones, and settings in the stream. The output is piped to the waiting <command>zfs receive</command> on the remote host <replaceable>backuphost</replaceable> through <application>SSH</application>. Using a fully qualified domain name or IP address is recommended. The receiving machine writes the data to the <replaceable>backup</replaceable> dataset on the <replaceable>recvpool</replaceable> pool. Adding <option>-d</option> to <command>zfs recv</command> overwrites the name of the pool on the receiving side with the name of the snapshot. <option>-u</option> causes the file systems to not be mounted on the receiving side. When <option>-v</option> is included, more detail about the transfer is shown, including elapsed time and the amount of data transferred.
Dataset, User, and Group Quotas
<link linkend="zfs-term-quota">Dataset quotas</link> are used to restrict the amount of space that can be consumed by a particular dataset. <link linkend="zfs-term-refquota">Reference Quotas</link> work in very much the same way, but only count the space used by the dataset itself, excluding snapshots and child datasets. Similarly, <link linkend="zfs-term-userquota">user</link> and <link linkend="zfs-term-groupquota">group</link> quotas can be used to prevent users or groups from using all of the space in the pool or dataset.
The following examples assume that the users already exist in the system. Before adding a user to the system, make sure to create their home dataset first and set the <option>mountpoint</option> to <literal>/home/<replaceable>bob</replaceable></literal>. Then, create the user and make the home directory point to the dataset's <option>mountpoint</option> location. This will properly set owner and group permissions without shadowing any pre-existing home directory paths that might exist.
To enforce a dataset quota of 10 GB for <filename>storage/home/bob</filename>:
<prompt>#</prompt> <userinput>zfs set quota=10G storage/home/bob</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:41952
String age
a year ago
Source string age
a year ago
Translation file
books/es_ES/handbook.po, string 6887