You have a backup file and you want to go back to how it was. It does not work: the router refuses the file, or it reboots and comes back with a configuration that half fits, or you restore it onto a replacement device and half the ports do not exist there.
What it is not: a corrupted file is rare. Usually nothing is broken and RouterOS does exactly what it was told. The misunderstanding is about what the two file types are. A .backup is a binary imprint of this one device's configuration store, keys and interface names included, and it belongs to this architecture and this version. An .rsc is a text file full of commands that you can read, edit and run line by line.
The rule of thumb follows from that. Back to yesterday on the same device: the backup. To another model, another version or a cleaner start: the export. Taking a backup to another model is not something that sometimes fails, it is something that was never meant to work.
The quick checks, in order
- Is the file really there?
/file print. A good answer: the file is listed, with a size that is not zero and close to what you expected. A half-uploaded file gives an incomprehensible error when you load it. - Is there room?
/system resource printand look atfree-hdd-space. A good answer: more free than the file is big, with margin. See No space for an upgrade. - Is it the same architecture?
/system resource printon both devices, look atarchitecture-nameandboard-name. A good answer: identical on both. If they differ, the backup is the wrong route. - Which version?
/system package print. A good answer: the version the backup was made on, or newer. Restoring a 7.19 backup onto 7.13 is asking for trouble. - Does the password work?
/system backup load name=backup password=.... A good answer: the router announces a reboot. An encrypted backup without the right password goes nowhere, and that password is not stored on the router. - With an export: where does it stop?
/import file=config.rsc verbose=yes. A good answer: every line is shown and no error appears. If it stops halfway, you now know exactly at which line and why.
The usual causes, most common first
The backup password is missing
An encrypted backup without its password is a file with no use. There is no back door. Keep the password with the rest of the handover and not on the device itself.
Another model, other ports
A configuration that names ether1 to ether10 does not go onto a device with five ports. With a backup you get a device that does not come up the way it should; with an export, every line naming an interface that does not exist fails while the lines after it carry on. The result is a half-configured device, which is more annoying than an empty one.
The export was made without sensitive data
A plain /export leaves out passwords, wifi keys and VPN keys. Restoring it gives a configuration that looks complete and that nobody can log into. Use /export file=name show-sensitive when you want the file as a recovery path, and treat it as a password file afterwards.
The device is not empty
Importing an export over an existing configuration, or over the default one, gives duplicate rules, clashing addresses and firewall rules in the wrong order. Reset to empty first, with /system reset-configuration no-defaults=yes skip-backup=yes, and import after that.
What the configurator does about it
- The Import screen reads a text export, not a
.backup. Paste the output of/exportinto it, preferably withshow-sensitive, because otherwise the keys come back as empty fields. - The tool reads the
# model =line from the export header and looks that model up in the catalogue. When it cannot find it, it builds a stand-in device from the interface names it sees in the export. The port count is then a guess; check the port assignment before you use the new script. - The hard rule on import is that nothing is thrown away. What the tool understands becomes a field; what it does not understand lands in the Carried over from your configuration section and is re-emitted unchanged at the end of the script. The tool says so itself and asks you to check the ordering: a line referring to something created later in the script may need moving.
- This is also the clean route to another model. Import the old export, pick the new device, walk through the sections and have a fresh script generated. You then get port names that exist on the new device, instead of a backup that invents them.
- Services & tools has Weekly backup + export on the router. It makes both every week: an encrypted
.backupand an/export ... show-sensitive, and mails them if you configured e-mail. The backup password is required and goes into the script. - Next to every script there is a rollback script that removes what the script added. That is not a backup: lines that overwrite an existing value cannot be undone, because that old value lives on the device and not in the script. Those are listed separately. The real exact way back is the backup you make before pasting.
- What the tool does not do: it restores nothing and never touches your device. It produces text; the pasting and the restoring are yours.
Where the cause lies outside your router
- The transfer. A file uploaded over FTP in text mode is broken. Use WinBox or SFTP.
- The replacement device. An RMA unit sometimes arrives with an older RouterOS. Upgrade first, restore after.
- Netinstall. If a device will not come up after a failed attempt, netinstall is the way back. See Netinstall.
Read on: Backups, Importing an existing configuration and Using the script.