How to Automate MikroTik Router Backups

The Problem

Most MikroTik routers get configured once and then left alone. Over months and years, someone adds firewall rules, tweaks NAT entries, adjusts OSPF timers. Nobody writes any of it down. The config that's running in production is the only record of what was done.

Then something breaks. A firmware upgrade goes sideways and the router reboots into a partially migrated config. A new hire cleans up "unused" firewall rules and takes down a VPN tunnel. The compact flash in a RB2011 starts throwing read errors. In every one of these cases, the question is the same: what was the config before this happened?

The answer is usually bad. An export someone ran eight months ago sitting in a random directory. An FTP server that stopped receiving backups when the disk filled up six months ago and no one noticed until now. A Scheduler script that was working fine until someone changed the FTP password. MikroTik backup automation is one of those things that either works reliably or doesn't work at all — there's rarely a middle state where it's "mostly working."

At scale this gets worse fast. If you manage fifty routers, you might be on top of it. If you manage five hundred, manual backup processes will fail silently across a meaningful percentage of your fleet at any given time.

RouterOS Backup Methods

RouterOS has two built-in mechanisms for saving configuration, and both have real tradeoffs.

/system backup save produces a binary .backup file. It captures the full configuration including passwords and certificates. You can restore it with one command and come back to exactly the state the device was in. The catch: it's device-specific and version-dependent. Restoring a backup from RouterOS 6 to a device running RouterOS 7 will fail or produce unexpected results. You can't open the file in a text editor to see what's in it. You can't diff two backups to find what changed.

/export produces a human-readable text file containing the RouterOS commands needed to recreate the configuration. It's possible to partially import an export on a different device, and you can read it with any text editor. The tradeoffs: it doesn't include passwords or private keys, it omits settings that are at their default values, and the ordering of entries can vary between RouterOS versions. Two exports of the same config taken on different firmware versions may look different even if nothing changed.

Neither method runs automatically. To get scheduled backups, the traditional approach is a Scheduler + FTP or SFTP script on each device. This works, but it requires per-device configuration, a working FTP server, error handling for failed transfers, and some way to detect when backups stop arriving. In a fleet of hundreds of devices, that's a lot of moving parts.

What Goes Wrong Without Automated Backups

The consequences of not having reliable backup automation tend to be invisible until they aren't:

• Device failure with no recent backup. Hardware fails, config is lost, and reconstruction from memory takes hours — assuming anyone still knows how it was set up.
• Firmware upgrade with no rollback path. RouterOS major version upgrades occasionally break things. Without a pre-upgrade config export, rolling back means starting over.
• Config change breaks connectivity. Without a recent baseline to diff against, finding what changed requires checking every section of the config manually.
• Compliance and audit requirements. Regulated environments often require demonstrable config history. "We think the config has been like this for a while" doesn't hold up.
• Staff turnover and tribal knowledge. The engineer who built the BGP setup left six months ago. The config is running, but no one understands it, and there's no version history to trace how it got to its current state.

What a Backup System Should Do

A reliable mikrotik backup automation solution needs to address the failure modes of the manual approach:

• Automatic scheduling. Backups should run without any per-device scripting. The schedule should be configurable centrally, not distributed across hundreds of individual device schedulers.
• Text-based storage. Configs need to be stored in a format that supports comparison. Binary backups are useful for full restores but useless for understanding what changed.
• Version history with diffs. Every backup should be a point in time you can return to, and you should be able to compare any two versions side by side.
• Failure visibility. If a backup fails, or if a config changes unexpectedly outside of a maintenance window, someone should be alerted. Silent failure is the main problem with DIY backup scripts.
• Restore capability. Viewing old configs is useful. Pushing a previous config back to a device is the actual recovery action — and that should be automatable too.
• Fleet scale. The system should work the same way whether you have ten devices or a thousand. No per-device setup required.

How The Other Dude Automates Backups

The Other Dude handles mikrotik configuration management through a Go-based poller that connects to each device using the RouterOS binary API over TLS (port 8729). There are no per-device backup scripts, no FTP server to maintain, and no Scheduler entries to configure on each router.

The backup process works as follows:

• Scheduled collection. The backup scheduler service runs within the backend and captures a full /export from each device on a configurable interval. The same device credentials used for monitoring and management are used for backup collection — no additional credential setup required.
• Version-controlled storage. Config exports are stored in PostgreSQL with complete version history. Every backup is a timestamped snapshot. Nothing is overwritten.
• Change detection. The poller can detect configuration changes via NATS events in addition to scheduled polling, so a change pushed through WinBox or the CLI shows up in the history within minutes rather than waiting for the next scheduled run.
• Diff viewer. The web UI shows a timeline of config changes per device. Select any two versions and get a side-by-side diff — additions in green, removals in red, unchanged lines in grey. This works the same way whether you're comparing yesterday to today or last year to last month.
• One-click restore. Select a previous backup from the history and push it back to the device using the config editor's two-phase apply mechanism. The two-phase process applies the config and waits for confirmation before committing, which means a restore that breaks connectivity will roll back automatically.
• Batch operations. You can pull the current config from multiple devices and compare them to identify inconsistencies — useful when you want to verify that a template change was applied uniformly across a group of devices.

Because the backup system is built on top of the same API connection the poller uses for everything else, there's no separate backup infrastructure to maintain. A device that's reachable for monitoring is reachable for backups.

Related Guides