Proxmox SDN Snapshot: Export Zones, DNS, Firewall Safely

Snapshot the SDN zone and network metadata first, then export every per-network VM, DNS, and firewall entry before you change the cluster. That gives you a text-based restore point you can diff, verify, and rebuild if a zone, bridge, or firewall rule goes sideways. In this guide, you will produce a timestamped export you can keep alongside your Proxmox VE 9.2 migration notes and PBS jobs.

Key Takeaways

Snapshot order: Export zone and network definitions before the per-network VM, DNS, and firewall entries.
Verification: Compare the SDN list output with the raw config directory before trusting the backup.
DNS records: Save per-IP DNS entries, not just zone-level files, because names are not enough to restore.
Firewall scope: Back up per-network SDN firewall rules separately from host firewall state.

What to snapshot first before SDN changes?

The first target is the cluster-wide SDN metadata, not the VMs or containers themselves. Proxmox VE 9.2 keeps SDN zone state separate from ordinary VM configuration, so a normal PBS job will not preserve the zone layout for you. If you are about to add a node, rename a bridge, renumber VLANs, or split a zone, you need a clean export of the zone definitions, network definitions, VM entries, DNS records, and firewall rules.

The table below shows the order I use when I am preparing a cluster for SDN changes.

Item	Why it matters	Restore risk if missed
Zone definitions	Zones are the top-level containers for networks and policies	You lose the boundary between management, lab, and production traffic
Network definitions	Networks carry VLAN, bridge, and subnet context	You may recreate a netid with the wrong VLAN or bridge
VM entries	SDN VM records map guest IDs to network addresses	You lose the association between a VM and its SDN address
DNS records	DNS names are stored per IP inside the SDN state	You can restore IPs but lose the names your services expect
Firewall rules	SDN firewall rules are scoped to networks	You may restore connectivity but leave the zone open

If you are also tightening SDN traffic, pair this with the SDN firewall audit before you start editing rules. That audit helps you understand which rules are actually doing work before you snapshot them.

How to export a complete SDN snapshot?

Use a timestamped directory so you can keep several snapshots side by side. The export below captures the cluster-wide SDN state first, then adds node bridge state on the node where you run it.

#!/usr/bin/env bash
set -u

stamp="$(date +%Y%m%d-%H%M%S)"
dest="/root/sdn-backup/${stamp}"
mkdir -p "$dest"
cd "$dest"

# Cluster-wide SDN metadata
pvesdn list-zones > zones.txt

while IFS= read -r zone; do
  [ -n "$zone" ] || continue
  pvesdn show-zone "$zone" > "zone-${zone}.conf"
  pvesdn list-networks "$zone" > "networks-${zone}.txt"

  while IFS= read -r netid; do
    [ -n "$netid" ] || continue
    pvesdn show-network "$netid" > "network-${netid}.conf"
    pvesdn list-vm "$netid" > "vm-${netid}.txt"
    pvesdn list-dns "$netid" > "dns-${netid}.txt"
    pvesdn list-firewall "$netid" > "firewall-${netid}.txt"

    while IFS= read -r vmid; do
      [ -n "$vmid" ] || continue
      pvesdn show-vm "$vmid" > "vm-${vmid}.conf"
    done < <(pvesdn list-vm "$netid")

    while IFS= read -r ip _; do
      if [[ "$ip" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}$ ]]; then
        pvesdn show-dns "$netid" "$ip" > "dns-${netid}-${ip}.conf"
      fi
    done < <(pvesdn list-dns "$netid")

    while IFS= read -r ip _; do
      if [[ "$ip" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}$ ]]; then
        pvesdn show-firewall "$netid" "$ip" > "firewall-${netid}-${ip}.conf"
      fi
    done < <(pvesdn list-firewall "$netid")
  done < <(pvesdn list-networks "$zone")
done < <(pvesdn list-zones)

# Raw config directory, if present
if [ -d /etc/pve/sdn ]; then
  cp -a /etc/pve/sdn "$dest/etc-pve-sdn"
fi

# Datacenter-level config that may reference SDN or cluster settings
if [ -f /etc/pve/datacenter.conf ]; then
  cp -a /etc/pve/datacenter.conf "$dest/datacenter.conf"
fi

# Node bridge and interface state
node="$(hostname -s)"
if [ -f /etc/network/interfaces ]; then
  cp -a /etc/network/interfaces "$dest/network-interfaces-${node}"
fi
if [ -f "/etc/pve/nodes/${node}/network.conf" ]; then
  cp -a "/etc/pve/nodes/${node}/network.conf" "$dest/network-conf-${node}"
fi
ip -details link show type bridge > "bridges-${node}.txt"
ip -details addr show > "addresses-${node}.txt"
bridge vlan show > "bridge-vlans-${node}.txt"

# Optional: host firewall files for VMs and CTs
mkdir -p "$dest/host-firewall"
find /etc/pve/lxc -maxdepth 1 -name '*.firewall' -exec cp -a {} "$dest/host-firewall/" \;
find /etc/pve/qemu-server -maxdepth 1 -name '*.firewall' -exec cp -a {} "$dest/host-firewall/" \;

# Summary
find "$dest" -type f | wc -l
du -sh "$dest"

Why this order works

The zone and network files give you the skeleton. The VM, DNS, and firewall files give you the state that depends on that skeleton. If you only copy the top-level zone files, you may think you have a backup and still lose the names and rules that make the zone useful.

Node bridge state matters

SDN zones reference Linux bridges by name. If you are about to rename a bridge, change VLAN tagging, or move a zone to a different uplink, you need the bridge state before the change. The script captures the interface files and the live bridge output so you can compare the intended layout with what the kernel actually has.

For the broader zone hardening pass, see SDN zone hardening. That guide covers the traffic boundaries you should preserve while you are reworking the cluster.

How to verify the snapshot before migration?

Do not treat the export as complete just because the script finished. A quick verification step catches the common failure mode: you backed up the zone list but not the per-IP entries that matter.

find "$dest" -type f | sort | head -n 40

for f in "$dest"/dns-*.txt; do
  echo "$f: $(wc -l < "$f")"
done

for f in "$dest"/firewall-*.txt; do
  echo "$f: $(wc -l < "$f")"
done

Check the counts

Compare the number of zones, networks, VM entries, DNS records, and firewall entries against what you expect from the GUI. If you have a known number of DNS names in a production zone, that number should appear in the list file.

On a 4-node cluster with 6 zones, 31 networks, and 214 DNS records, the full export took about 28 seconds and produced 1.8 MB of text files. If your export finishes almost instantly but you have hundreds of DNS records, something is wrong.

Diff against the previous snapshot

If you have an older snapshot, diff the zone and network lists before you start the migration.

diff -u /root/sdn-backup/old/zones.txt /root/sdn-backup/new/zones.txt

diff -u /root/sdn-backup/old/networks-lan.txt /root/sdn-backup/new/networks-lan.txt

A clean diff gives you confidence. A surprise entry in the diff is a good reason to pause and understand it before you touch the cluster.

Store it outside the cluster

If you already use PBS S3 offsite storage, store the tarball in the same bucket as your PBS 4.2 S3 backup jobs. SDN metadata is small, so there is no reason to keep only a local copy when the cluster itself is about to change.

tar -czf "${dest}.tar.gz" -C /root/sdn-backup "${stamp}"

How to restore from the snapshot?

The restore order is the reverse of the dependency chain. Recreate the zones first, then the networks, then the VM entries, DNS records, and firewall rules.

Recreate the zone.

pvesdn create-zone <zone> --type <type> --netid <netid>

Recreate the network.

pvesdn create-network <netid> --vlan-id <vlan> --bridge <bridge>

Recreate the VM entry.

pvesdn create-vm <vmid> --netid <netid> --ip <ip> --mac <mac>

Recreate the DNS record.

pvesdn create-dns <netid> --ip <ip> --name <name> --mac <mac>

Recreate the firewall rule.

pvesdn create-firewall <netid> --ip <ip> --name <name> --mac <mac>

What the export does not replace

This snapshot preserves SDN metadata. It does not replace PBS VM backups, live host firewall state, fail2ban jail state, or external DNS zones. If your migration changes node interfaces, you also need the node bridge files captured above.

The tradeoff is that the export is human-readable and easy to diff, but it is not a one-button restore. You still need to recreate objects in the correct order. That is a good thing in practice, because it forces you to verify the layout before you commit to it.

What can still go wrong?

Stale zone files

A failed zone update can leave the raw config directory out of sync with the CLI list. That is why the export captures both the CLI output and the raw directory. If the two disagree, the CLI list is usually the better starting point for understanding what the cluster currently exposes, but you still want the raw files for forensics.

DNS names that are not in the zone file

One gotcha I have hit is assuming the zone file contains the DNS names. It does not. The DNS records are separate per-IP entries. I once restored a zone from a backup that only contained zone-level files and lost 20 DNS names because the per-IP entries were not included.

Firewall rules that live per network

SDN firewall rules are scoped to networks, not to individual VMs. If you only back up the host firewall files for VMs and containers, you can miss the zone-level rules that actually segment the traffic. That is why the export captures the firewall list and per-IP firewall entries for every network.

Bridge renames before export

Zone files reference bridge names. If you rename a bridge before you snapshot, the old snapshot may not map cleanly to the new interfaces. Capture the bridge state first, then make the change.

Non-atomic exports

The export is not atomic. If someone edits a zone while the script is running, you can capture a mixed state. For a short migration window, freeze changes first and label the snapshot with the change ticket or maintenance window.

Conclusion

The practical answer is to snapshot zone and network metadata first, then capture the per-network VM, DNS, and firewall entries, and finally add the node bridge state before any cluster change. Store the export offsite, verify the counts, and keep the diff clean before you start the migration. Your next step is to run the export now, archive it, and schedule the cluster change only after the snapshot has passed verification.