Skip to main content

Table of Contents

Introduction

Background

Research Computing Snapshot Schedule and Retention Policy

Getting an Older Version of a File Back from Snapshot

Additional Helpful Notes

Additional Help

What is Snapshot?

Snapshot is a technology that provides efficient time-based archives of data so that each user can quickly restore a file accidentally deleted or changed to its previous state on his/her own. Older versions of files are available based on the time the snapshot was taken – not based on each time the file was changed. It is not a file versioning system: It does not keep every version of a saved file. Instead, it knows what the file contained at a particular time. Every user with an account on UNC’s research clusters automatically has home directory files in the snapshot system.

Snapshot supports only directories and files in Research Computing’s NAS Filesystems: home and dept spaces. The following are not protected with Snapshot: pine (scratch), 21dayscratch, proj or ms. Only those on a Research Computing’s NAS Filesystem are protected with Snapshot.

Background

Snapshot gives us a self-service automated file recovery system that is significantly faster than traditional tape back up methods. Tape systems are cumbersome for backing up files that are small or that change frequently due to the need for a robot to find, load and fast-forward a physical tape to access each file. Tape systems are best for storing large files that are read infrequently and need to be kept as-is for a long time (Research Computing Mass Storage).

Behind the scenes, Snapshot stores the addresses on the disk of changed sections of files, not a copy of the entire changed file. This saves space and makes for a faster back up process. It reconstitutes a requested file by putting together the its list of file addresses on the disk for the requested timestamp. As a result, restoring a file from its collection of snapshots is almost instantaneous (taking only seconds to produce).

Snapshot by itself does not provide full disaster recovery services because it does not keep copies of data off-site. It can serve as a disaster recovery option, however, when used in combination with remote site mirroring. Mirroring is the automatic duplicate writing of files onto two different volumes of space. If the mirrored volume is located remotely/off-site, then this is considered a disaster recovery solution. Since snapshot copies only changed blocks, disk mirroring to a remote system is much faster than a traditional off-site tape backup since less data is transferred and disk read/write times are faster than tape read/write times. Research computing does not have a remote location for its mirrored snapshot copies.

Research Computing Snapshot Schedule and Retention Policy

Snapshot has the ability to update hourly, nightly and/or weekly. Hourly snapshots are those scheduled for a particular time every day (not every hour of the day). Nightly snapshots happen at midnight Monday through Saturday. The weekly snapshot is taken at midnight on Sundays. Research Computing takes its hourly snapshots at 11am and 4pm and keeps two hourly snapshots.
Hourly snapshots are useful for mistakes made that you recognize immediately, i.e. for when you accidentally delete a file, update the wrong file, or overwrite a file copy. You can quickly correct your mistake by copying files out of one of the two hourly snapshots. There will always be only two hourly snapshots. The 11am snapshot overwrites the previous day’s 11am snapshot while preserving the previous day’s 4pm snapshot. At 4pm the 4pm snapshot from yesterday is effectively overwritten. If you make changes to a file at noon and then accidentally delete it at 3, snapshot will be able to restore the one it had as of 11am (not noon).

 

Nightly and weekly snapshots are useful when time has passed before you realize a file has been compromised and you need the version of the file from a day or more ago. As space permits, Research Computing retains up to 24 nightly snapshots or four weeks’ worth of snapshots.

 

One caveat: As already mentioned, disk space consumption is required for snapshots based on the rate-of-change within the filesystem. If a high rate-of-change or odd use of the filesystem causes the filesystem to run low on disk space, there is a mechanism in place to delete the oldest snapshot in order to free up space in the filesystem. This should rarely (if ever) happen.

Getting an Older Version of a File Back from Snapshot

As mentioned previously, each snapshot uses disk space in the filesystem. This means that snapshots can be accessed from the filesystem itself. It also means you can restore what you need without having to submit a request for a restore to the system administrators (self-service). The block method Snapshot uses means that while each snapshot does impact remaining space available due to space quotas, snapshot files for a directory are so small (typically < 10k) that the impact is minimal.

Users access a snapshot by listing or changing directories to the “.snapshot” sub-directory in the directory where the file was stored. To restore files, go to the .snapshot sub-directory that has the file you need and copy that file either to the same location it existed previously or to a new location (so as not to overwrite the existing file in the current filesystem space).

Let’s look at an example:

On the research clusters (e.g. longleaf, dogwood) your home directory and starting point upon login is the /nas/longleaf/home/<onyen>/ directory. You have a large quota of space and are encouraged to save any applications, scripts or smaller input / output files in this location. Please note the following example will work for all directories and files in Research Computing’s NAS Filesystems: home and dept space. The following, not inclusive, list of spaces are not protected with snapshot: pine (scratch), 21dayscratch, proj or ms.

[chammitt@longleaf-login1 ~]$ pwd

/nas/longleaf/home/chammitt

 

List of snapshots in home directory:

 

Note that in the output below only the past week is displayed.

[chammitt@longleaf-login1 ~]$ ls -tlu .snapshot

total 200

drwxrwxrwx 23 chammitt root 8192 Oct  8 11:03 hourly.0

drwxrwxrwx 23 chammitt root 8192 Oct  8 00:00 nightly.0

drwxrwxrwx 23 chammitt root 8192 Oct  7 16:03 hourly.1

drwxrwxrwx 23 chammitt root 8192 Oct  7 00:00 nightly.1

drwxrwxrwx 23 chammitt root 8192 Oct  6 00:00 nightly.2

drwxrwxrwx 23 chammitt root 8192 Oct  5 00:00 nightly.3

drwxrwxrwx 23 chammitt root 8192 Oct  4 00:00 nightly.4

drwxrwxrwx 23 chammitt root 8192 Oct  3 00:03 nightly.5

drwxrwxrwx 23 chammitt root 8192 Oct  2 00:03 nightly.6

 

Active Filesystem:

 

The following lists the contents in my home directory that contain the word “test.”

 

[chammitt@longleaf-login1 ~]$ ls -lhu|grep test

drwxrwx— 2 root     root     4.0K Oct  8 03:49 test

drwxr-xr-x 2 chammitt employee 4.0K Oct  8 11:24 testsnapshot

 

Snapshot Filesystem:

 

The following is from the directory hourly.0 (see the output listing two steps above), about which more will be discussed below.

[chammitt@longleaf-login1 ~]$ ls -lth .snapshot/hourly.0|grep test

-rw-r–r– 1 chammitt employee 2.6G Oct  3 07:46 testwestportdd6

-rw-r–r– 1 chammitt employee 977M Oct  3 07:45 testwestportdd66

-rw-r–r– 1 chammitt employee 3.9G Oct  2 11:11 testwestportdd2

-rw-r–r– 1 chammitt employee 977M Sep 27 11:21 test5dd

-rw-r–r– 1 chammitt employee 977M Sep 27 11:21 test4dd

drwxrwx— 2 root     root     4.0K Aug  5 11:18 test

 

Notice there are several more files in the snapshot than in the active filesystem, as some files have been deleted from the active filesystem.  Also note that the directory “testsnapshot” is missing from the snapshot, which is because that directory was created after the snapshot was taken.

Now, let’s say that file “test4dd” is the file I wish to recover to my home directory.

[chammitt@longleaf-login1 ~]$ cp -p .snapshot/hourly.0/test4dd .

 

Notice the “-p” flag with the cp command above to preserve file attributes:  permissions, timestamps, etc. Without this flag, the copy is seen as a new write and thus the timestamp is the current time and the permissions are based upon your umask and primary UNIX GID.

[chammitt@longleaf-login1 ~]$ ls -lht|grep test

drwxr-xr-x 2 chammitt employee 4.0K Oct  8 11:24 testsnapshot

-rw-r–r– 1 chammitt employee 977M Sep 27 11:21 test4dd

drwxrwx— 2 root     root     4.0K Aug  5 11:18 test

Additional Helpful Notes

 

  • When listing snapshot, use the –u flag with the ls command to see the access times and when the snapshot was created. Otherwise, you would go by the snapshot name.
[chammitt@longleaf-login1 ~]$ ls -lt .snapshot

total 200

drwxrwxrwx 23 chammitt root 8192 Oct  5 08:51 hourly.0

drwxrwxrwx 23 chammitt root 8192 Oct  5 08:51 hourly.1

drwxrwxrwx 23 chammitt root 8192 Oct  5 08:51 nightly.0

drwxrwxrwx 23 chammitt root 8192 Oct  5 08:51 nightly.1

drwxrwxrwx 23 chammitt root 8192 Oct  5 08:51 nightly.2

drwxrwxrwx 23 chammitt root 8192 Oct  3 07:45 nightly.3

drwxrwxrwx 23 chammitt root 8192 Oct  3 07:45 nightly.4

drwxrwxrwx 23 chammitt root 8192 Oct  2 11:21 nightly.5

drwxrwxrwx 23 chammitt root 8192 Sep 28 10:06 nightly.6

 

As opposed to

[chammitt@longleaf-login1 ~]$ ls -ltu .snapshot

total 200

drwxrwxrwx 23 chammitt root 8192 Oct  8 11:03 hourly.0

drwxrwxrwx 23 chammitt root 8192 Oct  8 00:00 nightly.0

drwxrwxrwx 23 chammitt root 8192 Oct  7 16:03 hourly.1

drwxrwxrwx 23 chammitt root 8192 Oct  7 00:00 nightly.1

drwxrwxrwx 23 chammitt root 8192 Oct  6 00:00 nightly.2

drwxrwxrwx 23 chammitt root 8192 Oct  5 00:00 nightly.3

drwxrwxrwx 23 chammitt root 8192 Oct  4 00:00 nightly.4

drwxrwxrwx 23 chammitt root 8192 Oct  3 00:03 nightly.5

drwxrwxrwx 23 chammitt root 8192 Oct  2 00:03 nightly.6

 

  • To preserve file attributes, use cp –p or rsync –a when copying from snapshots to the active filesystem.
  •  If copying lots of files or directories, use rsync instead of cp.
  • Snapshot permissions are the same as filesystem permissions; if you don’t have access…you don’t have access.
  • The .snapshot directory is available in many and all areas.  You can start at the root of a volume, or far down the directory tree. For example, these locations are the same:

 

[chammitt@longleaf-login1 ~]$ ls -lhtu /nas/longleaf/home/.snapshot/hourly.0/chammitt/|grep test

drwxrwx— 2 root     root     4.0K Oct  8 11:03 test

-rw-r–r– 1 chammitt employee 977M Oct  8 11:03 test4dd

-rw-r–r– 1 chammitt employee 977M Oct  8 11:03 test5dd

-rw-r–r– 1 chammitt employee 3.9G Oct  8 11:03 testwestportdd2

-rw-r–r– 1 chammitt employee 2.6G Oct  8 11:03 testwestportdd6

-rw-r–r– 1 chammitt employee 977M Oct  8 11:03 testwestportdd66

[chammitt@longleaf-login1 ~]$ ls -lhtu /nas/longleaf/home/chammitt/.snapshot/hourly.0|grep test

drwxrwx— 2 root     root     4.0K Oct  8 11:03 test

-rw-r–r– 1 chammitt employee 977M Oct  8 11:03 test4dd

-rw-r–r– 1 chammitt employee 977M Oct  8 11:03 test5dd

-rw-r–r– 1 chammitt employee 3.9G Oct  8 11:03 testwestportdd2

-rw-r–r– 1 chammitt employee 2.6G Oct  8 11:03 testwestportdd6

-rw-r–r– 1 chammitt employee 977M Oct  8 11:03 testwestportdd66

Additional Help

Be sure to check the Research Computing page for information about other resources available to you.