FreeBSD Doc (Archived)/books_handbook — Spanish @ Weblate: ZFS provides a built-in command to compare the differences in …

The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

Content

Source string comment (itstool) path: sect3/para

English

ZFS provides a built-in command to compare the differences in content between two snapshots. This is helpful when many snapshots were taken over time and the user wants to see how the file system has changed over time. For example, <command>zfs diff</command> lets a user find the latest snapshot that still contains a file that was accidentally deleted. Doing this for the two snapshots that were created in the previous section yields this output:

Spanish

Needs editing

Context	English	Spanish	State
	<prompt>#</prompt> <userinput> zfs set sharenfs="-alldirs,-maproot=<replaceable>root</replaceable>,-network=<replaceable>192.168.1.0/24</replaceable>" <replaceable>mypool/usr/home</replaceable></userinput>
	Managing Snapshots
	<link linkend="zfs-term-snapshot">Snapshots</link> are one of the most powerful features of <acronym>ZFS</acronym>. A snapshot provides a read-only, point-in-time copy of the dataset. With Copy-On-Write (<acronym>COW</acronym>), snapshots can be created quickly by preserving the older version of the data on disk. If no snapshots exist, space is reclaimed for future use when data is rewritten or deleted. Snapshots preserve disk space by recording only the differences between the current dataset and a previous version. Snapshots are allowed only on whole datasets, not on individual files or directories. When a snapshot is created from a dataset, everything contained in it is duplicated. This includes the file system properties, files, directories, permissions, and so on. Snapshots use no additional space when they are first created, only consuming space as the blocks they reference are changed. Recursive snapshots taken with <option>-r</option> create a snapshot with the same name on the dataset and all of its children, providing a consistent moment-in-time snapshot of all of the file systems. This can be important when an application has files on multiple datasets that are related or dependent upon each other. Without snapshots, a backup would have copies of the files from different points in time.
	Snapshots in <acronym>ZFS</acronym> provide a variety of features that even other file systems with snapshot functionality lack. A typical example of snapshot use is to have a quick way of backing up the current state of the file system when a risky action like a software installation or a system upgrade is performed. If the action fails, the snapshot can be rolled back and the system has the same state as when the snapshot was created. If the upgrade was successful, the snapshot can be deleted to free up space. Without snapshots, a failed upgrade often requires a restore from backup, which is tedious, time consuming, and may require downtime during which the system cannot be used. Snapshots can be rolled back quickly, even while the system is running in normal operation, with little or no downtime. The time savings are enormous with multi-terabyte storage systems and the time required to copy the data from backup. Snapshots are not a replacement for a complete backup of a pool, but can be used as a quick and easy way to store a copy of the dataset at a specific point in time.
	Creating Snapshots
	Snapshots are created with <command>zfs snapshot <replaceable>dataset</replaceable>@<replaceable>snapshotname</replaceable></command>. Adding <option>-r</option> creates a snapshot recursively, with the same name on all child datasets.
	Create a recursive snapshot of the entire pool:
	<prompt>#</prompt> <userinput>zfs list -t all</userinput> NAME USED AVAIL REFER MOUNTPOINT mypool 780M 93.2G 144K none mypool/ROOT 777M 93.2G 144K none mypool/ROOT/default 777M 93.2G 777M / mypool/tmp 176K 93.2G 176K /tmp mypool/usr 616K 93.2G 144K /usr mypool/usr/home 184K 93.2G 184K /usr/home mypool/usr/ports 144K 93.2G 144K /usr/ports mypool/usr/src 144K 93.2G 144K /usr/src mypool/var 1.29M 93.2G 616K /var mypool/var/crash 148K 93.2G 148K /var/crash mypool/var/log 178K 93.2G 178K /var/log mypool/var/mail 144K 93.2G 144K /var/mail mypool/var/newname 87.5K 93.2G 87.5K /var/newname mypool/var/newname@new_snapshot_name 0 - 87.5K - mypool/var/tmp 152K 93.2G 152K /var/tmp <prompt>#</prompt> <userinput>zfs snapshot -r <replaceable>mypool@my_recursive_snapshot</replaceable></userinput> <prompt>#</prompt> <userinput>zfs list -t snapshot</userinput> NAME USED AVAIL REFER MOUNTPOINT mypool@my_recursive_snapshot 0 - 144K - mypool/ROOT@my_recursive_snapshot 0 - 144K - mypool/ROOT/default@my_recursive_snapshot 0 - 777M - mypool/tmp@my_recursive_snapshot 0 - 176K - mypool/usr@my_recursive_snapshot 0 - 144K - mypool/usr/home@my_recursive_snapshot 0 - 184K - mypool/usr/ports@my_recursive_snapshot 0 - 144K - mypool/usr/src@my_recursive_snapshot 0 - 144K - mypool/var@my_recursive_snapshot 0 - 616K - mypool/var/crash@my_recursive_snapshot 0 - 148K - mypool/var/log@my_recursive_snapshot 0 - 178K - mypool/var/mail@my_recursive_snapshot 0 - 144K - mypool/var/newname@new_snapshot_name 0 - 87.5K - mypool/var/newname@my_recursive_snapshot 0 - 87.5K - mypool/var/tmp@my_recursive_snapshot 0 - 152K -
	Snapshots are not shown by a normal <command>zfs list</command> operation. To list snapshots, <option>-t snapshot</option> is appended to <command>zfs list</command>. <option>-t all</option> displays both file systems and snapshots.
	Snapshots are not mounted directly, so no path is shown in the <literal>MOUNTPOINT</literal> column. There is no mention of available disk space in the <literal>AVAIL</literal> column, as snapshots cannot be written to after they are created. Compare the snapshot to the original dataset from which it was created:
	<prompt>#</prompt> <userinput>zfs list -rt all <replaceable>mypool/usr/home</replaceable></userinput> NAME USED AVAIL REFER MOUNTPOINT mypool/usr/home 184K 93.2G 184K /usr/home mypool/usr/home@my_recursive_snapshot 0 - 184K -
	Displaying both the dataset and the snapshot together reveals how snapshots work in <link linkend="zfs-term-cow">COW</link> fashion. They save only the changes (<emphasis>delta</emphasis>) that were made and not the complete file system contents all over again. This means that snapshots take little space when few changes are made. Space usage can be made even more apparent by copying a file to the dataset, then making a second snapshot:
	<prompt>#</prompt> <userinput>cp <replaceable>/etc/passwd</replaceable> <replaceable>/var/tmp</replaceable></userinput> <prompt>#</prompt> <userinput>zfs snapshot <replaceable>mypool/var/tmp</replaceable>@<replaceable>after_cp</replaceable></userinput> <prompt>#</prompt> <userinput>zfs list -rt all <replaceable>mypool/var/tmp</replaceable></userinput> NAME USED AVAIL REFER MOUNTPOINT mypool/var/tmp 206K 93.2G 118K /var/tmp mypool/var/tmp@my_recursive_snapshot 88K - 152K - mypool/var/tmp@after_cp 0 - 118K -
	The second snapshot contains only the changes to the dataset after the copy operation. This yields enormous space savings. Notice that the size of the snapshot <replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable> also changed in the <literal>USED</literal> column to indicate the changes between itself and the snapshot taken afterwards.
	Comparing Snapshots
	ZFS provides a built-in command to compare the differences in content between two snapshots. This is helpful when many snapshots were taken over time and the user wants to see how the file system has changed over time. For example, <command>zfs diff</command> lets a user find the latest snapshot that still contains a file that was accidentally deleted. Doing this for the two snapshots that were created in the previous section yields this output:
	<prompt>#</prompt> <userinput>zfs list -rt all <replaceable>mypool/var/tmp</replaceable></userinput> NAME USED AVAIL REFER MOUNTPOINT mypool/var/tmp 206K 93.2G 118K /var/tmp mypool/var/tmp@my_recursive_snapshot 88K - 152K - mypool/var/tmp@after_cp 0 - 118K - <prompt>#</prompt> <userinput>zfs diff <replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable></userinput> M /var/tmp/ + /var/tmp/passwd
	The command lists the changes between the specified snapshot (in this case <literal><replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable></literal>) and the live file system. The first column shows the type of change:
	The path or file was added.
	The path or file was deleted.
	M
	The path or file was modified.
	R
	The path or file was renamed.
	Comparing the output with the table, it becomes clear that <filename><replaceable>passwd</replaceable></filename> was added after the snapshot <literal><replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable></literal> was created. This also resulted in a modification to the parent directory mounted at <literal><replaceable>/var/tmp</replaceable></literal>.
	Comparing two snapshots is helpful when using the <acronym>ZFS</acronym> replication feature to transfer a dataset to a different host for backup purposes.
	Compare two snapshots by providing the full dataset name and snapshot name of both datasets:
	<prompt>#</prompt> <userinput>cp /var/tmp/passwd /var/tmp/passwd.copy</userinput> <prompt>#</prompt> <userinput>zfs snapshot <replaceable>mypool/var/tmp@diff_snapshot</replaceable></userinput> <prompt>#</prompt> <userinput>zfs diff <replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable> <replaceable>mypool/var/tmp@diff_snapshot</replaceable></userinput> M /var/tmp/ + /var/tmp/passwd + /var/tmp/passwd.copy <prompt>#</prompt> <userinput>zfs diff <replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable> <replaceable>mypool/var/tmp@after_cp</replaceable></userinput> M /var/tmp/ + /var/tmp/passwd
	A backup administrator can compare two snapshots received from the sending host and determine the actual changes in the dataset. See the <link linkend="zfs-zfs-send">Replication</link> section for more information.
	Snapshot Rollback
	When at least one snapshot is available, it can be rolled back to at any time. Most of the time this is the case when the current state of the dataset is no longer required and an older version is preferred. Scenarios such as local development tests have gone wrong, botched system updates hampering the system's overall functionality, or the requirement to restore accidentally deleted files or directories are all too common occurrences. Luckily, rolling back a snapshot is just as easy as typing <command>zfs rollback <replaceable>snapshotname</replaceable></command>. Depending on how many changes are involved, the operation will finish in a certain amount of time. During that time, the dataset always remains in a consistent state, much like a database that conforms to ACID principles is performing a rollback. This is happening while the dataset is live and accessible without requiring a downtime. Once the snapshot has been rolled back, the dataset has the same state as it had when the snapshot was originally taken. All other data in that dataset that was not part of the snapshot is discarded. Taking a snapshot of the current state of the dataset before rolling back to a previous one is a good idea when some data is required later. This way, the user can roll back and forth between snapshots without losing data that is still valuable.

Loading…

None

New source string

FreeBSD Doc (Archived) / 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:41404

String age

a year ago

Source string age

a year ago

Translation file

books/es_ES/handbook.po, string 6819