Backup/Restore

About Backup and Restore

The ability to recover from a disaster is an essential part of any system maintenance plan. As part of your disaster recovery plan, we recommend that you perform periodic backups of your devices managed by Cloud-Delivered Firewall Management Center.

Backup managed devices

The Cloud-Delivered Firewall Management Center web interface enables you to backup Secure Firewall Threat Defense devices. You can execute an on-demand device backup or a scheduled device backup. The backup files are stored in Cisco's secure cloud storage that can be downloaded from the Device backup page.


Note

Decryption of private keys during backup— Private keys in PKI objects, which represent the public key certificates and paired private keys that are 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.

Restore managed devices

You must use the Firewall Threat Defense CLI to restore the Firewall Threat Defense device. Understand and plan for the following:

  • Restoring Firewall Threat Defense overwrites all existing configurations with the backup configuration.

  • Though the Firewall Threat Defense restore process restores the VPN configuration from the backup, after the device restore, you must re-add or re-enroll the VPN certificates, and redeploy the device.

Clear backup for optimal storage space

By default, the Cloud-Delivered Firewall Management Center performs a daily cleanup, retaining only the five most recent backups per managed Firewall Threat Defense device. When new backups for the same device is triggered, the oldest backup files are deleted at the scheduled cleanup time.

Backup and restore Cloud-Delivered Firewall Management Center

Backup of Cloud-Delivered Firewall Management Center is not supported from the application interface. As Cloud-Delivered Firewall Management Center is a Cisco-managed SaaS platform, Cisco handles the infrastructure resiliency, platform recovery, and disaster recovery operations internally.

However, if you want to store the Cloud-Delivered Firewall Management Center configuration files externally for version control or for any other compliance requirements, use the Import/Export feature. This feature allows you to export policies, objects, templates, and other settings through the UI or REST APIs.

Managed device backup and restore requirements

Model requirements

  • Firewall Threat Defense standalone devices, native instances, container instances, HA pairs, and clusters.

  • Firewall Threat Defense Virtual on VMware only. The devices can be standalone, HA pairs, and clusters.


    Note

    For Firewall Threat Defense Virtual on other virtual platforms, backup and restore are managed at the respective platform. For example, for Firewall Threat Defenses deployed on AWS, device backup and restore are managed by AWS management console.

To replace a device where backup and restore is not supported in Cloud-Delivered Firewall Management Center, you must manually recreate device-specific configurations in Cloud-Delivered Firewall Management Center.

Model requirements for device replacement

For a sucessful restoration, the old and new managed devices must have the same:

  • model number,

  • number of network modules,

  • number of physical interfaces, and

  • same type of physical interfaces.

Version requirements

Before backing up a device, note down its Firewall software version, build number, and patch level. To restore the backup, the replacement device must run the same software version and build number, including patches, as that of the backup.

License requirements

No special licenses are required to execute backup and restore of the managed devices.

Guidelines for device backup and restore


Caution

Users with CLI access can access the Linux shell access with the expert command, which can present a security risk. For system security reasons, we strongly recommend:

  • Only use the Linux shell under TAC supervision or when explicitly instructed by Firewall and Cloud-Delivered Firewall Management Center user documentation.

  • Restrict the list of users with Linux shell access.

  • Do not add users directly in the Linux shell; only use the procedures in this chapter.

Backup and restore is for device Recovery/Return Material Authorization

Backup and restore are primarily intended for Return Material Authorization (RMA) scenarios. Do not execute the restore process on a faulty or failed physical device. Execute the process only on a replaced hardware.

If the backup resides only on the faulty device, it will be erased when you reimage the device. Similarly, if the device fails to boot up, you may not be able to recover the backup. Hence, ensure that you always secure a copy of the backup that can be accessed for restoration.

Device backup and restore does not equate to import/export of device configuration

A backup file contains information that uniquely identifies a device that cannot be shared. Do not use the backup and restore process to copy configurations between devices, or as a way to save configurations while testing new ones. Instead, use the import/export feature.

For example, Firewall Threat Defense device backups include the device's management IP address and all information needed for the device to connect to its managing Cloud-Delivered Firewall Management Center. Do not restore the Firewall Threat Defense backup to a device being managed by a different manager; the restored device attempts to connect only to the manager specified in the backup.

Restore is individual and local

You restore threat defense devices individually and locally. This means:

  • You cannot use Cloud-Delivered Firewall Management Center to restore a device. You must use the Firewall Threat Defense CLI to restore. However, for the ISA 3000 zero-touch restore, you would use an SD card and the reset button.

  • You cannot use a Cloud-Delivered Firewall Management Center user account to log into and restore one of its managed devices. Cloud-Delivered Firewall Management Center and Firewall Threat Defense devices maintain their own user accounts.

SSH host key verification for remote SCP storage

The Firewall Threat Defense verifies the SSH host key of a remote SCP storage server before starting file transfers. Previously, SCP operations could connect without requiring the remote server key in the local /root/.ssh/known_hostsfile.

Administrators must add and verify the remote storage server’s SSH host key before using remotely stored backup for Firewall Threat Defense restore.

Before adding a key, obtain or confirm the expected SSH host-key fingerprint with the remote storage server administrator.

If the host key is missing or does not match the key presented by the remote server, the transfer is blocked. Typical error messages include Host key verification failed and Error in copying backup file from remote location.

On the replacement Firewall Threat Defense CLI console, connect to the SSH server once and accept the new key:

ssh -o StrictHostKeyChecking=accept-new -o ConnectTimeout=10 @ exit

Verify the stored key:

ssh-keygen -F -l

Use the same IP address or hostname in the known_hosts entry as used in the backup, restore, or migration configuration. If the remote server’s SSH host key changes legitimately, remove the old entry, confirm the new fingerprint with the server administrator, and add the new key before retrying the operation.

Backup and restore in Firewall Threat Defense high availability deployments

In a Firewall Threat Defense HA deployment, you must:

  • Back up the device pair from the Cloud-Delivered Firewall Management Center, but restore individually and locally from the Firewall Threat Defense CLI.

    The backup process produces unique backup files for Firewall Threat Defense HA devices. 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.

    A Firewall Threat Defense HA device's role is noted in its backup file name. When you restore, make sure you choose the appropriate backup file: primary or secondary.

  • Do not suspend or break HA before you restore.

    Maintaining the HA configuration ensures that replacement devices can easily reconnect after restore. Note that you will have to resume HA 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 an HA pair. Any physical replacement tasks that 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.

Backup and Restore in Firewall Threat Defense Clustering Deployments

In the Firewall Threat Defense clustering deployment, you must:

  • Back up the entire cluster from the Cloud-delivered Firewall Management Center, but restore nodes individually and locally from the threat defense CLI.

    The backup process produces 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.

    If the control node fails a pre-backup check, backups of its data nodes are also prevented from starting. If the control node passes these checks but its backup fails later, data node backups continue. A data node backup failure does not automatically stop the other node backups. Check the backup result for each node.

  • All the nodes that are part of the cluster must be registered in the management center, for the backup to be successful.

  • 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.

Back up managed devices

You can perform on-demand or scheduled backups for supported Secure Firewall Threat Defense devices using Cloud-Delivered Firewall Management Center without a backup profile.

When to back up

  • Back up during a maintenance window or other time of low use. To maintain operational continuity, we suggest scheduling weekly backups. This allows for quick device restoration and service recovery in the event of a failure.

  • As part of your disaster recovery plan, perform periodic backups (on-demand or scheduled).

  • Before a device 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.

  • After a device upgrade. Back up the device after you upgrade, so that you have a freshly upgraded device backup.

Securing backup files

Backup files are stored as unencrypted archive (.tar) files; they should be stored in a secure repository.

Back up a Firewall Threat Defense Device from Cloud-delivered Firewall Management Center

Before you begin

Ensure that any firewall located between the Firewall Threat Defense and Cloud-Delivered Firewall Management Center is configured to allow outbound HTTPS traffic from the Firewall Threat Defense to the Security Cloud Control host.

Ensure that you read and understand the requirements and guidelines. Do not skip any steps or ignore security concerns. Careful planning and preparation can help you avoid missteps.

Procedure

Step 1

Log in to Security Cloud Control.

Step 2

Under Products, click Firewall.

Step 3

Select Administration > Firewall Management Center to open the Integrations page.

  1. Select Cloud-Delivered FMC and in the Management pane, click Devices to navigate to the Cloud-Delivered Firewall Management Center user interface.

  2. Select Administration > Advanced > Backup & Restore.

Step 4

Click Create device backup.

Step 5

In the Configure backup tab, select one or more Firewall Threat Defense devices in Select devices to backup.

You can filter the list based on the device groups, or device type—Standalone, High Availability, and Cluster. For clustering, choose the cluster. You cannot perform backups on individual nodes.


Note

If the device name has special characters other than hyphen, period, and underscore, those special characters will be replaced with an underscore.

Step 6

Click Next to view the summary of your selections, and then Click Start backup to start the on-demand backup.

In a Firewall Threat Defense HA or cluster deployment, though you select the HA or cluster as a unit for backup, the system produces unique backup files for each device in the HA pair or cluster nodes. The device's or node's role is noted in the backup file name.

Monitor the progress under Tasks in the Notifications pane:

  • The notifications will display one consolidated entry per backup action.

  • To view detailed information for each of the devices being backed up, click Details.

  • In the Device backup information dialog, you can monitor the backup progress at granular level.

  • For cluster backup, you can view node-wise backup progress.

  • To download the backup report in PDF format, click Download report.

Step 7

To request cancellation for an individual device or the entire backup job, in the Notifications pane, click Details. In the Device backup information dialog box, click Cancel or Cancel all when the progress reaches 25%. Consider the following notes to execute the Cancel operation:

  • Backup cancellation requires supported software—FTD version 7.7 or later—and the cancellation feature must be enabled.

  • For unified backup jobs, a device backup cannot be cancelled before its progress reaches 25%.

  • Completed or failed backups cannot be cancelled.

  • Cancelling an entire job attempts to cancel eligible device backups.

  • Unsupported devices and devices below the required progress continue with backup.

  • Cancelling a cluster control-node backup will also cancel its data-node backups.

After requesting cancellation, inspect each device’s result. “Cancel Backup Initiated” indicates that cancellation was requested; confirm "Backup cancelled" is displayed in the Tasks.

Step 8

To delete a backup, select the backup file checkbox, choose More actions > Delete. You cannot retrieve a deleted backup.

Restore Security Cloud Control-Managed Devices

For Firewall Threat Defense devices, you must use the Firewall Threat Defense CLI to restore from backup. You cannot use the Cloud-Delivered Firewall Management Center to restore a device.

Before you restore

  • If you have made changes to device licensing after your last backup of the device, revert the changes on the device before restoring. 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 a Firewall Threat Defense device sets the management IP address of the replacement device to the management IP address of the old device. To avoid IP address conflicts, disconnect the old device from the management network before you restore the backup on its replacement.

  • Ensure that you do not unregister managed devices from the Security Cloud Control, even if you physically disconnect an appliance from the network.

    If you unregister, you must redo some device configurations, such as security zone to interface mappings. After you restore, Security Cloud Control and devices should begin communicating normally.

  • Reimage replacement device.

    In an RMA scenario, the replacement appliance arrives configured with factory defaults. However, if the replacement appliance is already configured, we recommend that you reimage to the major version of the device backup that is used for restoration. Reimaging returns most settings to factory defaults, including the system password. You can only reimage to major versions, so you must patch after you reimage to the exact device patch version of the backup file.

Restore a Firewall Threat Defense Device

Firewall Threat Defense backup and restore is intended for RMA. Restoring the configurations overwrites all configurations on the device, including the management IP address. It also reboots the device.

In case of hardware failure, this procedure outlines how to replace a firewall device, either standalone, in an HA pair, or a cluster. It assumes you have access to a successful backup of the device or devices you are replacing.


Note

Do not unregister from the Security Cloud Control prior to restore process, even when disconnecting a device from the network. In Firewall Threat Defense HA and clustering deployments, do not suspend or break high availability or clusters. Maintaining registration ensures that replacement devices can automatically reconnect after restore.

In a Firewall Threat Defense HA deployment, you can use this procedure to replace either or both peers. To replace both, perform all steps on both devices simultaneously, except the restore CLI command itself. You cannot replace a Firewall Threat Defense HA device without a successful backup.


Note

The system stores the 5 most recent Firewall Threat Defense backups per device and clear all the other backups to optimize storage space. If you require the other backups for compliance purposes, we recommend that you download them (as explained in this procedure) to your private environment.

Before you begin

You must read and understand the requirements, guidelines, limitations, and best practices. Do not skip any steps or ignore security concerns. Careful planning and preparation can help you avoid missteps.

Procedure

Step 1

Contact Cisco TAC for replacement hardware.

Obtain an identical model, with the same number of network modules and same type and number of physical interfaces. You can begin the RMA process from the Cisco Returns Portal.

Step 2

Log in to Security Cloud Control and choose Products > Firewall.

Step 3

Select Administration > Firewall Management Center to open the Integrations page.

  1. Select Cloud-Delivered FMC and in the Management pane, click Devices to navigate to the Cloud-Delivered Firewall Management Center user interface.

  2. Select Administration > Advanced > Backup & Restore.

Step 4

The Device backup page displays the device name, backup file name, device model, device version, and the backup file size. Locate a successful backup of the faulty device and select the device backup check box to download.

Step 5

To download the backup file to your local storage, click Download.

Step 6

To download the backup file through a storage URL, choose More actions > Export the backup links. The CSV file with the backup storage URL is downloaded to your local system. The URL in the CSV is valid only for six hours, after which you must export it again to get a different URL. The backup links and the CSV file containing them must be treated as sensitive and confidential data. Store them securely and restrict access to authorized personnel only.


Note

In a HA or cluster device backup, you can download a specific HA peer or cluster node backup respectively.

Step 7

Copy the downloaded backup file to an SCP-accessible location so that the new device can access the backup file. Alternatively, you can manually copy the backup file to the replacement device at /var/sf/backup.

Step 8

Remove (unrack) the faulty device and disconnect all interfaces. In threat defense HA deployments, this includes the failover link.

See the hardware installation and getting started guides for your model: Cisco Firepower NGFW: Install and Upgrade Guides.

Step 9

Install the replacement device and connect it to the management network.

Connect the device to power and the management interface to the management network. In Firewall Threat Defense HA deployments, connect the failover link. However, do not connect the data interfaces.

Refer to the hardware installation guide for your model: Cisco Firepower NGFW: Install and Upgrade Guides.

Step 10

In an RMA scenario, the replacement device will arrive with factory default configurations. If the replacement device is not running the same major version as the faulty device, you must reimage the replacement device.

For reimage instructions, refer to the Cisco Secure Firewall ASA and Threat Defense Reimage Guide.

Step 11

Perform initial configuration on the replacement device.

Access the Firewall Threat Defense CLI as the admin user. You can use the console or you can SSH to the factory-default management interface IP address (192.168.45.45). A setup wizard prompts you to configure the management IP address, gateway, and other basic network settings.

See the initial configuration topics in the getting started guide for your model: Secure Firewall Threat Defense: install and upgrade guides.


Note

If you need to patch the replacement device, start the management center registration process as described in the getting started guide. If you do not need to patch, do not register.

Step 12

Ensure that the replacement device is running the same Firewall software version and build number, including patches, as that of the faulty device backup.

The existing device should not be deleted from the management center. The replacement device should be unmanaged from the physical network. The Firewall Threat Defense CLI does not have an upgrade command. To patch:

  1. From the management center web interface, create a new AC policy and use the default action "Network Discovery". Do not add any features or modifications to this policy. This policy will be used to register the replacement device and deploy a policy with no features so that you do not require licenses, and you can proceed to patch the device successfully. When the backup is restored, it should restore the licensing and policy into the expected state.

  2. Complete the device registration process: Refer Cisco Security Cloud Control: Secure Firewall Threat Defense Management.

  3. Patch the device using the procedures given in the Secure Firewall Threat Defense upgrade guides for Cloud-Delivered Firewall Management Center.

  4. Unregister only the temporary device entry created for the replacement device. Refer Cisco Security Cloud Control: Secure Firewall Threat Defense Management. Keep the original faulty device’s existing record in the management center so that the restored device can reconnect using that record.

    If you do not unregister, you will have a redundant device entry registered to the management center after the restore process brings your "old" device back up.

Step 13

Make sure the replacement device has access to the backup file. (You can either store the backup file in an SCP-accessible location or copy it to the device at /var/sf/backup.)


Note

Before restoring from an SCP server, add and verify the server’s SSH host key on the replacement Firewall Threat Defense device that will run the restore command. If the host key is not configured, the file transfer will fail. For more information on key configuration, see SSH host key verification for remote SCP storage.

Step 14

From the Firewall Threat Defense CLI, restore the backup.

Access the Firewall Threat Defense CLI as the admin user. You can use the console or you can SSH to the newly configured management interface (IP address or hostname). Keep in mind that the restore process will change this IP address.

  • To restore using SCP, execute the following CLI:

    restore remote-manager-backup location scp-hostname username filepath backup tar-file .

    The console prompts for the remote storage password. Only after entering the correct password, the backup package is downloaded and restore commences.

  • To restore from the local device, execute the following command: restore remote-manager-backup backup_tar_file

In Firewall Threat Defense Virtual HA and clustering deployments, make sure you choose the appropriate backup file: primary vs. secondary, or control vs. data. The role is noted in the backup file name. If you are restoring all devices, do this sequentially. Do not run the restore command on the next device until the previous device is restored and rebooted successfully.

Step 15

Log in to Security Cloud Control and wait for the devices to connect.

When the restoration is complete, the device logs you out of the CLI, reboots, and automatically connects to Security Cloud Control.


Note

The device is queued for deployment under Deploy.

Step 16

Before you deploy, perform any post-restore tasks and resolve any post-restore issues:

  • Resolve licensing conflicts or orphan entitlements. Contact Cisco TAC.

  • Resume HA synchronization.

  • VPN certificate enrollments are not restored and are marked as failed after restore. Re-add or re-enroll VPN certificates.

Step 17

Deploy configurations.

You must deploy. If a restored device is not queued under Deploy, force deploy from the Device Management page.

Step 18

Connect the device's data interfaces.

See the hardware installation guide for your model: Cisco Secure Firewall Threat Defense: Install and Upgrade Guides.

What to do next

After restore, you must reconfigure anything that was not restored. This can include reconfiguring licensing and audit log server certificate settings. You also must re-add/re-enroll failed Firewall Threat Defense VPN certificates. Ensure that you redeploy for the changes to take effect.

Restore Firewall Threat Defense from Backup: Firewall Threat Defense Virtual

Use this procedure to replace a faulty or failed Firewall Threat Defense Virtual device for VMware.

In Firewall Threat Defense HA and clustering deployments, you can use this procedure to replace all peers. To replace all, perform all steps on all devices simultaneously, except the restore CLI command itself.


Note

Do not unregister from the Security Cloud Control prior to restore process, even when disconnecting a device from the network. In Firewall Threat Defense HA and clustering deployments, do not suspend or break high availability or clusters. Maintaining registration ensures that replacement devices can automatically reconnect after restore.

Before you begin

You must read and understand the requirements, guidelines, limitations, and best practices. Do not skip any steps or ignore security concerns. Careful planning and preparation can help you avoid missteps.

Procedure

Step 1

Log in to Security Cloud Control.

Step 2

Under Products, click Firewall.

Step 3

Select Administration > Firewall Management Center to open the Integrations page.

  1. Select Cloud-Delivered FMC and in the Management pane, click Devices to navigate to the Cloud-Delivered Firewall Management Center user interface.

  2. Select Administration > Advanced > Backup & Restore.

Step 4

The Device backup page displays the device name, backup file name, device model, device version, and the backup file size. Locate a successful backup of the faulty device and select the device backup check box to download.

Step 5

Locate a successful backup of the faulty device from Device Backups under Backup Management.

Step 6

To download the backup file to your local storage, click Download.

Step 7

To download the backup file through a storage URL, choose More actions > Export the backup links. The CSV file with the backup storage URL is downloaded to your local system. The URL in the CSV is valid only for six hours, after which you must export it again to get a different URL. The backup links and the CSV file containing them must be treated as sensitive and confidential data. Store them securely and restrict access to authorized personnel only.


Note

In a HA or cluster device backup, you can download a specific HA peer or cluster node backup respectively.

Step 8

Copy the downloaded backup file to an SCP-accessible location so that the new device can access the backup file. Alternatively, you can manually copy the backup file to the replacement device at /var/sf/backup.

Step 9

Remove the faulty device.

Shut down, power off, and delete the virtual machine. For procedures, see the documentation for your virtual environment.

Step 10

Deploy a replacement device.

See the Cisco Firepower Threat Defense Virtual for VMware Getting Started Guide.

Step 11

Perform initial configuration on the replacement device.

Use the VMware console to access the Firewall Threat Defense Virtual CLI as the admin user. A setup wizard prompts you to configure the management IP address, gateway, and other basic network settings.

Do not set the same management IP address as the faulty device. This can cause problems if you need to register the device in order to patch it. The restore process will correctly reset the management IP address.

See the CLI setup topics in the getting started guide: Cisco Firepower Threat Defense Virtual for VMware Getting Started Guide.

Step 12

Ensure that the replacement device is running the same Firewall software version and build number, including patches, as that of the faulty device backup.

The existing device should not be deleted from the Security Cloud Control. The replacement device should be unmanaged from the physical network. The Firewall Threat Defense Virtual CLI does not have an upgrade command. To patch:

  1. Complete the Firewall Threat Defense Virtual registration process in Security Cloud Control.

  2. Patch the Firewall Threat Defense Virtual device.

  3. Unregister only the temporary device entry created for the replacement device from Security Cloud Control. Keep the original faulty device’s existing record in the management center so that the restored device can reconnect using that record.

Step 13

Make sure the replacement device has access to the backup file. (You can either store the backup file in an SCP-accessible location or copy it to the device at /var/sf/backup.)


Note

Before restoring from an SCP server, add and verify the server’s SSH host key on the replacement Firewall Threat Defense device that will run the restore command. If the host key is not configured, the file transfer will fail. For more information on key configuration, see SSH host key verification for remote SCP storage.

Step 14

From the Firewall Threat Defense Virtual CLI, restore the backup.

Access the Firewall Threat Defense Virtual CLI as the admin user. You can use the console or you can SSH to the newly configured management interface (IP address or hostname). Keep in mind that the restore process will change this IP address.

  • To restore using SCP, execute the following CLI: .

    restore remote-manager-backup location scp-hostname username filepath backup tar-file

    The console prompts for the remote storage password. Only after entering the correct password, the backup package is downloaded and restore commences.

  • To restore from the local device, execute the following command: restore remote-manager-backup backup_tar_file

In Firewall Threat Defense Virtual HA and clustering deployments, make sure you choose the appropriate backup file: primary vs secondary, or control vs. data. The role is noted in the backup file name. If you are restoring all devices, do this sequentially. Do not run the restore command on the next device until the previous device is restored and rebooted successfully.

Step 15

Log in to Security Cloud Control and wait for the devices to connect.

When the restoration is complete, the device logs you out of the CLI, reboots, and automatically connects to Security Cloud Control.


Note

The device is queued for deployment under Deploy.

Step 16

Before you deploy, perform any post-restore tasks and resolve any post-restore issues:

  • Resolve licensing conflicts or orphan entitlements. Contact Cisco TAC.

  • Resume HA synchronization.

  • VPN certificate enrollments are not restored and are marked as failed after restore. Re-add or re-enroll VPN certificates.

Step 17

Deploy configurations.

You must deploy. If a restored device is not queued under Deploy, force deploy from the Device Management page.

Step 18

Connect the device's data interfaces.

See the hardware installation guide for your model: Cisco Secure Firewall Threat Defense: Install and Upgrade Guides.

What to do next

After restore, you must reconfigure anything that was not restored. This can include reconfiguring licensing and audit log server certificate settings. You also must re-add/re-enroll failed Firewall Threat Defense Virtual VPN certificates. Ensure that you redeploy for the changes to take effect.