Hans Dieter Petersen

RHRZ University of Bonn

The Computing Center (RHRZ) of the University Bonn runs since 3 year AFS-Fileservers for today about 20.000 Volumes (resp. DFS filesets). The backup was formerly done with ADSM V1 Server running under VM/XA SP 2.1, where the AFS Client under UNIX saves the files. This is done for the HOME-Volumes with help of DOMAIN-Option for each HOME-Volume. Although the AFS-ACLs are saved, the AFS-Volume-information (header) and the Mount-points are not saved by the AFS-Client.

The AFS-Backup command (/usr/afsws/etc/backup) is a Client-Server implementation which is contained in the normal AFS Program Product. It does the dump of AFS-Volumes to a so called Tape-Server-Program (butc) and saves the dump information into an ubik driven database (/usr/afs/db/db). IBM now official offers an ADSM-API programme buta, which acts as the butc-programme, but uses ADSM-Filespaces as tapes.

Since the introduction of ADSM V3.1 under UNIX, the RHRZ switches over to the new way of dumping AFS-Volumes with the buta interface to ADSM. The benefits are the possibility to restore an AFS-volume with all information and to restore an AFS server partition with one command in the case of disk failures on fileserver disks.

The backup is done in steps:

The filespace name is generated from the AFS-dump-id, which changes from command to command. So there is no way of incremental backup in the sense of ADSM filespaces. AFS backup can be configured to do incremental backups in a similar way as for the UNIX-dump command. AFS-backups saved by ADSM look like archives. The administrator has to setup a special expiration job, which does the deletion of the filespace form ADSM and the dump-information from the AFS backup database. The delbuta command is included in the ADSM buta client product.

The talk will discuss, where the clients and server parts of the different commands should run. Some performance data will be offered and further hints for restore will be included.

Hans Dieter Petersen

RHRZ University of Bonn

NIM offeres a way of doing a mksysb (make system backup) driven by the NIM server on a running NIM client. In the case of disk errors on the system disk, a mksysb install is the easiest way of restoring a system. A new installation from the NIM server using bundles or scripts may contain errors, when the software bundle are setup in the administrativ tasks.

The NIM mksysb object allows only the excluding of UNIX-path-descriptions. There is no way excluding volume groups or filesystems. To reduced the files for the rootvg, it is nescessary to setup an exclude file (avoid the dumping of /afs, the root of the AFS-filespace). This can be automated via rsh (or ssh) scripts, which are running on the NIM-Server.

The mksysb data is saved on the NIM server resp. a machine, which has enough disk space which is accessed via NFS. The amount of needed disk space depends on the number of workstations you intend to dump. We use ADSM to do a backup of the mksysb data into a backuppool after the creation and then delete them from the disk. The mksysb data is stored on a disk of the ADSM server, to use the sharedmem connection from the client to the server.

Excluded from this way of saving the mksysb data is the ADSM-Server workstation. The data for the ADSM server is stored on the NIM server in two files.

The restore can be done by two steps in the case of disk corruption on servers:

To get the most recent running version of the rootvg, it is not usefull to save the whole amount of 600 MB each day. We set up a normal ADSM backup of the DOMAIN / with several excludes, to save files, which probably change often. So we can distribut the mksysb backups over one ore two weeks for all our server workstations, doing ADSM incremental backup on file base daily or more often, when the data changes more rapidly.

The talk will give some hints and performance numbers of the mksysb backups for the servers in the compunting center of the University of Bonn.