===== Example of UFS snapshots under FreeBSD =====
This is a brief description of UFS snapshots under %%FreeBSD%%. Most of this information was written back in fall of 2004, and might be slightly out-of-date. But I'm putting this up here right now (Jan 2006) because I keep //thinking// that I have already put this information up here, so I tell people "just check the %%FreeBSD%% wiki" when they ask me for information about snapshots. Then I look dumb when it isn't here... By putting this up here, I hope to look a little less dumb.
This was originally written as a one-page handout for some user-group presentations, so it is very brief. Still, I hope it will be helpful for people looking for a starting point.
This filesystem snapshot ability is available and was reasonably reliable starting with %%FreeBSD%% 5.3-release, although I've mainly been using it on 6.0-release and later versions of %%FreeBSD%%.
See also: http://www.mckusick.com/softdep/index.html
There is a **snapshot** utility command available, which provides a more convenient way to handle some of the details that I've written about below. I can't say much about it, since I wrote my own snapshot-handling scripts (good enough for my trivial needs...) before that command was written. It might also be true that the **snapshot** command is only available on 6.0-release and later systems. For details on that command, see: **man 8 snapshot**
The **snapshot** utility command is also used by a **periodic-snapshot** utility. See **man 8 periodic-snapshot**.
The **dump** command also supports a **-L** option, which will automatically create a snapshot of a live (mounted and writable) filesystem, and then dump from the static, read-only snapshot instead of the actively-changing filesystem. For more details, see: **man 8 dump**
There is also now a port called "freebsd-snapshot", which can be useful for making and managing snapshots. I haven't tried it myself, but it looks like it might be useful. I don't know how it compares to the **periodic-snapshot** utility mentioned above.
----
==== Status of my example system before making the snapshot: ====
# df -k
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad4s3a 272558 60038 190716 24% /
devfs 1 1 0 100% /dev
/dev/ad4s3e 4164558 1315622 2515772 34% /usr
/dev/ad4s3d 421358 19344 368306 5% /var
# cd /usr
# ls
.snap/ cvs/ lib/ obj/ src/
X11R6/ games/ libdata/ ports/
bin/ home/ libexec/ sbin/
compat/ include/ local/ share/
==== Creating the snapshot ====
Note that most of this is done as userid root. I included the **time** command to show how quickly the snapshot is made, in real time, while the partition is mounted and a few processes are actively using it. On larger partitions, this snapshot operation will take more time. People tell me that on significantly larger partitions, it will take significantly more time...
# /usr/bin/time mount -u -o snapshot /usr/.snap/2004_1006 /usr
0.60 real 0.00 user 0.04 sys
# ls -l /usr/.snap/2004_1006
-r-------- 1 root operator 4404019424 Oct 6 14:13 /usr/.snap/2004_1006
Note: That's the size that the snapshot image-file //looks like// to the **ls** command. The snapshot isn't actually using up that much disk space on your partition!
It is also possible to use the **mksnap_ffs** command. This takes a path as name for a snapshot, the equivalent to the above is
# /usr/bin/time mksnap_ffs /usr/.snap/2004_1006
0.62 real 0.00 user 0.03 sys
==== Mounting the snapshot as a separate partition ====
First, create a memory-device for it:
# /usr/bin/time mdconfig -a -t vnode -u 0 -f /usr/.snap/2004_1006
0.03 real 0.00 user 0.00 sys
And then mount that memory device:
# mkdir -p /WayBack/usr-2004_1006
# chmod 755 /WayBack /WayBack/usr-2004_1006
# mount -r /dev/md0 /WayBack/usr-2004_1006
==== Status of the example system after mounting the snapshot ====
# df -k
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad4s3a 272558 60038 190716 24% /
devfs 1 1 0 100% /dev
/dev/ad4s3e 4164558 1318198 2513196 34% /usr
/dev/ad4s3d 421358 19344 368306 5% /var
/dev/md0 4164558 1315622 2515772 34% /WayBack/usr-2004_1006
# cd /WayBack/usr-2004_1006
# ls
.snap/ cvs/ lib/ obj/ src/
X11R6/ games/ libdata/ ports/
bin/ home/ libexec/ sbin/
compat/ include/ local/ share/
Besides the fact that you have that new partition there (which is a mirror of the original partition), notice that the amount of diskspace used on ///var// has not increased by much. However, as more files are modified on the live partition, then the amount of disk space actually used by the snapshot will increase (since the snapshot will keep the original version of any file or directory which is modified after the snapshot was made).
==== Listing snapshots ====
A list of snapshots can be shown with the **snapinfo** command. Passing //-v// to it will show more information.
==== Getting rid of the snapshot ====
The snapshot-image file will not disappear due to system reboots, but the memory device and the effect of the **mount** command will (//aside: I don't know if the **snapshot** or **periodic-snapshot** utilities do something special to recreate those//). You can keep multiple snapshots for any filesystem partition, although there is some maximum limit of how many you can keep (I believe that right now the limit is 20 separate snapshots existing at the same time on a given UFS2 partition).
If you have not rebooted since mounting the snapshot as a new partition, then to get rid of it completely you would want to:
# umount /WayBack/usr-2004_1006
# mdconfig -d -u 0
# rm /usr/.snap/2004_1006
override r-------- root/operator snapshot for /usr/.snap/2004_1006? y
If you have rebooted, then all you would need to do is the **rm** command.