symbol for authentication required denotes that authentication is required.

Details on AFS Backup Volumes and the OldFiles Directory

You currently have your data spread over multiple volumes (volume is an AFS term for fix area on disk that contains a set of directories and files). Your home directory is usually all in one volume, your group directory is made up of several volumes. From the point of view of directories on a UNIX system, it all looks like one big directory tree. However, when you amoung directories, you may also be moving from one volume to another.

The quick and dirty what to determine what volume you are in when you are sitting within a given directory is to issue the AFS command that checks your volume quota:

fs lq .

You will see something like:

Volume Name            Quota    Used    % Used   Partition 
user.testuser           5000    3259       65%         73%

The first field tells you that you are in the volume "user.testuser".

Each volume has a clone of itself, called a 'backup volume'. The name of the corresponding backup volume can be determined by appending ".backup" to the volume name. For example, the backup volume for the home directory of 'testuser' as shown above is "user.testuser.backup".

The backup volume is recreated every day a the same time (5:30 am here at SPH). It contains a snapshot of the all the files in the corresponding non-backup volume at that time. At any time before 5:30 am, you can go into the backup volume and view or copy out files as they existed at 5:30 am of the previous day. Any files you may have deleted or edited during the day will be in the backup volume in their undeleted or unedited form as long as you get to them before the backup is recreated at 5:30 am.

Just because an AFS volume exists doesn't mean that you will automatically see it in a UNIX directory. A volume gets associated with a given UNIX directory and this is referred to as its "mount point". For example, the directory /afs/sph.umich.edu/user/t/testuser is the mount point for the volume "user.testuser". By changing directory (chdir) into /afs/sph.umich.edu/user/t/testuser, you are moving into the volume "user.testuser".

A backup volume can have a mount point just like any other volume. This means that you can associate a directory with it such that be changing directory into that directory (mount point), you are leaving some volume and entering the backup volume. By convention, we mount the backup volumes at the directory OldFiles, oldfiles or .oldfiles within its non-backup counterpart.

When you access the OldFiles, oldfiles or .oldfiles directories (or whatever else it may be called), you are actually accessing the backup volume rather than the corresponding non-backup volume.

There are a few confusing issues that can arise here. The first is that all volumes except for the root of our AFS cell have mount points that are within other volumes, thus forming a big tree of volumes. For example, the volume "sph.group" has the mount point of /afs/sph.umich.edu/group. One of your group volumes, group.singing, is mounted within sph.group at the mount point /afs/sph.umich.edu/group/singing. You may have more volumes which are mounted within /afs/sph.umich.edu/group/singing.

The confusion is introduced that mount points themselves are saved in the backup volumes. If you enter a backup volume, e.g. you move into the backup volume for your group's top-level volume by changing directory to /afs/sph.umich.edu/group/singing/OldFiles, you will see all the files and directories as they stood at the most recent 5:30 am backup volume creation. Any mount points that you have in group.singing, will also be visible in the backup volume. For example, you could have another volume group.singing.people mounted at /afs/sph.umich.edu/group/singing/people. Therefore, that mount point would be also mirrored in /afs/sph.umich.edu/group/singing/OldFiles/people. If you were to move into .../singing/OldFiles then, in turn, into .../singing/OldFiles/people, you would be moving out of group.singing.backup and back into a non-backup volume, group.singing.people.

Because people are not aware of the fact that AFS volumes are mounted one within another from the UNIX file system point of view, they think that by changing directory into an OldFiles directory, they will then be entirely in the backup volume as long as they don't change directory backup up out of OldFiles. This isn't true; they will exit the backup volume as soon as they change directory "down" into a mount point for another volume.

The second source of confusion is that we don't always create the OldFiles mount points (but we should). Because most people don't understand the volume concept (but they should), they are not aware when they are moving from one volume to another and the lack of an OldFiles directory at the top of each volume helps contribute to this ignorance.

The take-home lesson here is that you should know when you are changing volumes. If you need to recover a file that you have deleted by venturing into the backup volume, change directory to the mount point of the volume (the top of the directory tree within that volume) and look for the OldFiles (or similar directory). The command:

  fs ls *

will list all mount points withing a given directory and you should be able to spot the backup volume in the output. If you start moving down into directories within OldFiles, be sure that you know when you have moved into the mount point for a different volume (e.g. you leave group.singing.backup and enter group.singing.people). When that happens, you should look for another OldFiles directory for the volume that you have just entered.

If you ever find that the OldFiles mount point is missing and you know that you are at the top of a volume, ask our group to create it for you. If you're so inclined, you can create the mount point yourself with the command:

fs mkmount OldFiles somevolume.backup

This command will create a directory, "OldFiles" within the directory you are sitting when you enter the command which is a mount point for the volume somevolume.backup (the backup volume corresponding to the volume, somevolume -- you should replace this with your own volume name).

Questions:

Q: Are the files in the OldFiles directories from the day before, as usual, when the monthly backup is being done?

A: The files in OldFiles are a copy of the corresponding volume as it exists at around 5:30 am (it takes several minutes to create all the backup volumes so each OldFiles is created at a different time). So at 5:29 am, OldFiles contains files that existed yesterday at ~5:30 am. At 5:45 am, OldFiles contains files as they existed about 15 minutes ago. The creation of OldFiles (or, more accurately stated, the creation of the backup volume) is independant of monthly, weekly or daily backups. OldFiles is created each and every day whether or not we later dump that backup volume to a tape.

Q: If a person realized on the 16th that they deleted a file that was last seen on the 15th, could that person go into the OldFiles directory and restore the file?

A: It depends at what time the file was lost on the 15th and if the file even existed at the time of any backup volume creation (e.g. a file created at 5:50 am on the 15th and deleted at noon on the 15th would not appear in OldFiles on any day). If the file existed for more than 24 hours, then yes, it could have been grabbed from OldFiles after it went missing so long as it was grabbed before the next 5:30 am.