This page has been transferred from the previous website as-is. The information is still relevant.
UNIX File System Backups at SLAC
UNIX File Systems
For UNIX, there are several network file systems managed by the Computing Division, but we will broadly refer to their backups as NFS and AFS backups. NFS and AFS are backed up in different ways and have different backup schedules. However, there are a few underlying policies that were followed in setting up both backup systems.
NFS and AFS backups are performed automatically on a daily basis and should be viewed primarily as a way of recovering from hardware failures, not as an archival system. This means that the backups are not retained forever. Please see the retention period information below for each backup type.
NFS Backup and Recovering Your Own Files
By default, we do not backup NFS file systems unless requested to do so. In those cases, backups run nightly and tapes must be provided by the group who owns the data. Please submit an NFS backup request to unix-admin.
Those NFS file systems that are backed up are done so via IBM Tivoli Storage Manager (ITSM, or commonly just TSM) software. We currently support RHEL 6/7 and Centos 7 x86/x64 clients. Solaris SPARC/x86/x64 clients will be supported until existing hosts are retired.
Files are recovered from TSM by using the dsmj (GUI) or dsmc (command line) programs. If you backed up files from a flora public machine, then you can also restore the file from a flora. Users may recover any file owned by their account using either interface, though the graphical interface may be easier to understand. See the TSM Restore Web page for instructions on restoring your files. To request the restoration of files you do not own or that were backed up directly from an NFS server (as opposed to the client you login to), send email (with an explanation) to unix-admin.
TSM is an incremental backup system. It backs up only the files that changed since the last backup, and maintains information on the state of the client file system. It is possible to restore the file system to the last backup state, and to restore some older versions of deleted files. TSM is not configured to restore the file system to the state it had at a specific point in time, i.e., it may not be possible to restore a directory to the way it looked 4 weeks ago at 12pm or any other particular day or time. Such a policy would use significantly more tape space since the backup server would be forced to keep a copy of every file version going back to that date.
TSM Schedule and Retention Policy
The TSM backup runs each night, usually starting sometime between 12:00AM-5:00AM on TSM client machines.
TSM maintains backup data for both active and inactive file versions. An active version of a file is the most recent backup copy of a file stored in TSM for a file that currently exists on a file server or workstation. An active version remains active and exempt from deletion until: 1) replaced by a new backup version or 2) TSM detects, during an incremental backup, that the user has deleted the original file from a file server or workstation. An inactive version of a file is a copy of a backup file in TSM that either is not the most recent version, or the corresponding original file was deleted from the client file system.
Unless otherwise stated, the STANDARD retention policy is as follows:
- Up to 31 days of a particular file are kept on tape as long as the file exists on the client's file system.
- Only the most recently backed up version on tape is active. All other versions on tape are inactive.
- Once a file on tape goes inactive, it expires after 31 days and gets deleted off tape.
- If a file is deleted from a client's disk, several things happen during the next full incremental backup: 1) the active version of that file on tape will be marked inactive, 2) all inactive copies start expiring off tape as they reach 31 days of age, and 3) the last remaining inactive copy (which is also the most current backup copy) will be kept for 31 days, after which it expires too.
- Note that as long as a file remains on a client's disk, its latest backup copy will remain active on tape and not expire.
What does this all mean? Basically, while a file still exists on disk, the last 31 days of backups are also on tape. But once a file is deleted from disk, all of its copies on tape will expire as they each reach 31 days of age. So, for example, if a file is changing every day and then gets deleted, there will be 31 copies on tape. Each day, the current oldest copy will expire. After 31 days, no more copies will remain on tape.
We will notify file owners in advance if their backups are not using the STANDARD retention policy.
AFS Backup and Recovering Your Own Files
AFS backup is provided by the native AFS backup system. The unit of AFS file storage and backup is the volume. Typically, each user's home directory is a single volume. For the first level of backup, AFS creates a copy of each volume at midnight each night. This copy is called a "backup volume". You can find this backup volume from the .backup link in each home directory. If you have just deleted or damaged a file that existed at midnight, type "cd ~/.backup" to find a version of it from the previous day and copy it back into your home directory.
Note that backup volumes are automatically "mounted" for home directory volumes only. This means that you must manually mount backup volumes for group volumes or user sub-volumes if you need to recover files from the midnight copy. To do this you will need the volume name. The easiest way to get this is to execute the "fs listquota" command on the directory in question. For example, if you had accidentally removed a file from the directory /afs/slac/g/babar/data/data01, you would type
> fs listquota /afs/slac/g/babar/data/data01 Volume Name Quota Used %Used Partition g.babar.data.01 500000 223503 45% 32%
The first column lists the name of this volume as "g.babar.data.01". To get the name of the backup volume, append ".backup", then mount it in your home directory with the command:
> fs mkmount ~/bdata01 g.babar.data.01.backup
and reference it at ~/bdata01. (You may pick any name in place of bdata01 as long as the directory doesn't already exist.) The only privileges you need for fs mkmount are insert and administer for the directory you are mounting in (such as your home directory).
We recommend doing such mounts in your home directory to avoid creating directory "loops". For example, it is tempting to mount the .backup volume in the volume you're dealing with, because that is frequently your current directory. However, if you mount a volume's .backup volume within itself, and you leave the mount there, then tomorrow and thereafter, .backup and .backup/.backup and .backup/.backup/.backup etc. will exist. This causes real problems to recursive commands like "ls -lR", "find", and "du". We also recommend that you remove the mount when you are done with it, because you won't really like seeing it under your home directory. You can remove it with
> fs rmmount ~/bdata01
AFS Backup Schedule and Retention Policy
The AFS backup is a series of full and incremental backups, designed to provide complete coverage of recent changes, and sparser coverage going back in time. A level 0 backup is a full backup of the AFS file system. A level 1 backup is an incremental backup of all changes since the previous level 0 backup. A level 2 backup is an incremental backup of all changes since the previous level 1 backup. The schedule of AFS backups is as follows:
Level 0: A full backup is performed starting at midnight on the first Sunday of each month. This backup is retained for six months. After six months, only the quarterly (January, April, July, October) backups are kept. The quarterly backups are retained for one year.
Level 1: An incremental backup is performed starting at midnight every Sunday morning (except for the first Sunday of each month). These backups are retained for two months.
Level 2: An incremental backup is performed starting at midnight Monday through Saturday. These backups are retained for two weeks.
The result of that schedule is that a volume can be retrieved from the daily backups for the first two weeks, then from the weeklies for the first two months, then from the monthlies for the first six months, and then from the quarterlies for one year.
AFS backups are not yet retrievable by users with the exception of those files that are located in the user's .backup subdirectory created each midnight. See the AFS Restore Web page or send email to unix-admin to request the retrieval of a file from backup.
Related articles