DevOps Intermediate 12 min • 23.10.2026 г.

Автоматичен backup на MikroTik рутер

Готов bash скрипт за автоматичен backup на MikroTik RouterOS: binary backup + .rsc export през SSH ключове, сваляне към Linux сървър, ретенция и известия.

Автоматичен backup на MikroTik рутер към Linux сървър

Предварителни изисквания

  • MikroTik рутер с RouterOS v7
  • Linux машина (физическа, LXC или VM) с достъп до рутера
  • Базови познания по работа в терминал

Рутерът е устройството, което държи цялата ти мрежа — интернет, VPN, VLAN-и, firewall правила, пренасочвания на портове. Конфигурацията на един домашен или офис MikroTik се натрупва с месеци: тунели, настроени адресни списъци, изключения, скриптове в планировщика. И точно затова загубата му боли толкова много — защото никой не помни всички детайли, а дефолтната фабрична настройка нищо не прилича на реалната работеща мрежа.

В тази статия изграждаме пълноценна система за автоматичен backup, която прави следното: всеки ден се свързва през SSH с твоите MikroTik рутери, създава binary backup и текстов export, сваля ги на Linux сървър (LXC контейнер на Proxmox е идеален), пази ги за 30 дни и ти праща известие при проблем. Настройва се веднъж за 15 минути и след това работи само.


1. Двете лица на backup-а: .backup срещу .rsc

RouterOS предлага два различни формата за архивиране и те не са взаимозаменяеми. Разбирането на разликата е важно, защото всеки отговаря на различен сценарий на възстановяване.

Binary (.backup)Текстов (.rsc export)
СъдържаниеПълно състояние на систематаСамо конфигурацията като команди
ВъзстановяванеЕдна команда, всичко се връщаИмпорт команде по команда
ПортабилностСамо за същата/съвместима версия RouterOSРаботи на всеки рутер и версия
ЧетимостДвоичен файл — не се четеОбикновен текст — отваряш и преглеждаш
Типична употребаБързо възстановяване на същия хардуерМиграция към нов рутер, одит, diff

Затова скриптът прави и двата файла. Binary backup-ът е за сценария „рутерът умря — връщам го за 2 минути”, а .rsc файлът е за „купих нов модел — пренасям конфига” и за случаите, когато просто искаш да видиш как е бил настроен рутерът преди половин година.

Внимание: и двата формата съдържат чувствителни данни — пароли, VPN ключове, community strings. Директорията с бекъпите трябва да е достъпна само за root, а самият сървър да е защитен. В статията за SSH hardening е описано как.

2. Подготовка: SSH ключ вместо парола

Скриптът работи с SSH ключова автентикация — това е задължително условие за автоматизация, защото паролата в скрипт или в sshpass е лоша идея. RouterOS поддържа публични SSH ключи от години и настройката отнема две минути.

Първо генерираме ключ на Linux сървъра (ако нямаш такъв):

ssh-keygen -t ed25519 -f ~/.ssh/mikrotik_backup -C "mikrotik-backup" -N ""

Използваме отделен ключ специално за бекъпите — така при нужда можеш да го отнемеш от рутера, без да пипаш останалите си връзки. След това качваме публичния ключ на рутера. Най-лесно е през терминала на MikroTik:

/user ssh-keys import public-key-file=mikrotik_backup.pub user=admin

Файлът mikrotik_backup.pub първо качваш на рутера (чрез WinBox → Files, drag-and-drop, или чрез SFTP). За по-добра хигиена си струва да създадеш отделен потребител с политика read,ssh — бекъпът не се нуждае от права за писане на конфигурация:

/user add name=backup-user group=backup comment="Автоматичен backup"
/user ssh-keys import public-key-file=mikrotik_backup.pub user=backup-user

Сега тестът — от Linux машината не бива да се иска парола:

ssh -i ~/.ssh/mikrotik_backup -o BatchMode=yes admin@192.168.88.1 "/system identity print"

Ако видиш името на рутера — всичко е готово. Ако иска парола, провери дали си импортнал ключа за същия потребител, с който се свързваш.

3. Скриптът

Това е целият скрипт. Запиши го като /usr/local/bin/mikrotik-backup.sh на сървъра:

#!/usr/bin/env bash
# ============================================================
#  mikrotik-backup.sh — Автоматичен backup на MikroTik рутери
#  Статия: https://linuxdevops.dev/tutorials/mikrotik-backup-avtomatizacia/
# ============================================================

set -euo pipefail

# ============================ КОНФИГУРАЦИЯ ============================

# Формат: "име|хост|порт|потребител"
ROUTERS=(
  "main|192.168.88.1|22|admin"
  # "garage|192.168.88.2|22|admin"
  # "office|vpn.example.com|2222|backup-user"
)

BACKUP_DIR="/var/backups/mikrotik"  # къде се пазят локално
KEEP_DAYS=30                        # колко дни да се пазят стари директории
SSH_TIMEOUT=20                      # timeout за SSH връзката (сек)
NTFY_TOPIC=""                       # по избор: "https://ntfy.sh/таен-topic-тук"

LOG="$BACKUP_DIR/backup.log"
DATE="$(date +%F)"
LOCK="/tmp/mikrotik-backup.lock"

SSH_OPTS=(-o BatchMode=yes
          -o ConnectTimeout="$SSH_TIMEOUT"
          -o StrictHostKeyChecking=accept-new)

log() { printf '[%s] %s\n' "$(date '+%F %T')" "$*" | tee -a "$LOG"; }

notify() {
  if [ -n "$NTFY_TOPIC" ]; then
    curl -sS --max-time 10 -H "Title: MikroTik backup" -d "$1" "$NTFY_TOPIC" >/dev/null 2>&1 || true
  fi
}

# Забрана на паралелни изпълнения (cron + ръчно пуск)
mkdir -p "$BACKUP_DIR"
exec 9>"$LOCK"
if ! flock -n 9; then
  log "❌ Друг backup процес вече работи. Излизам."
  exit 1
fi

# backup_router <име> <хост> <порт> <потребител>
backup_router() {
  local name="$1" host="$2" port="$3" user="$4"
  local dest="$BACKUP_DIR/$name/$DATE"
  local bname="${name}-${DATE}"

  mkdir -p "$dest"
  log "→ $name ($host): започвам…"

  # 1. Binary backup на рутера
  if ! ssh "${SSH_OPTS[@]}" -p "$port" "$user@$host" \
        "/system backup save name=$bname dont-encrypt=yes" >>"$LOG" 2>&1; then
    log "❌ $name: не успях да създам binary backup"
    return 1
  fi

  # 2. Текстов export (RouterOS v7: show-sensitive; за v6 махни флага)
  if ! ssh "${SSH_OPTS[@]}" -p "$port" "$user@$host" \
        "/export show-sensitive file=$bname" >>"$LOG" 2>&1; then
    log "❌ $name: не успях да създам .rsc export"
    return 1
  fi

  # 3. Сваляне на двата файла през SFTP
  if ! scp -P "$port" "${SSH_OPTS[@]}" \
        "$user@$host:$bname.backup" "$user@$host:$bname.rsc" "$dest/" >>"$LOG" 2>&1; then
    log "❌ $name: не успях да сваля файловете"
    return 1
  fi

  # 4. Верификация — празен бекъп е по-лош от липсващ
  if [ ! -s "$dest/$bname.rsc" ] || [ ! -s "$dest/$bname.backup" ]; then
    log "❌ $name: някой от файловете е празен!"
    return 1
  fi

  # 5. Чисти временните файлове от рутера
  ssh "${SSH_OPTS[@]}" -p "$port" "$user@$host" \
      "/file remove [find name~\"$bname\"]" >>"$LOG" 2>&1 || true

  log "✅ $name: OK — $(du -h "$dest/$bname.backup" | cut -f1) backup, $(du -h "$dest/$bname.rsc" | cut -f1) rsc"
}

cleanup_old() {
  log "🧹 Изтривам бекъпи по-стари от $KEEP_DAYS дни…"
  find "$BACKUP_DIR" -mindepth 2 -maxdepth 2 -type d \
      -name "20*" -mtime "+$KEEP_DAYS" -exec rm -rf {} \; 2>>"$LOG" || true
}

log "🚀 MikroTik backup стартира за ${#ROUTERS[@]} рутер(а)"

OK=0; FAILED=0; FAILED_LIST=""
for entry in "${ROUTERS[@]}"; do
  IFS='|' read -r name host port user <<< "$entry"
  if backup_router "$name" "$host" "$port" "$user"; then
    OK=$((OK + 1))
  else
    FAILED=$((FAILED + 1))
    FAILED_LIST="$FAILED_LIST $name"
  fi
done

cleanup_old

log "🏁 Край: ✅ $OK успешни, ❌ $FAILED неуспешни"

if [ "$FAILED" -gt 0 ]; then
  notify "❌ MikroTik backup: $FAILED неуспешни рутера:$FAILED_LIST (✅ $OK успешни)"
  exit 1
fi

notify "✅ MikroTik backup: всички $OK рутера са архивирани успешно."
exit 0

Няколко конструктивни решения си струват обяснение. set -euo pipefail спира скрипта при първата сериозна грешка в логиката, но самите backup-и са в if конструкции — една недостъпна мрежа не спира архивирането на останалите рутери. flock пази срещу преплитане на два процеса, ако cron задействането съвпадне с ръчен пуск. Верификацията е най-важната част: бекъп, който е бил „успешно създаден”, но е празен файл, е по-опасен от липсващ — той ти внушава фалшиво чувство за сигурност. Затова проверяваме, че и двата файла физически съществуват и имат съдържание.

Флагът show-sensitive е RouterOS v7 синтаксис — той кара export-а да включи и паролите (в v6 всичко е било включено по подразбиране). Без него .rsc файлът е безполезен за възстановяване, защото липсват паролите на потребителите и wireless профилите.

4. Първо изпълнение и автоматизация с cron

Правим скрипта изпълним и го пускаме ръчно първия път:

chmod +x /usr/local/bin/mikrotik-backup.sh
/usr/local/bin/mikrotik-backup.sh

Очакван резултат в терминала:

[2026-10-23 03:00:01] 🚀 MikroTik backup стартира за 1 рутер(а)
[2026-10-23 03:00:01] → main (192.168.88.1): започвам…
[2026-10-23 03:00:04] ✅ main: OK — 108K backup, 24K rsc
[2026-10-23 03:00:04] 🧹 Изтривам бекъпи по-стари от 30 дни…
[2026-10-23 03:00:04] 🏁 Край: ✅ 1 успешни, ❌ 0 неуспешни

Провери и структурата на файловете:

find /var/backups/mikrotik -type f | sort
# /var/backups/mikrotik/main/2026-10-23/main-2026-10-23.backup
# /var/backups/mikrotik/main/2026-10-23/main-2026-10-23.rsc

Ако всичко изглежда добре — оставяме cron да се грижи. Пускаме crontab -e като root и добавяме:

# MikroTik backup — всеки ден в 03:00
0 3 * * * /usr/local/bin/mikrotik-backup.sh >/dev/null 2>&1

Изборът на 03:00 през нощта не е случаен: рутерът е свободен, връзката е стабилна, а дори backup-ът временно да натовари мрежата — никой няма да забележи. Ако искаш известия в телефона, регистрираш topic в ntfy.sh (безплатно, без акаунт), инсталираш приложението и попълваш NTFY_TOPIC в конфигурацията на скрипта. Повече за този подход — в статията за уведомяванията със скриптове.

5. Най-важната част: възстановяване

Backup, който никога не си възстановявал, не е backup — е надежда. Затова отделяме десет минути, за да тестваме обратния процес преди да ни се наложи.

Възстановяване от binary backup (същият рутер или съвместим модел):

/system backup load name=main-2026-10-23.backup

RouterOS ще попита за потвърждение и ще се рестартира. Внимавай: това заменя цялата текуща конфигурация с тази от архива.

Възстановяване от .rsc export (нов рутер или след reset):

/system reset-configuration no-defaults skip-backup=yes
/import file-name=main-2026-10-23.rsc

Практичен съвет: свали веднъж последния .rsc файл на лаптопа си и го прочети. Това е едновременно тест, че файлът е валиден, и най-добрата документация на собствената ти мрежа, която можеш да имаш — всяко правило, всеки тунел и всеки адресен списък е описан вътре.

6. Отстраняване на проблеми

Най-честите затруднения при първоначалната настройка и как се решават:

Permission denied при SSH връзка. Ключът не е импортнат за съответния потребител на рутера или ползваш грешния private key. Провери с ssh -i ~/.ssh/mikrotik_backup -v user@host — verbose изходът показва кой ключ се предлага.

scp спира с protocol грешка. Някои по-стари RouterOS версии имат ограничен SFTP сървър. Ако ползваш OpenSSH 9+ (който по подразбиране говори SFTP протокол през scp), добави флага -O, за да принудиш стария SCP протокол: scp -O -P 22 ....

/export show-sensitive дава syntax error. Имаш RouterOS v6 — там флагът не съществува, защото export винаги е включвал чувствителните данни. Просто махни show-sensitive от реда.

Бекъпът е създаден, но файла не се намира при scp. Файловете се появяват в главната директория на рутера. Провери с /file print дали наистина съществуват и съвпадат ли имената буква по буква.

Cron не прави нищо. Най-честата причина е липсващ път към ssh ключа — cron работи с минимална среда. Ползвай абсолютни пътища в скрипта (както е направено) и провери grep CRON /var/log/syslog.

7. Заключение

С тази настройка получаваш ежедневен, верифициран backup на всички MikroTik рутери, пазен с ретенция на отделен сървър, с известия при проблем и — което е най-важното — тествана процедура за възстановяване. Общото време за внедряване е около четвърт час, а икономисаната главаобръчена при повреда се измерва в часове, ако не и в дни.

Идеи за следваща стъпка: копирай получените директории към второ място (външен диск или отдалечен сървър) с rsync, за да имаш 3-2-1 защита, или добави проверка за промяна в конфигурацията, за да пазиш версиите само когато наистина са се променили.

Може да ви е интересно още: MikroTik рутер от терминала · Back to Home VPN с MikroTik · MikroTik RouterOS — чеклист за мониторинг · SSH hardening в 10 стъпки