Автоматичен backup на MikroTik рутер
Готов bash скрипт за автоматичен backup на MikroTik RouterOS: binary backup + .rsc export през SSH ключове, сваляне към 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 стъпки