Cisco Element Management System Installation and Configuration Guide, 3.2 Service Pack 7 - Cisco EMF Database Backup and Restore [Cisco Element Manager System]

Table Of Contents

Cisco EMF Database Backup and Restore

Cisco EMF Backup

When to Backup

Backup Storage and Sizing

Planning for Backup Storage and Sizing

Pre-Backup Checklist

Cisco EMF Backup Process

Performing a Manual Backup

Performing a Forced Backup

Performing Automatic or Scheduled Backups

Optional Parameters for Cisco EMF Backup

Archiving Backups to Tape

Backed Up Data

Frequency of Backups

Backup Directories and Filenames

Impact of Cisco EMF Backup

Cisco EMF Restore

When To Restore

Pre-Restore Checklist

Cisco EMF Restore Process

Optional Parameters for Cisco EMF Restore

Restoring Databases from Another Machine

Restoring Databases from Tape

ObjectStore Database Integrity

Backup and Restore Limitations

Cisco EMF Database Backup and Restore

The backup and restore mechanism comprises two major functions:

1. The backup mechanism takes a consistent snapshot of the Cisco EMF system, as stored in multiple ObjectStore databases. It also has the ability to store relevant system configuration.

2. The restore mechanism reinstates the Cisco EMF system to the exact state stored in the relevant backup.

Cisco EMF maintains all data in ObjectStore databases. Databases may become corrupt, for example, if the hard disk fails, or if the machine the databases are stored on stops working. This situation is very serious for mission critical software; therefore, backing up your databases and configuration to another area of the disk can remedy this problem.

Backup and restore allows you to recover from hardware or software failures with minimal loss of management data. You can also use backup and restore to move databases from one Cisco EMF installation to another, for example, to facilitate hardware upgrades.

Typically, backups are automatically performed each day, and the UNIX utility cron is used to schedule a backup each day for the early hours.

Note Backup and restore functionality is only available to server (not client) installations.

Caution It is not possible to restore a backup from a pre-Cisco EMF v3.2 SP4 system directly onto a Cisco EMF v3.2 SP7 system. See Pre-Restore Checklist for the workaround.

Cisco EMF Backup

The Cisco EMF Backup starts by taking a full backup of the database, then by taking incremental backups. Incremental backups only contain data that has been updated or altered since the full backup and any prior incremental backups. This section contains the following information:

•When to Backup

•Backup Storage and Sizing

•Pre-Backup Checklist

•Cisco EMF Backup Process

•Impact of Cisco EMF Backup

When to Backup

Backups should be done in the following circumstances:

•Before upgrading Cisco EMF. (See Chapter 3, "Upgrading the Cisco EMF EMS")

•Before a new Element Manager is installed.

•Before de-installing an Element Manager.

•Before installing an upgrade for installed Cisco EMF Element Manager packages.

•Before installing a patch for installed Cisco EMF or Element Manager packages.

•Before making any major changes to the network data model (such as deletion or untested changes) or before making any major changes to the network hardware.

•Before such as deploying a large number of new network devices.

•On a daily basis.

Backup Storage and Sizing

When you perform a full backup, Cisco EMF attempts to calculate the amount of disk space required to complete the full backup successfully. However, with regard to incremental backups, since it is not possible to determine the amount of data that has changed in the database, Cisco EMF makes a conservative estimation, requiring the equivalent disk space for a full backup. During an incremental backup, if the backup fails due to a lack of sufficient disk space and you know that the size of your incremental backup is not as large as a full backup, you can override the disk space check. To override the disk space check, run the backup using the -c option, then choose to ignore the disk space check for incremental backups (for additional information on the -c option, see "Optional Parameters for Cisco EMF Backup" section on page 8-5.)

Note When you install Cisco EMF, the location of the ObjectStore database files are configured. (See Configuring an ObjectStore Installation for Cisco EMF, page 2-5) You need ObjectStore Release 5.1 Service Pack 4 for a Cisco EMF installation.

Planning for Backup Storage and Sizing

When planning backup storage and sizing, there are a number of points that you must consider:

1. It is important to ensure that your backup directory area is large enough. This depends upon two main considerations:

a. the size of your databases

b. the volatility of your data, or what percentage of the database disk blocks change each day

The following formula can be calculated to discover approximate space requirements:

Number of weeks on disk * (Number of full backups per week + (Number of incremental backups per week * volatility factor)) = X * combined database sizes

For example, assume the following is true:

–10% of the database disk blocks are modified each day, giving us a volatility factor of 0.1 (valid values are between 0 and 1 (that is, 0-100%)

–Seven backups are performed each week, 1 full and six incremental

–2 represents the number of weeks on disk

–Combined database size is 10GB

The equation for this example would be: 2 * (1 + (6 * 0.1)) = 3.2 * 10

This example requires a 32GB backup area. The worst case scenario for a 10GB installation is with 100% volatility (replace 0.1 with 1 in the above equation) which requires a 140GB backup area.

2. By default, the system maintains up to two weeks of backup information on disk at any time. Before the first backup of a new week begins, any backup data older than two weeks is automatically deleted. However, you can override the default behavior of deleting old backups. (See Optional Parameters for Cisco EMF Backup.) If you want to save this older data, you can easily archive it to tape. (See Archiving Backups to Tape.)

Pre-Backup Checklist

Before you perform a backup, there are a number of issues to consider:

1. Ensure that the tape archive option is set, if required, for automated backups (using cron). If you choose not to use this option, backups over two weeks old will be deleted, unless this behavior has been modified. (See Optional Parameters for Cisco EMF Backup.)

2. If old backups (older than two weeks) are to be archived, check that the correct tape device is selected.

3. Ensure that sufficient disk space is available to contain two weeks worth of backups. Generally, there should be twice as much storage available for backup as there is for the main databases.

4. Consider the timing of the backup with respect to system load and the locking of essential services.

Backups should not be scheduled when the following activities are in progress:

•Auto Discovery

•Scheduled discovery

•Device commissioning

•Alarm deletion

•attributeHistory is being purged

•Object group updates containing queries on a large number of objects (20,000+) are in progress

•Notifications are running that generate a large number of alarm events

Note For more information about the Attribute History subsystem, see Chapter 12, "Performance Data Storage".

Cisco EMF Backup Process

This section contains the following information:

•Performing a Manual Backup

•Performing a Forced Backup

•Performing Automatic or Scheduled Backups

•Optional Parameters for Cisco EMF Backup

•Archiving Backups to Tape

•Backed Up Data

•Frequency of Backups

•Backup Directories and Filenames

Caution The backup process can be discontinued using Ctrl-C. UNIX system commands must not be used to terminate the backup process, as this leaves the system in a locked state.

Performing a Manual Backup

To perform a manual backup, enter:

<CEMF_ROOT>/bin/cemf backup

Note Replace <CEMF_ROOT> with the directory where Cisco EMF is located. By default, this directory is /opt/cemf.

Performing a Forced Backup

An incremental backup has a size limit of 2GB for new or changed data.

If a large deployment is done between full backups, then a full backup should be forced. For example, if a large deployment is done on Friday, and the next full backup is due on Sunday, then a full backup must be forced on the Friday after the deployment is complete.

Note If you are deploying large numbers of objects on a regular basis, then it is recommended that you force a full backup each day.

To perform a forced backup, enter:

<CEMF_ROOT>/bin/cemf backup -F

Note Replace <CEMF_ROOT> with the directory where Cisco EMF is located. By default, this directory is /opt/cemf.

Performing Automatic or Scheduled Backups

The backup operation can be automated by setting up a cron job to perform backups on a regular basis. For example, if a backup must be made every day at 3:00 a.m., the following line should be added to the cron table:
0 3 * * * <CEMF_ROOT>/bin/cemf backup
Optional Parameters for Cisco EMF Backup

Optional backup parameters are as follows:

Table 8-1 Backup Options

Parameter

Description

-l <backup_dir>

Specify the directory in which the backup output is written. The default location is: /opt/Backup

-t

Specify that old backups should be archived to tape. The default is not to archive to tape.

-h

Prints the help message

-F

Forces a full backup

-d

Specify the tape device

-c

Change settings stored in backup configuration file. (See Changing Configuration Settings.)

Changing Configuration Settings

The <CEMF_ROOT>/bin/cemf backup -c option allows the user to specify preferences for backup commands. The following parameters can be specified:

•You can specify the directory that backups will be placed in (or retrieved from). This directory can be overridden using the -l command line option.

•You can specify old backups to be archived to tape when a new backup is created. This can be overridden by using the -t command line option. The default is not to archive to tape.

•You can specify the tape device that backups should be archived to, if archiving is enabled. This can be overridden using the -d command line option.

•You can specify whether or not incremental backups should fail if there is not enough space for a full backup.

•You can specify whether or not old backups should be deleted if they are not archived to tape.

Archiving Backups to Tape

Caution Archive to tape should only be used for backups of less than 4GB.

Only two weeks worth of backups are kept on the system. Each time a backup is performed, a check is made to ensure there are less than two weeks worth of backups. If there are more than two weeks of backups, they are removed from the system.

If you want to save these older backups, you can archive them to tape by adding the -d and -t backup options to the cemf backup command. You can also use the -c option to set configuration so that backups automatically archive to tape. (See Optional Parameters for Cisco EMF Backup.)

Backed Up Data

The Cisco EMF backup process backs up the Cisco EMF databases, plus any additional files that need to be kept synchronized with these databases. The filesToBackup file, located in the <CEMF_ROOT>/config/data directory, can be used to list additional files that will be saved and restored as part of the Cisco EMF backup/restore process. The files listed in filesToBackup will be tarred into the incrementX.config tar file when the command cemf backup is executed.

By default, the filesToBackup file contains the following entries:

•data/filesToBackup

•.installInfo

•.systemInfo

•.backupInfo

Adding or Removing Files

You can make changes to the filesToBackup file to add additional files or remove files. If you want to add or remove a file that exists in the <CEMF_ROOT>/config directory, you do not need to enter the full path, as <CEMF_ROOT>/config is assumed by default. For example, if you wanted to backup the <CEMF_ROOT>/config/.installInfo file, the correct way to enter that entry would be as follows:

.installInfo

To backup a file located in a subdirectory of <CEMF_ROOT>/config, list only the subdirectory name and the name of the file (for example, data/filesToBackup).

If the file to be added or removed does not exist in the <CEMF_ROOT>/config directory, simply enter the full path.

Tip If you do not want to backup and restore the filesToBackup file itself, you can delete this entry (data/filesToBackup) in filesToBackup.

The Cisco EMF backup does not backup the entire Cisco EMF installation. This is a task for the system administrator.

Frequency of Backups

You can start a backup on any given day of the week. It is recommended to perform at least one backup daily.

At least one full backup is taken once a week. A full backup is always taken on a Sunday. (See Backup Directories and Filenames.) The initial backup you take is always a full backup, and it can be followed by up to nine incremental backups. This process (1 full, up to 9 incremental) repeats itself. The number of full or incremental backups taken in any given week can vary, depending on the frequency of backups performed in a day. At least one full backup is carried out every seven days (on a Sunday) or every 9 increments, whichever comes first.

For example, compare the following two scenarios:

Scenario One: In any given week, only one backup will be taken each day. The starting day will be Saturday.

Table 8-2 Scenario One: One Backup Per Day

Day

Backup Number*

Type of Backup

Saturday

0

Full

Sunday

0

Full

Monday

1

Incremental

Tuesday

2

Incremental

Wednesday

3

Incremental

Thursday

4

Incremental

Friday

5

Incremental

Saturday

6

Incremental

Sunday

0

Full

*The Backup Number begins with zero, reflecting the fact that each (full) filename starts with zero.

The table shows that because we started on a Saturday, the mandatory Sunday full backup also commenced the next day. Then, only 6 incremental backups could take place before the next Sunday's full backup. In scenario one, three full backups are carried out that week. A total of 6 incremental backups were taken.

Scenario Two: In any given week, three backups will be taken each day. The starting day will be Monday.

Table 8-3 Scenario Two: Three Backups Per Day

Day

Backup Number

Type of Backup

Monday

0

Full

1

Incremental

2

Incremental

Tuesday

3

Incremental

4

Incremental

5

Incremental

Wednesday

6

Incremental

7

Incremental

8

Incremental

Thursday

9

Incremental

0

Full

1

Incremental

Friday

2

Incremental

3

Incremental

4

Incremental

Saturday

5

Incremental

6

Incremental

7

Incremental

Sunday

0

Full

1

Incremental

2

Incremental

Monday

3

Incremental

4

Incremental

5

Incremental

The table shows that each full backup is followed by up to nine incremental backups. After only 7 incremental backups, Sunday's backup is a mandatory full backup. In scenario two, a total of three full backups are carried out that week. A total of 21 incremental backups were taken. Remember, a full backup is always taken after nine incremental backups, and on a Sunday.

Backup Directories and Filenames

When you perform the first backup in any given week, a directory is created to contain the backup data for that week. This directory can be found in <BACKUP_INSTALL> and is named after the previous Sunday's date, in the format mm-dd-yyyy. <BACKUP_INSTALL>/10-22-2000 is an example of a backup directory name. A full backup is taken and a new directory created every Sunday of the week.

Note Date must always be specified in the US format.

Note <BACKUP_INSTALL> is the directory where the backup path is stored. By default, this directory is /opt/Backup.

The following table lists each backup, starting with the very first backup, and provides the type of backup (incremental or full); the directory where the backup is stored; and the specific filename for each backup.

Table 8-4 Backup Numbers, Types, Directories, and Filenames

Backup Number

Backup Type

Directory Where Backup is Stored*

Filename

1st

Full

<BACKUP_INSTALL>/<mm-dd-yyyy>/full_01.dir

increment0.1

2nd - 10th

Incremental

<BACKUP_INSTALL>/<mm-dd-yyyy>/full_01.dir

increment1.1 - 9.1

11th

Full

<BACKUP_INSTALL>/<mm-dd-yyyy>/full_02.dir

increment0.1

12th - 20th

Incremental

<BACKUP_INSTALL>/<mm-dd-yyyy>/full_02.dir

increment1.1 - 9.1

21st

Full

<BACKUP_INSTALL>/<mm-dd-yyyy>/full_03.dir

increment0.1

22nd - 30th

Incremental

<BACKUP_INSTALL>/<mm-dd-yyyy>/full_03.dir

increment1.1 - 9.1

Full backups—For each full backup, one file can contain only 2 GB of data. If your database is 2 GB or less, you will only have one full backup file (increment0.1). However, if your database is larger than 2 GB, you will have multiple full backup files, namely, increment0.1, increment0.2, increment0.3, and so on.

Also, each named increment file, whether it is a full backup or an incremental backup, has two additional files:

•incrementX.config—tar file containing CEMF-specific configuration files

•incrementX.cemfCatalog.tar—file that contains system configuration (software and hardware configuration) from the backup system

The filesToBackup file, located in the <CEMF_ROOT>/config/data directory, specifies which files are backed up into the incrementX.config tar file. You can make changes to these files if desired. (See "Adding or Removing Files" section on page 8-6.)

Impact of Cisco EMF Backup

Before a backup commences, Cisco EMF locks deployment, alarm processing, installation and changes to the object model. They are unlocked when the first phase of the backup is complete.

Tip If the backup fails to unlock the system, the command unlockSystem can be used. (See Chapter 17, "Troubleshooting" unlockSystem, page 17-11.)

If you want to track the process of the backup, view the backup.log file, located in the following directory: <LOGSDIR>/logs.

Note <LOGSDIR> is the directory chosen at install time. During installation you can choose to place the log files into a non-standard location, the default location is <CEMF_ROOT>/logs .

During the initial phase of a backup, you can not do the following:

•Provision new objects, but those objects that are in the process of being created will be completed. New provisioning requests received after the backup has started are queued by Cisco EMF.

•Delete objects, but those objects that are in the process of being deleted will be completed. New deletion requests received after the backup has started are queued by Cisco EMF.

•Rename or reparent managed objects in views.

•Modify the Cisco EMF metamodel. The metamodel will be modified when Element Managers are added or removed from the system.

•Modify alarm groups or persistent object groups. "Persistent" object groups are stored in the database and therefore remain intact when the system is shutdown and restarted.

At any point during the entire backup, you can not do, and should not attempt to do the following:

•Install or de-install packages. A backup is not allowed if an installation or de-installation is in progress.

•Start, stop, or reset Cisco EMF.

•Restore a backup.

Alarm processing is suspended for the short time necessary to snapshot the databases prior to backup. You may see a delay between the time an alarm is sent from the device to its appearance in an application, such as the Event Browser. Alarms will not be lost.

Cisco EMF Restore

The Cisco EMF restore process can restore all system databases, plus any configuration saved with those databases. You can specify a particular day to restore from, allowing selective rollback to a known state. The restore process can also be used to restore a subset of databases.

This section contains the following information:

•When To Restore

•Pre-Restore Checklist

•Cisco EMF Restore Process

•Optional Parameters for Cisco EMF Restore

•Restoring Databases from Another Machine

•Restoring Databases from Tape

•ObjectStore Database Integrity

When To Restore

A database restore may be necessary in a number of circumstances:

•To move management from one system to another, for example to upgrade to a faster machine

•If disk failure or other catastrophic hardware failure occurs, and network management must continue using alternate hardware

•If power failure occurs, causing abnormal termination of the system. This may leave the system databases in an inconsistent state, affecting the ability of Cisco EMF to correctly manage network elements.

•If the system databases are otherwise corrupted or their integrity is compromised, for example accidental deletion

•If the installation of an Element Manager is unsuccessful and leaves the system in an inconsistent state which cannot be recovered by de-installing that element manager

•If the de-installation of an Element Manager is unsuccessful, or only partially successful, which leaves the system in an inconsistent state that cannot otherwise be recovered

Pre-Restore Checklist

Caution When restoring from an earlier version of Cisco EMF to a later version, additional steps are required. (See Chapter 3, "Upgrading the Cisco EMF EMS".)

If a situation arises where you need to restore a Cisco EMF v3.2 Patch 1, 2, or 3 databuild onto Cisco EMF v3.2 SP7, the following steps should be taken:

•Uninstall the system

•Install Cisco EMF

•Install the Patch on which the databuild was taken

•Restore the databases

•Install Cisco EMF v3.2 SP7

•Backup the databases

•Start Cisco EMF

Note The only situation in which this is likely to occur in a deployment scenario is if database problems are encountered on the system after Cisco EMF v3.2 SP7 has been installed and started, and before a backup has been taken (this is why it is recommended that a backup is taken as soon as this or any patch/service pack is installed). In this case you may wish to restore a pre-Cisco EMF v3.2 SP4 backup.

When restoring from a backup from Cisco EMF v3.2 SP4 or later, it is vitally important that the system on which the restore is being performed is identical to, or compatible with, that from which the backup was taken. In particular:

1. The major version of Cisco EMF for the system being restored to must be the same or greater than the system the backup was taken on.

2. The Cisco EMF patch level for the system being restored to should be the same or greater than the system the backup was taken on.

3. The same element manager packages, with compatible versions, should be present, as in the original backup. If new packages have been added since that backup was taken, they should be de-installed (remember that you will lose the data associated with these packages).

4. If restoring to an alternative machine, there must be sufficient disk space to accommodate the restored databases.

5. To successfully restore a particular backup, the restore process must have the initial, full backup, plus all incremental backups.

Cisco EMF Restore Process

To restore Cisco EMF, proceed as follows:

1. Stop Cisco EMF by typing cemf stop.

2. Make sure that the backup being restored is consistent with the existing packages. If a new package has been installed since the chosen backup was made, the system may be left in an inconsistent state when the restoration proceeds. In these situations, you should do the following:

a. De-install packages installed since the selected backup was made. You will lose all of the data associated with these packages.

b. Select a backup consistent with currently installed packages you know to be robust. If this backup was made after the current packages were installed, use this backup and then do a restore.

3. You can run the restore either interactively (cemf restoreDataset) or manually (cemf restore).

To run the interactive restore, proceed as follows:

a. Stop Cisco EMF.

If you attempt to run this command with Cisco EMF running, an error message is displayed.

b. Run the restore by typing the following:

<CEMF_ROOT>/bin/cemf restoreDataset (additional options are available, see Optional Parameters for Cisco EMF Restore.) This command simply executes cemf restore in an interactive fashion, allowing you to select the parameters you desire instead of entering them manually. A list of all the existing backups by weekly date appears.

c. Select the relevant week.

d. Select the relevant backup.

To run a manual restore, enter:

<CEMF_ROOT>/bin/cemf restore -t mm-dd-yyyy (additional options are available, see Optional Parameters for Cisco EMF Restore.)

Note Replace <CEMF_ROOT> with the directory where Cisco EMF is located. By default, this directory is /opt/cemf/.

Optional Parameters for Cisco EMF Restore

Optional restore parameters for the cemf restoreDataset command are as follows:

Table 8-5 Restore Options for cemf restoreDataset

Parameter

Description

-t

Specify date the backup was made

-l <directory>

Specify directory where backup is located

-h

Prints out the help text

Optional restore parameters for the cemf restore command are as follows:

Table 8-6 Restore Options for cemf restore

Parameter

Description

-t

Specify date the backup was made

-m

Specify time backup was made

-f

Specify the full backup number (one or more)

-c

Specify the backup increment number

-u

Do not restore configuration files

-l <directory>

Specify directory where backup is located

-x <tape device>

Specify tape device

-h

Prints out the help text

Restoring Databases from Another Machine

Databases can be restored from a Cisco EMF installation on another machine. Before proceeding with the restore, please ensure the following:

1. The conditions in the pre-restore checklist are met. (See "Pre-Backup Checklist" section on page 8-3.)

2. You have a local copy of the backup.

This restore process ensures that databases will be updated with the current configuration.

If Cisco EMF or its databases on which the backup was performed have been installed in a different location to your Cisco EMF on which the restore was performed, some configuration information should be updated. This is performed automatically by the restore script, which prints out text messages similar to the following example, indicating that it is performing a configuration update:
Updating config...
.
.
Marking substitutions in file: /opt/cemf/config/ini/objectServer.ini
Marking substitutions in file: /opt/cemf/config/ini/configServer.ini
.
.
Updating file: /opt/cemf/config/ini/objectServer.ini
Updating file: /opt/cemf/config/ini/configServer.ini
.
.
Finished updating config.
Note If the Cisco EMF installation on which the backup was performed is the same as the Cisco EMF on which they were restored, the following information will be displayed:
"INFO: Config information is consistent."

Restoring Databases from Tape

To restore databases from tape, use the -x <tape device> option with the cemf restore command.

The following information appears when you restore from tape:
About to look on tape 
Insert the backup tape and press return key
After you press return, information similar to the following appears (file names and IP addresses will vary):
About to restore to disk the following files... 
04-22-2001/ 
04-22-2001/full_01.dir/ 
04-22-2001/full_01.dir/increment0.config 
04-22-2001/full_01.dir/backupRecord 
04-22-2001/full_01.dir/.backupRecord.old 
04-22-2001/full_01.dir/increment0.1 
Files have been restored to disk. 
Restore complete. 
INFO: Config information is consistent.
Updating IP address to 172.16.111.22
ObjectStore Database Integrity

Cisco EMF 3.2 includes an ObjectStore database integrity verification tool that enables you to verify the physical integrity of the ObjectStore database files in a Cisco EMF 3.2 installation. After any system failure, and perhaps even periodically, you may wish to run this tool across some or all of the Cisco EMF databases to check the database sanity at the physical level. In general, if this too reports any errors, please contact Cisco TAC.

This tool can be found under $OS_ROOTDIR/bin. The database integrity tool can detect invalid pointers and references within databases, as well as truncated databases. A value of 0 is returned if the database is intact; otherwise, a non-zero result is returned.

$OS_ROOTDIR is set by invoking cemf shell.

Caution The database integrity tool must only be used when Cisco EMF is not running.

The basic syntax of the command is:
osverifydb -all <db name>
Note A full database check requires this to be run across all databases in <CEMF_ROOT>/db/*.db or as appropriate if you have installed Cisco EMF databases in a non-default location.

For example:
% osverifydb -all vectors.db
<...output...>
% echo $?
<0 for successful verification, non-zero for failures>

The "-all" option forces the utility to check all database segments, not just the ObjectStore internal segment. To allow osverifydb to operate on larger Cisco EMF databases , the cache size available to ObjectStore must be increased. This can be done by setting the OS_CACHE_SIZE environment variable, e.g. in csh, issue the command:
setenv OS_CACHE_SIZE 134217728
The cache size is specified in bytes.

The osverifydb utility can take a significant amount of time to run. On a Sun Ultra 60, with dual processors and 512Mb of memory, the utility takes 45 minutes to analyze around 300Mb of databases. It should be run on all databases found in the Cisco EMF installation, including those belonging to Element Managers.

Backup and Restore Limitations

Several limitations exist with backup and restore. These do not affect the integrity of the backups. However, these issues constrain administration of the Cisco EMF system:

•For the duration of the initial backup phase, deployment requests are queued and will not be processed until the initial backup phase is complete. Therefore, if backup takes too long and is performed frequently, the ability of operators to provision subscribers and devices may be affected.

•Patching and backing up must be mutually exclusive to avoid configuration file inconsistencies in the restored system. Therefore, patching Cisco EMF around times of backup is not allowed.