Back Up, Export, and Restore a Palo Alto Configuration

Before you run this

This guide covers three related tasks on a Palo Alto firewall: exporting a copy of the configuration off the box (a backup — completely safe, read-only), saving named snapshots on the box, and loading and committing a configuration (a restore — this changes the running config and can lock you out or drop production traffic).

Exporting or saving a snapshot changes nothing and is safe to run any time. Loading a configuration and committing it is the dangerous part. A restored config can carry a different management IP, a different admin password, different interface or route settings, or security rules that block your session. Treat the load-and-commit step as production change, not a backup.

• Privileges: you need an admin account with a superuser role (or a role explicitly granted config export/import and commit rights). The web GUI is over HTTPS; the CLI is over SSH.
• Test first: read any configuration file before you load it. If you can, load and commit it on a lab firewall or a VM-Series instance before touching production. Never import a snapshot from an unknown source and commit it blind.
• Keep an out-of-band path open: have a console cable or a separate management path connected before you commit a restore. If the restored config changes the management interface, your SSH/HTTPS session dies mid-commit and the console is your only way back.
• Back up before you change anything: export the current running config to your workstation first, so you have a known-good file to return to.
• Maintenance window: do restores in a window. A commit interrupts sessions.
• Rollback path: PAN-OS saves a numbered configuration version on every commit. Before you commit, Revert to running configuration discards the candidate. After a bad commit, Load configuration version lets you pick the previous version and commit back. That is your undo — know where it is before you start.

I'm assuming a standalone PAN-OS 11.1 firewall (PA-series or VM-Series) not managed by Panorama, with GUI and SSH access. Menu paths on 10.x and 11.0 are nearly identical; if a label differs, it will be in the same Device > Setup > Operations area.

The three config files you care about

• running-config.xml — what the firewall is actually running now.
• Named snapshots — point-in-time copies you save on the box under a name you choose. They do not auto-load; you load and commit them deliberately.
• Configuration versions — snapshots PAN-OS creates automatically on each commit, numbered. This is what makes commits reversible.

A "backup" for off-box safekeeping means exporting running-config.xml (or a named snapshot) to a file you keep somewhere else.

Back up: export the running config to a file

GUI

1. Go to Device > Setup > Operations.
2. In the Configuration Management section, click Export named configuration snapshot.
3. In the dropdown, choose running-config.xml.
4. Click OK. Your browser downloads the XML file. Store it somewhere safe and dated, e.g. firewall01-running-2025-01-15.xml.

That file is a complete, human-readable copy of the config. This is the backup you want before every change.

CLI (good for scheduled/scripted backups)

From operational mode over SSH, you can push the running config straight to an SCP or TFTP server:

scp export configuration from running-config.xml to user@192.168.10.5:/backups/

Replace user@192.168.10.5:/backups/ with your own SCP account, host, and destination path. The firewall will prompt for the SCP password and, on first connection, to accept the host key.

If you use TFTP instead of SCP:

tftp export configuration from running-config.xml to 192.168.10.5

Replace 192.168.10.5 with your TFTP server's address.

For a scheduled hands-off backup, the mainstream approach is to have an external host pull or receive the file (an SCP server the firewall pushes to on a cron schedule via a jump host, or Panorama if you run it). PAN-OS also has a Scheduled Config Export feature under Panorama; if you don't run Panorama, drive the scp export command from an external scheduler. Check the PAN-OS admin guide for the exact scheduling options on your platform before relying on them.

Save a named snapshot on the box

Before a risky change, it's useful to freeze a copy on the firewall itself.

GUI: Device > Setup > Operations > Save named configuration snapshot, give it a name like pre-change-2025-01-15, click OK.

CLI: in configure mode:

configure
save config to pre-change-2025-01-15.xml
exit

This saves the current candidate config under that name. It does not commit anything.

Full device backup (state, not just config)

For a full rebuild — say an RMA where you replace hardware — the plain config XML is usually what you restore, but PAN-OS can also export a device state bundle that includes more than the config (relevant for VM-Series licensing and large-scale VPN). In the GUI that's Device > Setup > Operations > Export device state, producing a device-state.tgz. Use this in addition to, not instead of, your config XML, and follow Palo Alto's RMA / device-state restore procedure in the admin guide for the exact import step, since it differs from a normal config load.

Restore: import, load, and commit

This is the change-making part. Console access open, backup of the current running config already taken, maintenance window — then proceed.

Step 1 — Import the file onto the firewall (GUI)

1. Device > Setup > Operations > Import named configuration snapshot.
2. Browse to your saved XML file and upload it. This only stores the file on the firewall; it does not apply it.

Step 2 — Load it into the candidate config

1. Device > Setup > Operations > Load named configuration snapshot.
2. Select the file you just imported.
3. Click OK. PAN-OS loads it into the candidate config. Nothing is live yet.

The CLI equivalent, in configure mode, once the file is on the box:

configure
load config from firewall01-running-2025-01-15.xml

Replace the filename with your imported file's name.

Step 3 — Review, then commit

Look at what changed before you make it live. In the GUI, use Config > Preview Changes (available from the Commit dialog) to see the diff between candidate and running. On the CLI:

show config diff

When you're satisfied:

• GUI: click Commit (top right), review the summary, Commit.
• CLI: commit

If the restored config changes the management IP or admin credentials, your session will drop at commit. That's expected — reconnect on the new address, or via console if you lose it.

Restoring by rolling back a commit (no file needed)

If you just want to undo your last commit, you don't need a file at all — use the auto-saved versions:

1. Device > Setup > Operations > Load configuration version.
2. Pick the version from before your change (they're timestamped).
3. Commit.

Verify it worked

• After a backup: open the exported XML in a text editor and confirm it's real XML with your hostname, interfaces, and rules in it — not an error page or a truncated file. Confirm the file size is non-trivial.
• After a restore/commit: the commit dialog reports success or the specific error. Then sanity-check the box actually matches the config you loaded:

show system info
show interface all
show config running | match hostname

Confirm the hostname, management IP, interface IPs, and a couple of known security rules are what the restored config should produce. From a client behind the firewall, confirm expected traffic still passes.

Undo

• Before commit: Device > Setup > Operations > Revert to running configuration (or CLI revert config) throws away the candidate — no harm done.
• After a bad commit: Load configuration version, pick the previous timestamped version, and commit. This is exactly why you export the current running config before every restore — worst case, you re-import that known-good file and commit it.

For the authoritative menu labels and any options specific to your platform or PAN-OS build, see Palo Alto Networks' PAN-OS Administrator's Guide section on "Manage Configuration Backups" and "Load a Configuration Version."