Skip to Content
Last modified by Drunk Monkey on 2024-09-01 11:57
Show last authors
1 Snapshots with ZFS are similar to snapshots with Linux LVM. A snapshot is a first class read-only filesystem. It is a mirrored copy of the state of the filesystem at the time you took the snapshot. Think of it like a digital photograph of the outside world. Even though the world is changing, you have an image of what the world was like at the exact moment you took that photograph. Snapshots behave in a similar manner, except when data changes that was part of the dataset, you keep the original copy in the snapshot itself. This way, you can maintain persistence of that filesystem.
2
3 You can keep up to 2^64 snapshots in your pool, ZFS snapshots are persistent across reboots, and they don't require any additional backing store; they use the same storage pool as the rest of your data. If you remember our post about the nature of copy-on-write filesystems, you will remember our discussion about Merkle trees. A ZFS snapshot is a copy of the Merkle tree in that state, except we make sure that the snapshot of that Merkle tree is never modified.
4
5 Creating snapshots is near instantaneous, and they are cheap. However, once the data begins to change, the snapshot will begin storing data. If you have multiple snapshots, then multiple deltas will be tracked across all the snapshots. However, depending on your needs, snapshots can still be exceptionally cheap.
6
7 == Creating Snapshots ==
8
9 You can create two types of snapshots: pool snapshots and dataset snapshots. Which type of snapshot you want to take is up to you. You must give the snapshot a name, however. The syntax for the snapshot name is:
10
11 * //pool/dataset@snapshot-name//
12 * //pool@snapshot-name//
13
14 To create a snapshot, we use the "zfs snapshot" command. For example, to take a snapshot of the "tank/test" dataset, we would issue:
15
16 {{code language="bash session"}}# zfs snapshot tank/test@tuesday{{/code}}
17
18 Even though a snapshot is a first class filesystem, it does not contain modifiable properties like standard ZFS datasets or pools. In fact, everything about a snapshot is read-only. For example, if you wished to enable compression on a snapshot, here is what would happen:
19
20 {{code language="bash session"}}# zfs set compression=lzjb tank/test@friday
21 cannot set property for 'tank/test@friday': this property can not be modified for snapshots{{/code}}
22
23 == Listing Snapshots ==
24
25 Snapshots can be displayed two ways: by accessing a hidden ".zfs" directory in the root of the dataset, or by using the "zfs list" command. First, let's discuss the hidden directory. Check out this madness:
26
27 {{code language="bash session"}}# ls -a /tank/test
28 ./ ../ boot.tar text.tar text.tar.2
29 # cd /tank/test/.zfs/
30 # ls -a
31 ./ ../ shares/ snapshot/{{/code}}
32
33 Even though the ".zfs" directory was not visible, even with "ls -a", we could still change directory to it. If you wish to have the ".zfs" directory visible, you can change the "snapdir" property on the dataset. The valid values are "hidden" and "visible". By default, it's hidden. Let's change it:
34
35 {{code language="bash session"}}# zfs set snapdir=visible tank/test
36 # ls -a /tank/test
37 ./ ../ boot.tar text.tar text.tar.2 .zfs/{{/code}}
38
39 The other way to display snapshots is by using the "zfs list" command, and passing the "-t snapshot" argument, as follows:
40
41 {{code language="bash session"}}# zfs list -t snapshot
42 NAME USED AVAIL REFER MOUNTPOINT
43 pool/cache@2012:12:18:51:2:19:00 0 - 525M -
44 pool/cache@2012:12:18:51:2:19:15 0 - 525M -
45 pool/home@2012:12:18:51:2:19:00 18.8M - 28.6G -
46 pool/home@2012:12:18:51:2:19:15 18.3M - 28.6G -
47 pool/log@2012:12:18:51:2:19:00 184K - 10.4M -
48 pool/log@2012:12:18:51:2:19:15 184K - 10.4M -
49 pool/swap@2012:12:18:51:2:19:00 0 - 76K -
50 pool/swap@2012:12:18:51:2:19:15 0 - 76K -
51 pool/vmsa@2012:12:18:51:2:19:00 0 - 1.12M -
52 pool/vmsa@2012:12:18:51:2:19:15 0 - 1.12M -
53 pool/vmsb@2012:12:18:51:2:19:00 0 - 1.31M -
54 pool/vmsb@2012:12:18:51:2:19:15 0 - 1.31M -
55 tank@2012:12:18:51:2:19:00 0 - 43.4K -
56 tank@2012:12:18:51:2:19:15 0 - 43.4K -
57 tank/test@2012:12:18:51:2:19:00 0 - 37.1M -
58 tank/test@2012:12:18:51:2:19:15 0 - 37.1M -{{/code}}
59
60 Notice that by default, it will show all snapshots for all pools.
61
62 If you want to be more specific with the output, you can see all snapshots of a given parent, whether it be a dataset, or a storage pool. You only need to pass the "-r" switch for recursion, then provide the parent. In this case, I'll see only the snapshots of the storage pool "tank", and ignore those in "pool":
63
64 {{code language="bash session"}}# zfs list -r -t snapshot tank
65 NAME USED AVAIL REFER MOUNTPOINT
66 tank@2012:12:18:51:2:19:00 0 - 43.4K -
67 tank@2012:12:18:51:2:19:15 0 - 43.4K -
68 tank/test@2012:12:18:51:2:19:00 0 - 37.1M -
69 tank/test@2012:12:18:51:2:19:15 0 - 37.1M -{{/code}}
70
71 == Destroying Snapshots ==
72
73 Just as you would destroy a storage pool, or a ZFS dataset, you use a similar method for destroying snapshots. To destroy a snapshot, use the "zfs destroy" command, and supply the snapshot as an argument that you want to destroy:
74
75 {{code language="bash session"}}# zfs destroy tank/test@2012:12:18:51:2:19:15{{/code}}
76
77 An important thing to know, is if a snapshot exists, it's considered a child filesystem to the dataset. As such, you cannot remove a dataset until all snapshots, and nested datasets have been destroyed.
78
79 {{code language="bash session"}}# zfs destroy tank/test
80 cannot destroy 'tank/test': filesystem has children
81 use '-r' to destroy the following datasets:
82 tank/test@2012:12:18:51:2:19:15
83 tank/test@2012:12:18:51:2:19:00{{/code}}
84
85 Destroying snapshots can free up additional space that other snapshots may be holding onto, because they are unique to those snapshots.
86
87 == Renaming Snapshots ==
88
89 You can rename snapshots, however, they must be renamed in the storage pool and ZFS dataset from which they were created. Other than that, renaming snapshots is pretty straight forward:
90
91 {{code language="bash session"}}# zfs rename tank/test@2012:12:18:51:2:19:15 tank/test@tuesday-19:15{{{/code}}
92
93 == Rolling Back to a Snapshot ==
94
95 A discussion about snapshots would not be complete without a discussion about rolling back your filesystem to a previous snapshot.
96
97 Rolling back to a previous snapshot will discard any data changes between that snapshot and the current time. Further, by default, you can only rollback to the most recent snapshot. In order to rollback to an earlier snapshot, you must destroy all snapshots between the current time and that snapshot you wish to rollback to. If that's not enough, the filesystem must be unmounted before the rollback can begin. This means downtime.
98
99 To rollback the "tank/test" dataset to the "tuesday" snapshot, we would issue:
100
101 {{code language="bash session"}}# zfs rollback tank/test@tuesday
102 cannot rollback to 'tank/test@tuesday': more recent snapshots exist
103 use '-r' to force deletion of the following snapshots:
104 tank/test@wednesday
105 tank/test@thursday{{/code}}
106
107 As expected, we must remove the "@wednesday" and "@thursday" snapshots before we can rollback to the "@tuesday" snapshot.
108
109 == ZFS Clones ==
110
111 A ZFS clone is a writeable filesystem that was "upgraded" from a snapshot. Clones can only be created from snapshots, and a dependency on the snapshot will remain as long as the clone exists. This means that you cannot destroy a snapshot, if you cloned it. The clone relies on the data that the snapshot gives it, to exist. You must destroy the clone before you can destroy the snapshot.
112
113 Creating clones is nearly instantaneous, just like snapshots, and initially does not take up any additional space. Instead, it occupies all the initial space of the snapshot. As data is modified in the clone, it begins to take up space separate from the snapshot.
114
115 == Creating ZFS Clones ==
116
117 Creating a clone is done with the "zfs clone" command, the snapshot to clone, and the name of the new filesystem. The clone does not need to reside in the same dataset as the clone, but it does need to reside in the same storage pool. For example, if I wanted to clone the "tank/test@tuesday" snapshot, and give it the name of "tank/tuesday", I would run the following command:
118
119 {{code language="bash session"}}# zfs clone tank/test@tuesday tank/tuesday
120 # dd if=/dev/zero of=/tank/tuesday/random.img bs=1M count=100
121 # zfs list -r tank
122 NAME USED AVAIL REFER MOUNTPOINT
123 tank 161M 2.78G 44.9K /tank
124 tank/test 37.1M 2.78G 37.1M /tank/test
125 tank/tuesday 124M 2.78G 161M /tank/tuesday{{/code}}
126
127 == Destroying Clones ==
128
129 As with destroying datasets or snapshots, we use the "zfs destroy" command. Again, you cannot destroy a snapshot until you destroy the clones. So, if we wanted to destroy the "tank/tuesday" clone:
130
131 {{code language="bash session"}}# zfs destroy tank/tuesday{{/code}}
132
133 Just like you would with any other ZFS dataset.
134
135 == Some Final Thoughts ==
136
137 Because keeping snapshots is very cheap, it's recommended to snapshot your datasets frequently. Sun Microsystems provided a Time Slider that was part of the GNOME Nautilus file manager. Time Slider keeps snapshots in the following manner:
138
139 * frequent- snapshots every 15 mins, keeping 4 snapshots
140 * hourly- snapshots every hour, keeping 24 snapshots
141 * daily- snapshots every day, keeping 31 snapshots
142 * weekly- snapshots every week, keeping 7 snapshots
143 * monthly- snapshots every month, keeping 12 snapshots
144
145 Unfortunately, Time Slider is not part of the standard GNOME desktop, so it's not available for GNU/Linux. However, the ZFS on Linux developers have created a "zfs-auto-snapshot" package that you can install from the [[project's PPA>>url:https://web.archive.org/web/20210430213453/https://launchpad.net/~~zfs-native/+archive/stable]] if running Ubuntu. If running another GNU/Linux operating system, you could easily write a Bash or Python script that mimics that functionality, and place it on your root's crontab.
146
147 Because both snapshots and clones are cheap, it's recommended that you take advantage of them. Clones can be useful to test deploying virtual machines, or development environments that are cloned from production environments. When finished, they can easily be destroyed, without affecting the parent dataset from which the snapshot was created.
148
149
150 ----
151
152 (% style="text-align: center;" %)
153 Posted by Aaron Toponce on Wednesday, December 19, 2012, at 6:00 am.
154 Filed under [[Debian>>url:https://web.archive.org/web/20210430213453/https://pthree.org/category/debian/]], [[Linux>>url:https://web.archive.org/web/20210430213453/https://pthree.org/category/linux/]], [[Ubuntu>>url:https://web.archive.org/web/20210430213453/https://pthree.org/category/ubuntu/]], [[ZFS>>url:https://web.archive.org/web/20210430213453/https://pthree.org/category/zfs/]].
155 Follow any responses to this post with its [[comments RSS>>url:https://web.archive.org/web/20210430213453/https://pthree.org/2012/12/19/zfs-administration-part-xii-snapshots-and-clones/feed/]] feed.
156 You can [[post a comment>>url:https://web.archive.org/web/20210430213453/https://pthree.org/2012/12/19/zfs-administration-part-xii-snapshots-and-clones/#respond]] or [[trackback>>url:https://web.archive.org/web/20210430213453/https://pthree.org/2012/12/19/zfs-administration-part-xii-snapshots-and-clones/trackback/]] from your blog.
157 For IM, Email or Microblogs, here is the [[Shortlink>>url:https://web.archive.org/web/20210430213453/https://pthree.org/?p=2900]].
158
159 ----
160
161 {{box title="**Archived From:**"}}
162 [[https:~~/~~/web.archive.org/web/20210430213453/https:~~/~~/pthree.org/2012/12/19/zfs-administration-part-xii-snapshots-and-clones/>>https://web.archive.org/web/20210430213453/https://pthree.org/2012/12/19/zfs-administration-part-xii-snapshots-and-clones/]]
163 {{/box}}