When upgrading to 11.1 (or later) from a pre-11.1 version of Cisco Prime Network Registrar and when there are significant number of DHCPv6 leases (and/or DHCPv6 lease history records), customers SHOULD schedule a DHCP database dump and load (see Using the cnrdb_util Utility) to reduce the size of the DHCPv4 database after the upgrade. The upgrade does NOT reduce the size of the original dhcp.ndb database when the DHCPv6 leases (active + history) are moved to the new dhcp6.ndb and the only way to reduce the size of the original database is to do a dump and load. Viewing the size of the dhcp6.ndb file (using the ls command) will give you an estimate as to the size by which the database can be reduced.

Use the cnr_shadow_backup utility to back up the following databases:

• CNRDB databases —...data/dhcp, ...data/dns/csetdb, ...data/dns/rrdb, ...data/cdns, ...data/leasehist, ...data/lease6hist, ...data/subnetutil, ...data/mcd, ...data/replica, and ...data/ccm/ndb

• Smart License databases—...data/sanosync.data, ...data/sapiidsync.data, and ...data/satimeflagsync.data.

The most basic component of a backup strategy is the daily shadow backup. When problems occur with the operational database, you might need to try recovering based on the shadow backup of the previous day. Therefore, you must recognize and correct any problems that prevent a successful backup.

The most common problem is disk space exhaustion. To get a rough estimate of disk space requirements, take the size of the .../data directory and multiply by 10. System load, such as usage patterns, application mix, and the load on Cisco Prime Network Registrar itself, 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

Using a utility on the wrong type of database other than the one recommended can cause database corruption. Use only the utilities indicated. Also, never use the database utilities on the operational database, only on a copy.

You can set the time at which an automatic backup should occur by editing the cnr.conf file (in .../conf). Change the cnr.backup-time variable to the hour and minute of the automatic shadow backup, in 24-hour HH: MM format, then restart the server agent. For example, the following is the preset value:

cnr.backup-time=23:45

Note	You must restart Cisco Prime Network Registrar for a change to cnr.backup-time to take effect.

You can also initiate a manual backup with the cnr_shadow_backup utility, which requires root privileges. Enter the cnr_shadow_backup command at the prompt to perform the backup.

Note	To restore DHCP data from a failover partner that is more up to date than a backup, see Restoring DHCP Data from a Failover Server.

You should avoid scheduling third-party backup programs while cnr_shadow_backup is operating. Third-party backup programs should be run either an hour earlier or later than the cnr_shadow_backup operation. As described in Setting Automatic Backup Time, the default shadow backup time is daily at 23:45.

Configure third-party backup programs to skip the Cisco Prime Network Registrar operational database directories and files, and to back up only their shadow copies.

The operational files are listed in Backup Strategy. Cisco Prime Network Registrar also maintains lock files in the following directories:

• Cisco Prime Network Registrar server processes—/var/nwreg2/local/temp/np_destiny_trampoline or /var/nwreg2/regional/temp/np_destiny_trampoline

The lock files are recreated during a reboot. These files are important while a system is running. Any maintenance process (such as virus scanning and archiving) should exclude the temporary directories, operational database directories, and files.

The cnr_exim data import and export tool now supports the following for a user not constrained to a specific tenant:

• Exporting all the data
• Exporting the data specific to a tenant either with or without the core data
• Exporting and importing license related data
• Importing all of the data
• Importing the data specific to a tenant and optionally mapping it to a new tenant either with or without the core data. This allows you to build a base configuration for new tenants. When specifying tenant tags, the imported data is used to find the old tenant id and the current configuration is used to find the new tenant id.

Some of the advantages that come with the use of multi-tenant architecture are that you can move configurations for a tenant from one cluster to another to export a tenant template data and them import that data as another tenant.

Note	A user constrained to a specific tenant can only export or import data for that tenant.

The cnr_exim tool also serves to export unprotected resource record information. However, cnr_exim simply overwrites existing data and does not try to resolve conflicts.

Note	You cannot use cnr_exim tool for import or export of data from one version of Cisco Prime Network Registrar to another. It can be used only for import or export of data from or to the same versions of Cisco Prime Network Registrar.

Before using the cnr_exim tool, exit from the CLI, then find the tool in the install-path/usrbin directory.

You must reload the server for the imported data to become active.

Note that text exports are for reading purposes only. You cannot reimport them.

The text export prompts for the username and password (the cluster defaults to the local cluster). The syntax is:

> cnr_exim –e exportfile [–N username –P password –C cluster] 

To export (importable) raw data, use the –x option:

> cnr_exim –e exportfile -x

To export DNS server and zone components as binary data in raw format, use the –x and –c options:

> cnr_exim –e exportfile –x –c "dnsserver,zone"

The data import syntax is (the import file must be in raw format):

> cnr_exim –i importfile [–N username –P password –C cluster] 

You can also overwrite existing data with the –o option:

> cnr_exim –i importfile –o

The following table describes all the qualifying options for the cnr_exim tool.

The cnrdb_recover utility is useful in restoring the Cisco Prime Network Registrar databases to a consistent state after a system failure. You would typically use the –c and –v options with this command. The following table describes all of the qualifying options. The utility is located in the install-path/bin directory.

In the case of a catastrophic failure, restore a snapshot of all database files, along with all log files written since the snapshot. If not catastrophic, all you need are the system files at the time of failure. If any log files are missing, cnrdb_recover –c identifies the missing ones and fails, in which case you need to restore them and perform the recovery again.

Use of the catastrophic recovery option is highly recommended. In this way, the recovery utility plays back all the available database log files in sequential order. If, for some reason, there are missing log files, the recovery utility will report errors. For example, the following gap in the log files listed:

log.0000000001
log.0000000053

results in the following error that might require you to open a TAC case:

db_recover: Finding last valid log LSN:file:1 offset 2411756
db_recover: log_get: log.0000000002: No such file or directory
db_recover: DBENV->open: No such for or directory 

The cnrdb_verify utility is useful for verifying the structure of the Cisco Prime Network Registrar databases. The command requires a file parameter. Use this utility only if you are certain that there are no programs running that are modifying the file. The following table describes all its qualifying options. The utility is located in the install-path/bin directory.

The syntax is described in the usage information when you run the command:

./cnrdb_verify
 
usage: cnrdb_verify [-mNoqV] [-b blob_dir] [-h home] [-P password] db_file ...

The cnrdb_checkpoint utility is useful in setting a checkpoint for the database files so as to keep them current. The utility is located in the install-path/bin directory.

The syntax is described in the usage information when you run the command:

./cnrdb_checkpoint

usage: cnrdb_checkpoint [-1Vv] [-h home] [-k kbytes] [-L file] [-m msg_pfx] [-P password][-p min]

The cnrdb_util utility is useful for dumping and loading the Cisco Prime Network Registrar databases. In addition, you can use this utility to shadow backup and recover the Cisco Prime Network Registrar databases, to clear the log files, as well as to change the database page size.

The utility is located in the install-path/usrbin directory:

Important

It is strongly recommended that a backup be done before performing any operation on the Cisco Prime Network Registrar databases. If existing backup files are to be retained, they must be backed up as well.

The cnrdb_util utility runs in two modes.

• Interactive mode—Prompts the user for operations and options.
• Batch mode—Requires information (both operation and options) as arguments while executing this utility.

The syntax is described in the usage information when you run the command:

./cnrdb_util –h 

The following tables describe all of the qualifying operations and options.

Important

You can perform only one operation at a time.

Important

If the source and target directories are the same, the Dump and Load operations will delete the source files when the target files are created. This is done to minimize the disk space requirements when a dump/load operation is run to recapture the unused space in large database files.

Note	The Dump operation will dump each database to a file in the specified location using the database file name appended by '.dbdump'. The Load operation will only load database files if a *.dbdump file is found; the name of the database file is the name without '.dbdump'.

You can restore DHCP data from a failover server that is more current than the result of a shadow backup. Be sure that the failover partner configurations are synchronized. Also, ensure that the following steps are run on the bad failover partner (that is, the one whose database is bad) and that you want to restore to.

1. Stop the server agent:

   systemctl stop nwreglocal
   

2. Determine the processes running:

   /opt/nwreg2/local/usrbin/cnr_status
   

3. Kill the remaining processes:

   kill -9 pid
   

4. Delete the eventstore, ndb, and logs directories:

   rm /var/nwreg2/data/dhcpeventstore/*.*
     
   rm -r /var/nwreg2/data/dhcp/ndb/
   rm -r /var/nwreg2/data/dhcp/ndb6/
   

   Warning

   When removing either DHCP databases, BOTH MUST be removed - the DHCPv4 (data/dhcp/ndb) or DHCPv6 (data/dhcp/ndb6) lease databases. Removing only one (and leaving the other) is unsupported and may produce unpredictable results.

5. Restart the server agent:

   systemctl start nwreglocal