Mikrotik RouterOS automatic backup and update: one script on the router itself

The whole job runs as a RouterOS script on the device

This project is a single RouterOS script rather than an application you install somewhere. The script lives in the router as a RouterOS script entry and is invoked by a scheduler task, so the backup logic, the release check and the upgrade all execute on the device itself. The repository layout supports that reading: the top level holds BackupAndUpdate.rsc alongside a howto folder with the screenshots used in the walkthrough and a lab folder. Everything the script needs is already present in RouterOS, which is why there is no dependency to install and no server to run. The consequence is equally important. Whatever the script can reach is limited to what a router can do on its own, and the place backups end up is wherever the mail server sends them. The upstream project is RouterOS Script, and the releases are named after RouterOS version dates, with 26.02.22 from 2026-02-22 as the most recent tag and the last push to the repository on 2026-08-27. The project is licensed under the MIT License, with the terms in a LICENSE.md file.

Three script modes, and the difference between them

The first decision you make is the scriptMode parameter at the top of the file, and the three available modes differ in how much autonomy the script has over the router's firmware. In backups only mode, the script creates system and configuration backups and attaches them to an email, using your mail account as the storage location for them. In backups and notifications mode, the same backup work happens and the script additionally watches for new RouterOS releases and reports them by email, with no change to the running version. In backups and automatic RouterOS upgrade mode, the script backs up first, then checks for a newer version and initiates the upgrade if one exists. The upgrade mode sends two emails, one carrying the backups taken from the previous RouterOS version and a second, sent after the upgrade, carrying backups of the updated system. That pairing is the point of the design. You get a copy of the state you are leaving and a copy of the state you land in, which is what makes a failed upgrade recoverable.

Patch-only upgrades keep a device from jumping a minor version

The upgrade mode can be narrowed to patch updates, and the README gives the case that motivates it. If the router is on v6.43.6, the script can autonomously move it to v6.43.7 while avoiding v6.44.0. The distinction is between a patch release and a minor one, and for a router sitting at a remote site the difference is whether you get a bug fix or a feature set with new configuration behaviour. RouterBOARD firmware can also be upgraded automatically, and the choice is driven by the installed RouterOS version, so the firmware step follows whichever RouterOS release the script settles on. The upgrade channel itself is configurable, so you can decide how far the script is allowed to travel on its own. The trade-off is real rather than theoretical. Automatic upgrades remove a manual step but also remove the opportunity to read the release notes for the version being installed, and the script's own safety net is narrow: it is programmed to stop the automatic update process if it fails to dispatch the backups by email.

Preparing the script and the mail server

The setup is a five-step walkthrough, and the first step is a constraint rather than a preference. The README warns that the device identity must not contain spaces or special characters, because the identity ends up inside the email subjects and attachments that the script produces. You download BackupAndUpdate.rsc and edit the parameters at the beginning of the file, where the README says every parameter is commented, and the two that catch people out are the correct email address for backups and the scriptMode variable. The script then goes into a RouterOS script entry: open System, then Scripts, click New, and name it BackupAndUpdate, because the scheduler task refers to the script by that exact name. The mail server is configured under Tools, then Email, and the README suggests smtp2go.com if you do not already have one, noting a free allowance of a thousand emails a month. A test message confirms the settings before anything is automated.

/tool e-mail send to="[email protected]" subject="backup & update test!" body="It works!";

A scheduled task, and why start times cannot collide

The trigger is a RouterOS scheduler entry under System, then Scheduler, added with the name Backup And Update, a start time of 03:10:00 and an interval of 1d 00:00:00, with the on-event field pointing at the script. The scheduler task can be created with a single command in the terminal instead, which is faster if you are already logged in. The on-event value is the script path followed by a semicolon, and the semicolon is part of the RouterOS syntax rather than shell punctuation.

/system scheduler add name="Firmware Updater" on-event="/system script run BackupAndUpdate;" start-time=03:10:00 interval=1d comment="" disabled=no

One detail in that command deserves attention. The README states that the start time has to be different for all your Mikrotik devices in a chain, which is a scheduling requirement rather than a style note. If several routers start their work at exactly the same second, they compete for the same upstream mail service and the same outbound connections, and a throttled provider turns that into a partial backup day. The manual test step then closes the loop: run /system script run BackupAndUpdate; in a WinBox terminal, watch the log window for the script's operation, and if it finishes without errors, look for the backup message in your mailbox.

Where this approach stops being enough

The design has a clear boundary and it is worth naming it before you deploy it. Backups live in an email account, which means the mail provider is your retention system, your archive and your off-site copy at once. There is no second copy, no version listing you can browse, and no checksum list you can compare a restored configuration against. The email attachment also decides the format, and the README gives no retention or cleanup behaviour to configure. If a router stops reaching the mail server, the backups stop, and in automatic upgrade mode the script responds by halting the update rather than continuing, which protects the device but leaves the fleet without fresh backups. Recovery from a router that has already lost its configuration is also not covered in the walkthrough. The script writes the backup out, it does not restore one, so a restoration procedure is something you still have to own.

Why not a central backup server or a dedicated tool

The usual alternative to a script like this is a server that pulls backups from every router on a schedule and writes them to object storage, with the server holding the retention policy and the inventory. The difference in approach is where the logic and the trust live. The central server is the single place that knows which devices exist, when each was last seen and what has changed since, and it survives a router being wiped because the copy was never on the router. A router-resident script has the opposite property. There is no server to operate, no agent to install on the device, and nothing to keep running in a datacentre, and each router handles its own schedule. What it gives up is the fleet-wide view and any storage you do not manage yourself, since the mailbox is doing that job. The two are not equivalent in cost either. The script needs no infrastructure and no per-device server credentials, while a pull-based setup needs API keys in every router configuration.

Editorial conclusion

The script fits a small estate of MikroTik routers where the operator already logs in over WinBox, needs daily configuration backups kept somewhere off the device, and wants RouterOS patch releases applied without a site visit. It does not fit fleets that need backups written to a specific storage service, that need the full upgrade history kept centrally, or that run a busy-chained schedule, because the start time has to differ per device and the mail path is the only exit. Before using it, set the device identity to a name without spaces or special characters, pick the scriptMode you actually want, and confirm the mail server test in Tools, Email works before you let the scheduler run an unattended upgrade.

Frequently asked questions

Official sources

1. beeyev/Mikrotik-RouterOS-automatic-backup-and-update on GitHub
2. Issues
3. License: MIT
4. README
5. Releases