ftp.seagate.com/2014.07.ftp.seagate.com.tar/ftp.seagate.com/pub/palindrome/technote/tn9506.asc

Text File | 1995-05-23 | 18KB | 311 lines

Tech Note:  TN9506
May 22, 1995.

Centralized Backup / Distributed Restore.



Scope:

     This Tech Note describes a technique that can be used to save time in
a full-server recovery situation.  This Tech Note contains instructions for
use on NetWare 3.1x and 4.x servers, and for Palindrome NLM backup products
(for NetWare) versions 3.1 and 4.0.  Some related issues are covered in
detail in other Palindrome Tech Notes, and some of the steps described in
this Tech Note are outlined in detail in the product manuals.
(see bibliography at the end of this Tech Note.)

Abstract:

     The CB/DR (Centralized Backup / Distributed Restore) technique is
intended to save time during a full server recovery situation, when the
server being recovered is being protected by a Palindrome installation on
a different server.  The theory is, that by doing this, you not only save
the time involved in transferring the data across the network to the server
being restored, but in a disaster situation, you do not have to restore the
server Palindrome is installed on before beginning the restore of the other
server.
     The first question you must ask is, wether this technique is practical;
Is the amount of data to be restored of a sufficient amount that the time
saved is greater than the time it takes to perform the technique.  This is
dependent on a large number of factors; the speed of the network connection,
the speed (processor) of the server Palindrome is installed on, the speed
of the server you are restoring data to, the speed and efficiency of the two
server's bus (ISA, EISA, etc), the memory configurations of the two servers
(free cache buffers, directory cache buffers, packet recieve buffers, etc.),
and the type and amount of data to be restored.
     It is important to note here, that this technique hinges greatly on
preparedness.  You should read this document thoroughly, and refer to the
corresponding portions in the product manuals, and be familliar with the
concepts and terminology.  All personell who may be involved with the
proceedure should be fully briefed.  It is also strongly recommended that you
attempt several "dry runs" in a test environment first.  Things you learn in
the lab may save you from problems and frustrations in an emergency situation.
     This proceedure involves hardware installation, and that, in of itself
can be a very time consuming and troublesome step.  This is probably the
most important step to optimizing this technique.  If you can eliminate ahead
of time, problems that can arise during the hardware installation step, you
will be that much closer to getting the server restored quickly.  One
suggestion for accomplishing this is to have a SCSI card already installed
in the server that is to be restored.  This usually carries some serendipity
with it because the same SCSI card can also be used for the server's hard
drive.  Just be certain that the SCSI card is on the Palindrome Certified
Devices list, and that there is an open SCSI ID to mount the tape drive on.
(for hardware installation details, refer to the documentation  included with
the backup software).

Conventions:
     For the purpose of example, we will refer to an imaginary network with
two NetWare 3.12 servers, named FS1 and FS2, each of which has a single
volume named SYS.  Palindrome is installed in the \PNA directory on FS1, and
all the appropriate supporting software is installed and up to date, for
example, CLIB, STREAMS, SPXS, TLI, SMDR, and TSA312 (TSA name is specific to
the version of NetWare running on the server).  The Palindrome software
installed on FS1 is protecting the two server's SYS volumes, and Binderies,
and the history databases (which track the backups and where data is
located in the backup library) are centrally located on FS1/SYS:.
The backup device is referred to as a tape drive, but is by no means limited
to this technology, as Palindrome products are supported by a variety of
tape and optical devices.
     Where specific instructions for the 4.0 Palindrome products are needed,
they will be noted, as will differences in operation on NW 4.x networks, or
other situations where the history databases might not be available such as,
if FS1 were also down, or if FS2 is being restored on an isolated subnetwork,
or if the histories are distributed, or centralized on a third server.  .  .
Special instructions are noted with a pair of right-pointing angle brackets
(>>).

STEP 1.  FS2 needs to be restored.  Most would argue that the first thing
         That must be done is to re install NetWare to allow the server to
         be visible on the network, and to allow it to mount it's volumes.
         The Palindrome Server Recovery Tech Note (or, alternatively,
         Appendix C in the Palindrome 4.0 Administrator's Guide, on the
         same subject) details a process by which
         a pair of floppy disks are prepared ahead of time, with the bare-
         minimal files necessary to run NetWare, and the Palindrome backup
         software, plus a specially developed utility that copies these
         components to the server volume, and the startup files and disk
         drivers to the DOS partition.  This proceedure can significantly
         reduce the time involved in the first step of the process.
           Part A.   Install NetWare.  Make the server available on the
                     network, and give it the name FS2.
                     >>If FS2 is a NetWare 4.x server it is strongly
                       recommended that NDS be protected and restored through
                       partitioning and replication.  Restoring a NetWare 4.x
                       NDS from tape raises many complex issues that are
                       beyond the scope of this document, but not beyond the
                       scope of adaptivity.  Please see the Palindrome Tech
                       Note, Protecting NW 4.x servers, and the product
                       documentation for details on this topic.
             IMPORTANT:  It is assumed that the "new" FS2 you will
                     be restoring data to has the same namespaces installed
                     (MAC, OS2, etc.) as the "old" FS2.  If the namespaces
                     are not the same, unexpected results may occur.  See
                     the product manuals for details.
             Part B.   Install Hardware.  Install a SCSI controller card in FS2,
                     if one is not already installed.  Make sure it is listed
                     on the Palindrome Certified Devices List, and make sure
                     that the driver is the correct one, and that it properly
                     functions with the Palindrome software.  This is a place
                     where testing ahead of time will really pay off.
                     Connect the tape drive to the SCSI bus, making sure that
                     there are no SCSI ID conflicts and that the bus is
                     properly terminated.  For more details on completing
                     this step properly, see the Installation and Support
                     Guide included with your product documentation.
                     Make sure that your backup media are available,
                     especially the latest backup.  If you are unsure about
                     which tape was used in the last backup, you can journal
                     all of them with the Palindrome software, and check the
                     "last update date", and compare them to find the latest
                     tape.  This technique is important in a situation where
                     your current tapeset is not available, (such as in a
                     disaster).
              Part C.   Install the Palindrome Backup Software.  Installation is
                     an important step, because it locates the software and
                     related support files on the new FS2 platform.  Follow
                     all the standard instructions for installation for your
                     particular version, including creation of the Autologin
                     user.  Do not spend time configuring the software or
                     populating the protected resource list, as all that
                     information will be replaced in the next step.
                     You should also deactivate the Palindrome software on
                     FS1 by unloading the running Palindrome modules at the
                     console.
                     >>If the Palindrome software is version 4.0, you should
                       run the server prep disk first, before you install the
                       software from the workstation.
                     >>If FS1 had/has NW 4.x running on it, be sure to delete
                       the old Job Queue object that was in use by the old
                       installation using NWADMIN, before beginning the
                       installation on FS2.

STEP 2.  Once the Palindrome software is installed, and the server is running,
         you need to restore the Control Database.  The Control Database is a
         set of two files in the \PNA directory named ASDB.PAC and ASNX.PAC.
         They maintain the software configuration, the protected resource
         list and history location information for all protected resources,
         as well as the configured devices information, and auto login user,
         and tape library.  When you install the software, INSTALL.EXE
         creates a new set of Control Databases.  These two files must now be
         deleted.  You can then run PNA from the DOS prompt on the
         workstation, and the program will note the absence of Control DBs,
         and proceed to prompt you through restoring them.  Put the most
         recently updated backup tape into the tape drive, and the software
         will configure the device, and ask you to supply the autologin name
         and password, which was lost when we deleted the PACs, and will be
         restored when we get the Control Databases back from tape.
         Alternately, you could simply copy the AS*.PAC files over from the
         FS1/SYS:\PNA directory, or "sneaker net" them over on floppies.
         However, it's VERY important that you make sure that the Control
         Database files you use are the MOST CURRENT available.  The reason
         why it's preferred to restore from tape, is that that insures that
         the Control Databases and History Databases are in synch.
         >> If the Palindrome Software is version 4.0, then in order to
            properly restore the Control Databases, you must load PAL.NLM
            on the server console, and select Restore Control Database from
            the menu presented.  4.0 uses six files for a Control Database,
            but they all have a PAC extension, and are all located in the
            \PNA directory.  Additionally there are 4 other PAC files in the
            \PNA directory, but you should delete these as well, and allow
            them to be restored from tape, or by copying.

STEP 3.  When the Control Databases are restored, you may now run the
         Palindrome software as you would at any other time.  Other factors
         can affect this.  .  .
         >> If FS1 is no longer available on the network, and the file
            histories for FS2/SYS: and FS2/Bindery were stored on FS1, then
            the history location for the FS2 resources must be reconfigured
            to FS2/SYS:, or another location that is available on the network.
            To do this, enter the PNA software, from the System Screen,
            select Configure - Protected Resources List, and highlight the
            resource to reconfigure.  With the resource highlighted, press
            enter, then highlight the history location of that resource, and
            press enter again.  The software will present you with dialogs to
            select a new server and volume.  Remember, only servers running
            the Novell Target Service Agent software will be listed as
            available for this.
            Once the history location has been reconfigured, you must restore
            the histories from tape, (or copy them from the appropriate
            subdirectory on FS1/SYS:, but since we are assuming that the
            reason we're doing this is because FS1 is down, we restore from
            tape.  This is simply a note that copying them over would work).
            To restore histories, tag the resource in the System Screen, and
            select Restore - File History Database.  The software will prompt
            for the appropriate tapes.
            >> For Palindrome 4.0, history location is configured in Resource
               Manager on the configure screen, click on the edit button.
               When history location is reconfigured, again, you must restore
               the history databases from tape, using the Operation Menu,
               Restore History Database.

     Once the Palindrome software installation is back "together", with the
regular hardware installed and running, the control and history databases
restored and on line, the installation is effectively "moved" to FS2.  If for
any reason you wanted to keep the installation on FS2, and not move it back,
you could do that.
     At this point, you can go ahead and begin the restore of FS2's data as
you would any other server.  However, there are a couple of things that can
cause problems that you need to be aware of.  .  .
     >> If FS1 is no longer available, and you have redirected the histories
        for it's resources to FS2, or another server, when you attempt to
        view it's files in 3.1's Volume Screen, or 4.0's File Manager, 3.1
        will not be able to connect to the FS1/SYS: resource.  4.0 will be
        able to display the history information, but not the volume as it is.
        Obviously, you won't be able to restore anything to FS1 in this case.
     >> Once you restore the bindery of FS2, the autologin user will regain
        all of it's old attributes.  Which means, the user you created in
        STEP 1 will be gone, and another user (the original autologin user
        from FS2) will take it's place, with the same username and password.
        Just because the user has the same username and password doesn't mean
        it's the same.  The login script will be back to what it was, and
        the rights and restrictions too.  Be aware of these changes when they
        happen.
     >> If FS1 and FS2 were a NW 4.x network, and you were protecting them
        with Palindrome version 3.1, the same things apply as above with a
        bindery user, because 3.1 uses bindery emulation when logging into
        NDS.
     >> If you were forced to restore NDS using the backups, rather than
        replication, other complex issues are involved that are beyond the
        scope of this document.  Please see the Palindrome Tech Note,
        Protecting NW 4.x servers.

Bibliography:

     This Tech Note covers a relatively simple proceedure with Palindrome
backup products, however, like many simple proceedures with our software,
it ends up touching on a large number of other issues which are very complex,
like NDS backup and restore, and hardware installation.  There are other
excellent sources of information on these topics, and they are listed below.
     Other Palindrome Tech Notes are available either in Palindrome Support
Encyclopedia, or the Palindrome BBS, or our forum in Compuserve,
GO PALINDROME.  The Palindrome BBS is 708-505-3336, 8n1.

TN9401 Troubleshooting NLM hangs.
           Hints on server tuning, and instructions for updating NLMs.
       filename TN9401.ASC
TN9402 Creating Archivist user for NW 4.02
           (NDS issues for PNA 3.1)
       filename TN9402.ASC
TN9404 Moving a 3.1 NLM installation.
           Essentially covers the same proceedure but for 3.1 only.
       filename TN9404.ASC
TN9405 Server Recovery Tech Note (NW 3.1x)
       filename TN9405.ASC
TN9406 Server Recovery Tech Note (NW 4.02)
       filename TN9406.ASC
TN9501 Server Recovery Tech Note (NW 4.1)
            These Tech Notes detail how to recover a NetWare server by
            using a set of two prepared floppy disks, as opposed to
            going through the NetWare installation process first.
        filename TN9501.ASC
Palindrome Certified Devices List
            filename CDL31.ASC and CDL40.ASC
Palindrome Tested Device Driver Configurations List
            filename TSTDRVR.ASC

Several sub-proceedures are not described in detail in this tech note, but
are described in your product Manuals.  Where to find these proceedures is
listed below.


Installation of Backup Hardware:
3.1 Installation and Support Guide, ch. 2
4.0 Installation Guide, ch. 1

Installation of Palindrome Software:
3.1 Installation and Support Guide, ch. 3, and 4,
4.0 Installation Guide,    ch. 2 and 3

Restoring Control Databases:
3.1 User's Guide, p. 1-13, 6-2
4.0 Administrator's Guide, pp. 1-19 thru 1-21

Configuring History Database Location:
3.1 Reference Guide, p. 2-27, Users Guide, p. 3-18, 3-19, 3-20
4.0 Administrator's Guide, p. 6-22, 6-32, 6-36, 8-21 thru 8-24,

Restoring History Databases:
3.1 Users Guide, p. 3-22, 5-15, 6-4
4.0 Administrator's Guide, 6-18,

Full Restore of a Server:
3.1 Users Guide,  ch. 6
4.0 Administrator's Guide, ch. 6