Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Зачем так усложнять. Можно же использовать старый добрый rancid. Он прекрасно работает с микротиками так ещё и diff делает.
Век живи век учись, с cisco гонял этого зверя. С микротом не доводилось. Можно попробовать. Спасибо за наводку.
можете подсказать, почему бэкап с помощью rsc вдруг перестал бэкапить все
Бэкапит только название и скрипты кажется, а все остальные настройки игнорирует.
system export file=1.rsc Бэкапит только название и скрипты кажется, а все остальные настройки игнорирует.
Сложно ответить на такой вопрос. Можно попробовать посмотреть версию RoS и если она имеет возможность к обновлению — обновить. На RoS 6.35 + все работает. Еще хочу заметить что
system не нужно указывать export file=1 будет достаточно.
Начиная с RouterOS 6rc1 по умолчанию выдает «compact». То есть разницу текущего конфига и default конфига.
Полный бэкап:
Полный бэкап:
/export verbose file=backup
у cisco есть замечательная директива archive для бекапов
Использую oxidized для этих целей и сохраняю на приватный gitlab — всегда можно посмотреть историю изменений. Работает и с Cisco, и с Mikrotik и еще бог знает с чем.
github.com/ytti/oxidized
github.com/ytti/oxidized
дратути. Надысь, писал я про подобное(честно говоря вообще не понял к чему тут zabbix, поясните пожалуйста)
Критика: если адреса микротиков в цикле — не будет работать. Я по опыту скажу, я делал список в отдельном файле, в том же скрипте, через параметры, используя for, until — хренушки.
Всегда будет трабла одна — если в середине цикла косячный микротик — рвётся весь цикл. т.е. если недоступен, если поменялась публичная часть ключа и т.п. Я долго это дело костылил, но дошёл только до одного — делать скоп микротик в цикле категорически неправильно. Поэтому в своём решении я разделил сам скрипт и конфиги в отдельные файлы. Т.е. скрипт как хорошая программа имеет какие-то дефолты, которые потом можно перебить в конфигурационном файле для определённого микротика. Выгода в том, что если сломается бэкап одного — не пострадают остальные(как у вас). Так же я добавил логгирование, вполне себе нормальное(которое даже при неожиданном отключении нормально залогирует, что не было бэкапа)
Почитайте пожалуйста, мою статью, взгялните критическим взгядом. Незачем плодить 100500 проектов, мне кажется. Лучше туда добавить что-то(к примеру заббикс, только я не пойму зачем?)
habrahabr.ru/post/342060
PS — не в обиду, по существу.
Критика: если адреса микротиков в цикле — не будет работать. Я по опыту скажу, я делал список в отдельном файле, в том же скрипте, через параметры, используя for, until — хренушки.
Всегда будет трабла одна — если в середине цикла косячный микротик — рвётся весь цикл. т.е. если недоступен, если поменялась публичная часть ключа и т.п. Я долго это дело костылил, но дошёл только до одного — делать скоп микротик в цикле категорически неправильно. Поэтому в своём решении я разделил сам скрипт и конфиги в отдельные файлы. Т.е. скрипт как хорошая программа имеет какие-то дефолты, которые потом можно перебить в конфигурационном файле для определённого микротика. Выгода в том, что если сломается бэкап одного — не пострадают остальные(как у вас). Так же я добавил логгирование, вполне себе нормальное(которое даже при неожиданном отключении нормально залогирует, что не было бэкапа)
Почитайте пожалуйста, мою статью, взгялните критическим взгядом. Незачем плодить 100500 проектов, мне кажется. Лучше туда добавить что-то(к примеру заббикс, только я не пойму зачем?)
habrahabr.ru/post/342060
PS — не в обиду, по существу.
От глючного микротика в середине цикла меня спасала кострукция примерно следующего вида — запускаем скрипт, общающийся с одним девайсом в фоне, инкрементим счетчик. Как только счетчик доходит до некоторого порога — делаем wait — ждем, пока кто-нибудь (!) освободится, декрементим счетчик, запускаем следующего. Так, пока в списке что-то осталось. Потом делаем waitall. Итого — обходим овер-дофига железок, каждая может подвиснуть и/или затормозить, а всё вместе отработает за вполне разумное время.
я делал не только так, — костыляки бессмысленные. Я думаю, что проще и лучше вынести конфиги отдельно, скрипт отдельно, тогда не будет проблем и можно будет задавать очень много кастомных параметров, при этом же сохраняя то, что можно оставить для других 100500 микротиков дефолтные, которые определены в сприпте.
Про заббикс так и не понял. В моём понимании система… мониторит, а система резервного копирования — правильно, бэкапит.
Так же не вижу очистки бэкапов, которые так и накапливаются на устройстве. Через определённое количество времени(когда тупо память забьётся на микротике), такие бэкапы встанут в единственно возможную позу — перестанут делаться. Произойдёт фиктивное срабатывание скрипта, далее произойдёт тот самый wait непонятно чего, а потом скрипт в конце завершится с exitcode=0. Всё вроде и работает, а бэкапа-то нет…
Про заббикс так и не понял. В моём понимании система… мониторит, а система резервного копирования — правильно, бэкапит.
Так же не вижу очистки бэкапов, которые так и накапливаются на устройстве. Через определённое количество времени(когда тупо память забьётся на микротике), такие бэкапы встанут в единственно возможную позу — перестанут делаться. Произойдёт фиктивное срабатывание скрипта, далее произойдёт тот самый wait непонятно чего, а потом скрипт в конце завершится с exitcode=0. Всё вроде и работает, а бэкапа-то нет…
Ух, да вы говорите верно, но к сожалению практика уже показала что если я не могу достучаться до хоста по ssh, например no route to host, все прекрасненько отрабатывает на последующих микротах. По заббиксу скажу так — он уже есть, уже работает и костылить велосипед рядом — смысла не вижу. Отправлять можно хоть в socket.
Да, тут полностью согласен, если сессия зависнет и не завершиться — цикл остановится и не будет продолжаться. Будет ждать сначала ssh потом scp и еще раз scp тут зарыта собака и если что то пойдет не так — будет боль и страдание, но для этого существует мониторинг zabbix — в котором не получение данных в течении n количества минут от скрипта гласит — а ну поднимай свой тощий зад и тащи его сюда скорей посмотри что там с бекапами
бэкапы старше чем ST_RTN дней
А как вы обрабатываете ситуацию, когда бекапы не далались 30 дней — существующие не удалятся?
А как вы обрабатываете ситуацию, когда бекапы не далались 30 дней — существующие не удалятся?
на микротике удаляются только те, которые делаются скриптом.
RTN только для архивации, за это время они лежат в папке ../hostname, а старше этой даты в ../hostname/archive
Удалять они вообще не удаляются с хоста, где выполняется скрипт(очень малый размер)
По итогу: если SN_RTN=30, то при работе скрипта все бэкапы переместятся в archive на 31 день, если вы таки делаете бэкап.
RTN только для архивации, за это время они лежат в папке ../hostname, а старше этой даты в ../hostname/archive
Удалять они вообще не удаляются с хоста, где выполняется скрипт(очень малый размер)
По итогу: если SN_RTN=30, то при работе скрипта все бэкапы переместятся в archive на 31 день, если вы таки делаете бэкап.
Честно, увидел ваш проект после того как написал свой скрипт. Посмотрел — честно говоря это уже что-то из разряда сервисов с логированием и возможностью подключения модулей. Мой же скрипт прост как дважды два, но затрагивает одну интересную проблему bash — отсутствие вложенных массивов.Я, честно говоря, люблю больше python и мне было бы даже проще и быстрее написать программу которая будет вам не только по ssh ходить, но еще и чаю нальет лог запишет. К слову сказать есть много библиотек для работы ssh в python. Так вот мне захотелось сделать это безобразие на bash в стиле python — получилось сносно. Считаю что из этого кода кто то может почерпнуть для себя что то интересное. Еще раз повторюсь моей целью не было просто взять и написать штуку которая будет лучше всех собирать бекапы =)
Не знало про zabbix_sender, спасибо.
А есть что-то для заббикса но работающее исключительно в песочнице javascript-браузера?
Нужно контролировать доступность веб-ресурса именно из браузера инфокиоска.
Пинги могут идти, сервер работать, а веб-приложение именно с этого киоска — нет.
А есть что-то для заббикса но работающее исключительно в песочнице javascript-браузера?
Нужно контролировать доступность веб-ресурса именно из браузера инфокиоска.
Пинги могут идти, сервер работать, а веб-приложение именно с этого киоска — нет.
я думаю что вы сможете отсылать на заббикс сервер данные в формате JSON, другой вопрос как код внедрить в js. Ну тут я уже к сожалению не помогу. Формат JSON который принимает заббикс можно подсмотреть в том же zabbix-sender'e поснифать пакеты и потом посмотреть содержимое, не думаю что там есть что то сверхестественное, возможно вы сможете найти описание формата на просторах www.zabbix.com но не путайте с форматом LLD — это всего лишь кусочек того что отправляет sender.
Немножко паранойи и предостережений
1 — вы оставляете бекап на самом микротике, если вашу железку унесут плохие люди, то получат доступ к вашим данным(snmp, users, etc.) В общем то можно не заходить на микротики, а выполнить команду удалённо, бекап может остаться там, а export можно через '>' отправить в файл.
2 — вы не проверяете содержимое файла .rsc, бывают ситуации(баги) когда скрипт не отрабатывает до конца, можно смотреть что скрипт содержит хотя бы 50 строчек, например.
3 — есть нюансы в зависимости от версий RouterOS и от платформы, я бы порекомендовал делать ещё export verbose, это поможет при замене микротика другой платформой и версией софта, могут меняться разные умолчания и синтаксис, без export verbose этого вы не увидите.
1 — вы оставляете бекап на самом микротике, если вашу железку унесут плохие люди, то получат доступ к вашим данным(snmp, users, etc.) В общем то можно не заходить на микротики, а выполнить команду удалённо, бекап может остаться там, а export можно через '>' отправить в файл.
2 — вы не проверяете содержимое файла .rsc, бывают ситуации(баги) когда скрипт не отрабатывает до конца, можно смотреть что скрипт содержит хотя бы 50 строчек, например.
3 — есть нюансы в зависимости от версий RouterOS и от платформы, я бы порекомендовал делать ещё export verbose, это поможет при замене микротика другой платформой и версией софта, могут меняться разные умолчания и синтаксис, без export verbose этого вы не увидите.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бекапим Mikrotik с помощью SSH и SCP