What a backup here actually is, how schedules inherit, and the one thing this page does not do.
A backup is a text export of the configuration — the RouterOS script form, the same thing you would get from an export on the device itself, stored in the manager's database. Downloading one gives you a .rsc file.
It is not the binary backup file RouterOS can also produce. That difference matters in both directions: a text export is readable, diffable and portable between devices of the same model, but it is not a byte-for-byte image of the box.
.rsc like a password file. Reading backups requires the admin or operator role; deleting one requires admin.The Backups page opens with a summary of every device you can see: how many are covered, and what is wrong with the rest. It is the answer to "are we backing everything up", without reading the list device by device.
The rest is split by what is actually wrong, because the four cases need different work:
| Count | What it means |
|---|---|
| No backup | No export has ever been stored for that device. |
| Incomplete latest | The newest stored export is one of the cut-short ones described below, and the good backup that had replaced it is gone — pruned by retention, or deleted. That device's latest stored configuration is not a usable restore point. |
| Overdue | A schedule exists and has missed two runs in a row. One missed run — a device offline for an hour, a restart — is not reported; the second consecutive miss is a pattern. |
| No schedule | Nothing backs that device up on its own: no schedule of its own, no site policy, no global default. A device you back up by hand appears here, however recent its last export — it is not called overdue, because there is no schedule for it to be late against. |
Click any count to see the devices behind it, with when each was last backed up and its interval, and to act on them there — back one up now, or give it a schedule. The summary re-reads itself when an export finishes or a schedule changes, so a gap you close stops being shown.
Disabled devices and SNMP-only devices are left out of the totals entirely. The manager never backs those up, so counting them as gaps would report work that does not exist. Everything in the summary is read from the manager's own database — no device is contacted to produce it.
An export that arrives cut short is worse than no export: it looks like a backup and is not one. Every export is checked before it is stored, and older rows are re-examined as well — anything that does not hold a whole configuration is marked incomplete in the list so it is never mistaken for a usable restore point.
The test is deliberately one-directional. A stored config that is a strict prefix of a later one was truncated in transit — configuration that reappears was never really deleted. The reverse, a later export being shorter, is a real deletion someone made, and is left alone.
Two more things the list tells you:
Backups can run on a schedule at three levels. They resolve in a fixed order, and knowing it saves a lot of confusion:
| Level | Behaviour |
|---|---|
| Per-device, set by hand | Always wins. Once you set a device's schedule explicitly, no site or global policy overwrites it again. |
| Per-site | Every device in the site inherits it, including devices added later. Overrides the global default. |
| Global default | A fallback for sites with no schedule of their own, so a newly created site is covered without anyone opening the Backups page. Off unless you turn it on. |
Remove a site policy and the inherited schedules it created go with it — but hand-set device schedules stay, because they were never inherited in the first place.
Intervals run from every two hours to weekly, with a time of day for the longer ones. Schedules can also be applied to a whole site or to many devices in one pass.
A schedule can prune its own history by count, by age, or both — keep the last N, keep anything newer than N days. Pruning runs after each scheduled backup, so a device that has stopped being backed up also stops being pruned.
Backups taken by hand are not on a schedule and are not pruned by one.
Optionally, each successful backup is also written to a file on a mounted volume — one .rsc per device, organised by site, overwritten each time. Turn it on in Settings.
This is what makes a real off-box strategy possible: mount the volume elsewhere, point a git checkout at it and commit after each write for a free change history, or sync it to a NAS. The manager only ever writes there — it never deletes, so housekeeping on that volume is yours.
Say it plainly: the manager cannot push a configuration back onto a device. There is no restore button, and nothing on the Backups page will rebuild a router for you. What you have is a verified, dated, diffable copy of the configuration and a download link.
Restoring is therefore a RouterOS operation you carry out yourself: put the .rsc on the device and let RouterOS run it.
import file-name=address.rscThe parameters worth knowing are verbose, which executes line by line and makes a failure findable, dry-run, which simulates the import without changing anything, and from-line, which resumes at a given line. The last two are available in verbose mode.
Full detail is the vendor's: Configuration Management — Configuration Import.
Three consequences worth planning around: