Table of Contents

Administering Network Registrar

This chapter explains how to administer and control your servers' operations through Network Registrar's GUI (the ntwkreg program) and CLI (the nrcmd program).

Table 4-1 lists the major Network Registrar server administration tasks and the sections where you can find procedural information about how to accomplish those tasks.

For details about the Network Registrar user interfaces, see "Network Registrar User Interfaces."

Administering Clusters

A cluster is a group of DNS or DHCP servers that share the same Network Registrar database. Adding a cluster tells Network Registrar about the existence of a cluster. To configure or administer the cluster, you must first connect to it.

Note   The Network Registrar DNS and DHCP servers typically run on the same physical machine. In this case, the term cluster refers to the physical machine.

Adding a Cluster

Each cluster requires a user name-password combination, which Network Registrar uses to control access to each cluster.

Using the GUI:

Step 1   In the Server Manager window (Figure 3-1), click the Add button on the toolbar (or select List of Clusters in the Server Manager window, then click the right mouse button to click Add Cluster). This opens the Add Cluster dialog box (Figure 4-1).

Step 2   Enter the host name of the cluster. (Enter localhost if the cluster is located on the same machine as the GUI.) Do not use a host name that includes the at (@) symbol as part of its name.

Step 3   Click OK. You may need to add a user name, password, and license key. (See the "Starting the GUI" section.)

If the host name you add does not exist on the network, you cannot connect to it. In fact, if you have the Connect to this cluster once added option selected, an "Unable to connect to cluster" warning appears. (Remove any such clusters by clicking the Remove button in the toolbar.)

Viewing the State of a Cluster

To see whether a cluster is connected or not, you can view its state.

Using the GUI:

Step 1   In the Server Manager window (Figure 3-1), click the Admin toolbar button, then click Clusters. The State column indicates the state of the cluster, Connected or Disconnected.

Step 2   Click Close to close the Clusters dialog box.

Using the CLI:

The CLI is always connected to one cluster if it is successfully invoked.

Connecting to a Cluster

After you add a cluster to Network Registrar, you must connect before you can configure or administer the cluster.

If you try to connect to a cluster being used by someone else, Network Registrar warns you that the cluster is locked and tells you who is holding the lock. The format of the warning message is:

username@machine-name.process-id-number

• The username is the Network Registrar login user name. Note that it is case-sensitive.
  
  
• The machine-name is the name of the machine on which Network Registrar is running.
  
  
• The process-id-number identifies the unique process on machine-name in which the GUI or CLI is running.
  
  
• • On Solaris, the machine-name may differ from the machine on which the GUI is being displayed.
    
    
  • On Windows 95 or Windows NT, the GUI always runs and displays on the same machine (regardless of where the GUI executable resides).
    
    

If someone else is using the cluster, then disconnect. If you want to connect to a locked cluster, then contact the person who is currently connected and request that he or she disconnect.

You can override the lock, but you should do so only if you know that no one else is editing the cluster, for example, if the other system had crashed while the cluster was connected.

Using the GUI:

Step 1   In the Server Manager window (Figure 3-1), right-click the cluster to which you want to connect. Alternatively, click the Admin toolbar button, click Clusters, then select the cluster.

Step 2   Click Connect.

Step 3   If in the Clusters dialog box, click Close to close it.

Using the CLI:

Use the nrcmd -C switch to connect to a cluster. For example, to connect to the cluster named mycluster, enter the following from a command line prompt on an NT machine:

C:\Program Files\Network Registrar\bin> nrcmd -C mycluster 
 

Disconnecting from a Cluster

When you disconnect from a cluster, you can no longer configure or administer it from that workstation. Another user can then administer the cluster.

Using the GUI:

Step 1   In the Server Manager window (Figure 3-1), right-click the cluster from which you want to disconnect. Alternatively, click the Admin toolbar button, click Clusters, then select the cluster.

Step 2   Click Disconnect.

Step 3   If you are in the Clusters dialog box, click Close to close it.

Using the CLI:

Use the exit command at the nrcmd> prompt to disconnect from a cluster.

nrcmd> exit 
 

Removing a Cluster

When you remove a cluster, the user interface no longer knows about the cluster and its name does not appear in the Server Manager.

Using the GUI:

Step 1   In the Server Manager window (Figure 3-1), right-click the cluster you want to remove. Alternatively, click the Admin toolbar button, click Clusters, then select the cluster.

Step 2   Click Remove.

Step 3   Click Yes in the Network Registrar dialog box.

Step 4   If you are in the Clusters dialog box, click Close to close it.

Administering Users

Using the Admin GUI or the CLI admin command, you can add administrators, change passwords, and configure administrators for the cluster.

Adding an Administrator

You can add administrators responsible for the clusters.

Using the GUI:

Step 1   From the Admin menu, select Add Administrator.

Step 2   Enter the administrator's user name. You can choose any text string for the administrator's name.

Step 3   Enter the administrator's password.

Network Registrar uses the password to authenticate the names. If you create an administrator without a password, Network Registrar cannot authenticate the name and thus will deny that user access to the cluster.

Step 4   Enter the password a second time.

Step 5   Select the clusters the administrator can access.

You can only select clusters that were added (see the "Adding a Cluster" section). You do not have to be connected to the cluster to add an administrator.

Step 6   Click Add.

Using the CLI:

Use the admin create command to create an administrator and associated password. For example, to create the administrator Bob with password xyz, enter:

nrcmd> admin bob create password=xyz 
 

Creating a Password Without Displaying It

Using the CLI, you can create a password without displaying it on the screen.

Using the CLI:

If you want to enter a password and not have Network Registrar display the password on your screen, create an administrator and do not supply a password. Then use the admin enterPassword command to enter a password and prevent Network Registrar from echoing it on the screen. Network Registrar prompts you to verify the password before it accepts it.

Use the admin enterPassword command to associate a password with an administrator. For example, to cause the CLI to prompt you for a password for administrator Bob, enter:

nrcmd> admin bob enterPassword 
password:
verify password:
100 Ok
 

Changing the Administrator's Password

You can change the password for any administrator.

Using the GUI:

Step 1   From the Admin menu, select Change Administrator Password.

Step 2   Enter the administrator's user name.

Step 3   Enter the administrator's current password.

Step 4   Enter the administrator's new password.

Step 5   Enter the new password a second time.

Step 6   Select the cluster the administrator can access.

Step 7   Click OK.

Using the CLI:

Use the admin set password command to change an existing password. For example, to change Bob's password to abc, enter:

nrcmd> admin bob set password=abc 
 

Listing Network Administrators

Use the admin list command to list all administrators in Network Registrar.

nrcmd> admin list 
 

Exiting Network Registrar

Exiting the Network Registrar user interface does not affect your network servers' or your hosts' ability to request leases or access the Internet.

Using the GUI:

From the Admin menu, select Exit.

If you did not save any configuration changes, Network Registrar prompts you to save changes.

Using the CLI:

To exit the Network Registrar CLI, use the exit command. Network Registrar writes all your unsaved changes to the database. If Network Registrar is unable to save your changes, it displays the same error code as if you had used the save command.

nrcmd> exit 
 

Controlling Servers

You can control the Network Registrar servers as follows:

• Starting—Loads the database and starts the server
  
  
• Stopping—Stops the server
  
  
• Reloading—Stops and restarts the server
  
  

Starting Servers

This section describes how to start the Network Registrar servers.

Using the GUI:

Step 1   In the Server Manager window, right-click the server you want to start. Alternatively, select the server, then click the Servers menu.

Step 2   Click Start.

Step 3   Click OK.

Using the CLI:

Use the server start command to start the specified server. For example, to start the Network Registrar DNS server, enter:

nrcmd> server DNS start 
 

Stopping Servers

This section describes how to stop the Network Registrar servers.

Using the GUI:

Step 1   In the Server Manager window, right-click the server you want to stop. Alternatively, select the server, then click the Servers menu.

Step 2   Click Stop.

Step 3   Click Yes to confirm, then OK.

Using the CLI:

Use the server stop command to stop the specified server. For example, to stop the Network Registrar DHCP server, enter:

nrcmd> server DHCP stop 
 

Reloading Servers

When you reload the server, Network Registrar performs three steps: it stops the server you selected, loads configuration data, and restarts the server. Only after you issue the reload command does the server use your changes to the configuration.

Using the GUI:

Step 1   In the Server Manager window, right-click the server you want to reload. Alternatively, select the server, then click the Servers menu.

Step 2   Click Reload.

Step 3   Click OK.

Using the CLI:

Use the server reload command to reload the specified server. For example, to reload Network Registrar's DHCP server, enter:

nrcmd> server DHCP reload 
 

Network Registrar stops the server you selected, loads the configuration data, and restarts the server.

Logging Server Events

When you start Network Registrar, it automatically starts logging system activity. Network Registrar maintains all the logs in the Program Files\Network Registrar\logs (Windows NT) or /install-path/nwreg2/logs (UNIX) directory. If you would like to view the contents of these logs while the Network Registrar servers are running, issue the command tail -f (Solaris), or view the files through the Web browser (Windows NT).

Caution   To avoid filling up the Windows NT Event Viewer, in the Event Log Settings, select the Overwrite Events as Needed option. If you do not set this, you might fill up your disk with log messages and thus prevent Network Registrar from running.

This section describes the types of logs that Network Registrar keeps and explains how to set and view the debug logging options.

Event Logging Format

The format for the log entries include the following categories:

• Activity—Logs the activity of your servers.
  
  
• Info—Logs standard operations of the servers, such as starting up and shutting down.
  
  
• Warning—Logs events that warn users of events, such as invalid packets, user miscommunication, or an error in a script while processing a request.
  
  
• Error—Logs events that prevented the server from operating properly, such as out of memory or unable to acquire resources (sockets, logs, backing store or configuration databases) or errors in configuration.
  
  

The DHCP server in particular has some log settings that can severely restrict what is logged, and, therefore, improve server performance. These are available by using the dhcp set log-settings= command in the CLI (see the Network Registrar CLI Reference Guide for details).

Note   Warnings and errors are also sent to the Event Viewer on Windows systems or to the Syslog on Solaris systems. See the earlier Caution.

Log Files

Table 4-2 shows all the Network Registrar log files.

Each component has a number of log files, each with a maximum size of 1 MB. The first log file is created without a suffix extension. When that file reaches 1 MB in size, Network Registrar renames it to xx_log_01 and begins filling up the current log. When the current log file reaches 1 MB, it renames the current to _01 and _01 to _02, and so on.

The DNS server can have a maximum of three log files. By default, the DHCP server can have a maximum of four log files of one MB each.

Debugging Servers

You can set the debug levels for the Network Registrar DNS and the DHCP servers, from 1 to 4 for the DNS server and from 1 to 9 for the DHCP servers, with the higher levels giving you more extensive logging.

Note   Each of these servers has different categories for which you can request tracing information. Because setting the tracing level can have a serious impact on the performance of your system, you should contact the Cisco Technical Assistance Center (TAC) for more information about using debugging. If you reload the DNS server after enabling the debug settings through the GUI, Network Registrar disables debug. You must enable the debug setting again if you want debugging.

Using the GUI:

The Debug settings button lets you collect debug information about the servers. You should only need to set debug settings if you have been instructed by Cisco Technical Assistance Center.

Step 1   In the Server Manager window, right-click the server for which you want to set debug options, then click Properties. Alternatively, select the server, then click the Show Properties toolbar button.

Step 2   Click the Advanced tab in the DNS or DHCP Properties dialog box.

Step 3   Click the Debug settings button.

Step 4   From the Debug Settings dialog box, select the Enable Debug check box.

Step 5   Enter the category as supplied by the Cisco Technical Assistance Center.

Step 6   Check MLOG, which sends the output to Network Registrar log files.

Step 7   Click OK.

Using the CLI:

Use the server setDebug command to specify the debugging level.

nrcmd> server DNS setDebug D=5 
 

In UNIX, you must stop and then restart the Network Registrar Server Agent by entering the commands aicservagt stop and aicservagt start. In Windows NT, select Start > Settings > Control Panel > Services, highlight AIC Server Agent, click Stop, and then Start. To disable debugging, use the server unsetDebug command.

Monitoring and Reporting Server Status

You can monitor the state of your Network Registrar servers by displaying or reporting aspects of a specified server's health. The following items can decrement the health of the servers, so you should monitor their status periodically:

• DNS server
  
  
• • Memory allocation errors
    
    
  • Unable to contact root servers
    
    
• DHCP Server
  
  
• • Configuration errors
    
    
  • Out of memory
    
    
  • Low on packet caching
    
    
  • Options would not fit in packet limit stated
    
    
  • No more leases available
    
    

  ---

  Note   On a UNIX machine, you can run the aicstatus command in the /opt/nwreg2/usrbin/ directory to see if your server is running. See the Network Registrar Installation Guide.

  ---

Adding Servers to the Server Status Monitor

You can view the status of a server by adding it to the Server Status Monitor in the GUI.

Using the GUI:

The Status Monitor window (Figure 3-12) is where you can place server icons to monitor their state. The icons change to reflect the server's current state. The traffic lights indicate the state of the server: started is green and stopped is red.

The bar to the right of the traffic light shows the health of the server, that is, it indicates how well the server is running. The health is a combination of servers' resources and network balance.

Step 1   In the Server Manager window, right-click the server you want to add to the Status Monitor. Alternatively, select the server, then click the Servers menu.

Step 2   Click Add to Status Monitor. Alternatively, in Windows 95 or Windows NT, drag the server icon to the Status Monitor window (Figure 3-12).

You can add as many servers as you want to the Status Monitor window. They can be from any of the clusters to which you connected.

Note   When Network Registrar cannot contact the server, you will see the warning triangle and exclamation point and the green or red color is muted. The warning can mean that the network is down, the server machine crashed, the server was stopped from the control panel, or the client lost its address (and, therefore, communication with the server).

Removing Servers from the Server Status Monitor

You can remove a server from the Server Status Monitor in the GUI.

Using the GUI:

Step 1   In the Status Monitor window (Figure 3-12), right-click the server you want to remove.

Step 2   Click Remove.

Displaying the Server's Health

You can display the health of a server (whether or not it is running) in the CLI.

Using the CLI:

Use the server getHealth command to display the specified server's health. For example, to display Network Registrar's DHCP server's health, enter:

nrcmd> server DHCP getHealth 
 

The number 10 indicates the highest level of health, and decreases incrementally to 1.

Displaying Server Statistics

You can display statistics on a server.

Using the GUI:

Step 1   In the Server Manager window, right-click the server whose statistics you want to view. Alternatively, select the server, then click the Servers menu.

Step 2   Click Show Statistics. Network Registrar displays the Statistics window.

Step 3   To refresh the statistics, click Refresh.

Using the CLI:

Use the server getStats command to display the specified server's statistics. For example, to display Network Registrar's DHCP server's statistics, enter:

nrcmd> server DHCP getStats 
 

Using the Web GUI:

The Network Registrar Web GUI lets you log in to your Network Registrar servers and run the Server Status report. This report displays the status of the specified server. It indicates whether the server is running or stopped. (See the "Running Reports" section.)

Displaying IP Address Usage

You can generate an IP address usage report.

Using the CLI:

Use the report file command to display the IP address usage for specified servers. For example, to display Network Registrar's DHCP server's address usage, enter:

nrcmd> report file myreportfile 
 

Using the Web GUI:

You can use the Web GUI to display the server's address usage. The Web GUI lets you log in to your Network Registrar servers and run an Address Usage report. The Address Usage report displays the IP address usage for all of the servers or just some of the servers in your network. (See the "Running Reports" section.)

Displaying Related DHCP Servers

Network Registrar displays a related DHCP server report that contains the following information:

• Type—Main or backup DHCP server
  
  
• Server name—The DNS name of the server
  
  
• IP address—The server's IP address in dotted octet format
  
  
• Requests—The number of outstanding requests, or two dashes if not applicable
  
  
• Communication status—Whether the servers can communicate or if communication has been interrupted (OK or INTERRUPTED)
  
  
• Cluster state—The failover state of this DHCP server
  
  
• Partner state—The failover state of partner server
  
  

Using the GUI:

Step 1   In the Server Manager window, right-click the DHCP server for which you want to show the related server. Alternatively, select the DHCP server, then click the Servers menu.

Step 2   Click Show related servers. (This option is only available if you configured DHCP failover; see "Configuring DHCP Failover.") Network Registrar displays the Related Servers window.

Step 3   To refresh the related servers list, click Refresh. Network Registrar refreshes the window every 10 seconds. If you want more current information, click Refresh.

Using the CLI:

Use the server getRelatedServers command to display the connection status between the main and backup DHCP server. For example, to display Network Registrar's DHCP servers, enter:

nrcmd> server DHCP getRelatedServers 
 

Using the Web GUI:

You can use the Web GUI to display the server's related servers. The Web GUI lets you log in to your Network Registrar servers and run a Related Servers report. The Related Servers report displays the IP address usage for all of the servers or just some of the servers in your network. (See the "Running Reports" section.)

Displaying Leases

After you establish a scope, you can monitor lease activity and view lease attributes using either the Leases tab in the GUI or the lease list command in the CLI.

Using the GUI:

Step 1   In the Server Manager window, expand the DHCP server with the scope containing the leases.

Step 2   Right-click the scope, then click Properties. Alternatively, select the scope, then click the Show Properties toolbar button.

Step 3   In the Scope Properties dialog box, click the Leases tab to open the Lease Properties dialog box (Figure 4-2).

Step 4   Select the lease that you want to view.

Step 5   Click the Lease Properties button. The properties of the lease you selected appear.

Using the CLI:

Use the lease list command from the DOS prompt to view the properties of a particular lease. For example:

nrcmd -C cluster -N user -P password lease list 
 

Using the Web GUI:

You can use the Web GUI to display the server's lease status. In addition, the Web GUI lets you log in to your Network Registrar servers and run a Lease Status report.The Lease Status report displays the status of leases, whether they are available, reserved, and, if reserved, the associated MAC address. (See the "Running Reports" section.)

Backing Up the Network Registrar Databases

Because the Network Registrar database does a variety of memory caching and may be active at any time, you cannot rely on system backups to protect the database. For one thing, there may be Network Registrar operations in progress during the backup, causing backup data inconsistency and an unusable replacement database.

For this purpose, Network Registrar provides a shadow backup facility. Once a day, at a configurable time, Network Registrar suspends all activity to the database and takes a snapshot of the critical files. This snapshot is guaranteed to be a consistent view of the database and is preserved correctly on a system backup tape. Network Registrar backs up the DNS data even when the shadow backup is run on a secondary server. This backup is only a single generation backup. To maintain multiple backup versions, you must implement an archiving strategy.

Caution   If you are using Windows NT, you should configure system backup utilities and procedures to skip the Network Registrar operational database directories and files, and to back up only the shadow copies of the database files. Otherwise, your server could crash.

Before Performing a Backup or Recovery

Before undertaking a database backup or recovery, be sure to understand that the notation ".../data/db" in the following sections refers to directories in the Network Registrar product installation path, depending on the platform.

• UNIX: ".../data/db" means /var/nwreg2/data/db
  
  
• Windows NT: ".../data/db" means \Program Files\Network Registrar\data\db
  
  

Network Registrar database utility programs mentioned in the following sections are located in the ".../bin" directory, which you run as its full path name.

• UNIX: ".../bin/program" means /opt/nwreg2/bin/program
  
  
• Windows NT: ".../bin/program" means \Program Files\Network Registrar\bin\program
  
  

---

Note   Be careful to use only the approved utility programs for each type of database, as described in the following sections.

---

Backup Strategy

The backup strategy involves backing up two databases:

• MCD database
  
  
• CNRDB database
  
  

The most basic component of a backup strategy is the daily shadow backup. In the event of problems with the operational database, you might need to try recovery based on the previous day's shadow backup. Therefore, you must recognize and correct any problem that prevents a successful backup. The most common problem is disk space exhaustion. To get a rough estimate of disk space requirements, sum up the size of the following MCD and CNRDB database files:

.../data/dhcp/ndb/dhcp.ndb 
.../data/dhcp/ndb/log.* 
.../data/db/mcddb.d0* 
 

A conservative approach would suggest that there be a minimum of perhaps five or ten times that amount of space available on the disk. System load, usage patterns, application mix, the load on Network Registrar itself, and so on, may dictate that a much larger reserve of space be available.

You should regularly archive existing shadow backups (such as to tape, other disks, or other systems) to preserve them for possible future recovery purposes.

Caution   Be aware that there are different database technologies used in Network Registrar that have distinct sets of utility programs. Using a utility on the wrong type of database can cause database corruption. Use only the utilities indicated. Also, never use the database utilities casually, and never on the operational database, only on a copy.

Setting the Shadow Backup Time

You can set the time at which an automatic shadow backup should occur through a single entry in the system registry, at the following paths:

• UNIX:
  
  

/opt/nwreg2/conf/aic.conf 
 

• Windows NT:
  
  

HKEY_LOCAL_MACHINE/SOFTWARE/American Internet/Network Registrar/2.0/DBShadowTime 
 

This entry is a string that represents the time of day at which the shadow backup is scheduled to occur (in 24-hour HH:MM format). The default is 23:45. If you remove this registry entry or set it to an illegal value (for example, anything that does not begin with a digit), you suppress the backups. The server is otherwise unaffected.

Performing a Manual Backup

You can also initiate a manual shadow backup with the mcdshadow utility. There are no command line arguments. Enter the mcdshadow command to cause Network Registrar to perform the shadow backup. Because a full copy of the database is created, the backup may take a few minutes to be completed.

Backing Up and Recovering MCD Data

The operational database is in .../data/db and the shadow copy is in /data/db.bak. The actual file names are mcddb.d01, mcddb.d02, and mcddb.d03.

Caution   For the MCD database, use only the dbcheck and keybuild utilities. Do not use the cnrdb_archive, cnrdb_recover, or cnrdb_check utility that applies to the CNRDB database.

Checking MCD Database Integrity

To check the integrity of the MCD database after a backup:

Step 1   Stop all Network Registrar servers.

Step 2   Go to the .../data/db directory for the MCD database.

Step 3   As a safety check, enter the command .../bin/dbcheck -a mcddb. (This requires root privileges.)

Recovering MCD Data

Use the shadow backup to recover MCD data, either because a system crash corrupted the regular working database or because the disk on which it resides is corrupted.

Step 1   In UNIX, stop the Network Registrar Server Agent by entering the command aicservagt stop. In Windows NT, select Start > Settings > Control Panel > Services, highlight AIC Server Agent, and click Stop. If you do not stop the Network Registrar Server Agent, you will get errors.

Step 2   Check the size of the existing database files in .../data/db. Verify that there is at least 15% more disk space available before continuing with the next step.

Step 3   Make sure that the following three files are in .../data/db.bak: mcddb.d01, mcddb.d02, and mcddb.d03.

Step 4   Copy these files to .../data/db. (Do not move them, because you may need them again.)

Step 5   Change the directory to .../data/db.

Step 6   To rebuild the key files, enter the command .../bin/keybuild mcddb.

Step 7   As a safety check, enter the command .../bin/dbcheck mcddb. (This requires root privileges.)

You should not have errors. If you do, be sure that:

• The Network Registrar Server Agent (aicservagt) is stopped.
  
  
• You are working in the .../data/db directory.
  
  
• The mcddb.dbd file is present in the .../data/db directory.
  
  

MCD Data Files

The files listed in Table 4-3 are required for a fully functioning MCD database. As described earlier, only a small subset of these files are present in a shadow backup.

Backing Up CNRDB Data

In the case of the CNRDB database, a shadow backup copies the database and all log files to a secondary directory within the directory tree of the installed Network Registrar product.

Caution   For the CNRDB database, be sure to use only the cnrdb_archive, cnrdb_recover, or cnrdb_check utilities. Do not use the keybuild or dbcheck utility that applies to the MCD database.

For DHCP, the operational database is in .../data/dhcp/ndb and the associated operational logs are in /data/dhcp/ndb/logs. The database shadow copy is in /data/dhcp.bak/ndb and the associated log shadow copy is in /data/dhcp/dhcp.bak/ndb/logs.

The actual file naming convention is:

• Database: dhcp.ndb
  
  
• Log files: log.0000000001 through log.9999999999 (typically only a small number of log files are present on a system; the specific file name extensions in use at a site vary over time as the database is used)
  
  

Recovering CNRDB Data

You should always attempt recovery on a copy of the database file and associated log files, never on the operational files. (This is a simple file copy operation, distinct from a shadow backup.) Also, you should never attempt a recovery while Network Registrar is running.

Note   It is possible to damage the CNRDB database files without the damage being immediately obvious. Such damage could occur because of (a) inappropriately deleting log files, (b) mixing pre- and post-recovery database and log files, (c) attempting recovery of database files currently in use by an application, or (d) using tools intended for other databases (such as MCD database tools).

Use the cnrdb_recover utility (included in the Network Registrar product distribution) for database recovery. Use this tool with care. You should never use it directly on an operational database, or on files concurrently accessed by another application. On a successful recovery of a database, you should not intermingle the recovered files (database file and log files) with files from another source (such as the operational database or shadow backups). Recovered database files acquire state information that make them incompatible with older database files.

Here is the procedure for CNRDB database recovery:

Step 1   Stop all Network Registrar servers. Be sure that enough disk space is available for two copies of the database files, plus a 15% safety margin.

Step 2   Create two temporary directories, outside the Network Registrar installation tree for safety:

.../dbcopy 

.../recover 
 

Step 3   Copy the database files using shell level copy commands, in the following order:

/dbcopy contains a safety copy of the database files. Do not allow these files to be modified in any way. Do not run any utilities or servers on these files.

Step 4   Repeat the three previous steps, except copy the files to .../recover/.

Step 5   Try to recover the current database files:

Step 6   If there are any indications (such as server log messages or missing data) that database recovery was unsuccessful, you may need to base a recovery attempt on the current shadow backup (in the Network Registrar installation tree). The procedure is identical to that of Step 5, except that the current contents of /dbcopy/ are not disturbed, and the source of the files copied to /recover/ is /data/dhcp/dhcp.bak.

Once the files from the shadow backup are copied to /recover, copy the operational log files from /data/dhc/ndb/logs to /recover. This may cause older files in/recover to be overwritten by newer log files from the operational database. This is expected and typically occurs to at least one log file. Be careful, however, not to do the reverse by overwriting new log files from the operational database with older ones from the shadow backup.

If the attempted operation fails, try it again, this time using only the shadow backup files (and not copying the operational log files). In this case, all data written to the database since the shadow backup was made is lost.

Step 7   If Step 6 should fail (perhaps because the current shadow backup is simply a copy of corrupted files), use the most recent previous shadow backup. (This illustrates the need to regularly archive shadow backups.) Unlike in Step 6, you cannot add operational log files to older shadow backup files. All data added to the database since the shadow backup was made will be lost.

Step 8   After a successful database recovery: