Every UniFi deployment has one object that matters more than the rest: the controller's configuration. Switches and access points are replaceable in an afternoon. The site configuration — networks, VLANs, policies, WLANs, port profiles — is the network, and if it is lost, every device becomes a factory-reset AP with an IP address.
Backups are the least interesting part of UniFi and the only part that matters on a bad day.
What the controller actually is
| Deployment | Runs on | Notes |
|---|---|---|
| UniFi OS console | UDM, CloudKey, UNVR | Controller is an app inside UniFi OS |
| Self-hosted | Linux, Docker, Windows | You own the OS, the database, and the backups |
| Hosted | Ubiquiti cloud | Least control, least maintenance |
All three present the same interface and the same site model. The differences that matter are where the backup file lives, how you authenticate, and what happens when the console itself fails.
The site model
A controller holds one or more sites. Each site has its own networks, devices, WLANs, policies, and statistics. The site switcher in the top-left is not cosmetic: a setting applied in the wrong site does nothing, silently.
For a district, one site per... is a design decision. One site for everything keeps policy in one place but makes the device list large. Separate sites per campus isolate failures but multiply the configuration you must keep consistent. Most districts run one site and use zones, VLANs, and AP groups for structure — which is the model the rest of this series assumes.
The site switcher is the most common cause of "the setting didn't apply"
Before troubleshooting a setting, confirm the site selector shows the site you think it does. A rule created in the wrong site is invisible where you are looking and active where you are not.
Backups: three kinds
| Kind | Where | Contains | Restore use |
|---|---|---|---|
| Automatic cloud | Ubiquiti account | Controller config | Console replacement |
Local .unf |
Your download or a server | Controller config | Full restore, migration |
| Site export | Per site, JSON | One site's config | Moving a site between controllers |
None of them contain Protect recordings, and none contain device firmware. A backup restores configuration; it does not restore video, and it does not downgrade devices.
A backup routine that survives a dead console
- Enable automatic cloud backups and verify the last one is recent. This is the "console died" path.
- Download a local backup weekly to a server you control. This is the "account locked" path.
- Export the site configuration monthly as JSON. This is the "I need to diff or migrate" path.
- Store the controller version with each backup. A backup restored onto older firmware may not import.
Automating step 2 is worth the effort: a scheduled curl against the backup endpoint, or a small
script using the API, writing to a dated file and pruning old ones.
Restoring without a second outage
The restore itself is fast. The mistakes are in the ordering:
- Match or exceed the firmware version. Restoring a newer backup onto older controller firmware fails or produces a partially applied config.
- Restore before adopting devices. If devices are already adopted to a fresh controller, they carry their own config and the restore does not overwrite them cleanly.
- Expect devices to reprovision. After a restore, APs and switches may reboot once. Do it in a maintenance window.
- Verify the four things that matter: networks and VLANs, WLANs, firewall policies, port profiles.
- Check the device list for anything missing or in an adoption-failed state.
A backup is not a backup until you have restored it
An untested backup is a hope. Once a year, restore one onto a spare console or a VM, confirm the networks and policies appear, then throw it away. The exercise takes an hour and answers the only question that matters.
Access: who can change what
| Role | Can do | Use for |
|---|---|---|
| Super admin | Everything, including account and backup | You, and only you |
| Site admin | Full control of assigned sites | A backup engineer |
| Read-only | View config and stats | Auditing, vendor support |
| Local-only account | Console access without cloud | Break-glass when SSO fails |
Two habits worth adopting: a local break-glass account that does not depend on the Ubiquiti cloud identity, and a read-only account for any script or vendor that only needs to look.
What breaks in production
- Cloud-only access. The account is locked or the cloud is unreachable, and no local credentials exist.
- Restoring onto older firmware, which fails halfway and leaves a partially configured site.
- Assuming video is backed up. Protect recordings are not in the network backup.
- No record of the controller version, so a restore is a guess.
- Backups on the same console. The disk fails and takes the configuration with it.
Checklist
- Automatic cloud backup is enabled and recent.
- A local backup is downloaded on a schedule to storage you control.
- The controller version is recorded with each backup.
- A restore has been tested at least once.
- A local break-glass admin account exists.
- Read-only access exists for scripts and vendors.
Next
The configuration is safe. Continue with Networks, VLANs, and DHCP to see what is inside it.