Резервное копирование на MikroTik
Актуальное руководство по резервному копированию на MikroTik RouterOS 7.22.1 Stable (апрель 2026 г.): backup, export, SSH-ключи, БД The Dude и User Manager, контейнеры и многое другое.
Основные способы резервного копирования устройств MikroTik
Основными способами резервного копирования на устройствах MikroTik являются способы backup и export. Каждый из этих способов имеет свои преимущества и недостатки, но ни один из этих двух способов не может копировать: содержимое файлового хранилища, а также элементы, которые хранятся в файловом хранилище (базы данных The Dude и User Manager, пользовательские интерфейсы и контейнеры). В связи с этим резервное копирование этих элементов должно выполняться отдельно.
Резервная копия backup рассчитана на полное восстановление на том же самом устройстве MikroTik на котором она изначально была создана и не рассчитана на восстановление на другом, даже точно таком же устройстве. При восстановлении на другом устройстве возможны проблемы, которые в том числе могут проявить себя не сразу, а через какое-то время из-за чего будет сложно связать имеющуюся проблему с выполненным ранее восстановлением из резервной копии. Резервная копия backup содержит информацию, являющуюся индивидуальной для каждого отдельного устройства. Например, это информация о MAC-адресах интерфейсов.
Создание резервной копии export, является дополнительной возможностью команды export, которая изначально рассчитана на то, чтобы предоставить конфигурацию устройства MikroTik в текстовом виде для ее дальнейшего анализа. Предоставление конфигурации возможно как с помощью направления вывода результата выполнения команды в терминал командной строки, так и с помощью вывода в текстовый файл, что и используется для создания резервной копии export. Если резервную копию export создать при нахождении в корневом разделе командной строки, то будет создана резервная копия содержащая конфигурацию всех разделов конфигурации кроме раздела /user, а если такая резервная копия будет создана из одного из вложенных разделов конфигурации, то она будет содержать данные о конфигурации, находящейся в этом разделе и во всех подчиненных разделах. В т.ч. можно зайти в раздел /user и отдельно сделать резервную копию этого раздела, но пароли пользователей устройства MikroTik все-равно не получится отобразить и сохранить. Резервную копию export можно открыть текстовым редактором, изучить ее содержимое и при необходимости отредактировать. Поэтому такая резервная копия подходит для переноса конфигурации на устройство MikroTik, отличное от того на котором копия изначально была сделана. В том числе ее можно использовать для восстановления на устройстве, которое имеет принципиально разные аппаратные конфигурации: разное количество свитч-чипов, несовпадение количества беспроводных модулей и др.
| Специфика | Способ копирования | |
|---|---|---|
| Backup | Export | |
| Тип копии | Бинарная | Текстовая |
| Расширение копии | .backup | .rsc |
| Использование через GUI | Да | Нет |
| Использование через CLI | Да | Да |
| Восстановление резервной копии на том же самом устройстве MikroTik | Да | Да |
| Восстановление резервной копии на другом устройстве MikroTik | Нет | Да |
| Копирование всех настроек1 | Да | Нет |
| Выборочное копирование настроек | Нет | Да |
| Копирование в локальное файловое хранилище устройства MikroTik | Да | Да |
| Копирование в облачное хранилище, предоставляемое компанией MikroTik | Да | Нет |
| Редактирование резервной копии | Нет | Да |
| Копирование учетных записей пользователей устройства MikroTik | Да | Да2 |
| Копирование паролей учетных записей пользователей устройства MikroTik | Да | Нет |
| Копирование SSH-ключей | Да | Нет |
| Копирование сертификатов | Да | Нет |
| Копирование файлового хранилища | Нет | Нет |
| Копирование базы данных The Dude3 | Нет | Нет |
| Копирование базы данных User Manager3 | Нет | Нет |
| Копирование пользовательских интерфейсов3 | Нет | Нет |
| Копирование контейнеров3 | Нет | Нет |
| Копирование настроек контейнеров | Да | Да |
1 В контексте данной таблицы не являются настройками: SSH-ключи, сертификаты, база данных The Dude, база данных User Manager, пользовательские интерфейсы и контейнеры. Но, при этом, информация о факте использования The Dude и User Manager, а также пути до баз данных являются настройками.
2 Возможно только при выборочном копировании раздела /user.
3 Хранится в файловом хранилище.
Рекомендуемый порядок восстановления из резервных копий
Алгоритм полного восстановления устройств MikroTik при использовании резервного копирования backup
- Восстановление пользовательских интерфейсов, баз данных The Dude и User Manager.
- Восстановление основной части конфигурации из резервной копии backup.
- Восстановление контейнеров.
- Восстановление прочих файлов из файлового хранилища, которые не имеют отношения к конфигурации.
В зависимости от ситуации некоторые шаги могут быть пропущены.
Алгоритм полного восстановления устройств MikroTik при использовании резервного копирования export
- Восстановление пользовательских интерфейсов, баз данных The Dude и User Manager.
- Восстановление сертификатов и ssh-ключей (в любом порядке).
- Восстановление списка пользователей и их паролей.
- Восстановление основной части конфигурации из резервной копии export.
- Восстановление контейнеров.
- Восстановление прочих файлов из файлового хранилища, которые не имеют отношения к конфигурации.
В зависимости от ситуации некоторые шаги могут быть пропущены.
Восстановление без использования резервного копирования backup или export
При необходимости восстановления только отдельной части конфигурации, необходимо выполнить восстановление именно этой части по соответствующей инструкции из этой статьи. Однозначного алгоритма нет, так как существует большое количество возможных комбинаций.
Резервное копирование backup и восстановление из резервной копии backup
Резервное копирование backup можно выполнять в локальное файловое хранилище устройства MikroTik на котором копия создается или в облачное файловое хранилище, которое бесплатно предоставляется компанией MikroTik. Такое хранилище имеет ряд ограничений о которых будет рассказано в соответствующем разделе.
При создании резервной копии backup можно задать пароль и указать способ шифрования, что приведет к шифрованию резервной копии. Если пароль не указать, то файл с резервной копией не будет зашифрован.
Резервное копирование backup в локальное файловое хранилище
Через графический интерфейс
С помощью WinBox 3
| Рисунок 1. Резервное копирование backup в локальное файловое хранилище |
| Рисунок 2. Резервное копирование backup в локальное файловое хранилище |
С помощью WinBox 4
| Рисунок 3. Резервное копирование backup в локальное файловое хранилище |
| Рисунок 4. Резервное копирование backup в локальное файловое хранилище |
Через командную строку
/system/backup save name=backup password=password encryption=aes-sha256
Если пароль задавать не требуется, то password=password указывать не надо. Если необходимо использовать шифрование aes-sha256, то encryption=aes-sha256 указывать не обязательно, т.к. именно это шифрование используется по умолчанию.
Восстановление из резервной копии backup из локального файлового хранилища
Перед восстановлением следует убедиться, что нужный файл с резервной копией backup уже находится в файловом хранилище RouterOS. Если резервная копия была защищена паролем, то этот пароль потребуется указать при загрузке. После подтверждения восстановления, RouterOS без предупреждения полностью заменит текущую конфигурацию, конфигурацией из файла с резервной копией backup. После завершения восстановления устройство MikroTik автоматически перезагрузится.
Через графический интерфейс
С помощью WinBox 3
| Рисунок 5. Восстановление из резервной копии backup из локального файлового хранилища |
С помощью WinBox 4
| Рисунок 6. Восстановление из резервной копии backup из локального файлового хранилища (скриншот 1) |
| Рисунок 7. Восстановление из резервной копии backup из локального файлового хранилища (скриншот 2) |
Через командную строку
/system/backup/ load name=backup.backup password=password
Если при создании резервной копии пароль не задавался, то параметр password и его значение указывать не надо.
Резервное копирование backup в облачное хранилище MikroTik
Резервное копирование backup можно делать в облачное хранилище, которое компания MikroTik предоставляет бесплатно для каждого своего устройства. Для каждого устройства MikroTik можно создать одну резервную копию backup размер которой должен быть не более 15 МБайт. Для возможности сохранения резервной копии в облаке с устройства MikroTik по TCP- и UDP-порту 15252 должен быть доступен сервер с доменным именем cloud2.mikrotik.com. Загружаемая в облако резервная копия обязательно должна быть зашифрована с помощью алгоритма aes.
При выполнении резервного копирования backup в облачное хранилище MikroTik возможны два действия (action):
create-and-upload– создать резервную копию backup и загрузить ее в облако,upload– загрузить в облако уже существующий файл backup из локального файлового хранилища.
При использовании действия create-and-upload в параметре name надо указать имя, создаваемой резервной копии, а при использовании действия upload – имя уже имеющейся в файловом хранилище резервной копии.
В параметре name необходимо указать:
- имя, создаваемой резервной копии, если используется действие
create-and-upload; - имя уже имеющейся в файловом хранилище резервной копии, если используется действие
upload.
Если при выполнении действия upload необходимо изменить имя резервной копии, то новое имя можно указать в качестве значения параметра name.
После успешной загрузки резервной копии в облако, в записи этой резервной копии можно увидеть ее уникальный идентификатор Secret Download Key. С использованием этого идентификатора можно скачать из облака резервную копию на устройство MikroTik отличное от того на котором эта копия была создана изначально.
Через графический интерфейс
С помощью WinBox 3
| Рисунок 8. Запуск резервного копирования backup в облачное хранилище |
| Рисунок 9. Получение подтверждения об успешном выполнении резервного копирования backup в облачное хранилище |
С помощью WinBox 4
| Рисунок 10. Запуск резервного копирования backup в облачное хранилище |
| Рисунок 11. Получение подтверждения об успешном выполнении резервного копирования backup в облачное хранилище |
Через командную строку
/system/backup/cloud/ upload-file action=create-and-upload name=backup password=password
Восстановление из резервной копии backup из облачного хранилища MikroTik
До восстановления из резервной копии backup, хранящейся в облаке, копия вначале будет загружена в локальное файловое хранилище устройства MikroTik и только потом восстановлена. Файл, загруженный из облака в локальное файловое хранилище по умолчанию будет иметь такое же имя с которым он числился в облаке. Если необходимо изменить имя загруженного файла, то это можно сделать указав соответствующее значение для параметра dst-file. Если действие (action) download-and-apply заменить на download, то резервная копия будет только загружена без последующего восстановления.
Через графический интерфейс
С помощью WinBox 3
| Рисунок 12. Восстановление из резервной копии backup из облачного хранилища |
С помощью WinBox 4
| Рисунок 13. Восстановление из резервной копии backup из облачного хранилища |
Через командную строку
/system/backup/cloud/ download-file action=download-and-apply password=password number=0
Резервное копирование export и восстановление из резервной копии export
Резервное копирование export
Как уже было написано ранее резервное копирование export и восстановление таких резервных копий возможно только через командную строку.
Резервное копирование export в файловое устройства MikroTik
С помощью приведенной далее команды будет создана резервная копия всех разделов конфигурации (кроме раздела /user) и сохранена в файловом хранилище устройства MikroTik с именем gw.rsc (расширение rsc будет подставлено автоматически).
/export file=gw show-sensitive
Резервное копирование export в файловое хранилище локального компьютера
С помощью приведенного далее способа можно создать резервную копию export и сохранить ее сразу на локальный компьютер. Для этого необходимо удаленно выполнить команду export и перенаправить результат вывода в файл на локальном компьютере. Если файл не существует, то он будет создан. Для возможности использования команды ssh можно использовать встроенный в Windows OpenSSH-клиент, который потребуется доустановить.
| Рисунок 14. Резервное копирование export в файловое хранилище локального компьютера |
Восстановление из резервной копии export
Восстановление из резервной копии export выполняется с помощью команды import. При импорте не происходит замена имеющейся конфигурации новой, а происходит последовательное выполнение команд, указанных в файле .rsc. Таким образом новая конфигурация накладывается на уже имеющуюся и это следует учитывать с целью избегания конфликтов конфигураций.
При импорте резервной копии, созданной с помощью команды export желательно использовать ту же или максимально близкую к ней версию RouterOS на которой изначально была создана резервная копия. Это связано с тем, что, чем выше разница в версия RouterOS, тем выше вероятность получить ошибку при импорте из-за изменений в RouterOS.
При переносе резервной копии export на оборудование другой модели до импорта рекомендуется открыть файл в текстовом редакторе и проверить аппаратно-зависимые строки: имена интерфейсов, параметры беспроводных пакетов, SFP-порты, модельные отличия и другие настройки, которые могут не совпасть на новом оборудовании.
У команды import есть следующие параметры:
file-name– имя текстового файла с расширением «rsc»;from-line– номер строки, с которой должен быть начат импорт (по умолчанию с первой строки);verbose– отображение прогресса импорта:no– без отображения прогресса (по умолчанию),yes– построчное отображение прогресса с указанием номера строки,progress– отображение прогресса в процентах;
dry-run– симуляция импорта без применения изменений (требует verbose=yes или verbose=progress). Проверяет корректность файла и не проверяет совместимость с текущими настройками.
Приведенный далее пример командного выражения выполняет импорт из файла gw.rsc с построчным отображением прогресса с указанием номера строки.
/import file=gw.rsc verbose=yes
Резервное копирование и восстановление из резервной копии SSH-ключей
Для резервного копирования и восстановления SSH-ключей следует различать:
- SSH-ключи устройства MikroTik (host key);
- SSH-ключи пользователей устройства MikroTik, которые назначаются через меню
/user/ssh-keys.
Резервное копирование и восстановление из резервных копий разных видов SSH-ключей выполняется по-разному.
Резервное копирование SSH-ключей
С помощью описанного в этом разделе резервного копирования, будут получены SSH-ключи устройства MikroTik. Эту пару ключей в последующем можно использовать для восстановления идентичности SSH-сервера и SSH-клиента устройства MikroTik.
При резервном копировании SSH-ключей требуется указать префикс имени файлов и пароль, которым будет защищен закрытый ключ. Префикс может быть любым. С практической точки зрения в качестве префикса рекомендуется указывать имя устройства. Это будет полезно при сохранении в одном месте ключей от множества разных устройств.
В результате резервного копирования в файловом хранилище устройства MikroTik появятся два файла: закрытый ключ с именем prefix_rsa.pem и открытый ключ с именем prefix_rsa_pub.pem.
Через графический интерфейс
С помощью WinBox 3
| Рисунок 15. Резервное копирование SSH-ключей |
С помощью WinBox 4
| Рисунок 16. Резервное копирование SSH-ключей |
Через командную строку
/ip/ssh/ export-host-key key-file-prefix=GW passphrase=12345678
Восстановление из резервной копии SSH-ключей
При восстановлении SSH-ключей следует выполнить три действия:
- Восстановление SSH-ключа для устройства MikroTik.
- Восстановление закрытого ключа для работы SSH-клиента. Действие выполняется для конкретного пользователя RouterOS, который будет использовать SSH-клиент устройства MikroTik для исходящих SSH-подключений.
- Восстановление открытого ключа для работы SSH-сервера. действие выполняется для конкретного пользователя RouterOS, который будет использовать SSH-сервер устройства MikroTik для входящих SSH-подключений.
Данные действия не заменяют друг друга и выполняются в зависимости от того, какую именно схему аутентификации требуется восстановить.
Восстановление на устройстве MikroTik его исходного SSH-ключа (host key)
Через графический интерфейс
С помощью WinBox 3
| Рисунок 17. Восстановление SSH-ключа для устройства MikroTik |
С помощью WinBox 4
| Рисунок 18. Восстановление SSH-ключа для устройства MikroTik |
Через командную строку
/ip/ssh/ import-host-key private-key-file=GW_rsa.pem passphrase=12345678
Восстановление закрытого ключа для работы SSH-клиента
Через графический интерфейс
С помощью WinBox 3
| Рисунок 19. Восстановление закрытого ключа для работы SSH-клиента |
| Рисунок 20. Результат восстановления закрытого ключа для работы SSH-клиента |
С помощью WinBox 4
| Рисунок 21. Восстановление закрытого ключа для работы SSH-клиента |
| Рисунок 22. Результат восстановления закрытого ключа для работы SSH-клиента |
Через командную строку
/user/ssh-keys/private/ import private-key-file=GW_rsa.pem passphrase=12345678 user=admin
Восстановление открытого ключа для работы SSH-сервера
Через графический интерфейс
С помощью WinBox 3
| Рисунок 23. Восстановление открытого ключа для работы SSH-сервера |
| Рисунок 24. Результат восстановления открытого ключа для работы SSH-сервера |
С помощью WinBox 4
| Рисунок 25. Восстановление открытого ключа для работы SSH-сервера |
| Рисунок 26. Результат восстановления открытого ключа для работы SSH-сервера |
Через командную строку
/user/ssh-keys/ import public-key-file=GW_rsa_pub.pem user=admin
Резервное копирование и восстановление из резервной копии пользовательских интерфейсов
Если для каких-либо групп пользователей настроено использование собственных пользовательских интерфейсов (скинов), то резервное копирование таких интерфейсов необходимо выполнять отдельно, т.к. они хранятся в файловом хранилище и поэтому не входят ни в backup, ни в export. Пользовательские интерфейсы хранятся в файловом хранилище в папке skins в виде файлов с расширением .json.
Резервное копирование пользовательских интерфейсов
Для резервного копирования достаточно скачать на компьютер содержимое папки skins из файлового хранилища RouterOS.
С помощью WinBox 3
| Рисунок 27. Резервное копирование пользовательских интерфейсов в файловое хранилище локального компьютера |
С помощью WinBox 4
| Рисунок 28. Резервное копирование пользовательских интерфейсов в файловое хранилище локального компьютера |
Восстановление из резервной копии пользовательских интерфейсов
Для восстановления пользовательских интерфейсов необходимо сохраненные ранее JSON-файлы загрузить обратно в папку skins в файловом хранилище устройства MikroTik. Если такой папки еще нет, то ее надо предварительно создать или сразу загружать JSON-файлы, находящиеся в такой папке.
Восстанавливать пользовательские интерфейсы целесообразно до импорта раздела /user из-за того, что данный раздел содержит ссылки на соответствующие файлы, если их использование подразумевается конфигурацией RouterOS.
Резервное копирование и восстановление пользовательских групп и пользователей
Резервное копирование пользовательских групп и пользователей
Резервное копирование отдельно пользовательских групп, пользователей и паролей возможно только через командную строку с помощью команды export, выполненной из раздела конфигурации /user. При таком резервном копировании также будет сохранена информация об ограничениях на вход по IP-адресам, используемым привязкам к пользовательским интерфейсам, а также ряд другой информации, содержащейся в разделе /user в командной строке или в разделе System → Users в графическом интерфейсе.
Экспортировать пароли пользователей не получится, даже если использовать параметр show-sensitive.
Далее приведен пример команды с помощью которой можно выполнить резервное копирование пользовательских групп и пользователей из файла users.rsc.
/user/export file=users.rsc show-sensitive
В результате выполнения команды в файловом хранилище устройства MikroTik появится файл user.rsc, в котором будет содержаться резервная копия раздела /user. Содержимое файла может быть похоже на следующее:
/user group add name=group-helpdesk /user add comment="system default user" group=full name=admin password="" add group=group-helpdesk name=afedorov password=""
Восстановление из резервной копии пользовательских групп, пользователей и паролей
До восстановления, при необходимости, резервную копию следует отредактировать вручную с помощью текстового редактора и в password="" между кавычек указать нужный пароль для соответствующего пользователя. Далее восстановление пользовательских групп, пользователей и паролей выполняется точно также как и восстановление резервной копии export.
Резервное копирование и восстановление из резервной копии сертификатов
При резервном копировании MikroTik следует разделять конфигурацию, в которой сертификаты используются, и сами сертификаты. С помощью резервного копирования export можно сохранить только ссылки на имена сертификатов, но не сами сертификаты, а с помощью резервного копирования backup сохраняются и сами сертификаты, но их можно восстановить только на устройстве на котором резервная копия была создана изначально и только в составе всей конфигурации целиком.
В рамках данной статьи описан экспорт в формате PEM. Такой вариант удобен тем, что сертификаты и соответствующие им закрытые ключи сохраняются отдельными файлами, которые легко проверить и при необходимости перенести на другое устройство.
Резервное копирование сертификатов
В RouterOS 7.22.1 Stable используются следующие флаги сертификатов:
- K (PRIVATE-KEY) – закрытый ключ;
- L (CRL) – сведения о списках отзыва сертификатов;
- C (SMART-CARD-KEY) – ключ смарт-карты;
- A (AUTHORITY) – сертификат удостоверяющего центра;
- I (ISSUED) – сертификаты, подписанные сертификатом CA, который уже присутствует в хранилище сертификатов данного устройства MikroTik;
- R (REVOKED) – отозванный сертификат;
- E (EXPIRED) – сертификат у которого истек срок действия;
- T (TRUSTED) – доверенный сертификат.
Записи без рабочих флагов в рамках данной статьи следует рассматривать как шаблоны сертификатов на текущем устройстве.
Резервное копирование шаблонов сертификатов и списка отзывов сертификатов (CRL) в RouterOS не предусмотрено. По этой причине шаблоны сертификатов целесообразно хранить в виде набора команд, который при необходимости можно вручную добавить в резервную копию export.
Пример такого набора команд:
/certificate add name=Template country=RU unit="R*" common-name="R*" subject-alt-name=\ IP:100.64.255.255 days-valid=3650 key-usage=tls-client
Если сертификат имеет закрытый ключ, то при резервном копировании (экспорте) такого сертификата рекомендуется задавать пароль. В результате резервного копирования в файловом хранилище устройства MikroTik появятся файлы с расширение crt, а если экспортированный сертификат имел закрытый ключ, то для него будет создан не только файл с расширением .crt, но и файл с расширением .key.
В приведенных далее примерах будет последовательно показано:
- резервное копирование сертификата удостоверяющего центра CA,
- резервное копирование серверного сертификата TLS Server,
- резервное копирование сертификата R2 (другого устройства MikroTik).
Через графический интерфейс
С помощью WinBox 3
| Рисунок 29. Cписок сертификатов до начала выполнения резервного копирования |
| Рисунок 30. Резервное копирование сертификата удостоверяющего центра CA |
| Рисунок 31. Резервное копирование серверного сертификата TLS Server |
| Рисунок 32. Резервное копирование сертификата R2 (другого устройства MikroTik) |
С помощью WinBox 4
| Рисунок 33. Cписок сертификатов до начала выполнения резервного копирования |
| Рисунок 34. Резервное копирование сертификата удостоверяющего центра CA |
| Рисунок 35. Резервное копирование серверного сертификата TLS Server |
| Рисунок 36. Резервное копирование сертификата R2 (другого устройства MikroTik)
|
Через командную строку
/certificate/ export-certificate CA export-passphrase=12345678 type=pem export-certificate "TLS Server" export-passphrase=12345678 type=pem export-certificate R2 export-passphrase=12345678 type=pem
Восстановление из резервной копии сертификатов
До начала восстановления сертификатов, резервные копии сертификатов должны находиться в локальном файловом хранилище устройства MikroTik.
Для того, чтобы после восстановления цепочка сертификатов максимально, насколько это возможно, сохранила свойства исходной иерархии, сначала следует импортировать корневой сертификат CA и его закрытый ключ, затем – нижестоящие сертификаты и их ключи. Если в иерархии сертификатов есть промежуточные удостоверяющие центры, их также импортируют в порядке сверху вниз.
Флаг T (Trusted) следует включать только для тех сертификатов, которые действительно должны считаться доверенными, а не для всех подряд сертификатов. Чаще всего данный флаг включают для сертификатов корневого удостоверяющего центра, а не конечные серверные или клиентские сертификаты. Флаг R (Revoked) не переносится при восстановлении и поэтому ранее отозванные сертификаты следует отозвать заново. Шаблоны сертификатов и список CRL должны создаваться заново.
Через графический интерфейс
С помощью WinBox 3
| Рисунок 37. Файловое хранилище до начала восстановления сертификатов |
| Рисунок 38. Восстановление из резервной копии сертификата CA |
| Рисунок 39. Восстановление из резервной копии закрытого ключа CA |
| Рисунок 40. Восстановление из резервной копии сертификата CA |
| Рисунок 41. Восстановление из резервной копии закрытого ключа CA |
| Рисунок 42. Восстановление из резервной копии сертификата TLS Server |
| Рисунок 43. Восстановление из резервной копии закрытого ключа TLS Server |
| Рисунок 44. Восстановление из резервной копии сертификата R2 |
| Рисунок 45. Восстановление из резервной копии закрытого ключа R2 |
| Рисунок 46. Отзыв сертификата R2 |
| Рисунок 47. Актуальный список сертификатов (без шаблонов) |
С помощью WinBox 4
| Рисунок 48. Файловое хранилище до начала восстановления сертификатов |
| Рисунок 49. Восстановление из резервной копии сертификата CA |
| Рисунок 50. Восстановление из резервной копии закрытого ключа CA |
| Рисунок 51. Восстановление из резервной копии сертификата TLS Server |
| Рисунок 52. Восстановление из резервной копии закрытого ключа TLS Server |
| Рисунок 55. Восстановление из резервной копии сертификата R2 |
| Рисунок 56. Восстановление из резервной копии закрытого ключа R2 |
| Рисунок 57. Отзыв сертификата R2 |
| Рисунок 58. Актуальный список сертификатов (без шаблонов) |
Через командную строку
/file/
print
Columns: NAME, TYPE, SIZE, LAST-MODIFIED
# NAME TYPE SIZE LAST-MODIFIED
0 gw.rsc script 3962 20xx-xx-xx xx:xx:xx
1 backup.backup backup 31.0KiB 20xx-xx-xx xx:xx:xx
2 cert_export_TLS Server.key .key file 1886 20xx-xx-xx xx:xx:xx
3 cert_export_TLS Server.crt .crt file 1164 20xx-xx-xx xx:xx:xx
4 cert_export_R2.key .key file 1886 20xx-xx-xx xx:xx:xx
5 cert_export_R2.crt .crt file 1159 20xx-xx-xx xx:xx:xx
6 cert_export_CA.key .key file 1886 20xx-xx-xx xx:xx:xx
7 cert_export_CA.crt .crt file 1151 20xx-xx-xx xx:xx:xx
8 skins directory 20xx-xx-xx xx:xx:xx
9 skins/custom_skin.json .json file 444 20xx-xx-xx xx:xx:xx
/certificate/
import file-name=cert_export_CA.crt passphrase=12345678 name=CA trusted=yes
import file-name=cert_export_CA.key passphrase=12345678 name=CA trusted=yes
import file-name="cert_export_TLS Server.crt" passphrase=12345678 name="TLS Server" trusted=no
import file-name="cert_export_TLS Server.key" passphrase=12345678 name="TLS Server" trusted=no
import file-name=cert_export_R2.crt passphrase=12345678 name=R2 trusted=no
import file-name=cert_export_R2.key passphrase=12345678 name=R2 trusted=no
issued-revoke R2
#создание шаблона
add name=Template country=RU unit="R*" common-name="R*" subject-alt-name=\
IP:100.64.255.255 days-valid=3650 key-usage=tls-client
Резервное копирование и восстановление из резервной копии базы данных The Dude
С помощью резервного копирования backup и export можно сохранить только:
- параметр enabled и его значение, которые отвечают за факт включения или выключения The Dude;
- параметр data-directory и его значение, которые отвечают за путь к папке в которой хранится база данных The Dude.
Вся остальная информация (устройства, топологии, история мониторинга и т.д.) хранится в базе данных The Dude в формате SQLite, которая по умолчанию находится в файловом хранилище устройства MikroTik. А так как резервное копирование файлового хранилища не выполняется ни с помощью backup, ни с помощью export, то базу данных The Dude следует копировать отдельно.
Резервное копирование базы данных The Dude на RouterOS 7.22.1 Stable рекомендуется выполнять с помощью команды export-db, а восстановление – с помощью команды import-db. Аналогов данных команд в графическом интерфейсе не существует. Резервное копирование и восстановление базы данных The Dude также можно делать с помощью копирования папки dude и вложенных в нее файлов, но по ряду причин такой способ не рекомендуется.
Если необходимо восстановить не только базу данных The Dude, но и настройки относящиеся к этой службе, то следует выполнить импорт соответствующих настроек с помощью команды import.
Резервное копирование базы данных The Dude
Далее приведен пример двух командных выражений:
- Первое выражение выключает сервер The Dude, что требуется для обеспечения целостности данных при резервном копировании.
- Второе выражение выполняет резервное копирование базы данных The Dude и сохранение ее в файловом хранилище устройства MikroTik в виде архива с именем dude_26030601.tgz.
/dude/ set enabled=no export-db backup-file=dude_26030601.tgz
Восстановление из резервной копии базы данных The Dude
Далее приведен пример двух командных выражений:
- Первое выражение выполняет восстановление базы данных The Dude из резервной копии, которая хранится в файловом хранилище устройства MikroTik в виде архива с именем dude_26030601.tgz.
- Второе выражение включает сервер The Dude.
/dude/ import-db backup-file=dude_26030601.tgz set enabled=yes
Резервное копирование и восстановление из резервной копии базы данных User Manager
С помощью резервного копирования backup и export можно сохранить только:
- параметр enabled и его значение, которые отвечают за факт включения или выключения User Manager;
- параметр db-path и его значение, которые отвечают за путь к базе данных User Manager.
- настройки раздела
/radius.
Вся остальная информация хранится в базе данных User Manager в формате SQLite, которая по умолчанию находится в файловом хранилище устройства MikroTik. А так как резервное копирование файлового хранилища не выполняется ни с помощью backup, ни с помощью export, то базу данных User Manager следует копировать отдельно.
Резервное копирование базы данных User Manager на RouterOS 7.22.1 Stable рекомендуется выполнять с помощью команды save, восстановление – с помощью команды load. Аналогов данных команд в графическом интерфейсе не существует. Резервное копирование и восстановление базы данных User Manager также можно делать с помощью копирования папки user-manager5 и вложенных в нее файлов, но по ряду причин такой способ не рекомендуется. Резервное копирование папки um5files, которая также относится к User Manager, требуется, только если в нее вручную вносились изменения.
Если необходимо восстановить не только базу данных User Manager, но и настройки относящиеся к этой службе, то следует выполнить импорт соответствующих настроек с помощью команды import.
Резервное копирование базы данных User Manager
Далее приведен пример двух командных выражений:
- Первое выражение выключает User Manager, что требуется для обеспечения целостности данных при резервном копировании.
- Второе выражение выполняет резервное копирование базы данных User Manager и сохранение ее в файловом хранилище устройства MikroTik в виде архива с именем user_manager_26030601.umb.
/user-manager/ set enabled=no /user-manager/database/ save name=user_manager_26030601 overwrite=yes
Восстановление из резервной копии базы данных User Manager
Далее приведен пример двух командных выражений:
- Первое выражение выполняет восстановление базы данных User Manager из резервной копии, которая хранится в файловом хранилище устройства MikroTik в виде архива с именем user_manager_26030601.umb.
- Второе выражение включает User Manager.
/user-manager/database/ load name=user_manager_26030601.umb /user-manager/ set enabled=yes
Резервное копирование и восстановление из резервной копии контейнеров
Из-за специфики использования контейнеров в MikroTik RouterOS алгоритм резервного копирования и восстановления контейнеров на оборудовании MikroTik не является универсальным, но в данной статье он описан достаточно подробно для того, чтобы можно было внести необходимые доработки под требуемую ситуацию.
С помощью резервного копирования backup и export можно сохранить только настройки, относящиеся к разделам App и Container. А данные приложений: базы данных и файлы должны копироваться отдельно. В идеальном случае при резервном копировании файлов следует копировать только те папки, которые заданы в настройках контейнеров как точки монтирования (mounts). Их можно копировать либо напрямую через графический интерфейс, либо с помощью утилиты scp.
Резервное копирование и восстановление контейнеров будет описано на примере приложения WordPress.
Исходные данные:
- виртуальная машина на базе CHR с IP-адресом 192.168.255.101;
- приложение WordPress, доступное к установке через оснастку App и заранее настроенное компанией MikroTiuk;
- в качестве виртуальной сети используется шаблон готовой сети internal;
- а в качестве файлового хранилища используется блочное виртуальное USB-устройство, отформатированное с использованием файловой системы ext4;
- все переменные и параметры используются стандартные.
В рамках статьи будет описано резервное копирование и восстановление двух контейнеров:
- Резервное копирование и восстановление контейнера app-wordpress-db, который содержит базу данных MySQL и использует точку монтирования "/usb1-part1/apps/wordpress/db_data". Перенос такого контейнера возможен как через графический интерфейс, так и через командную строку.
- Резервное копирование и восстановление контейнера app-wordpress-server, который не использует точку монтирования для содержимого сайта, в связи с чем необходимо отдельно перенести директорию "/usb1-part1/apps/wordpress/server_root". На момент написания статьи перенос этой директории через графический интерфейс не работает и поэтому рекомендуется использовать утилиту SCP.
Если необходимо восстановить не только контейнеры, но и настройки относящиеся к ним, то следует выполнить импорта соответствующих настроек с помощью команды import.
В отличие от ручного создания контейнеров через раздел Containers, при развертывании приложения через App вендор не предоставляет возможность использовать корневую файловую систему RouterOS для хранения контейнеров. Развертывание приложения приводит к появлению в подключенном файловом хранилище двух контейнеров: контейнера базы данных с именем app-wordpress-db и контейнера сайта с именем app-wordpress-server. В рамках данной статьи приведено описание использования механизмов для СУБД MySQL/MariaDB, встроенных в контейнер.
Резервное копирование контейнеров
Алгоритм резервного копирования контейнеров:
- Выключить приложение WordPress до начала резервного копирования контейнеров.
- Убедиться, что произошла остановка контейнеров. Это можно сделать в разделе Containers.
- Подготовить структуру каталогов на компьютере для хранения резервной копии.
- По отдельности сохранить базу данных и файловое хранилище веб-сайта.
- Включить приложение WordPress после завершения резервного копирования.
Следует учитывать, что:
- если из-за особенностей контейнера точка монтирования не используются, может возникнуть необходимость копирования корневой директории контейнера (root dir), что в файловом хранилище RouterOS выглядит как container store;
- при ручном копировании директории типа container store через графический интерфейс возможны ошибки, из-за которых вместо каталога будет получен пустой файл. В подобных случаях следует использовать утилиту scp.
При ручном копировании директории типа container store через графический интерфейс вероятны баги, которые приведут к некорректному копированию папки: в результате будет получен пустой файл! Чтобы избежать этого, копируйте такие директории с помощью scp.
Резервное копирование базы данных сайта можно выполнить с помощью копирования файлов или с помощью выгрузки дампа базы данных. В статье будут описаны оба этих способа, но следует учитывать, что второй способ является более корректным, несмотря на большую его трудоемкость.
Через графический интерфейс
С помощью WinBox 3
| Рисунок 59. Выключение приложения WordPress |
| Рисунок 60. Результат выключения приложения WordPress |
| Рисунок 61. Список запущенных контейнеров |
| Рисунок 62. Создание папки apps и вложенной в нее папки wordpress |
| Рисунок 63. Копирование БД MySQL вручную (не рекомендуется) |
| Рисунок 64-1. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 64-2. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 64-3. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 64-4. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 64-5. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 65. Копирование папки server_root вручную |
| Рисунок 66. Запуск WordPress |
| Рисунок 67. Запуск WordPress |
С помощью WinBox 4
| Рисунок 68. Выключение приложения WordPress |
| Рисунок 69. Результат выключения приложения WordPress |
| Рисунок 70. Просмотр запущенных контейнеров |
| Рисунок 71. Создание папки apps и вложенной в нее папки wordpress |
| Рисунок 72. Копирование БД MySQL вручную (не рекомендуется) |
| Рисунок 73. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 74. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 75. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 76. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 77. Выгрузка БД MySQL через shell (рекомендуется) |
| Рисунок 78. Копирование папки server_root вручную |
| Рисунок 79. Запуск WordPress |
| Рисунок 80. Запуск WordPress |
Через командную строку
1. Остановка контейнеров.
/app/ set wordpress disabled=yes
2. Проверка состояния контейнеров через командную строку.
/container/ print Flags: S - STOPPED Columns: NAME, ROOT-DIR # NAME ROOT-DIR 0 S app-wordpress-db /usb1-part1/apps/wordpress/db_root 1 S app-wordpress-server /usb1-part1/apps/wordpress/server_root
3. Создание на компьютере папок apps, а в ней – директории wordpress. Шаг может быть выполнен любым удобным способом.
4. Резервное копирование базы данных сайта можно выполнить с помощью копирования файлов или с помощью выгрузки дампа базы данных. Оба этих способа будут описаны далее.
4.1. Резервное копирование базы данных сайта с помощью копирования файлов (возможно как с помощью помощью утилиты scp, так и с помощью графического интерфейса):
scp -O -r admin@192.168.255.101:usb1-part1/apps/wordpress/db_data D:/apps/wordpress
4.2. Резервное копирование базы данных сайта с помощью копирования файлов является более корректным, но более трудоемким способом.
4.2.1. Запуск только контейнера с БД.
/container/ start [find where name="app-wordpress-db"]
4.2.2. Выгрузка дампа базы данных (в примере используются стандартные параметры приложения).
/container/ shell app-wordpress-db cmd="mysqldump -uwordpress -p'wordpress' --single-transaction --quick --databases wordpress --result-file=/var/lib/mysql/wordpress.sql"
4.2.3. Остановка контейнера с БД.
/container/ stop [find where name="app-wordpress-db"]
4.2.4. Копирование дампа БД на компьютер (возможно как с помощью помощью утилиты scp, так и с помощью графического интерфейса).
scp -O admin@192.168.255.101:usb1-part1/apps/wordpress/db_data/wordpress.sql D:/apps/wordpress/wordpress.sql
5. Копирование хранилища веб-сайта (возможно как с помощью помощью утилиты scp, так и с помощью графического интерфейса).
scp -O -r admin@192.168.255.101:usb1-part1/apps/wordpress/server_root D:/apps/wordpress
6. Запуск приложения WordPress.
/app/ set wordpress disabled=no
Восстановление из резервной копии контейнеров
Через графический интерфейс
С помощью WinBox 3
| Рисунок 81. Создание директории apps |
| Рисунок 82. Список директорий в файловом хранилище для приложения WordPress |
| Рисунок 83-1. Восстановление БД MySQL нерекомендуемым способом |
| Рисунок 83-2. Восстановление БД MySQL нерекомендуемым способом |
| Рисунок 84-1. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-2. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-3. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-4. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-5. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-6. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-7. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-8. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-9. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 84-10. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 85. Восстановление хранилища веб-сайта |
| Рисунок 86. Запуск WordPress |
| Рисунок 87. Запуск WordPress |
С помощью WinBox 4
| Рисунок 88. Создание директории apps |
| Рисунок 89. Список директорий в файловом хранилище для приложения WordPress |
| Рисунок 90-1. Восстановление БД MySQL нерекомендуемым способом |
| Рисунок 90-2. Восстановление БД MySQL нерекомендуемым способом |
| Рисунок 91-1. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-2. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-3. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-4. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-5. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-6. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-7. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-8. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-9. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 91-10. Восстановление БД MySQL рекомендуемым способом |
| Рисунок 92. Восстановление хранилища веб-сайта |
| Рисунок 93. Запуск WordPress |
| Рисунок 94. Запуск WordPress |
Через командную строку
1. Создание на RouterOS папки apps, в ней – папки wordpress, а в папке wordpress – папок server_root и db_data.
/file/ add type=directory name=/usb1-part1/apps add type=directory name=/usb1-part1/apps/wordpress add type=directory name=/usb1-part1/apps/wordpress/db_data add type=directory name=/usb1-part1/apps/wordpress/server_root
2.1. Восстановление базы данных с помощью копирования файлов (нерекомендуемый способ):
scp -O -r "D:/apps/wordpress/db_data/." admin@192.168.255.101:usb1-part1/apps/wordpress/db_data/ /app/ set wordpress disabled=no #дождаться полной установки приложения set wordpress disabled=yes
2.2. Восстановление базы данных с помощью импорта дампа базы данных (рекомендуемый способ):
scp -O D:/apps/wordpress/wordpress.sql admin@192.168.255.101:usb1-part1/apps/wordpress/db_data/wordpress.sql /app/ set wordpress disabled=no #дождаться полной установки приложения set wordpress disabled=yes /container/ start [find where name="app-wordpress-db"] shell app-wordpress-db cmd="sh -c 'mysql -uwordpress -p\"wordpress\" wordpress < /var/lib/mysql/wordpress.sql'" #удаление дампа shell app-wordpress-db cmd="rm -f /var/lib/mysql/wordpress.sql" stop [find where name="app-wordpress-db"]
3. Загрузка файлов веб-сайта:
scp -O -r D:/apps/wordpress/server_root/. admin@192.168.255.101:usb1-part1/apps/wordpress/server_root/
4. Запуск WordPress:
/app/ set wordpress disabled=no
Полезные ссылки
Онлайн-курсы по MikroTik
- Администрирование сетевых устройств MikroTik
- Файрвол и приоритизация трафика на MikroTik
- Маршрутизация на MikroTik
- Коммутация на MikroTik
Онлайн-курсы по сетям
- Математика и физика в сетевых технологиях
- Архитектура современных компьютерных сетей
- Устройство, проектирование и диагностика беспроводных сетей IEEE 802.11 (Wi-Fi)
Telegram-каналы
Telegram-чат
Прочее