3.7 Have Copies of Important Configuration Files Available

3.8 Back Up Your System

There is no substitute for a comprehensive, reliable backup and recovery strategy. Without one, and without suitable preparation for the migration process, you are placing your business at risk. Here are two examples.

1. OS/2 Warp Server for e-business introduces a new file system (JFS). During the installation, the logical Volume Manager (LVM) will modify the server's partition table. In theory, any modification of disk structure is dangerous for the data residing on this disk and, if something goes wrong, could result in complete data loss. In this case, the only way to get the machine up and running again is booting from Disaster Recovery Diskettes and restoring the latest backup. Read more about Disaster Recovery in the Section 3.9 Prepare for Disaster Recovery.

2. If the migration to OS/2 Warp Server for e-business fails, the system will likely be in an undefined state. The machine may no longer boot properly, or the server service may refuse to start due to changed, and not yet reasonable, configuration parameters. Due to the system's complexity, you will have no guarantee in advance to get the system to work properly again. If you start to do modifications by hand, it could take hours of work to achieve this goal. If you fail, a restore from a previously taken backup will be the only way to get back to where you started.

   Important Note
   Basically, before starting to modify any productive environment, an administrator is in charge of a server backup. We strongly recommend not only saving the important files, but instead backing up the whole system. In other words, backup all partitions on all of the server's hard disks.

If, for any reason, you are unable to do so, you should at least have a backup of the following components (if they apply to your system):

1. Company's Data

2. User Home Directories

3. Applications

4. Operating System

5. User Logon Profiles

6. Server Configuration Data

We assume that you are already using a proven reliable backup solution for items 1-6. For further information on backup strategies, the redbook Using ADSM to Back Up OS/2 LAN Server and Warp Server, SG24-4682, might be useful.

1. DASD Limits

   For more information, refer to Section 3.12 Backup Directory Limits.

2. User/Group Definitions and Access Rights

   For more information, refer to Section 3.13 Backup Access Control Information.

3. Domain Setup Information

   For more information, refer to Section 3.14 Save the DCDB.

Steps 6-9 can be performed in one step with the SRVBU utility that will be described in the next section. Another useful tool for modifying your LAN Server environment or extracting information from it is LAN Server Management Tools (LSMT), which is introduced in Section 3.8.2 LAN Server Management Tools (LSMT) and further described in Appendix B. LAN Server Management Tools (LSMT). Both tools are available on the CD-ROM accompanying this redbook.

3.8.1 SRVBU Utility

SRVBU is a procedure written in REXX. Running on your server, SRVBU scans a predefined set of logical drives and performs the following actions on each of the scanned drives:

1. Backs up 386 HPFS Access Control Information to a file DISKX.ACL if X is the drive letter of a 386 HPFS formatted partition.

2. Backs up the NET.ACC to the file NETACC.BKP.

3. Backs up DASD limits to a file named DISKX.DLM if X is the drive letter of a DASD limit enabled partition.

4. Copies important server configuration files as specified in the SRVBU.INI file.

5. Writes a disk statistics file if specified in the SRVBU.INI file.

6. Writes a processing log as specified in the SRVBU.INI file.

7. Writes an error log as specified in the SRVBU.INI file.

Figure 4 shows the content of the directory holding the files saved by SRVBU.



Figure 4: Files Saved by the SRVBU Utility

Figure 5 illustrates the SRVBU.INI file to help understanding how this utility works:

; Purpose: ; - get from all HPFS disks the access control list ; - DASD limit list ; - get statistics from the disks ; - copy crucial files to a safe place based on the Julian date [TARGET] DestinationPath = f:\srvbu StatisticsFile = f:\logs\dskstat.csv LogFile = f:\logs\srvbu.log ErrFile = \srvbu.err DasdFile = f:\logs\dasd.log [REMOTECOPY] RemoteCopy = 1 AliasName = SRVBKP DriveLetter = Y: [ARCHIVE] Days = 30 [DISKS] C: D: E: F: G: H: [FILES] \config.sys \startup.cmd \ibmlan\srvbu\srvbu.ini \os2\install\ipl.log \ibm386fs\hpfs386.ini \ibmcom\protocol.ini \ibmlan\ibmlan.ini \ibmlan\rpl\rpl.map \ibmlan\accounts\netacc.bkp \ibmlan\logs\netaud.bkp \mptn\bin\setup.cmd \mptn\etc\ipdialer.ini \mptn\etc\namedb\named.bt \mptn\etc\namedb\named.ca \mptn\etc\namedb\syslog.cnf \mptn\etc\namedb\named.rev \mptn\etc\resolv2 \mptn\etc\hosts \mptn\etc\dhcpcd.cfg

Figure 5: SRVBU.INI File (Part 1 of 2)

\cmlib\acscfg.cfg \cmlib\acscfg.cf2 \cmlib\acscfg.ndf \cmlib\acscfg.sec \pcomos2\private\p3270a.ws \pcomos2\private\p3270b.ws \pcomos2\private\p3270c.ws \pcomos2\private\p3270d.ws \pcomos2\private\p3270e.ws \pcomos2\private\pcomm.bch \adsm\dsm.opt \adsm\dsmc.opt \adsm\dsmp.opt \pgms\adsm\dsm.opt \pgms\adsm\dsmc.opt \pgms\adsm\dsmp.opt \netprint\ibm4033.dat \netprint\redirect.err \netprint\interact.log \ibmcom\rfcnames.lst \ibmcom\rfcbcst.lst \softdist\nvdm.cfg \pgms\sofdist\nvdm.cfg

Figure 6: SRVBU.INI File (Part 2 of 2)

The [TARGET] section defines the name of the different log files and the path to the directory (DestinationPath=) that will be the root of the subtree containing the backup sets.

If the keyword RemoteCopy= in the [REMOTECOPY] section is set to 1, an additional NET USE command will be performed using the values of the keywords AliasName= and DriveLetter=. Furthermore, a directory with the server's name will be created if not already there, and the gathered information will be stored in a subdirectory underneath. This feature can be used to gather the critical data of all the company's servers on one alias.

No matter if copied locally or remotely, the gathered information is stored in a directory whose unique name is computed based on the Julian date and the number of backup sets specified by the keyword Days= in the [ARCHIVE] section of the SRVBU.INI file. In addition, the DISKX.ACL files are stored in the root directory of each partition they belong to.

[D:\]\IBMLAN\SRVBU\SRVBU * SRVBU Version 7.12 running at 14/12/98 22:00:07 > Destination Path: F:\SRVBU\18 > Remote Path: Y:\SRV163\18 * SRVBU Ended: 5.92 [D:\]

Figure 7: Running the SRVBU Utility

In the example shown in Figure 7, Days= was set to 30, which would give you access to the last 30 backup sets. On December 14th, 1998, which is the Julian day 348, the directory's name is 18 calculated from the formula 348 mod 30. This value can also be calculated with the MODCALC utility shown in Figure 8, which can be found on the CD-ROM accompanying this redbook. MODCALC is not officially supported by IBM.



Figure 8: SRVBU Directory Name Calculator

Figure 9 shows an example of the directory structure created by SRVBU.



Figure 9: Saving Location of the SRVBU Utility

Hint
Calling SRVBU with the /t parameter will output trace information to the screen.

With SRVBU, you can easily set up a scenario where the data of the company's critical servers is saved automatically. Make sure SRVBU is running on each server and that RemoteCopy= is set to 1. Use a scheduling program to start a command file automatically at a certain time. The command file should perform the following:

• Log on automatically to the network (make sure the user has RCWXDA rights or is logged on as with administrator rights).

• Check if the drive letter is already in use. In this case, SRVBU will fail and make an entry in the error log.

• Call SRVBU.CMD, which will copy the data to the destination path specified in the SRVBU.INI file.

• Log off from the network.

Gathering multiple generations of the critical server's data in one spot is both extra insurance against data loss and a useful feature for an administrator who could easily get information about all servers just by looking at this one alias.

3.8.2 LAN Server Management Tools (LSMT)

LAN Server Management Tools is a collection of REXX procedures that can either be called from the command line or from a PM-based GUI. LSMT is provided as-is and is not officially supported by IBM. Appendix B. LAN Server Management Tools (LSMT) provides information on obtaining LSMT.

LSMT acts as a two-way tool. You can:

• Export LAN Server configuration information to ASCII files using the GETxxxx commands. These files can easily be modified or backed up.

• Re-import these ASCII files to apply the modifications you have done using the SETxxxx commands, which form an exact counterpart to the GETxxxx commands following the same syntax.

Table 15 shows the call syntax of the available procedures, a brief functional description, and the name of the related output file that will hold the extracted information. The /m parameter (mute) suppresses output to the screen.


Table 15: LSMT GETxxxx Procedures

For more information about LSMT, please refer to Appendix B. LAN Server Management Tools (LSMT), where this tool is explained in more detail.

3.9 Prepare for Disaster Recovery