Solaris snapshots

In file systems, a snapshot is a copy of a set of files and directories as they were at a particular point in the past. The term was coined as an analogy to that in photography.  A snapshot can be thought as a concept similar to RAID 1 (mirroring). Rather than performing a block-by-block copy of a disk, and then performing all writes to both copies, a snapshot takes a shortcut. The snapshot starts from an original partition and instead of copying all of the original blocks, it creates a copy of the metadata structures. In essence, it has pointers to all the data blocks. Thus, a snapshot is relatively fast to create (few seconds on relatively free of activities filesystem).  

Most modern OSes support this concept either on the level of filesystem of on the level of LVM. One of the first implementation that included snapshot feature was the VERITAS File System. In Solaris this facility was available since 2001 with the introduction of fssnap command in Solaris 8 . A similar Windows term is Shadow Copy (also called Volume Snapshot Service or VSS)  was introduced with Windows XP with SP1, Windows Server 2003, and available in all subsequent releases of Microsoft Windows. Snapshots have also been available in the NSS (Novell Storage Services) file system on Netware since version 4.11, and more recently on Linux platforms in the  Novell Open Enterprise Server product. Linux LVM is also snapshots capable

Solaris snapshot capabilities

Solaris has a very elegant implementation of snapshots both in UFS and ZFS. We will discuss UFS implementation first. My discussion of UFS snapshot capabilities is partially based on the article Free Snapshots by Peter Baer Galvin in  Sys Admin .

The snapshot is placed within an existing file system or (theoretically) on a raw device. Changes to the snapped filesystem are then handled specially. For every block (metadata or normal data) that is to be written to the snapped filesystem, a copy of the original contents is created and placed on the snapshot and then the write is allowed to occur to the original file system. In this manner, the original source file system is kept up to date and its snapshot copy has the contents that the file system had when the snapshot occurred.  In essence Solaris snapshot facility implement perfect "one generation back" file recovery scheme at a very low cost. that means that if you created a snapshot in the morning any destruction of files to the last yesterday copy is easily reversible during the day. this is an extremely convenient feature on workstation to have and I personally cannot live without it a day as I am pretty absent minded individual when working with the large amount of similar files like Softpanorama website. 

• By having the snapshot copy mounted, a user could “cd back in time” by accessing the snapshot copy rather than the original file system. For example, if the system created a snapshot of a file system every midnight, a user could look at the system as it was yesterday, the day before he deleted that important file. He could then copy the file from “yesterday” to the current file system to restore its use.
• By allowing multiple snapshots of the same file system, it is possible to have views of the file system as it was every day in the past week, or every four hours in the past day, and so on.
• By quiescing a database or other important application, taking a snapshot, and continuing the application, a reliable, consistent backup could be made of data that is constantly changing. The snapshot copy is a view of the world at a time when the data was on disk and not changing. The application can continue running, users can continue their work, and the backup can be done without interfering with their activities.

Because snapshots are fast and low overhead, they can be used extensively without great concern for system performance or disk use (although those aspects must also be considered).

The basic Solaris command to create a snapshot is:

# fssnap -o backing-store=/snap /
/dev/fssnap/0

In this command backing-store is the file system on which to put the snapshot, and the last argument / is the file system to snap. The command returns a device name, which is an access point to the snapshot file system. Of course, you can create multiple snapshots, one per file system on the system:

# fssnap -o backing-store=/snap /opt
/dev/fssnap/1

The snapshot operation on a quiet file system took a few seconds. The busier the file system, the longer the operation.

A snapshot can reside on any file system type, even NFS. An unmounted device can also be used as the backing store

Now we can check the status of a snapshot:

# fssnap -i /
Snapshot number               : 0
Block Device                  : /dev/fssnap/0
Raw Device                    : /dev/rfssnap/0
Mount point                   : /
Device state                  : idle
Backing store path            : /snap/snapshot0
Backing store size            : 2624 KB
Maximum backing store size    : Unlimited
Snapshot create time          : Wed Oct 31 10:20:18 2001
Copy-on-write granularity     : 32 KB

Note that there are several options on snapshot creation, including limiting the maximum amount of disk space that the snap can take on its backing store.

From the system point of view, the snapshot looks a bit strange. The disk use, at least at the initial snap, is minimal as would be expected:

# df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t0d0s0    4030518 1411914 2578299    36%    /
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
mnttab                     0       0       0     0%    /etc/mnttab
swap                  653232      16  653216     1%    /var/run
swap                  653904     688  653216     1%    /tmp
/dev/dsk/c0t1d0s7    5372014  262299 5055995     5%    /opt
/dev/dsk/c0t0d0s7    4211158 2463312 1705735    60%    /export/home
/dev/dsk/c0t1d0s0    1349190    3313 1291910     1%    /snap

However, an ls shows seemingly very large files:

# ls -l /snap
total 6624
drwx------   2 root     root        8192 Oct 31 10:19 lost+found
-rw-------   1 root     other    4178771968 Oct 31 10:30 snapshot0
-rw-------   1 root     other    5500942336 Oct 31 10:24 snapshot1

These files are “holey”. Logically, they are the same size as the snapped file system. As changes are made to the original, the actual size of the snapshot grows as it holds the original versions of each block. However, almost all of the blocks are empty at the start, and so are left as “holes” in the file. The disk use is thus only the metadata and blocks that have changed.

The performance impact of a snapshot is that any write to a snapped-file system first has the original block written to the snap, so writes are 2X non-snapped file systems. This is similar to the overhead of RAID-1. Typically, RAID-1 writes are done synchronously to both mirror devices. That is, the writes must make it to both disks before the write operation is considered to be complete. This extra overhead makes writes more expensive. It is not clear whether snapfs commands are done synchronously or asynchronously, although it is likely the former.

What can be done once a snapshot is created? Certainly a backup can be made of the snapshot, solving the previously ever-present “how to back up a live file system consistently” problem. In fact, fssnap has built-in options to make it trivial to use in conjunction with ufsdump:

# ufsdump 0ufN /dev/rmt/0 'fssnap -F ufs -o raw,bs=/snap,unlink \
  /dev/rdsk/c0t0d0s0'

This command will snapshot the root partition, ufsdump it to tape, and then unlink the snapshot so the snapshot file is removed when the command finishes (or at least the file should be removed). In testing, the unlink option does indeed unlink the snapshot file, but the fssnap -d command is required to terminate the use of the snapshot and actually free up the disk space. Thus, this would be the full command:

# ufsdump 0ufN /dev/rmt/0 'fssnap -F ufs -o raw,bs=/snap,unlink \
  /dev/rdsk/c0t0d0s0'
# fssnap -d /

fssnap gets interesting when the snapshot itself is mounted for access, as in:

# mount -o ro /dev/fssnap/0 /mnt

Now we can create a file in /, and see that it does not appear in:

/mnt:
# touch /foo
# ls -l /foo
-rw-r--r--   1 root     other          0 Nov  5 12:25 /foo
# ls -l /mnt/foo
/mnt/foo: No such file or directory

Unfortunately, there does not appear to be any method to promote the snapshot to replace the current active file system. For example, if a systems administrator was about to attempt something complicated, such as a system upgrade, she could perform a snapshot first. If she did not like the result, she could restore the system to the snapshot version. (the “live upgrade” in Solaris provides a similar functionality.)

The backing store can be deleted manually after it’s finished. fssnap -d “deletes” the snap, but that is probably the wrong terminology. Rather, it stops the use of the snapshot, more like “detaching” it from the source file system. To actually remove the snapshot, the snapshot file must also be deleted via rm.

Alternately, the unlink option can be specified when the snap is created. This prevents a file system directory entry from being made for the file. In essence, it is then like an open, deleted file. Once the file is closed, the inode and its data are automatically removed. Unlinked files are not visible in the file system via ls and similar commands, making them harder to manage than normal “linked” file systems.

Apparently only one active snapshot of a file system can exist. This limits the utility of UFS snapshots to be a kind of safety net for users or systems administrators. For instance, a snapshot could be made once a night, but only one day’s worth of old data would then be available.

On the whole, fssnap is a welcome addition to the Unix filesystems functionality. Sun is obviously paying attention to its file systems, and adding features to make it more competitive.

With ZFS you can not only create snapshot but create a clone of a snapshot. The ZFS Administration Guide describes a clone thus:

A clone is a writable volume or file system whose initial contents are the same as the dataset from which it was created. As with snapshots, creating a clone is nearly instantaneous, and initially consumes no additional disk space. In addition, you can snapshot a clone.

NEWS CONTENTS

• 20090416 : Less Known Solaris features fssnap - c0t0d0s0.org ( Less Known Solaris features fssnap - c0t0d0s0.org, Apr 16, 2009 )
• 20090416 : Less Known Solaris features: fssnap ( Less Known Solaris features: fssnap, )
• 20090416 : A practical example. ( )
• 20090416 : Do you want to learn more ( )

Old News ;-)

[Apr 16, 2009] Less Known Solaris features fssnap - c0t0d0s0.org

Less Known Solaris features: fssnap

April 24. 2008 | www.c0t0d0s0.org

An ever reoccuring problem while doing backups is the problem, that you have to keep the state of the backup consistent. For example: You use the cyrus imapd for storing mails on a system. As it´s a system used for years, the message store is still on an UFS file system. Okay, now there is a little problem: You want to make make backups, but it´s a mail server.

With the amount of mail junkies in modern times, you can´t take the system offline for an hour or so, just to make a backup. But you have to take it offline. Especially a mail server is a moving target, as cyrus imapd has indexes for its mailboxes, and index files for the mailboxes itself. Let´s assume a backup takes 1 hour, and users delete mails in this time, create mailboxes and so on. It´s possible that you backup your mailserver in an inconsistent state, das the mail directory of the user may represent the state one hour ago, but the mailboxes file represent the state of one minute ago.

fssnap

UFS has a little known feature, that comes to help in such a situation. You can do a filesystem snapshot of the system. This is a non-changing point-in-time view to the filesystem, while you can still change the the original filesystem. fssnap is a rather old tool. We´ve introduced in the 1/01 update of Solaris 8.

There is a restriction with this snapshots: This snapshots are solely for the purpose of backups, thus they are not boot persistent. For boot persistent snapshots of a filesystem you will need the Sun Availability Suite.

A practical example.

Let´s assume that we have a directory called /mailserver. This directory is the mountpoint for a UFS filesystem on /dev/dsk/c1d1s1. At the moment it contains some files:

# ls -ls
total 10
2 -rw------T 1 root root 1024 Apr 23 01:41 testfile1
2 -rw------T 1 root root 1024 Apr 23 01:41 testfile2
2 -rw------T 1 root root 1024 Apr 23 01:41 testfile3
2 -rw------T 1 root root 1024 Apr 23 01:41 testfile4
2 -rw------T 1 root root 1024 Apr 23 01:41 testindex1


Now we want to make a backup. It´s sensible to take the mail server offline for a few seconds to keep the files consistent. In this moment we make the filesystem snapshot. This is really easy:

# fssnap -o bs=/tmp /mailserver
/dev/fssnap/0

With this command we told fssnap to take an snapshot of the filesystem mounted at /mailserver. Furthermore we configured that the snapshot uses the /tmp for it´s backing store. In the backing store the changes since the snapshot will be recorded. When fssnap is able to create the snapshot, it will return the name for the pseudo device containing the filesystem snapshot. In our case it´s /dev/fssnap/0. Please remember it, we need it later.

When you look at the /tmp directory you will find an backing store file for this snapshot. It´s called snapshot0 for the first snapshot on the system:

# ls -l /tmp
total 910120
-rw-r--r-- 1 root root 30 Apr 22 14:50 ogl_select305
-rw------- 1 root root 465976320 Apr 23 01:47 snapshot0

Now we bring the mailserver online again, and after a few seconds we see changes to the filesystem again (okay, in my example i will do this manually):

# mkfile 1k testfile5
# mkfile 1k testfile6
# mkfile 2k testindex1
# ls -l
total 16
-rw------T 1 root root 1024 Apr 23 01:41 testfile1
-rw------T 1 root root 1024 Apr 23 01:41 testfile2
-rw------T 1 root root 1024 Apr 23 01:41 testfile3
-rw------T 1 root root 1024 Apr 23 01:41 testfile4
-rw------T 1 root root 1024 Apr 23 01:53 testfile5
-rw------T 1 root root 1024 Apr 23 01:53 testfile6
-rw------T 1 root root 2048 Apr 23 01:53 testindex1

Now we want to make the backup itself. At first we have to mount the filesystem. Thus we create a mountpoint

# mkdir /mailserver_forbackup

Now we mount the snapshot. You will recognize the pseudo device here again. The snapshot is read only thus you have to specify it at mount time:

# mount -o ro /dev/fssnap/0 /mailserver_forbackup

Okay, when we look into the filesystem, we will see the state of the filesystem at the moment of the snapshot. testfile5, testfile6 and the bigger testindex1 are missing.

# ls -l
total 10
-rw------T 1 root root 1024 Apr 23 01:41 testfile1
-rw------T 1 root root 1024 Apr 23 01:41 testfile2
-rw------T 1 root root 1024 Apr 23 01:41 testfile3
-rw------T 1 root root 1024 Apr 23 01:41 testfile4
-rw------T 1 root root 1024 Apr 23 01:41 testindex1

Now we can to a backup without any problems and in a consistent manner:

# tar cfv /backup_mailserver_20080424.tar *
a testfile1 1K
a testfile2 1K
a testfile3 1K
a testfile4 1K
a testindex1 1K

After this step we should clean-up. We unmount the snapshot and delete the snapshot with it´s backing store file:

# umount /mailserver_forbackup
# fssnap -d /mailserver
Deleted snapshot 0.
# rm /tmp/snapshot0

Conclusion

With the fssnap command you have an easy way to do consistent backups on UFS filesystems. While it´s not as powerful as the functions of the point-in-time copy functionality in the Availability Suite, it´s a perfect match for it´s job.

Do you want to learn more

fssnap(1M)
fssnap_ufs(1M)

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019