UniFi Backups, Migration, and Disaster Recovery

Almost nobody thinks about UniFi backups until the controller hardware dies, a console fails, or an update goes sideways — and then it’s the only thing that matters. The good news: UniFi recovery is very doable if you understood beforehand what a backup contains and what survives a controller loss. This guide is that understanding plus a recovery and migration plan, so a dead controller is an afternoon, not a rebuild from memory.

What keeps working when the controller is gone

Start with the reassuring part, because it changes how much you should panic: adopted UniFi devices keep forwarding traffic without the controller. As covered in where to run the controller, the controller is a management plane, not a data plane. If the controller dies at 2 a.m., your Wi-Fi, switching, and (if the gateway is a separate adopted device) routing keep running on their last-known configuration.

What you lose immediately is management: you can’t change settings, adopt new devices, see stats, or push firmware. What you lose permanently — if you have no backup — is the configuration and history: SSIDs, VLANs, firewall rules, port profiles, device names, and the accumulated setup that took you hours. The network runs; you just can’t safely touch it and you can’t reconstruct it cleanly. That’s the gap a backup closes.

What a UniFi backup actually contains

A UniFi Network Application backup is essentially a snapshot of the controller’s configuration and state — the things you’d hate to retype:

• Site configuration: networks/VLANs, SSIDs, firewall and routing rules, port profiles.
• Device inventory and per-device settings (names, static IPs, port overrides, RF settings).
• Optionally, accumulated statistics/history depending on the backup scope you choose.

What it is not: it is not the device firmware, and it is not a substitute for the devices physically existing. It restores the brain — the configuration — onto a controller, after which devices re-associate with that restored controller and pick their settings back up. Think of it as the config and memory, not the hardware.

A second, related artifact worth knowing: a backup taken from one controller can generally be restored onto a different controller of a compatible version. That single fact is what makes both disaster recovery and migration possible — they’re the same mechanism used for different reasons.

Backups are worthless if you can’t reach them after the failure

The most common backup mistake is subtle: the only copy of the backup lives on the device that fails. A CloudKey backup stored only on that CloudKey is useless when the CloudKey is the thing that died. A self-hosted controller’s backup sitting only on that same server doesn’t help when that server is gone.

The rule: a backup must exist somewhere the failure can’t take with it.

• Enable scheduled/automatic backups so you’re not relying on remembering.
• Get a copy off the device — download backups somewhere separate (another machine, your normal file backups), or use UniFi’s account/cloud backup option where applicable, so a copy survives the appliance.
• Keep more than one generation. A backup that faithfully captured a broken or compromised state, with no earlier copy, isn’t a rescue.

A backup you cannot retrieve after the event is not a backup. Verify you can actually get to a recent copy from somewhere other than the thing that broke.

Disaster recovery: the actual sequence

When a controller or console fails, the recovery is methodical, not heroic:

1. Stand up a replacement controller — new console, restored self-hosted instance, or a temporary controller — on a compatible version. Restoring an old backup into a wildly newer or older controller is where version mismatches bite; aim for a compatible version.
2. Restore the backup onto it. This rebuilds your site configuration — networks, SSIDs, rules, device entries — without retyping anything.
3. Re-adopt the devices to the restored controller. Because the devices were managed by the old controller, they need to be pointed at / accept the new one. Devices on the controller’s own subnet are easiest; off-subnet devices need a Layer 3 pointer, exactly as in adoption troubleshooting. Treat lingering “managed by other” devices as stale-credential cases and clear them to default, then adopt fresh.
4. Verify: every device connected and provisioned, VLANs/SSIDs present, firewall rules intact, internet and inter-segment behavior as expected.

The reason this is an afternoon and not a catastrophe is entirely steps 0 and 2: you had a retrievable backup, and you restored it onto a compatible controller instead of rebuilding the config from memory.

Migration is disaster recovery you do on purpose

Moving from a CloudKey to a Dream Machine, from self-hosted to a console, or from one host to another, is the same backup/restore/re-adopt mechanism — just planned instead of forced:

• Take a fresh backup on the old controller right before migrating.
• Restore it onto the new controller at a compatible version.
• Re-adopt devices to the new controller, ideally on its subnet first, then segmented.
• Keep the old controller available but idle until the new one is fully verified — your instant rollback if something’s off. Don’t decommission the old one the same hour.

The mindset: a migration is a disaster recovery you’re choosing the timing of. Same steps, same backup dependency, far less stress because you scheduled it and kept the old path warm.

Don’t run two controllers fighting over the same devices

A migration- and recovery-specific trap: leaving the old controller running while the new one tries to manage the same devices. Two live controllers both trying to own a device produces flapping and stuck provisioning — a confusing failure that looks like a device bug but is really two managers. During recovery/migration, ensure exactly one controller is actively managing at the end. Keep the old one available for rollback, but not simultaneously contending for the devices.

A recovery posture you can actually rely on

1. Know what survives: devices keep passing traffic; configuration/history is what you lose without a backup.
2. Enable scheduled backups and keep multiple generations.
3. Store a copy off the device that could fail — that’s the difference between a real backup and a comforting illusion.
4. Recover by restoring onto a compatible-version controller, then re-adopting — not by retyping your config.
5. Treat migration as planned disaster recovery: fresh backup, restore, re-adopt, keep the old controller as rollback briefly.
6. End with exactly one active controller so devices aren’t fought over.

The teams that shrug off a dead CloudKey are not lucky — they had a retrievable backup and knew the restore/re-adopt path. The ones rebuilding everything from memory skipped exactly that. For where the controller should live in the first place and the update discipline that surrounds backups, see controller hosting options, firmware and update strategy, and the rest of our UniFi guides.