MikroTik умеет гораздо больше, чем маршрутизировать пакеты. RouterOS может сам сохранить конфигурацию, отправить её на сервер, сообщить о пропавшем сервисе и подать звуковой сигнал. Хорошая автоматизация экономит время администратора и оставляет понятный след: что произошло, когда и чем закончилось.
Мы собрали 18 практических рецептов для RouterOS 7. Идеи взяты из задач, которые обсуждают на форуме MikroTik и в r/mikrotik; примеры написаны для этой статьи по официальной документации. Для каждого рецепта указаны условия применения, команды и способ проверки.
Если нужен справочник команд для оборудования разных производителей, начните с нашей статьи «CLI-команды для коммутаторов».
Перед началом: как пользоваться примерами
Примеры предназначены для RouterOS 7; они не выполнялись на вашем маршрутизаторе. В старых выпусках 7.x отдельные функции могут отсутствовать. В частности, перед использованием JSON проверьте наличие команды :serialize, а перед настройкой логирования — доступные параметры действия.
Все адреса из диапазонов 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24 — адреса для документации. Замените их адресами своей инфраструктуры. Значения CHANGE-ME, имена серверов, каталоги и часовой пояс тоже нужно адаптировать.
В статье используются два вида примеров:
- Тело скрипта — вставляется в System → Scripts → Source. Имя и права указаны рядом с примером.
- Настройка — выполняется в терминале один раз. Команды
addне предназначены для многократного импорта: повторный запуск создаёт дубликаты.
В терминале вставляйте блоки с локальными переменными целиком, вместе с внешними фигурными скобками. Не разносите :local и обращение к переменной по независимым вводам.
Перед изменением правил доступа включите Safe Mode и сохраните рабочую конфигурацию. Для HTTPS нужны корректные часы и доверенная цепочка сертификатов. Пароли и токены храните как секреты: они остаются в исходнике скрипта, даже если не выводятся в журнал.
1. Две копии конфигурации: export и зашифрованный backup
Задача: иметь и читаемый текст настроек, и бинарную копию для восстановления.
Export удобен для сравнения изменений и переноса отдельных настроек. Бинарный backup содержит больше данных устройства. Эти форматы дополняют друг друга; текстовый export не заменяет полноценную копию.
Тело скрипта: имя avg-backup, политики read,write,test,sensitive.
{
:local secret "CHANGE-ME";
:if ($secret = "CHANGE-ME") do={
:error "Set a unique backup password first";
};
:local prefix "";
:if ([:len [/file find where name="flash"]] > 0) do={
:set prefix "flash/";
};
:local base ($prefix . "avg-latest");
/export file=$base;
/system backup save name=$base password=$secret encryption=aes-sha256;
:delay 2s;
:foreach ext in={".rsc";".backup"} do={
:local id [/file find where name=($base . $ext)];
:if ([:len $id] = 0) do={ :error "Backup file missing"; };
:if ([/file get $id size] = 0) do={ :error "Backup file empty"; };
};
:log info "AVG backup: export and encrypted backup created";
}Скрипт хранит одну свежую пару файлов. Если устройство имеет каталог flash, использует его; путь на USB или другой диск задавайте отдельно. Историю версий лучше вести на сервере, а не на небольшой флеш-памяти роутера.
Проверка: в Files появились два непустых файла; затем скачайте копии и проверьте восстановление на подходящем тестовом устройстве. Backup восстанавливайте с учётом модели и версии RouterOS. Не включайте show-sensitive для export без необходимости; даже обычный export проверяйте на секреты, записанные в исходниках пользовательских скриптов.
Источник: Backup, управление конфигурацией.
2. Отправка копий на SFTP-сервер
Задача: сохранить файлы вне устройства. Копия на самом роутере не поможет, если он потерян или повреждён.
Сначала выполните рецепт № 1. Создайте на сервере отдельную учётную запись и каталог. Пример предполагает, что сервер принимает SFTP и каталог доступен для записи.
Тело скрипта: имя avg-send-sftp, политики read,write,test,sensitive.
{
:local server "198.51.100.20";
:local login "router-backup";
:local secret "CHANGE-ME";
:if ($secret = "CHANGE-ME") do={ :error "Set SFTP password"; };
:local prefix "";
:if ([:len [/file find where name="flash"]] > 0) do={
:set prefix "flash/";
};
:foreach ext in={".rsc";".backup"} do={
:local src ($prefix . "avg-latest" . $ext);
:local id [/file find where name=$src];
:if ([:len $id] = 0) do={ :error "Create local backup first"; };
:if ([/file get $id size] = 0) do={ :error "Empty source file"; };
/tool fetch url=("sftp://" . $server) user=$login password=$secret \
src-path=$src dst-path=("/backups/site01/router01/latest" . $ext) \
upload=yes keep-result=no;
};
:log info "AVG backup: both files uploaded via SFTP";
}Замените каталог назначения на путь, который видит SFTP-пользователь: внутри chroot он может отличаться от пути на сервере. Пример перезаписывает latest; снимки и хранение 30–90 версий организуйте на сервере.
SFTP шифрует передачу. Параметр Fetch check-certificate относится к HTTPS и не является проверкой SSH-ключа SFTP-сервера. Для сценария с явно закреплённым SSH-ключом используйте получение копии внешним сервером из рецепта № 17.
Проверка: на сервере присутствуют оба непустых файла и их содержимое соответствует свежей локальной копии. Успех передачи не равен проверке восстановления.
Источник: Fetch.
3. Сохранение конфигурации в FTP-папку
Задача: интеграция со старым NAS или сервером, на котором доступен только FTP.
FTP передаёт пароль и данные без шифрования. Этот вариант используйте внутри доверенной сети или защищённого туннеля. Для передачи через интернет выбирайте другой транспорт.
Тело скрипта: имя avg-send-ftp, политики read,write,test,sensitive. Перед запуском создайте свежие файлы рецептом № 1.
{
:local secret "CHANGE-ME";
:if ($secret = "CHANGE-ME") do={ :error "Set FTP password"; };
:local prefix "";
:if ([:len [/file find where name="flash"]] > 0) do={
:set prefix "flash/";
};
:foreach ext in={".rsc";".backup"} do={
:local src ($prefix . "avg-latest" . $ext);
:local id [/file find where name=$src];
:if ([:len $id] = 0) do={ :error "Source file missing"; };
/tool fetch mode=ftp address=192.0.2.20 user="router-backup" \
password=$secret src-path=$src \
dst-path=("site01/router01/latest" . $ext) upload=yes;
};
:log info "AVG backup: FTP upload completed";
}На FTP-сервере заранее создайте папку site01/router01 и ограничьте права пользователя этим каталогом. Копии разных роутеров должны попадать в разные каталоги.
Проверка: два файла появились на FTP, скачиваются и не имеют нулевой длины. Настройте историю на стороне NAS: два файла latest сами по себе не дают глубины хранения.
Источник: примеры Fetch. Идея обсуждается в теме форума о резервировании на FTP; приведённый выше код подготовлен заново.
4. Ежедневный backup по расписанию
Задача: сначала создать копию, затем отправить её и записать результат.
Создайте скрипты avg-backup и avg-send-sftp из предыдущих рецептов. Затем добавьте управляющий скрипт avg-backup-job с политиками read,write,test,sensitive.
{
:do {
/system script run avg-backup;
/system script run avg-send-sftp;
:log info "AVG backup job: completed";
} on-error={
:log error "AVG backup job: failed; check files and server";
:error "Backup job failed";
};
}Настройка: ежедневный запуск в 03:15 по часам маршрутизатора.
/system scheduler add name=avg-backup-daily start-time=03:15:00 \
interval=1d on-event="/system script run avg-backup-job" \
policy=read,write,test,sensitive disabled=yesРасписание создаётся выключенным. Сначала вручную запустите avg-backup-job, проверьте файлы на сервере, затем включите расписание:
/system scheduler enable [find where name="avg-backup-daily"]Скрипты и расписание создавайте от выделенного администратора с необходимыми правами. У Scheduler должны быть права на запускаемые скрипты. Добавьте к длинной задаче защиту от параллельного запуска из рецепта № 18.
Проверка: следующий запуск завершился без ошибок; файлы действительно обновились на сервере. Контроль свежести со стороны сервера полезнее одного счётчика run-count.
Источник: Scheduler.
5. Проверка новой версии без внезапной перезагрузки
Задача: узнать о доступном обновлении, сохранив контроль над временем установки.
Тело скрипта: имя avg-update-check, политики read,write,test.
{
/system package update check-for-updates once;
:delay 3s;
:delay 3s;
:local status [/system package update get status];
:local current [/system package update get installed-version];
:local latest [/system package update get latest-version];
:if ($status = "New version is available") do={
:log warning ("AVG update: installed=" . $current . "; available=" . $latest);
} else={
:log info ("AVG update check: " . $status);
};
}Скрипт использует выбранный на устройстве канал. Посмотрите его командой /system package update print: менять канал автоматически здесь не нужно. Запускайте проверку раз в день через Scheduler или вручную.
Проверка: в журнале виден результат проверки, включая сетевую ошибку, если сервер обновлений недоступен. Сравнивать версии как строки нельзя: например, 7.9 и 7.10 не упорядочиваются обычным текстовым сравнением так, как ожидает администратор.
Источник: обновление RouterOS.
6. Автообновление только до одобренной версии
Задача: обновить роутер в окно обслуживания, но не устанавливать любой новый релиз без проверки.
Тело скрипта: имя avg-update-approved, политики read,write,test,reboot,sensitive. Нужен работающий avg-backup-job.
{
:local approved "CHANGE-ME";
:if ($approved = "CHANGE-ME") do={ :error "Set approved RouterOS version"; };
/system package update check-for-updates once;
:delay 3s;
:delay 3s;
:local latest [/system package update get latest-version];
:local status [/system package update get status];
:if (($status != "New version is available") || ($latest != $approved)) do={
:log warning ("AVG update skipped: available=" . $latest . "; status=" . $status);
:return;
};
/system script run avg-backup-job;
:log warning ("AVG update: installing approved version " . $approved);
/system package update install;
}Команда install скачивает обновление и инициирует перезагрузку. До включения расписания проверьте свободное место, changelog, совместимость пакетов и наличие доступа для восстановления. Значение approved задавайте после проверки нужного релиза на тестовом устройстве.
Проверка latest не выбирает произвольную архивную версию: если канал уже предлагает более новую, скрипт пропустит установку. Не запускайте этот рецепт для «проверки» на рабочем роутере: ручной запуск тоже может установить обновление.
Пример выключенного расписания для окна в 03:45:
/system scheduler add name=avg-update-window start-time=03:45:00 \
interval=1d on-event="/system script run avg-update-approved" \
policy=read,write,test,reboot,sensitive disabled=yesВключайте его только для согласованного окна. После выполнения выключите расписание или оставьте явно управляемым правилом обслуживания.
На физических RouterBOARD отдельно сравните current-firmware и upgrade-firmware в /system routerboard print. Если нужно обновить RouterBOOT, выполните /system routerboard upgrade, подтвердите операцию и запланируйте следующую перезагрузку. Для CHR этот шаг не применяется.
Проверка: после возврата устройства доступны нужные интерфейсы, маршруты, VPN и сервисы; установленная версия соответствует approved. Версия в меню — лишь часть проверки.
Источник: обновление RouterOS, RouterBOOT.
7. Port knocking для временного доступа к SSH и WinBox
Задача: открывать управление с определённого IPv4-адреса после трёх последовательных TCP-обращений.
В примере используются порты 40011 → 40022 → 40033. Первые два этапа действуют по 30 секунд; итоговое разрешение — 15 минут.
Настройка: правила отдельной цепочки. Включайте только после проверки существующего firewall.
/ip firewall filter
add chain=avg-knock protocol=tcp dst-port=40011 \
action=add-src-to-address-list address-list=avg-knock1 \
address-list-timeout=30s comment="AVG: knock 1"
add chain=avg-knock protocol=tcp dst-port=40022 src-address-list=avg-knock1 \
action=add-src-to-address-list address-list=avg-knock2 \
address-list-timeout=30s comment="AVG: knock 2"
add chain=avg-knock protocol=tcp dst-port=40033 src-address-list=avg-knock2 \
action=add-src-to-address-list address-list=avg-mgmt \
address-list-timeout=15m comment="AVG: knock 3"
add chain=avg-knock protocol=tcp dst-port=22,8291 src-address-list=avg-mgmt \
action=accept comment="AVG: temporary SSH and WinBox"
add chain=avg-knock action=return comment="AVG: return to input"
add chain=input in-interface-list=WAN protocol=tcp connection-state=new \
action=jump jump-target=avg-knock disabled=yes comment="AVG: knock entry"Здесь предполагается существующий список интерфейсов WAN и правило, запрещающее остальной входящий доступ с WAN. Переместите выключенное правило AVG: knock entry перед соответствующим запретом, проверьте порядок, затем включите. Уберите прежние безусловные разрешения SSH/WinBox с интернета, если они делали бы knocking бессмысленным. Ограничения /ip service также должны разрешать ожидаемый источник.
Клиент должен отправить попытки TCP-подключения на три порта в нужном порядке с одного внешнего адреса. Успешного TCP-соединения на knock-портах не будет: важны поступившие пакеты.
Проверка: до последовательности новые соединения на 22/8291 запрещены, после — разрешены только с адреса в avg-mgmt. Не забудьте проверить истечение времени. Уже установленные соединения могут оставаться разрешёнными правилом established.
Это дополнение к защите управления, а не замена VPN и аутентификации. Пример относится к IPv4; IPv6 настраивается отдельно. За одним NAT адресом итоговое разрешение может разделяться несколькими клиентами.
Источник: Port knocking.
8. Telegram-уведомление через HTTPS и JSON
Задача: отправить администратору короткое сообщение без ручного кодирования пробелов и спецсимволов в URL.
Создайте бота, определите chat_id и отправьте боту сообщение, чтобы он мог отвечать. Нужны DNS, выход на api.telegram.org, корректное время и доверенные сертификаты.
Тело скрипта: имя avg-telegram-test, политики read,test. Для запуска из другого механизма проверьте его контекст и права.
{
:local token "CHANGE-ME";
:local chatId "CHANGE-ME";
:if (($token = "CHANGE-ME") || ($chatId = "CHANGE-ME")) do={
:error "Set Telegram bot token and chat ID";
};
:local message ("Router " . [/system identity get name] . ": notification test");
:local body [:serialize to=json \
value={"chat_id"=$chatId;"text"=$message} options=json.no-string-conversion];
:do {
:local reply [/tool fetch \
url=("https://api.telegram.org/bot" . $token . "/sendMessage") \
http-method=post http-header-field="Content-Type: application/json" \
http-data=$body check-certificate=yes output=user as-value];
:local result [:deserialize from=json value=($reply->"data")];
:if (($result->"ok") != true) do={ :error "Telegram API rejected request"; };
:log info "AVG Telegram: notification sent";
} on-error={
:log warning "AVG Telegram: notification failed";
};
}JSON-сериализация защищает структуру сообщения от кавычек и переводов строки. Поле ok дополнительно проверяет ответ API. Не выводите URL с токеном в лог и не отправляйте сырые конфигурации в чат.
Проверка: сообщение пришло в нужный чат. Затем используйте такой блок в нужном событии, меняя только message. Сначала проверьте, что версия RouterOS поддерживает обе JSON-команды.
Источник: Scripting, Telegram Bot API: sendMessage.
9. Netwatch: журнал исчезновения и возврата узла
Задача: фиксировать переходы доступности, а не засорять журнал сообщением каждую минуту.
Замените 192.0.2.10 на контролируемый сервер или адрес провайдера, который должен отвечать на ICMP.
Настройка:
/tool netwatch add host=192.0.2.10 type=simple interval=30s timeout=2s \
down-script={:log warning "AVG Netwatch: target DOWN";} \
up-script={:log info "AVG Netwatch: target UP";} \
comment="AVG: controlled target" disabled=yesВключите запись после проверки адреса. При изменении состояния выполняется соответствующий обработчик; начальное поведение после запуска тоже нужно проверить.
Важный нюанс: Netwatch запускает скрипты в контексте *sys. Его глобальные переменные не следует использовать как общий канал обмена с Scheduler. Доступные политики ограничены read,write,test,reboot; вызываемый скрипт также должен укладываться в разрешённый набор. Не обходите это через отключение проверки прав.
Для проверки приложения используйте поддерживаемый вашей версией type=tcp-conn и порт сервиса, например 443. Ответ ICMP доказывает доступность узла, но не работоспособность HTTPS. Недоступность одного адреса не доказывает отказ всего интернета.
Проверка: временно остановите тестовый сервис или изолируйте тестовый узел; получите DOWN и затем UP. Не отключайте рабочий WAN ради первой проверки.
Источник: Netwatch.
10. Короткая мелодия по событию
Задача: дать локальный звуковой сигнал, когда администратор находится рядом с оборудованием.
На устройствах с поддерживаемым зуммером можно выполнить короткую последовательность нот. CHR и модели без зуммера звук не воспроизведут.
Тело скрипта: имя avg-sound-down, политики read,test.
{
:beep frequency=880 length=120ms;
:delay 180ms;
:beep frequency=660 length=120ms;
:delay 180ms;
:beep frequency=440 length=250ms;
}Для возврата сервиса используйте обратную последовательность 440 → 660 → 880. Сигнал конечный: он не создаёт бесконечный цикл.
Чтобы связать звук с Netwatch, добавьте вызов /system script run avg-sound-down к существующему down-script. Предварительно сохраните его содержимое: не заменяйте уже работающий обработчик целиком.
Проверка: ручной запуск воспроизводит три ноты и завершается. После этого проверьте один переход DOWN на тестовом объекте. Для удалённого администратора основной канал — уведомления, а не звук.
Идея встречается в обсуждении Netwatch и beep на Reddit и теме форума о звуковом цикле. Команда beep также рассматривается в материалах MikroTik MUM.
11. Отправка warning, error и critical на syslog
Задача: сохранить события вне роутера и искать их вместе с журналами остальной инфраструктуры.
Пример использует UDP syslog в закрытой сети или VPN. На сервере разрешите приём от адреса маршрутизатора.
Настройка: сначала добавьте удалённое действие.
/system logging action add name=avgSyslog target=remote \
remote=192.0.2.30 remote-port=514В свойствах действия выберите формат syslog. В выпусках с параметром remote-log-format:
/system logging action set [find where name="avgSyslog"] remote-log-format=syslogВ более ранних выпусках с параметром bsd-syslog используйте вместо предыдущей команды:
/system logging action set [find where name="avgSyslog"] bsd-syslog=yesНе выполняйте обе команды вслепую: доступный параметр виден в подсказке терминала и свойствах действия вашей версии.
/system logging add topics=warning action=avgSyslog
/system logging add topics=error action=avgSyslog
/system logging add topics=critical action=avgSyslog
:log warning "AVG syslog test";Темы в одном правиле через запятую задают сочетание условий. Поэтому warning и error здесь отправляются разными правилами. Существующее логирование в память оставьте для локальной диагностики.
Проверка: тестовое сообщение появилось на коллекторе с правильным источником и временем. UDP не гарантирует доставку. Для гарантированного централизованного хранения выбирайте транспорт и коллектор с учётом возможностей конкретной версии; не переносите этот UDP-рецепт в открытый интернет.
Источник: действия логирования.
12. Кольцевой журнал на диске и разовый снимок логов
Задача: сохранить важные события после перезагрузки, ограничив объём хранения.
Частые записи нагружают внутреннюю flash. Для длительного хранения предпочтительнее внешний носитель или удалённый сервер.
Настройка: пример для устройства с каталогом flash. На другом устройстве замените disk-file-name на реальный путь.
/system logging action add name=avgDisk target=disk \
disk-file-name=flash/avg-events disk-lines-per-file=1000 disk-file-count=3
/system logging add topics=warning action=avgDisk
/system logging add topics=error action=avgDiskДля разовой диагностики сделайте снимок текущего журнала, не включив постоянное подробное логирование:
/log print file=avg-log-snapshotСкачайте созданный файл и уберите его после расследования. Снимок содержит только доступные в текущем журнале записи; он не восстанавливает события, которые уже исчезли.
Проверка: записанное тестовое warning есть в файле журнала. Проверьте поведение при ротации и после перезагрузки. Не включайте постоянный debug на внутреннюю память без оценки нагрузки.
Источник: Log, действия логирования.
13. CPU и память: сигнал с гистерезисом
Задача: сообщать о перегрузке один раз при входе в проблемное состояние и один раз после восстановления.
Тело скрипта: имя avg-health, политики read,test. Запускайте раз в минуту от одного владельца через Scheduler.
{
:global avgHealthAlarm;
:if ([:typeof $avgHealthAlarm] = "nothing") do={ :set avgHealthAlarm false; };
:local cpu [/system resource get cpu-load];
:local total [/system resource get total-memory];
:local free [/system resource get free-memory];
:local freePct (($free * 100) / $total);
:if (($cpu >= 90) || ($freePct <= 10)) do={
:if ($avgHealthAlarm != true) do={
:set avgHealthAlarm true;
:log warning ("AVG health: CPU=" . $cpu . "%; free RAM=" . $freePct . "%");
};
};
:if (($cpu <= 70) && ($freePct >= 20)) do={
:if ($avgHealthAlarm = true) do={
:set avgHealthAlarm false;
:log info "AVG health: recovered";
};
};
}Пороги входа и выхода различаются: это уменьшает колебания сообщения вокруг одного значения. Пример реагирует на одну выборку; для устойчивой нагрузки добавьте требование нескольких последовательных превышений или используйте мониторинг с временным окном.
Глобальное состояние не сохраняется после перезагрузки и относится к контексту владельца. Не переносите эту переменную в Netwatch как общий флаг.
Проверка: для теста временно измените пороги, получите один alarm и один recovered, затем верните рабочие значения. Не создавайте нагрузку на боевой маршрутизатор специально.
Источник: Scripting, System Resource.
14. DHCP: кто получил и кто освободил адрес
Задача: связать время события, DHCP-сервер, IP и MAC при расследовании проблем клиента.
Это тело обработчика Lease Script, а не обычный скрипт Scheduler. Переменные создаются механизмом DHCP.
{
:if ($leaseBound = "1") do={
:log info ("AVG DHCP bound: server=" . $leaseServerName . \
"; ip=" . $leaseActIP . "; mac=" . $leaseActMAC);
} else={
:log info ("AVG DHCP released: server=" . $leaseServerName . \
"; ip=" . $leaseActIP . "; mac=" . $leaseActMAC);
};
}Откройте нужный DHCP Server → Lease Script. Если там уже есть обработчик, сохраните его и объедините действия, а не заменяйте чужую автоматизацию. Не запускайте этот блок из терминала в ожидании, что leaseActIP будет заполнен.
Для большой сети направляйте нужные события на syslog и задайте срок хранения. Повторные события DHCP нормальны; каждую аренду не стоит превращать в тревогу Telegram.
Проверка: переподключите тестового клиента или обновите его аренду и найдите запись с нужным MAC. DHCP-журнал не является полным учётом всех устройств сети: статически настроенные клиенты могут в него не попасть.
Источник: DHCP: Lease Script.
15. IP Cloud DDNS при меняющемся внешнем адресе
Задача: обращаться к роутеру по имени, когда провайдер меняет внешний IP.
Настройка:
/ip cloud set ddns-enabled=yes update-time=no
/ip cloud printПолученное dns-name используйте для разрешённого VPN-доступа или мониторинга. Здесь update-time выключен: синхронизацию часов отдельно настроим через NTP.
DDNS не пробивает CGNAT и не создаёт правила firewall. Если у провайдера нет входящей маршрутизации до вашего роутера, одного DNS-имени недостаточно. Сервис IP Cloud также означает обмен данными с инфраструктурой MikroTik.
Проверка: DNS-имя разрешается во внешний адрес, а нужный VPN действительно доступен с внешней сети. Проверка из той же локальной сети может дать другой результат.
Источник: IP Cloud.
16. Правильное время: NTP для расписания, TLS и логов
Задача: чтобы 03:15 в Scheduler было действительно нужным временем, а события разных устройств можно было сопоставить.
Настройка: пример для Новосибирска и внутреннего NTP-сервера. Замените пояс и адрес под свою инфраструктуру.
/system clock set time-zone-autodetect=no time-zone-name=Asia/Novosibirsk
/system ntp client set enabled=yes mode=unicast
/system ntp client servers add address=192.0.2.123
/system ntp client print
/system clock printДобавьте второй независимый источник времени, если он есть. До команды add проверьте существующий список серверов, чтобы не создавать дубликаты.
Проверка: клиент синхронизирован, время и часовой пояс верны. Доступность сервера по ping сама по себе не подтверждает синхронизацию NTP. Настройте время до проверки HTTPS-уведомлений и расписаний.
Источник: NTP.
17. Сервер сам забирает export по SSH и сравнивает изменения
Задача: вынести расписание и историю конфигурации на сервер резервного копирования.
Так роутеру не нужно хранить пароль от файлового сервера. Используйте отдельную учётную запись RouterOS с минимальными правами для SSH и export. Доступ к SSH ограничьте адресом сервера резервирования или VPN.
Пример для Linux-сервера, где заранее настроены ключ, каталог и проверенный known_hosts:
#!/usr/bin/env bash
set -euo pipefail
umask 077
backup_dir="/srv/router-backups/site01/router01"
mkdir -p "$backup_dir"
stamp="$(date -u +%Y%m%dT%H%M%SZ)"
tmp="$(mktemp "$backup_dir/.export.XXXXXX")"
trap 'rm -f -- "$tmp"' EXIT
if ! ssh -o BatchMode=yes -o StrictHostKeyChecking=yes \
-o ConnectTimeout=15 backup@192.0.2.1 '/export terse' > "$tmp"; then
echo "Export failed" >&2
exit 1
fi
if ! test -s "$tmp"; then
echo "Empty export" >&2
exit 1
fi
if ! grep -q '^#.*RouterOS' "$tmp"; then
echo "Unexpected export output" >&2
exit 1
fi
mv -- "$tmp" "$backup_dir/$stamp.rsc"
trap - EXIT
echo "Saved: $backup_dir/$stamp.rsc"До первого запуска сверяйте fingerprint SSH-ключа устройства по доверенному каналу. Не заменяйте проверку ключа значением StrictHostKeyChecking=no.
В cron или systemd timer задайте период запуска, а на сервере — хранение, контроль свежести и доступ к каталогу. Для сравнения версий используйте diff; если храните export в Git, репозиторий должен быть закрытым. Проверьте исходники скриптов в export: там могут оказаться самостоятельно записанные токены.
Этот рецепт сохраняет текстовый export. Для бинарного зашифрованного backup используйте отдельный процесс создания и получения файла.
Проверка: остановка SSH приводит к ошибке и не создаёт «успешную» копию. Успешный файл открывается, содержит ожидаемые разделы конфигурации, а отличия между версиями объяснимы.
Источник: export конфигурации. Подход к централизованному резервированию обсуждается и в r/mikrotik.
18. Защита долгого скрипта от повторного запуска
Задача: не допустить, чтобы новое срабатывание Scheduler стартовало вторую копию ещё работающего задания.
Добавьте проверку в начало именованного скрипта в System → Scripts:
:if ([/system script job print count-only where script=[:jobname]] > 1) do={
:error "Another instance of this script is already running";
};Далее оставьте основное тело, например avg-backup-job. Проверка рассчитана на запуск сохранённого скрипта: это не самостоятельная команда для терминала. Проверьте поддержку jobname вашей версией RouterOS.
Это практичный ограничитель для обычного расписания, а не универсальная атомарная блокировка: почти одновременные старты могут конкурировать. Если задача критична, сериализуйте запуск на внешнем сервере.
Вместо бесконечного ожидания пишите конечные задачи, ограничивайте тайм-ауты сетевых операций и фиксируйте ошибки. Для рутинной проверки не останавливайте все задания командой с широким find.
Проверка: на тестовом скрипте с короткой задержкой запустите второй экземпляр; он завершился с понятной ошибкой, а первый продолжил работу.
Источник: Scripting: single instance.
С чего начать на своём MikroTik
Начните с часов, двух локальных копий и выгрузки на сервер. Затем подключите удалённые логи и уведомления, а после — мониторинг событий. Автообновление и изменение доступа включайте после проверки на конкретном устройстве.
У каждого задания должны быть понятные входные данные, необходимые права, проверяемый результат и способ отключения. Хороший backup подтверждается восстановлением; хорошее уведомление — сообщением в нужном канале; хорошее обновление — работающей сетью после перезагрузки.
Откуда взяты идеи и что проверено
Мы изучили официальную документацию RouterOS, обсуждения автоматизации в r/mikrotik, поиска общего репозитория скриптов и резервирования и обновлений на форуме. Старые форумные примеры не переносились в статью без адаптации.
Команды и ограничения сверены с документацией на 8 октября 2026 года. Практический запуск на физических MikroTik и CHR в рамках подготовки статьи не выполнялся. Проверка на своей версии RouterOS и в своём контексте запуска остаётся обязательным этапом внедрения.
Нужна помощь с резервированием, мониторингом или обслуживанием сети? Свяжитесь с АВАНГАРД ИТ — разберём вашу инфраструктуру и подготовим подходящую схему.