RouterOS Config Backup & Restore: A Practical WISP Workflow

A .backup file is MikroTik's binary export — fast to restore, but opaque; you can't read it or diff it against yesterday's. A .rsc file is the plaintext script export — slower to apply by hand, but you can actually read it, search it, and see exactly what changed between two backups. Keep both; they serve different jobs.

• Daily scheduled backup across the whole fleet — automatic, no one has to remember.
• An extra backup immediately before any manual config change or firmware upgrade — this is the one that actually saves you, since it's the moment right before something was deliberately changed.
• Fleet-wide failure alerts — a backup job failing silently for weeks is the most common way backups stop being useful; raise a critical alert on failure so it gets noticed the same day.

Open the plaintext .rsc export directly in the backup table — this is how you confirm a device's actual running config matches what you expect, without touching the device at all. Useful for auditing a site after a tech visit, or just confirming nothing drifted since the last planned change.

Restore steps are vendor- and model-specific, but the shape is consistent: get the backup file onto the replacement or recovered device (via Winbox/SCP for MikroTik, the equivalent management tool for other vendors), apply it, then verify the device re-registers and polls cleanly before considering the site recovered. Always restore to a device running the same or a compatible firmware version as the one the backup was taken from — a version mismatch at restore time is a common source of a “restore that didn't actually restore everything.”

Backups are the safety net under both planned maintenance and unplanned failure. Pair a fresh pre-change backup with a maintenance window before any firmware rollout, so the change is both tracked and reversible.