MikroTik Backup Solution

The Problem with MikroTik Backups

Router backups should be the simplest operational task in network management. In practice, they're one of the most commonly broken. The typical MikroTik backup setup involves a Scheduler script on each device that runs /system backup save or /export and sends the result to an FTP server. This works until it doesn't — and the failure modes are almost always silent.

The FTP server's disk fills up. A firmware upgrade changes the Scheduler syntax. Someone changes the FTP password on the server but not on the 200 routers pushing to it. A device gets replaced and nobody copies the Scheduler script to the new one. In every case, backups stop arriving and nobody notices until the moment they need one.

Even when the backups are running, the result is a pile of text files in a directory. Finding what changed between Tuesday and Thursday means manually diffing two exports. Figuring out when a specific firewall rule was added means reading through dozens of exports chronologically. Restoring a previous config means copying the export text, SSHing into the router, and pasting it — hoping the import doesn't fail halfway through on a syntax difference between firmware versions.

This isn't a backup solution. It's a backup hope.

What a Real Backup Solution Requires

A mikrotik backup solution that actually works in production needs to address the specific failure modes of DIY approaches:

• Centralized scheduling. Backups should be triggered from the management platform, not from per-device Scheduler scripts. One schedule, applied fleet-wide. No per-device configuration to maintain or break.
• Version history, not just snapshots. Every backup should be a point in the device's config timeline. You should be able to navigate that timeline, see exactly what changed at each point, and compare any two versions.
• Diff capability. Side-by-side comparison showing added, removed, and modified lines between any two config versions. This is the difference between "something changed" and "this specific firewall rule was modified."
• Tested restore path. A backup you can't restore isn't a backup. The restore mechanism should be built into the platform, not a manual copy-paste-SSH workflow.
• Failure alerting. If a backup fails — device unreachable, API timeout, storage error — someone needs to know immediately, not six months later when they need the backup.
• Fleet-wide coverage. The system should work identically for ten devices or a thousand. Adding a new device to the fleet should automatically include it in the backup schedule.

How The Other Dude Handles Backups

The Other Dude's backup system is built on the same Go-based poller that handles monitoring and command execution. It connects to each device via the RouterOS binary API over TLS (port 8729) and retrieves a full /export on a configurable schedule — every six hours by default.

There are no per-device Scheduler scripts to maintain. No FTP server. No per-device backup configuration at all. Every device that's connected to the platform is automatically included in the backup schedule from the moment it's added.

Git-Backed Version History

Config exports are stored with complete version history in PostgreSQL. Every backup is a timestamped snapshot. The system compares each new snapshot to the previous one and records the diff. Nothing is overwritten — you have a complete timeline of every configuration state the device has been in since it was added to the platform.

This is functionally equivalent to having every config change committed to a git repository with a timestamp and a diff. You can navigate the timeline to answer questions like "what did this router's config look like on March 3rd?" or "when was this NAT rule first added?" without reading through raw export files.

Side-by-Side Diffs

The web UI includes a diff viewer that shows two config versions side by side with additions highlighted in green, removals in red, and unchanged lines in grey. Select any two snapshots for a device — or compare configs across two different devices — and see exactly what differs.

This is particularly useful for configuration drift detection. When a device's config changes between backup cycles due to an out-of-band WinBox or SSH change, the diff shows exactly what was modified. Combined with the platform's audit trail, you can distinguish between authorized changes pushed through the platform and unauthorized changes made directly on the device.

One-Click Restore

Select any previous backup from the timeline and push it back to the device. The restore uses the same two-phase commit mechanism as all config pushes: the config is applied, the platform verifies the device is still reachable, and if the device goes silent (indicating the restore broke connectivity), the change is automatically reverted.

This means you can restore a previous config to a remote device with confidence that you won't lock yourself out. If the restored config breaks the management path, the device reverts to its pre-restore state automatically.

Binary Export Download

In addition to text-based config exports, the platform supports downloading binary .backup files for full device restore scenarios. Binary backups capture passwords, certificates, and other data that text exports omit. These are useful as a disaster recovery artifact when you need to rebuild a device from scratch on identical hardware.

Change Detection Between Cycles

The backup system doesn't only run on the scheduled interval. The poller detects configuration changes via NATS events, so a change made through WinBox or SSH between scheduled backup cycles will trigger an additional snapshot capture. This means the version timeline reflects actual change events, not just periodic snapshots that might miss intermediate states.

Config Push Rollback as a Safety Net

Backups and config management work together as complementary safety mechanisms. The backup system gives you a timeline of every previous state. The config push system's two-phase commit gives you automatic rollback on bad changes. Together, they mean you always have both a way to undo a recent change automatically and a full history to restore from manually.

For MSPs managing multiple clients, the backup system is tenant-scoped. Each client's backup history is isolated. Backup schedules, retention policies, and restore operations all operate within tenant boundaries.

Getting Started

Backups start automatically when you add a device to the platform. There's no additional setup required. The Quick Start guide covers deploying the platform and connecting your first device — at which point the first config backup will be captured within minutes.

For a deeper look at the backup automation architecture and how it handles edge cases like unreachable devices and firmware version differences, see the detailed backup automation guide.