Difference between revisions of "Zfs snapshots"

From Asenjo
Jump to: navigation, search
(Delegating zfs permissions)
 
Line 7: Line 7:
 
== View Existing Snapshots ==
 
== View Existing Snapshots ==
  
<code><pre>
+
<pre>
 
# zfs list -t snapshot
 
# zfs list -t snapshot
  
Line 14: Line 14:
 
rpool/ROOT/solaris@install  32.8M      -  3.34G  -
 
rpool/ROOT/solaris@install  32.8M      -  3.34G  -
  
</pre></code>
+
</pre>
  
 
== Create Snapshots ==
 
== Create Snapshots ==
  
 
The most basic snapshot can simply be created by specifying the below command.
 
The most basic snapshot can simply be created by specifying the below command.
<code><pre>
+
<pre>
 
# zfs snapshot tank/testdata/finance@today
 
# zfs snapshot tank/testdata/finance@today
</pre></code>
+
</pre>
 
Now obviously their are “administrative” problems with the above command (most notably the fact that we are naming it “today” after all it won’t be today’s snap if we wait until tomorrow).  So it would be far more correct to name it by the actual date, however I can’t be bothered to remember the date, and frankly I don’t have to.  The below variation will use the output of the date +%m%d%Y command to generate the name of the snapshot, this will give us the ability to have the snapshot be named “03152011″ instead of “today”.
 
Now obviously their are “administrative” problems with the above command (most notably the fact that we are naming it “today” after all it won’t be today’s snap if we wait until tomorrow).  So it would be far more correct to name it by the actual date, however I can’t be bothered to remember the date, and frankly I don’t have to.  The below variation will use the output of the date +%m%d%Y command to generate the name of the snapshot, this will give us the ability to have the snapshot be named “03152011″ instead of “today”.
  
<code><pre>
+
<pre>
 
# zfs snapshot tank/testdata/finance@`date +%m%d%Y`
 
# zfs snapshot tank/testdata/finance@`date +%m%d%Y`
</pre></code>
+
</pre>
 
Remember to look at your snapshots to ensure they are being named as you expect.
 
Remember to look at your snapshots to ensure they are being named as you expect.
  
  
<code><pre>
+
<pre>
 
# zfs list -t snapshot
 
# zfs list -t snapshot
  
Line 40: Line 40:
  
 
rpool/ROOT/solaris@install  32.8M      -  3.34G  -
 
rpool/ROOT/solaris@install  32.8M      -  3.34G  -
</pre></code>
+
</pre>
  
 
== Rename a Snapshot ==
 
== Rename a Snapshot ==
Line 46: Line 46:
 
Now lets assume that above you created a snapshot without having it reference a specific date/time combination.  Maybe it was something like tank/software@preupgrade, and you have decided that the name really didn’t fit any more.  Perhaps you were doing multiple upgrade and people were getting confused between two different upgrades (say the 4.0 and the 4.1 upgrade of some hypothetical software/system) so now you have the 4.0 snapshot which is labeled tank/software@preupgrade and the 4.1 upgrade is labeled as tank/software@newupgrade.  It would make logical sense to rename them to perhaps tank/software@preupgrade-4.0 and tank/software@preupgrade-4.1.
 
Now lets assume that above you created a snapshot without having it reference a specific date/time combination.  Maybe it was something like tank/software@preupgrade, and you have decided that the name really didn’t fit any more.  Perhaps you were doing multiple upgrade and people were getting confused between two different upgrades (say the 4.0 and the 4.1 upgrade of some hypothetical software/system) so now you have the 4.0 snapshot which is labeled tank/software@preupgrade and the 4.1 upgrade is labeled as tank/software@newupgrade.  It would make logical sense to rename them to perhaps tank/software@preupgrade-4.0 and tank/software@preupgrade-4.1.
  
<code><pre>
+
<pre>
 
# zfs rename tank/software@preupgrade tank/software@preupgrade-4.0
 
# zfs rename tank/software@preupgrade tank/software@preupgrade-4.0
  
 
# zfs rename tank/software@newupgrade tank/software@preupgrade-4.1
 
# zfs rename tank/software@newupgrade tank/software@preupgrade-4.1
  
</pre></code>
+
</pre>
 
Well that gives you the ability to rename your snapshots, so you can easily handle the inevitable name changes.
 
Well that gives you the ability to rename your snapshots, so you can easily handle the inevitable name changes.
  
Line 58: Line 58:
 
OK so following along with our previous analogy of a hypothetical software upgrade.  We have now decided that the 4.0 upgrade project was a success and as such we no longer need the ability to rollback to tank/software@preupgrade-4.0 so it is time to delete it.
 
OK so following along with our previous analogy of a hypothetical software upgrade.  We have now decided that the 4.0 upgrade project was a success and as such we no longer need the ability to rollback to tank/software@preupgrade-4.0 so it is time to delete it.
  
<code><pre>
+
<pre>
 
# zfs destroy tank/software@preupgrade-4.0
 
# zfs destroy tank/software@preupgrade-4.0
</pre></code>
+
</pre>
 
Using Snapshot Holds
 
Using Snapshot Holds
  
 
Now while you did your previous destruction of the tank/software@preupgrade-4.0 someone from management was watching over your shoulder and saw how “easy” it was to delete a snapshot.  As such now you have to prevent an accidental deletion of the tank/software@preupgrade-4.1 snapshot.  Also if you insert a “-r” as an option it will be recursive to child objects as well.
 
Now while you did your previous destruction of the tank/software@preupgrade-4.0 someone from management was watching over your shoulder and saw how “easy” it was to delete a snapshot.  As such now you have to prevent an accidental deletion of the tank/software@preupgrade-4.1 snapshot.  Also if you insert a “-r” as an option it will be recursive to child objects as well.
  
<code><pre>
+
<pre>
 
# zfs hold keep tank/software@preupgrade-4.1
 
# zfs hold keep tank/software@preupgrade-4.1
</pre></code>
+
</pre>
 
Now we can view our holds.
 
Now we can view our holds.
  
<code><pre>
+
<pre>
 
# zfs holds tank/software@preupgrade-4.1
 
# zfs holds tank/software@preupgrade-4.1
  
Line 76: Line 76:
  
 
tank/software@preupgrade-4.1  keep  Thu Mar 15 09:02:22 2011
 
tank/software@preupgrade-4.1  keep  Thu Mar 15 09:02:22 2011
</pre></code>
+
</pre>
 
Of course we need a way to destroy held snapshots, can’t have the system going all “War Games” on us and deciding for us what can and cannot be deleted.  The below command will remove the hold.  You can now manually delete the snapshot, additionally you can also use “-d” option with the destroy parameter to schedule the deletion of the snapshot immediately upon the release of the snapshot hold.
 
Of course we need a way to destroy held snapshots, can’t have the system going all “War Games” on us and deciding for us what can and cannot be deleted.  The below command will remove the hold.  You can now manually delete the snapshot, additionally you can also use “-d” option with the destroy parameter to schedule the deletion of the snapshot immediately upon the release of the snapshot hold.
  
<code><pre>
+
<pre>
 
# zfs release keep tank/software@preupgrade-4.1
 
# zfs release keep tank/software@preupgrade-4.1
</pre></code>
+
</pre>
  
 
== Rollback to a Snapshot ==
 
== Rollback to a Snapshot ==
Line 87: Line 87:
 
Well something always happens, those top-notch contractors that were brought in to manage the 4.1 upgrade have completely botched the job, and you need to get your working production 4.0 platform back up and running.
 
Well something always happens, those top-notch contractors that were brought in to manage the 4.1 upgrade have completely botched the job, and you need to get your working production 4.0 platform back up and running.
  
<code><pre>
+
<pre>
 
# zfs rollback tank/software@preupgrade-4.1
 
# zfs rollback tank/software@preupgrade-4.1
</pre></code>
+
</pre>
 
It is important to note that if you are going to rollback “past” other snapshots that they will need to be destroyed first, or you can use the “-r” option to force the rollback “through” the other snapshots, until you get to the one you requested.
 
It is important to note that if you are going to rollback “past” other snapshots that they will need to be destroyed first, or you can use the “-r” option to force the rollback “through” the other snapshots, until you get to the one you requested.
  
Line 98: Line 98:
 
Now to see what a file system is taking using including all children.
 
Now to see what a file system is taking using including all children.
  
<code><pre>
+
<pre>
 
# zfs list -o space
 
# zfs list -o space
  
Line 111: Line 111:
 
rpool/export/home/matthew  267G  2.07G        0  2.07G              0          0
 
rpool/export/home/matthew  267G  2.07G        0  2.07G              0          0
  
</pre></code>
+
</pre>
 
Above you will see a trimmed listing of my test machine.  Notice that we have a couple of different points of interest in this particular command.  We have a USED, USEDSNAP, and USEDCHILD columns, lets define these.
 
Above you will see a trimmed listing of my test machine.  Notice that we have a couple of different points of interest in this particular command.  We have a USED, USEDSNAP, and USEDCHILD columns, lets define these.
  
Line 124: Line 124:
 
=== create delegation set ===
 
=== create delegation set ===
  
<code><pre>
+
<pre>
 
# zfs allow -s @adminrole create,destroy,snapshot,rollback,clone,promote,rename,mount,send,receive,quota,reservation tank [enter]
 
# zfs allow -s @adminrole create,destroy,snapshot,rollback,clone,promote,rename,mount,send,receive,quota,reservation tank [enter]
</pre></code>
+
</pre>
  
 
=== assign delegation set to user/group ===
 
=== assign delegation set to user/group ===
 
the syntax is the same for user or groups:
 
the syntax is the same for user or groups:
<code><pre>
+
<pre>
 
# zfs allow [user|group] @adminrole tank [enter]
 
# zfs allow [user|group] @adminrole tank [enter]
</pre></code>
+
</pre>
  
 
=== remove delegation ===
 
=== remove delegation ===
<code><pre>
+
<pre>
 
# zfs unallow [user|group] tank [enter]
 
# zfs unallow [user|group] tank [enter]
</pre></code>
+
</pre>
  
 
=== remove delegaton set ===
 
=== remove delegaton set ===
<code><pre>
+
<pre>
 
# zfs unallow -s @adminrole tank
 
# zfs unallow -s @adminrole tank
</pre></code>
+
</pre>
  
 
All info: http://docs.oracle.com/cd/E19253-01/819-5461/gbchv/index.html
 
All info: http://docs.oracle.com/cd/E19253-01/819-5461/gbchv/index.html

Latest revision as of 21:11, 28 August 2015

not really omnios specific of course.

Shamelessly plugged from http://blog.allanglesit.com/2011/04/zfs-snapshot-management/ and http://blog.allanglesit.com/2011/04/zfs-delegate-zfs-permissions/

View Existing Snapshots

# zfs list -t snapshot

NAME                         USED  AVAIL  REFER  MOUNTPOINT

rpool/ROOT/solaris@install  32.8M      -  3.34G  -

Create Snapshots

The most basic snapshot can simply be created by specifying the below command.

# zfs snapshot tank/testdata/finance@today

Now obviously their are “administrative” problems with the above command (most notably the fact that we are naming it “today” after all it won’t be today’s snap if we wait until tomorrow). So it would be far more correct to name it by the actual date, however I can’t be bothered to remember the date, and frankly I don’t have to. The below variation will use the output of the date +%m%d%Y command to generate the name of the snapshot, this will give us the ability to have the snapshot be named “03152011″ instead of “today”.

# zfs snapshot tank/testdata/finance@`date +%m%d%Y`

Remember to look at your snapshots to ensure they are being named as you expect.


# zfs list -t snapshot

NAME                         USED  AVAIL  REFER  MOUNTPOINT

tank/testdata/finance@03312011                  0      -    94K  -

tank/testdata/finance@today                0      -    94K  -

rpool/ROOT/solaris@install  32.8M      -  3.34G  -

Rename a Snapshot

Now lets assume that above you created a snapshot without having it reference a specific date/time combination. Maybe it was something like tank/software@preupgrade, and you have decided that the name really didn’t fit any more. Perhaps you were doing multiple upgrade and people were getting confused between two different upgrades (say the 4.0 and the 4.1 upgrade of some hypothetical software/system) so now you have the 4.0 snapshot which is labeled tank/software@preupgrade and the 4.1 upgrade is labeled as tank/software@newupgrade. It would make logical sense to rename them to perhaps tank/software@preupgrade-4.0 and tank/software@preupgrade-4.1.

# zfs rename tank/software@preupgrade tank/software@preupgrade-4.0

# zfs rename tank/software@newupgrade tank/software@preupgrade-4.1

Well that gives you the ability to rename your snapshots, so you can easily handle the inevitable name changes.

Delete a Snapshot

OK so following along with our previous analogy of a hypothetical software upgrade. We have now decided that the 4.0 upgrade project was a success and as such we no longer need the ability to rollback to tank/software@preupgrade-4.0 so it is time to delete it.

# zfs destroy tank/software@preupgrade-4.0

Using Snapshot Holds

Now while you did your previous destruction of the tank/software@preupgrade-4.0 someone from management was watching over your shoulder and saw how “easy” it was to delete a snapshot. As such now you have to prevent an accidental deletion of the tank/software@preupgrade-4.1 snapshot. Also if you insert a “-r” as an option it will be recursive to child objects as well.

# zfs hold keep tank/software@preupgrade-4.1

Now we can view our holds.

# zfs holds tank/software@preupgrade-4.1

NAME                TAG   TIMESTAMP

tank/software@preupgrade-4.1  keep  Thu Mar 15 09:02:22 2011

Of course we need a way to destroy held snapshots, can’t have the system going all “War Games” on us and deciding for us what can and cannot be deleted. The below command will remove the hold. You can now manually delete the snapshot, additionally you can also use “-d” option with the destroy parameter to schedule the deletion of the snapshot immediately upon the release of the snapshot hold.

# zfs release keep tank/software@preupgrade-4.1

Rollback to a Snapshot

Well something always happens, those top-notch contractors that were brought in to manage the 4.1 upgrade have completely botched the job, and you need to get your working production 4.0 platform back up and running.

# zfs rollback tank/software@preupgrade-4.1

It is important to note that if you are going to rollback “past” other snapshots that they will need to be destroyed first, or you can use the “-r” option to force the rollback “through” the other snapshots, until you get to the one you requested.

Monitoring Disk Space

Now if you plan on having any sort of storage, your first question should always be how can I monitor the utilization, it almost never is however for this moment we can live in happy-ville (or since I am writing this article while I am in Germany happy-burg) where everything just works, users manage their own stale data, and nothing ever breaks. However in the real world this stuff never happens so you have to be able to pro-actively manage your data. Frankly snapshots make managing your data (read: not filling up your disks) harder. Which ultimately should be expected whenever you have any sort of automated process which will generate any sort of duplicate data, keep in mind that ZFS does this very well and as long as you are not generating a ton of changes then snapshots will be fantastic. On the flip side of this coin there is some data that is just not good for snapshots, the most obvious being block devices. So the long and short of it is that when you first start doing snapshots you have no idea how much data they will take up over the long term. Once you have an idea for this you will be able to plan appropriately for your disk usage, although really you will need to monitor this throughout the life of your system.

Now to see what a file system is taking using including all children.

# zfs list -o space

NAME                       AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD

rpool                       267G  25.9G       20K     94K              0      25.9G

rpool/export                267G  10.1G         0   8.00G              0      2.07G

rpool/export/home           267G  2.07G         0     32K              0      2.07G

rpool/export/home/matthew   267G  2.07G         0   2.07G              0          0

Above you will see a trimmed listing of my test machine. Notice that we have a couple of different points of interest in this particular command. We have a USED, USEDSNAP, and USEDCHILD columns, lets define these.

USED – This is the total allocation for the file system + all snapshots + all child file systems + all child file systems snapshots. Get it? Basically this is what is actually being used. We can see in the above example that rpool is using 25.9GB total out of 267GB available and that 10.1GB is actually coming from rpool/export, now we can also see that if we follow the rabbit hole that rpool/export/home/matthew is contributing 2.07GB to the 10.1GB of rpool/export. USEDSNAP – This is the total allocation of this file systems snapshots, this doesn’t show you how much data the file system is taking up nor the amount of data is in child systems. This basically will indicate if you are low on space due to overzealous snapshots or simply a lack of data management by the users. In the above example I only have the install snapshot which the system does in this tree, which is fine just see that the rpool SNAPUSED value is 20K so clearly if we were out of space, snapshots would not be the problem in this tree. USEDCHILD – This is the total usage of storage of child file systems. As you can see above rpool/export and rpool/export/home both have a value of 2.07GB, this is because the rpool/export/home doesn’t actually add any data, it just passes up the data that exists below in rpool/export/home/matthew (where the 2.07GB actually exists).

Snapshots can make your life far easier, however they can be hard to manage if you are not careful and take the time to learn what you are doing. Spend a lot of time in test to really understand the functionality that is introduced by snapshots.

Delegating zfs permissions

create delegation set

# zfs allow -s @adminrole create,destroy,snapshot,rollback,clone,promote,rename,mount,send,receive,quota,reservation tank [enter]

assign delegation set to user/group

the syntax is the same for user or groups:

# zfs allow [user|group] @adminrole tank [enter]

remove delegation

# zfs unallow [user|group] tank [enter]

remove delegaton set

# zfs unallow -s @adminrole tank

All info: http://docs.oracle.com/cd/E19253-01/819-5461/gbchv/index.html