Ask an admin if they have backups of their routers and the answer is always yes. Ask when they last restored one, and the conversation gets quiet. Router backups have a special pathology: the device runs for years, the backup job rots silently (disk path changed, credential expired, disk filled), and the day lightning takes the PSU you discover your newest backup predates two ISP changes and the VPN migration.
RouterOS gives you two backup mechanisms that answer different questions, an upgrade system with one ordering rule people keep getting backwards, and netinstall for the day everything else failed. This article is the whole recoverability story in one place.
Binary Backup vs Export: Both, Not Either
Binary backup (/system backup save) is a full snapshot: complete config, users, passwords, certificates — restorable onto the same device (or same model) for identical-state recovery.
/system backup save name=gw-office password=BACKUP_ENCRYPTION_PASSAlways set a password — it encrypts the file, and these files contain everything needed to impersonate your router. The catch: binary backups are opaque (no diffing, no reading) and not portable across different models — restoring an RB5009 backup onto a CCR is asking for interface-mapping chaos.
Export (/export) is the human-readable config script:
/export show-sensitive file=gw-office-configSince RouterOS 7.x, /export hides secrets by default and show-sensitive includes them — the inversion of the old v6 hide-sensitive habit. An export without sensitive values documents; an export with them can rebuild. Exports diff beautifully in git (the Ansible article’s nightly export job is the implementation), work across models with light editing, and double as documentation. The catch: importing an export onto a non-blank config duplicates entries — exports rebuild from /system reset-configuration no-defaults=yes, not over live config.
The roles: binary backup for disaster recovery (same box, fast, complete), export for history, review and rebuild (readable, diffable, portable). A schedule that only does one of them is half a strategy.
Off-Box, Automatically
A backup on the router’s own flash protects against exactly nothing that matters — the failure modes are the flash dying, the box bricking, or theft. Ship both artifacts off-box nightly (scheduler discipline from the automation article applies):
# /system script add name=backup-to-remote policy=read,write,test,sensitive source=...:local name "gw-office-$[/system clock get date]"/system backup save name=$name password=BACKUP_ENC_PASS/export show-sensitive file=$name# SFTP push (target user is chrooted + write-only on the backup server)/tool fetch upload=yes mode=sftp address=10.99.0.5 user=rtrbackup password=SFTP_PASS \ src-path="$name.backup" dst-path="incoming/$name.backup"/tool fetch upload=yes mode=sftp address=10.99.0.5 user=rtrbackup password=SFTP_PASS \ src-path="$name.rsc" dst-path="incoming/$name.rsc"# keep flash tidy — remove local copies older than a few daysDetails that separate working DR from theater: the backup server account should be write-only into a landing directory (a compromised router must not be able to read or delete the archive — that’s your ransomware moat); retention runs server-side; and the job alerts on failure via the Telegram pattern from the automation article. A backup job that fails silently for eight months is the standard incident precondition.
And once a quarter: actually restore a binary backup onto a spare board or CHR instance. Restore-testing is the only evidence backups work; everything else is faith.
Upgrades: Channels, Order, Blast Radius
RouterOS 7 upgrade channels live under /system package update:
/system package update set channel=stable/system package update check-for-updates/system package update download # stages; applies on rebootstable is where production lives. testing/development are for lab boxes and for reading release notes early; long-term for v7 has historically lagged far behind — in practice, running a recent stable with deliberate timing is the conservative strategy on 7.x. “Deliberate timing” means: read the changelog (MikroTik’s release notes are terse but honest), wait a week or two after a release while the forum finds the sharp edges, then roll.
The ordering rule: RouterOS first, then firmware. The RouterBOOT bootloader is upgraded separately, and its new version ships inside the RouterOS package:
# after RouterOS upgrade + reboot:/system routerboard print # compare current-firmware vs upgrade-firmware/system routerboard upgrade/system rebootSo a full upgrade is two reboots: one applying RouterOS, one applying firmware. Skipping the firmware step leaves a version mismatch that’s usually harmless and occasionally the cause of deeply weird boot-time behavior — just finish the job. Never power-cycle a box mid-upgrade; flash writes that get interrupted are how routers meet netinstall.
Blast radius discipline: upgrade the lab CHR first (same version target, import of the production export — the CHR article covers the twin-environment pattern), then the least critical hardware, then the fleet one box at a time with a rollback plan. Before touching anything: fresh backup + export, off-box, verified. On paired setups (VRRP), upgrade the backup member, fail over, upgrade the former master — the same procedure as any HA pair.
Downgrades exist (/system package downgrade with the older package uploaded) but config compatibility runs forward, not backward — a config touched by 7.20 features may not load cleanly on 7.16. Treat downgrade as an emergency exit, not a strategy; your real rollback is the pre-upgrade backup.
Netinstall: The Last Resort That Must Be Rehearsed
Netinstall reflashes a board from scratch over Ethernet — the recovery for corrupted flash, forgotten-password-with-no-backup-access, or a botched upgrade. The workflow: run the netinstall utility on a directly-connected PC, power the router while holding reset to force Etherboot mode, select the RouterOS package, flash. It can wipe config or apply a baseline script during install.
Two operational truths. First, netinstall wants a boring setup: direct cable, static IP on the PC, no VLANs or fancy NICs in the path — half of “netinstall doesn’t work” is switches and firewalls between the PC and the board. Second, and the actual point: the worst time to use netinstall for the first time is during the outage. Run it once on a bench box so the day it matters, it’s a checklist and not an adventure. Know where your reset button is and what the beep patterns mean before the router is the only broken thing between users and the internet.
RouterBOOT’s protected bootloader option and the device-mode features (met in the containers article) can restrict netinstall/reset behavior for physical-security reasons — if you enable them, document it loudly, because they convert “netinstall recovery” into “RMA” if forgotten.
Verification
/system backup print # local artifacts exist and are recent/system script print # run-count on the backup job is climbing/system package update print # channel + installed vs latest/system routerboard print # firmware matches routerOS/log print where message~"backup|upgrade"Plus the two off-box checks no router command can do: files actually arriving on the backup server with sane sizes, and a quarterly restore test with a written result.
Closing Thoughts
Recoverability is a pipeline, not a file: binary backup and sensitive export, both shipped nightly to a write-only remote, failure-alerted, retention-managed, restore-tested on a schedule. Upgrades ride stable with a changelog read, a lab pass, RouterOS-then-firmware in that order, one box at a time. And netinstall is rehearsed before it’s needed. None of this is clever — which is the point. The clever parts of this series (BGP filters, VXLAN fabrics, container workloads) all stand on the assumption that the box under them can be rebuilt in twenty minutes from artifacts you trust. Make that assumption true.