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

Translation

(itstool) path: sect3/para
English
The rollback operation restored the dataset to the state of the last snapshot. It is also possible to roll back to a snapshot that was taken much earlier and has other snapshots that were created after it. When trying to do this, <acronym>ZFS</acronym> will issue this warning:
0/2770 · 277
Context English Spanish State
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.
In the first example, a snapshot is rolled back because of a careless <command>rm</command> operation that removes too much data than was intended.
<prompt>#</prompt> <userinput>zfs list -rt all <replaceable>mypool/var/tmp</replaceable></userinput>
NAME USED AVAIL REFER MOUNTPOINT
mypool/var/tmp 262K 93.2G 120K /var/tmp
mypool/var/tmp@my_recursive_snapshot 88K - 152K -
mypool/var/tmp@after_cp 53.5K - 118K -
mypool/var/tmp@diff_snapshot 0 - 120K -
<prompt>#</prompt> <userinput>ls /var/tmp</userinput>
passwd passwd.copy vi.recover
<prompt>#</prompt> <userinput>rm /var/tmp/passwd*</userinput>
<prompt>#</prompt> <userinput>ls /var/tmp</userinput>
vi.recover
At this point, the user realized that too many files were deleted and wants them back. <acronym>ZFS</acronym> provides an easy way to get them back using rollbacks, but only when snapshots of important data are performed on a regular basis. To get the files back and start over from the last snapshot, issue the command:
<prompt>#</prompt> <userinput>zfs rollback <replaceable>mypool/var/tmp@diff_snapshot</replaceable></userinput>
<prompt>#</prompt> <userinput>ls /var/tmp</userinput>
passwd passwd.copy vi.recover
The rollback operation restored the dataset to the state of the last snapshot. It is also possible to roll back to a snapshot that was taken much earlier and has other snapshots that were created after it. When trying to do this, <acronym>ZFS</acronym> will issue this warning:
<prompt>#</prompt> <userinput>zfs list -rt snapshot <replaceable>mypool/var/tmp</replaceable></userinput>
AME USED AVAIL REFER MOUNTPOINT
mypool/var/tmp@my_recursive_snapshot 88K - 152K -
mypool/var/tmp@after_cp 53.5K - 118K -
mypool/var/tmp@diff_snapshot 0 - 120K -
<prompt>#</prompt> <userinput>zfs rollback <replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable></userinput>
cannot rollback to 'mypool/var/tmp@my_recursive_snapshot': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
mypool/var/tmp@after_cp
mypool/var/tmp@diff_snapshot
This warning means that snapshots exist between the current state of the dataset and the snapshot to which the user wants to roll back. To complete the rollback, these snapshots must be deleted. <acronym>ZFS</acronym> cannot track all the changes between different states of the dataset, because snapshots are read-only. <acronym>ZFS</acronym> will not delete the affected snapshots unless the user specifies <option>-r</option> to indicate that this is the desired action. If that is the intention, and the consequences of losing all intermediate snapshots is understood, the command can be issued:
<prompt>#</prompt> <userinput>zfs rollback -r <replaceable>mypool/var/tmp@my_recursive_snapshot</replaceable></userinput>
<prompt>#</prompt> <userinput>zfs list -rt snapshot <replaceable>mypool/var/tmp</replaceable></userinput>
NAME USED AVAIL REFER MOUNTPOINT
mypool/var/tmp@my_recursive_snapshot 8K - 152K -
<prompt>#</prompt> <userinput>ls /var/tmp</userinput>
vi.recover
The output from <command>zfs list -t snapshot</command> confirms that the intermediate snapshots were removed as a result of <command>zfs rollback -r</command>.
Restoring Individual Files from Snapshots
Snapshots are mounted in a hidden directory under the parent dataset: <filename>.zfs/snapshots/<replaceable>snapshotname</replaceable></filename>. By default, these directories will not be displayed even when a standard <command>ls -a</command> is issued. Although the directory is not displayed, it is there nevertheless and can be accessed like any normal directory. The property named <literal>snapdir</literal> controls whether these hidden directories show up in a directory listing. Setting the property to <literal>visible</literal> allows them to appear in the output of <command>ls</command> and other commands that deal with directory contents.
<prompt>#</prompt> <userinput>zfs get snapdir <replaceable>mypool/var/tmp</replaceable></userinput>
NAME PROPERTY VALUE SOURCE
mypool/var/tmp snapdir hidden default
<prompt>#</prompt> <userinput>ls -a /var/tmp</userinput>
. .. passwd vi.recover
<prompt>#</prompt> <userinput>zfs set snapdir=visible <replaceable>mypool/var/tmp</replaceable></userinput>
<prompt>#</prompt> <userinput>ls -a /var/tmp</userinput>
. .. .zfs passwd vi.recover
Individual files can easily be restored to a previous state by copying them from the snapshot back to the parent dataset. The directory structure below <filename>.zfs/snapshot</filename> has a directory named exactly like the snapshots taken earlier to make it easier to identify them. In the next example, it is assumed that a file is to be restored from the hidden <filename>.zfs</filename> directory by copying it from the snapshot that contained the latest version of the file:
<prompt>#</prompt> <userinput>rm /var/tmp/passwd</userinput>
<prompt>#</prompt> <userinput>ls -a /var/tmp</userinput>
. .. .zfs vi.recover
<prompt>#</prompt> <userinput>ls /var/tmp/.zfs/snapshot</userinput>
after_cp my_recursive_snapshot
<prompt>#</prompt> <userinput>ls /var/tmp/.zfs/snapshot/<replaceable>after_cp</replaceable></userinput>
passwd vi.recover
<prompt>#</prompt> <userinput>cp /var/tmp/.zfs/snapshot/<replaceable>after_cp/passwd</replaceable> <replaceable>/var/tmp</replaceable></userinput>
When <command>ls .zfs/snapshot</command> was issued, the <literal>snapdir</literal> property might have been set to hidden, but it would still be possible to list the contents of that directory. It is up to the administrator to decide whether these directories will be displayed. It is possible to display these for certain datasets and prevent it for others. Copying files or directories from this hidden <filename>.zfs/snapshot</filename> is simple enough. Trying it the other way around results in this error:
<prompt>#</prompt> <userinput>cp <replaceable>/etc/rc.conf</replaceable> /var/tmp/.zfs/snapshot/<replaceable>after_cp/</replaceable></userinput>
cp: /var/tmp/.zfs/snapshot/after_cp/rc.conf: Read-only file system
The error reminds the user that snapshots are read-only and cannot be changed after creation. Files cannot be copied into or removed from snapshot directories because that would change the state of the dataset they represent.
Snapshots consume space based on how much the parent file system has changed since the time of the snapshot. The <literal>written</literal> property of a snapshot tracks how much space is being used by the snapshot.
Snapshots are destroyed and the space reclaimed with <command>zfs destroy <replaceable>dataset</replaceable>@<replaceable>snapshot</replaceable></command>. Adding <option>-r</option> recursively removes all snapshots with the same name under the parent dataset. Adding <option>-n -v</option> to the command displays a list of the snapshots that would be deleted and an estimate of how much space would be reclaimed without performing the actual destroy operation.
Managing Clones

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:41543
String age
a year ago
Source string age
a year ago
Translation file
books/es_ES/handbook.po, string 6839