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.

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.

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

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