Filter
Top Products
10-5
Cisco Broadband Access Center 3.8 Administrator Guide
OL-27172-01
Chapter 10 Database Management
Backup and Recovery
• As illustrated in the following example, this tool automatically creates a time stamped subdirectory,
under the directory you specify and places the backups there.
Examples Here is an example of using the backupDb.sh tool:
# backupDb.sh /var/backup
where /var/backup identifies the database backup directory.
In this example, all backup database files are stored in a directory called /var/backup/rdu-backup-
09252002-130345. The last subdirectory (rdu-backup-20020925-130345) is automatically created with
a current timestamp.
Note The timestamped subdirectory format is rdu-backup-yyyyMMdd-HHmmss. In this example, the
subdirectory would be rdu-backup-04272006-175430, meaning that the directory contains a backup that
was started at 5:54:30 pm on April 27, 2006.
The backupDb.sh tool also reports progress to the screen and logs its activity into history.log.
Note When using the backupDb.sh tool, you can use a –help option to obtain usage information. You can also
use the optional –nosubdir flag to disable, if necessary, the automatic creation of the subdirectory.
Database Recovery
Database recovery is the process of restoring the database to a consistent state. Since backup is
performed on a live RDU, the database can be changing while it is being copied. The database log files,
however, ensure that the database can be recovered to a consistent state.
Recovery is performed on a snapshot of a database. In other words, this task does not involve touching
the database on the live RDU server. The recovery task can be performed either immediately following
a backup or prior to restoring the database to the RDU server.
Note We recommend that you perform database recovery immediately after each backup. This way, the backed
up database can be more quickly restored in case of emergency.
The duration of database recovery depends on the number of database log files that were copied as part
of the backup, which in turn depends on the level of RDU activity at the time of the backup. The more
concurrent activity RDU experiences during the backup, the more transaction log files have to be copied
as part of the backup and the longer is the recovery. Generally, recovering a database takes from 10 to
60 seconds per transaction log file.
Use the recoverDb.sh tool, located in the <BPR_HOME>/rdu/bin directory, to perform recovery of the
snapshot of a database. When you use this tool, you must provide the location of the backup. This is also
the directory in which the recovery will be performed.