Snapshots
The NetApp filesystem provides a convenient way to recover files which have been accidentally deleted or otherwise damaged, within a short time frame – a system referred to as “snapshots”. File recovery becomes a simple copy procedure on the current filesystem, avoiding the necessity of Systems Administration hands-on interaction.
Directories which provide the snapshot feature are easily recognized by the presence of a .snapshot directory within (named as ~snapshot on Windows machines.) Currently, snapshots are enabled on /home, /uusoc/res, and /uusoc/sys.
Snapshots currently span a four week period. Four weekly backup directories, six nightly and 23 hourly directories provide a level of granularity sufficient for most restoration needs.
Hourly backups are done at every hour except midnight. At midnight, the nightly snapshot is made. Weekly snapshots are taken each Sunday. The sub-directories created in the .snapshot directory are ordered chronologically, with a numbered suffix indicating the age, such as /uusoc/res/gdc/.snapshot/hourly.7
The larger the number in the sub-directory’s suffix, the older the snapshot. For example, a user’s /home/username/.snapshot/hourly.0 directory will contain the most recent snapshot of /home/username, while /home/username/.snapshot/hourly.7 would contain the snapshot of /home/username seven hourly snapshots previous.
If you have proper permissions to browse the original directory, you can ‘cd’ into the matching snapshot directories and freely browse them.
Restoring a File from a Snapshot
As mentioned before, restoring a file is simply a copy command. In the following example, we’ll assume that you are logged into one of the facility Unix systems.
To restore /home/username/tmp/myfile.txt from a snapshot four hourly cycles back, you would use:
cp -a /home/username/.snapshot/hourly.3/tmp/myfile.txt /home/username/tmp/myfile.txt
(Remember, chronological labels start with 0, not 1. Four cycles back would be marked “3”.)
On a Windows system, the same can be accomplished by opening a window for U:\~snapshot\hourly.3\tmp and dragging the file myfile.txt to a window for U:\tmp
Disk-to-Disk Backups
In addition to the local snapshots, a second filer keeps disk-to-disk copies of our primary filer. Backups are currently done at least daily and as often as every hour depending on the load it puts on our file server; however, snapshots are only kept on a monthly basis on the backup filer. You should use the snapshot instructions above if you wish to retrieve a file that is less than a month old.
Should you wish to retrieve a copy of a file that is more than a month old, you can access it via shell.cs.utah.edu:/uusoc/backups/{res,sys,home}/.snapshot/monthly.X. Where ‘X’ is a digit starting at 0 and is incremented by one for each month. i.e. 0 is the current month, 1 is one month ago, etc. These directories: home, res, and sys, are automount points so you’ll have to cd into them before they become visible.
If you see a directory within the snapshot directory starting with the name of tokyo, it is for the active backup process. Please do not access these directories since they are in a state of flux.
If you are managing your own system, please look below for the NFS and CIFS exports to access these directories.
Filesystems Served from the NetApp Servers
The following is a chart showing the served volumes and their respective mapping to Unix (NFS) and Windows (CIFS/SMB) systems.
| NFS Export | Unix Mount Point | Windows Share | Windows Mount Point | |
| ithaca.cs.utah.edu:/vol/vol3/home | /home | \\ithaca.cs.utah.edu\home | H: | |
| (N/A See above.) | /home/{username} | \\ithaca.cs.utah.edu\{username} | U: | |
| ithaca.cs.utah.edu:/vol/vol1/sys | /uusoc/sys | \\ithaca.cs.utah.edu\sys | S: | |
| ithaca.cs.utah.edu:/vol/vol2 | /uusoc/res | \\ithaca.cs.utah.edu\res | R: | |
| tokyo:/vol/vol1/sys | /uusoc/backups/sys | \\tokyo.cs.utah.edu\sys | ||
| tokyo:/vol/vol2/ | /uusoc/backups/res | \\tokyo.cs.utah.edu\res | ||
| tokyo:/vol/vol3/home | /uusoc/backups/home | \\tokyo.cs.utah.edu\home |
All of the above mount points should already be set up on facility managed Unix and Windows systems. If you want to mount a Windows share but your Windows machine is not part of the CS domain, you will be prompted for a username and password to allow the mapping to take place. Use your SoC username in the following format: ‘CS\username‘ and then enter your Active Directory password. You can also permanently map this by right clicking on “My Computer” and selecting “Map Network Drive”. Add one of the paths above, select a drive letter, click on “Connect using a different user name” and use the username and password as described above.
Differences between Unix and Windows File Permissions
There are substantial differences in the way that Windows and Unix handle file permissions. Unix uses a simple “user, group, other” style of file permission settings, while Windows has multi-layered group and user Access Control Lists (ACLs).
If you change permissions on a file using the Unix ‘chmod’ command, all other permissions of the Window’s ACL, other than attributes shared with the Unix permission set, will remain the same. If you change the ACL of a file from a Windows machine, the attributes which match the Unix permission settings will change to what you have set the ACL to. This can lead to problems if the default ACL holds permission settings in contrast to what is desired and are not carefully set by the user. The easiest solution is to change the Windows ACL to the desired settings and check the file from a Unix system, using the ‘chmod’ command to correct any problems.
Going over all of the ramifications of this structure is beyond the scope of this document. For a detailed description of permissions issues in a shared Unix/Windows environment on the NetApp system, please see Documentation at NetApp.
Another issue concerns file access control on Windows machines for open files. Where Unix systems allow multiple programs and users to access the same file (if permissions allow), Windows locks the file almost completely while in use. This means that if you have a file open with a Windows program, attempts to move, rename, or delete the file from Unix (or another Windows program) will result in a “permission denied” error and failure to access the file with the second program. This error will occur, even if it appears that the Unix permissions of the file are correct, because the open file lock is held internally in Windows and is not set as a filesystem attribute. The only way to remove this lock, is to close the file in the Windows application which is holding it.
Quotas
The quota system for the NetApp filesystem is covered in the Quota Guide. Please refer there for further information.