Backup and restore has the following best practices.
When to Back Up
We recommend backing up during a maintenance window or other time of low use.
While the system collects backup data, there may be a temporary pause in data correlation
(management center only), and you may be prevented from changing configurations related to the backup. If
you include event data, event-related features such as eStreamer are not available.
You should back up in the following situations:
-
Regular scheduled or on-demand backups.
As part of your disaster recovery plan, we recommend that you perform periodic
backups.
The management center setup process schedules weekly configuration-only backups, to be stored locally. This
is not a substitute for full off-site backups—after initial setup finishes, you should
review your scheduled tasks and adjust them to fit your organization's needs. For
more information, see Scheduled Backups.
-
After SLR changes.
Back up the management center after you make changes to Specific Licensing
Reservations (SLRs). If you make changes and then restore an older backup, you will have
issues with your Specific Licensing return code and can accrue orphan entitlements.
-
Before upgrade or reimage.
If an upgrade fails catastrophically, you may have to reimage and restore. Reimaging
returns most settings to factory defaults, including the system password. If you have a
recent backup, you can return to normal operations more quickly.
Note
|
Restoring from a backup does not reset the password that you had configured after the reimage or an RMA.
|
-
After upgrade.
Back up after you upgrade, so you have a snapshot of your freshly upgraded deployment.
We recommend you back up the management center after you upgrade its managed devices, so your
new management center backup file 'knows' that its devices have been upgraded.
Maintaining Backup File Security
Backups are stored as unencrypted archive (.tar) files.
Private keys in PKI objects—which represent the public key certificates and paired private
keys required to support your deployment—are decrypted before they are backed up. The keys
are reencrypted with a randomly generated key when you restore the
backup.
Note
|
We recommend you back up management centers and devices to a secure remote location and verify transfer success. Backups left
locally may be deleted, either manually or by the upgrade process, which purges locally
stored backups.
Especially because backup files are unencrypted, do
not allow unauthorized access. If backup files are modified, the restore
process will fail. Keep in mind that anyone with the Admin/Maint role can
access the Backup Management page, where they can move and delete files from
remote storage.
|
In the management center's system configuration, you can mount an NFS, SMB, or SSHFS network volume as remote storage. After you do this, all subsequent
backups are copied to that volume, but you can still use the management center to manage them. For more information, see Remote Storage Device and Manage Backups and Remote Storage.
Note that only the management center mounts the network volume. Managed device backup files are routed
through the management center. Make sure you have the bandwidth to perform a large data transfer between
the management center and its devices. For more information, see Guidelines for Downloading Data from the Firepower Management Center to
Managed Devices (Troubleshooting TechNote).
Backup and Restore in Management
Center High Availability Deployments
In management center high availability deployments, backing up one management center does not back up the other. You should regularly back up both peers. Do not restore one
HA peer with the backup file from the other. A backup file contains information that
uniquely identifies an appliance, and cannot be shared.
Note that you can replace an HA management center without a successful backup. For more information on replacing HA management centers, both with and without successful backups, see Replacing Management Centers in a High Availability Pair.
Backup and Restore in Threat Defense High Availability Deployments
In the threat
defense High Availability deployment, you should:
-
Back up the device pair from the management center, but restore individually and locally from the threat
defense
CLI.
The backup process produces unique backup files for threat
defense High Availability devices. Do not restore one High Availability peer with the backup
file from the other. A backup file contains information that uniquely identifies an
appliance, and cannot be shared.
The threat
defense High Availability device's role is noted in its backup file name. When you restore,
make sure you choose the appropriate backup file: primary vs secondary.
-
Do not suspend or break High Availability before you restore.
Maintaining the High Availability configuration ensures replacement devices can easily reconnect after restore. Note that you will have to resume High Availability synchronization to make this happen.
-
Do not run the restore CLI command on both peers at the same time.
Assuming you have successful backups, you can replace either or both peers in the High
Availability pair. Any physical replacement tasks you can perform simultaneously:
unracking, reracking, and so on.
However, do not run the restore command on the second device until the
restore process completes for the first device, including the reboot.
Note that you can replace the threat
defense High Availability device without a successful backup.
Backup and Restore in Threat Defense Clustering Deployments
In the threat
defense clustering deployment, you should:
-
Back up the entire cluster from the management center, but restore nodes individually and locally from the threat
defense CLI.
The backup process produces a bundled tar file that includes unique backup files for
each cluster node. Do not restore one node with the backup file from another. A backup
file contains information that uniquely identifies a device, and cannot be shared.
The node's role is noted in its backup file name. When you restore, make sure you
choose the appropriate backup file: control or data.
You cannot back up individual nodes. If a data node fails to back up, the management center will still back up all other nodes. If the control node fails to back up, the backup
is canceled.
-
Do not suspend or break clustering before you restore.
Maintaining the cluster configuration ensures replacement devices can easily reconnect
after restore.
-
Do not run the restore CLI command on multiple nodes at the same time. We
recommend that you restore the control node first and wait until it rejoins the cluster
before you restore any data nodes.
Assuming you have successful backups, you can replace multiple nodes in the cluster.
Any physical replacement tasks you can perform simultaneously: unracking, reracking, and
so on. However, do not run the restore command on an additional node until
the restore process completes for the previous node, including the reboot.
Backup and Restore for Firepower 4100/9300 Chassis
To restore threat
defense software on a Firepower 4100/9300 chassis, the chassis must be running a compatible FXOS
version.
When you back up a Firepower 4100/9300 chassis, we strongly recommend you also back up FXOS configurations. For additional best practices, see Configuration Import/Export Guidelines for Firepower 4100/9300.
Before Backup
Before you back up, you should:
-
Update the VDB and SRU on the management center.
We always recommend you use the latest vulnerability database (VDB) and intrusion rules
(SRU). Before you back up the management center, check the Cisco Support & Download
site for newer versions.
-
Check Disk Space.
Before you begin a backup, make sure you have enough disk space on the appliance or on
your remote storage server. The space available is displayed on the Backup Management
page.
Backups can fail if there is not enough space. Especially if you schedule backups, make sure you regularly prune backup files or
allocate more disk space to the remote storage location.
Before Restore
Before restore, you should:
-
Revert licensing changes.
Revert any licensing changes made since you took the backup.
Otherwise, you may have license conflicts or orphan
entitlements after the restore. However, do
not unregister from Cisco Smart Software Manager (CSSM). If you unregister
from CSSM, you must unregister again after you restore, then re-register.
After the restore completes, reconfigure licensing. If you notice licensing
conflicts or orphan entitlements, contact Cisco TAC.
-
Disconnect faulty appliances.
Disconnect the management interface, and for devices, the data interfaces.
Restoring threat
defense devices sets the management IP address of the
replacement device to the management IP address of the old device. To avoid IP
conflicts, disconnect the old device from the management network before you restore the
backup on its replacement.
Note that restoring the management center does not change the management IP address. You must set that
manually on the replacement — just make sure you disconnect the old appliance from the
network before you do.
-
Do not unregister managed devices.
Whether you are restoring the management center or managed device, do not unregister devices from the
management center, even if you physically disconnect an appliance from the network.
If you unregister, you will need to redo some device configurations, such as security
zone to interface mappings. After you restore, the management center and devices should begin
communicating normally.
-
Reimage.
In an RMA scenario, the replacement appliance will arrive configured with factory
defaults. However, if the replacement appliance is already configured, we recommend you
reimage. Reimaging returns most settings to factory defaults, including the system
password. You can only reimage to major versions, so you may need to patch after you
reimage.
If you do not reimage, keep in mind that management center intrusion events and file lists are merged
rather than overwritten.
After Restore
After restore, you should:
-
Reconfigure anything that was not restored.
This can include reconfiguring licensing, remote storage, and audit log server
certificate settings. You also must re-add/re-enroll failed
threat
defense VPN certificates.
-
Update the VDB and SRU on the management center.
We always recommend you use the latest vulnerability database (VDB) and intrusion rules (SRU). This is especially important for the VDB, because the VDB in the backup will overwrite the VDB on the replacement management center. Ensure that you update the VDB to the latest version before deploying any changes to the device.
-
Deploy.
After you restore the management center, deploy to all managed devices. After you restore a device, you must force deploy from the Device Management page: see Redeploy Existing Configurations to a Device in the Cisco Secure Firewall Management
Center Device Configuration Guide. Whether you are restoring the management center or the device you must deploy.