When I started on our DR process, I just did full-volume dumps which included the SFS servers. At the DR site, things came up fine for about 5 DR exercises. Then SFS died. We had grown enough that the activity was re al during the full-volume backup. When I discussed possibilities with IBM, i t became clear that ANY external backup of SFS, while the SFS was running, had the potential to die after restore. So I changed our process to use SFS utilities to backup the content and full-volume backup of the 191 and 192
disks which are used as straight CMS disks. All of the 3xx disks (ones really used by SFS via *BLOCKIO) were migrated to volumes that are NOT pa rt of the full volume backups. At the DR site, I allocate (label and attach to system) these volumes and autolog the SFS servers. Each server has code i n the profile to detect the presence of a valid SFS data disk. If the data disk is okay then it starts normal (back home type of startup). If the di sk is not a normal SFS disk, then this is a first IPL at DR and the profile runs a FILESERV GENERATE. When that is finished, I can use the FILEPOOL RELOAD to load the content back into the SFS server. So either stop your SFS servers for the full volume backup or unload the sfs data and reload into new SFS servers at the DR site. /Tom Kern /301-903-2211 On Fri, 28 Mar 2008 16:03:22 +0100, Colin Allinson <[EMAIL PROTECTED] m> wrote: >I have done a refresh of our DR system. To put this in context - it is t he >function that we need rather than any particular data. > >I did this as full pack dumps and expected a few issues on the restart >after the restore (changing spool files etc.). I did expect to have some >SFS server issues with active files. > >What has happened is that most SFS servers start OK but the most active >one just dumps on startup. > >Is there any way to do a verification/clean process so that I can get it >started with whatever is valid - or do I have to take another complete >dump with our production system down. > >I would welcome any suggestions. > > >Colin Allinson > >Amadeus Data Processing GmbH >
