Backup best practices for ISPs

01What needs a backup

The right question is: if this device disappeared now, how many subscribers would lose access and how long would it take to reconfigure? At an ISP, the list usually is:

• PPPoE concentrators and BNGs: authentication, pools, speed profiles.
• Edge routers: BGP sessions, filters, announced prefixes.
• CGNAT: rules and port ranges, which you need to answer law enforcement requests.
• OLTs: profiles and the registration of every ONU. The hardest device to rebuild by hand.
• Aggregation and transport switches: VLANs and trunks.
• Firewalls and backhaul radios.

Keep an inventory (name, IP, vendor, model, role) and use it as the backup list. A new device that joins the network without joining the inventory is the first one missing when something breaks.

02Frequency

One collection a day, overnight, is the minimum. On top of that:

• run a manual backup before a planned change and another one after it;
• store a new version only when the configuration changes. Keeping the same file every day just takes up space and buries the real changes among identical copies.

03Text and history

Prefer text backups (show running-config, display current-configuration, /export) over binary formats. Text can be read, searched and compared. Binary can only be restored as a whole.

Keep versions as history instead of overwriting one file. With history, the question "what changed between yesterday and today?" is answered in seconds (see Comparing configuration versions).

04Where to keep it

Adapt the 3-2-1 rule: three copies, in two different places, one of them outside your environment.

The backup server should not run on the same device or the same physical machine it protects.

05Credentials and secrets

• create a user just for backups on each device, with read permission and, when possible, accepted only from the server IP;
• store those users' passwords encrypted on the backup server, never in a spreadsheet;
• decide whether the backup keeps the configuration secrets (PPPoE passwords, keys, communities). With them, the restore is complete; without them, the file is safer, but restoring means typing passwords again;
• restrict who can access the backup server: it holds the configuration of the whole network.

Example of a minimal user on MikroTik: a user just for backups.

06Knowing when it fails

The worst backup is the one that stopped working three months ago without anyone noticing. A changed password, a new IP, a replaced device: all of these break collection silently.

• check, every day, the list of devices whose last collection failed;
• check the date of the last good backup of each device, not just whether the job ran;
• when a device is replaced, update its backup entry the same day.

07How long to keep it

Since a new version is only stored when something changes, text history takes little space: you can keep years of it. For off-site copies, keep at least a few months, enough to cover a problem that takes a while to be noticed.

For CGNAT, align retention with what the ISP needs to answer subscriber identification requests; in Brazil, the Marco Civil da Internet requires keeping connection records for one year, and other countries have their own rules.

08Testing the restore

Pick one device per quarter and restore its backup onto a lab device or during a maintenance window. The test shows what is missing: a password that was not in the file, a command that does not come back on the same version, a step nobody documented.

The walkthrough is in How to restore a configuration from backup.

09Checklist

1. Inventory with every device that keeps the network running.
2. A backup user with minimal access on each device.
3. Automatic daily collection, and manual collection before and after changes.
4. Version history as text, with comparison between dates.
5. A copy off the server (cloud or another site).
6. Collection failure alerts checked every day.
7. A restore test at least once a quarter.