GUIDE / BACKUP & RESTORE

Backup & restore.

RouterOS has two backup formats and you want both. The binary backup captures everything (including credentials, keys, certificates) but is bound to the same RouterOS major version. The text export is portable across versions but doesn't include sensitive material. Take both before every major change.

1. Binary backup (`/system backup`)

Captures the full state of the device — config + user passwords + SSH host keys + certificates. Only restorable on the same RouterOS major version (and ideally the same minor).

# create a backup file on the router
/system backup save name=mtkf-2026-05-06

# encrypted backup (recommended — backups contain credentials)
# encryption=aes-sha256 explicit because the default on older
# RouterOS was the weaker AES-CBC variant; aes-sha256 is the
# current best-of-both-worlds choice and accepted on every
# RouterOS version that supports the option at all.
/system backup save name=mtkf-2026-05-06 \
  password="<long-passphrase>" \
  encryption=aes-sha256

# list backups
/file print where type=backup

Always set a password on backups that leave the router. The unencrypted format is easily readable; an attacker who steals it can extract every credential the router knows. The explicit encryption=aes-sha256 ensures the strong cipher even on older RouterOS builds that default to the weaker CBC variant.

2. Text export (`/export`)

Dumps the configuration as RouterOS-script text — human-readable, version- portable, diffable. Doesn't include user passwords, SSH private keys, or certificates; you'd re-create those manually.

# print the full config to the terminal
/export

# write the full config to a file
/export file=mtkf-config-2026-05-06

# export only a section
/ip firewall export file=mtkf-firewall-2026-05-06

# include sensitive defaults (commented hashes etc.)
/export verbose file=mtkf-verbose-2026-05-06

The text export is what you store in version control and what you use to migrate from v6 → v7 — see Upgrades → v6 → v7 migration.

3. Off-router backup

A backup file that lives only on the router doesn't help when the router is the thing that died. The patterns below run a daily backup on the router (so a fresh file always exists) and then pull it off from a separate host on a schedule. Pull from outside rather than letting the router push — that way the router never holds credentials for your backup destination, and a compromised router can't reach back into your backup store.

On the router: take the backup daily

Use the RouterOS scheduler so a fresh file always exists for the pulling host to grab. The text export goes alongside since it survives version mismatches (see §2):

/system scheduler add name=daily-backup interval=1d start-time=02:00:00 \
  on-event=":do { \
    /system backup save name=mtkf-daily password=\"<passphrase>\"; \
    /export file=mtkf-daily; \
  } on-error={}"

From Linux / macOS: `scp` + cron / launchd

A two-line shell script + a cron entry on a backup box pulls both files off the router. Use SSH key auth (set up once via /user ssh-keys import on the router) so the backup host never embeds a router password.

#!/bin/sh
# /usr/local/bin/mtkf-pull-backup.sh — run from cron / launchd
# Replace ROUTER, BACKUP_DIR, USER for your environment.

set -eu
ROUTER="rb.example.lan"
BACKUP_DIR="/var/backups/mtkf"
USER="backup"
TS=$(date +%Y-%m-%d)

mkdir -p "$BACKUP_DIR/$TS"

# Pull both formats. ".backup" = binary; ".rsc" = text export.
scp -q -o StrictHostKeyChecking=accept-new \
  "$USER@$ROUTER:mtkf-daily.backup" \
  "$USER@$ROUTER:mtkf-daily.rsc" \
  "$BACKUP_DIR/$TS/"

# Prune backups older than 30 days. Adjust to match your rotation.
find "$BACKUP_DIR" -mindepth 1 -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +

Schedule it (Linux cron, every day at 03:00 — one hour after the router scheduler):

# /etc/cron.d/mtkf-backup
0 3 * * *  backup  /usr/local/bin/mtkf-pull-backup.sh >> /var/log/mtkf-backup.log 2>&1

On macOS the equivalent is a LaunchAgent — drop a plist into ~/Library/LaunchAgents/com.mtkf.backup.plist and launchctl load it once:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>com.mtkf.backup</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/mtkf-pull-backup.sh</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Hour</key><integer>3</integer>
    <key>Minute</key><integer>0</integer>
  </dict>
  <key>StandardOutPath</key><string>/var/log/mtkf-backup.log</string>
  <key>StandardErrorPath</key><string>/var/log/mtkf-backup.log</string>
</dict>
</plist>

From another MikroTik: `/tool fetch`

If you've got a second router (e.g. an offsite cold-spare or a small hAP at a sibling site), it can pull the backup over SSH/SFTP using /tool fetch on its own scheduler. Useful when you don't have a Linux/macOS box on the same network:

# Run on the BACKUP router (not the source). One-time setup:
# - generate an ED25519 keypair, install the public key on the source
#   router via /user ssh-keys import (same posture as the Linux script).
# - set SOURCE-IP and BACKUP-USER below.

/system scheduler add name=pull-from-source interval=1d start-time=03:00:00 \
  on-event=":do { \
    /tool fetch url=\"sftp://backup@SOURCE-IP/mtkf-daily.backup\" \
      dst-path=mtkf-source-daily.backup mode=sftp; \
    /tool fetch url=\"sftp://backup@SOURCE-IP/mtkf-daily.rsc\" \
      dst-path=mtkf-source-daily.rsc mode=sftp; \
  } on-error={}"

The destination router stores both files in its own /file tree. Pair with a third-party off-site sync (rclone via container, or another scp chain to a Linux box) so a single failure doesn't lose both copies.

Restoring

Two paths depending on which format you have:

# binary restore (same major version only)
/system backup load name=mtkf-2026-05-06 password="<passphrase>"

# text-export restore (portable across versions)
/import file-name=mtkf-config-2026-05-06.rsc

The binary restore replaces the running config wholesale and reboots. The text restore replays the script line-by-line; review the file first if it came from a different device — interface names and addresses won't match unless you edit them out.

Rotation

Suggested cadence:

Daily incremental binary backup, retained 7 days, off-router.
Weekly text export, retained 4 weeks, off-router and version-controlled if possible.
Manual binary + text both before any upgrade or migration.

Backup & restore.

1. Binary backup (/system backup)

2. Text export (/export)