Manual

Recipe: a backup routine you actually keep up

Four files per site, one habit before every change, and a test you genuinely run.

Goal: at any moment you can get back to how it was yesterday, without having to remember anything you did not write down.

What you need

  • Access to the router over WinBox or SSH.
  • A folder per site on your own computer or server, not on the device itself.
  • A password manager for the backup password and the admin passwords.
  • Optionally an SMTP account for the weekly mail, on a line that is separate from the router you are protecting.

Step 1: two files off the device before every change

This is the whole routine, in two lines. Run them before you paste anything, every time:

/export file=before-2026-09-21 show-sensitive
/system backup save name=before-2026-09-21 password=...

Then download both off the device through the file list in WinBox. A file that lives only on the router is not a backup, because the router is the thing you are protecting against. The difference between the two files is in Backup and export; in short, the backup puts this device back exactly as it was, and the export is readable and portable.

An export taken with show-sensitive holds Wi-Fi passphrases and VPN keys in plain text. If you want to send one somewhere, take a second one with hide-sensitive and send that.

Step 2: keep what the configurator hands you

A generated configuration comes with four things. They belong together in the same folder:

  1. The script (.rsc), through Download .rsc.
  2. The rollback script (-rollback.rsc), through Rollback script. It removes what this script adds, found by its own name or comment, in reverse order.
  3. The settings file (.json), through Export settings, or Save site as file when you have several devices. That is how you reopen your own work in the tool later and change one thing, instead of filling everything in again.
  4. The handover sheet, through Handover sheet. That one is a print, not a download: you print it or save it as a PDF. Passwords are on it only if you tick Print passwords, and then the sheet belongs in a safe.

The .json file contains passwords and keys in plain text. The tool says so itself. Keep it with the customer records, not in a shared folder or a ticket.

Your work also lives in your browser, per project. That is convenient, but it is not a backup: it sits on that one computer, in that one profile, and it goes when you clear your browser data. See Saving and sharing.

Step 3: switch on the weekly backup on the router

In Services & tools:

  1. Turn on Weekly backup + export on the router.
  2. Fill in a backup password, at least 8 characters. The button next to it makes one of 16. Without a password the file is not encrypted at all.
  3. If you want them by mail, turn on Send e-mail and fill in the SMTP server, port (587), TLS (STARTTLS), user, password, sender and Recipient for backups.

What ends up in the script: one /system scheduler entry called weekly-backup that runs every 7 days at 03:30, does a /system backup save and an /export show-sensitive, and mails both files if you filled in a recipient.

Two things to know about that entry. The files get the same name every week, so only one generation stays on the device; the mail is what gives you history. And the tool has no field for uploading to FTP, SFTP or cloud storage. If you want that, write it as a custom script with an interval, in the same section.

Step 4: change with the difference, not with a new script

For a device already in service a full script is too blunt. Use Compare with the device: paste the output of /export from the running router and you get only the lines that bring it to your new configuration. The tool counts how much is added, changed, removed and unchanged, and tells you which tables are replaced whole because order matters in them, such as the firewall.

Testing: is that backup usable?

A backup you have never restored is an assumption. Do this once per site, and again at every major version jump:

  1. /file print on the router: are both files there, with last night's date and a plausible size?
  2. Open the .rsc in a text editor. Do you recognise your VLANs, your addresses and your firewall? An export that stopped halfway shows here, not later.
  3. Restore the backup onto a spare device of the same model, or an export onto a CHR. An /import file-name=... stops at the first error and leaves everything before it applied; run it with verbose=yes so you see where.
  4. Check that you still have the backup password. This is the step that fails in practice.

What to watch out for

  • The rollback script is not a backup. It only removes objects the script created itself. Lines that change an existing setting are listed as comments at the end of the file, under "not undone", because the old value was on the device and not in the script.
  • User passwords are never in an export. After restoring an export onto a fresh device you set them again. A binary backup does hold them.
  • A backup belongs to one device. Same model, preferably the same RouterOS version. For a different model the export is your way across, with the interface names adjusted.
  • Certificates and keys are missing from an export. A private key generated on the device and never exported is gone with the device.
  • Do not keep the password in the same folder. The backup file and its password together are one file.

Further reading: Backup and export, Saving and sharing and The handover sheet.

Want to try it right away? Open the configurator