Comments 26
Делал подобное. Я сохранял еще лицензию при постановке устройство в систему (система — это 3 скрипта =)) бекапов. И все это благолепие заворачивал в git репозиторий. Коммитил раз в месяц, мне чаще не нужно было. Плюс в том, что можно было различие отследить.
Почему не github.com/ytti/oxidized?
Можно делать без пароля:
dont-encrypt=yes
Идея. А нельзя ли вытягивать пользователей, файлы и т.д. через SFTP из микротика?
файлы — без проблем. А пользователей никак не вытянуть.
Пользователь на устройстве микротик не вытягивается никак(насколько я знаю). Да и смысла особого нет его вытягивать, можно написать скрипт, который его так же создаст, задаст пароль и наимпортирует ключей.
Касательно файлов на устройстве — в самом скрипте это уже делается. Когда создаётся бэкап, он кладётся на устройство, а потом с устройства копируется, и сразу же удаляется, ибо если они накопятся, то места под новые бэкапы уже не будет.
создаётся, копируется, удаляется:
Пользователь на устройстве микротик не вытягивается никак(насколько я знаю). Да и смысла особого нет его вытягивать, можно написать скрипт, который его так же создаст, задаст пароль и наимпортирует ключей.
Касательно файлов на устройстве — в самом скрипте это уже делается. Когда создаётся бэкап, он кладётся на устройство, а потом с устройства копируется, и сразу же удаляется, ибо если они накопятся, то места под новые бэкапы уже не будет.
создаётся, копируется, удаляется:
T_BKPSTR="system backup save name=$TGT_BKPNAME_BIN dont-encrypt=no password=$BKP_BINPWD"
T_BKPCLN="file remove [find name=$TGT_BKPNAME_BIN]"
$SSH_STR $T_BKPSTR # Initializing backup
sleep $IDL && $SCP_STR # Copy file to storage
sleep $IDL && $SSH_STR $T_BKPCLN # Remove created file on mikrotik
В чем смысл определения полных путей для всех команд, но через which? Это карго-культ — в больших кодовых базах на sh в самом деле определяют полные пути к используемым командам, но:
1. либо явно прописывают системный путь, т.е. /bin/ln, /usr/bin/env…
2. либо меняют текущий PATH
У вас ничего из перечисленного не происходит, CMD_CHO etc затрудняют чтение и не добавляют функциональности.
1. либо явно прописывают системный путь, т.е. /bin/ln, /usr/bin/env…
2. либо меняют текущий PATH
У вас ничего из перечисленного не происходит, CMD_CHO etc затрудняют чтение и не добавляют функциональности.
Спасибо за статью, кое-что взял себе на заметку.
У нас используется сервер мониторинга Nagios, в конфигах которого (текстовых) описаны разные железки, которые мониторятся. Так-же есть скрипт, который смотрит эти конфиги, и, в зависимости от типа устройства, вызывает тот или иной способ получения бекапа (через ssh, telnet, wget). Скрипт может быть запущен вручную, через cron или как сервис самого Nagios. Собственно сами резервируемые конфиги устройств ложатся в каталог /etc/backups/ на сервере мониторинга с установленным пакетом etckeeper, который в свою очередь коммитит их в git репозиторий и отправляет красивое письмо и нотифай в Telegram об изменениях.
У нас используется сервер мониторинга Nagios, в конфигах которого (текстовых) описаны разные железки, которые мониторятся. Так-же есть скрипт, который смотрит эти конфиги, и, в зависимости от типа устройства, вызывает тот или иной способ получения бекапа (через ssh, telnet, wget). Скрипт может быть запущен вручную, через cron или как сервис самого Nagios. Собственно сами резервируемые конфиги устройств ложатся в каталог /etc/backups/ на сервере мониторинга с установленным пакетом etckeeper, который в свою очередь коммитит их в git репозиторий и отправляет красивое письмо и нотифай в Telegram об изменениях.
Идея выбора бэкапа меня заинтересовала, кажется разумной.
Идея скрещивания функционала системы мониторинга с системами резервного копирование — не очень. Ну как-то это не то, я думаю, что какие-то действия при триггерах настроить через Zabbix(Nagios отрицаю) можно, к примеру как переключение на резервный канал, выключение интерфейса и.т.д., но очень странно слышать про бэкап.
Идея скрещивания функционала системы мониторинга с системами резервного копирование — не очень. Ну как-то это не то, я думаю, что какие-то действия при триггерах настроить через Zabbix(Nagios отрицаю) можно, к примеру как переключение на резервный канал, выключение интерфейса и.т.д., но очень странно слышать про бэкап.
Просто хостов за 500+ и нужно бекапить и мониторить.
Мониторинг по пингу включен на всех железках. Грех не использовать этот полный список.
Указываем в мониторинге тип железки, а в скрипте бекапа — смотреть на этот тип, ну и соответственно вызывать тот или иной алгоритм скачивания конфига. Что-бы не потерять что-то, проще вести единую базу.
Мониторинг по пингу включен на всех железках. Грех не использовать этот полный список.
Указываем в мониторинге тип железки, а в скрипте бекапа — смотреть на этот тип, ну и соответственно вызывать тот или иной алгоритм скачивания конфига. Что-бы не потерять что-то, проще вести единую базу.
И чего только люди не придумают, чтобы не ставить Noc.
ну круто, да, комплексная управлялка.
А вы подумали, уместна ли она везде? Вот прям везде, где у вас только, к примеру, микротик, который туннели в дц поднимает, а остальное вас не интересует?
Такие вещи уместны более в достаточно серьёзных сетях. Тут рассматривается нечто иное.
А вы подумали, уместна ли она везде? Вот прям везде, где у вас только, к примеру, микротик, который туннели в дц поднимает, а остальное вас не интересует?
Такие вещи уместны более в достаточно серьёзных сетях. Тут рассматривается нечто иное.
Я соглашусь, что возможны ситуации когда админу наплевать на варианты типа "выполнить не удалось; повторить через час".
Бывает что им не нужна история или историю они делают через mkrtk_22.`date +%s`.txt
Бывает что потом когда на сети появляется еще один вендор эти админы разводят руками и говорят "ой мой скрипт перестал работать напишу еще один" и заканчивают с 15 вендорами и богатым кроном.
Все эти варианты вполне…
вполне имеют место быть, я думаю) Автору хотелось попрактиковаться и сделать полезную штуку, только и всего.
Верно. больше хороших штук. Только в проде не оставляйте как наиграетесь. Пожалейте приемника ему же это поддерживать, а он ни в чем не виноват…
как раз отдал людям в прод, не считаю глупостью или чем-то таким. У всех свои бюджеты, я просто помог людям задаром ради интереса.
А преемник, ну тут достаточно просто виртуалку выключить или cron-джобы убрать и всё(я думаю разберутся).
Это просто виртуалка, в которой специальный пользователь работает по ssh, и вообще ничего криминального не вижу в этом.Работает это и с CCR и CCS, и с более простыми моделям и вообще не обламывается.
По мне так лучше писать скрипты, чем не писать. Инфраструктуры переменчивы и я думаю, что это вполне практичный скрипт для простого бэкапа. Мне и людям достаточен более чем.
А преемник, ну тут достаточно просто виртуалку выключить или cron-джобы убрать и всё(я думаю разберутся).
Это просто виртуалка, в которой специальный пользователь работает по ssh, и вообще ничего криминального не вижу в этом.Работает это и с CCR и CCS, и с более простыми моделям и вообще не обламывается.
По мне так лучше писать скрипты, чем не писать. Инфраструктуры переменчивы и я думаю, что это вполне практичный скрипт для простого бэкапа. Мне и людям достаточен более чем.
Я вот жалею человека, которому после меня достанется нок. Он просто сетевой админ и ни в чём не виноват. Скрипт бы он поправил, а вот с ноком...
Печально, что не видно вменяемых альтернатив.
Микроты же сами умеют сливать свои конфиги. Скрипт кладем на роутер, настраиваем шедулер.
Можно и через expect какой-нибудь, удобно если на железках разные пароли
что-то типа такого
Можно и через expect какой-нибудь, удобно если на железках разные пароли
что-то типа такого
#!/usr/bin/expect
set remote_server [lindex $argv 0]
set my_password { pass1 pass2 pass3}
spawn ssh user@$remote_server
expect {
"(yes/no)?*" {
send "yes\n"
}
}
set try 0
set timeout 1
expect {
"*word:*" {
if { $try>3} {exit 1}
send [lindex $my_password $try]\r
incr try
exp_continue
}
}
set timeout 15
expect " > "
send "/export compact file=\"file.log\"\r"
expect " > "
send "/tool fetch address=\"IP_ADDR_FTP\" src-path=\"file.log.rsc\" user=\"config\" mode=ftp password=config dst-path=\"file.log.rsc\" upload=yes\r"
expect " > "
send "\n"
expect " > "
send "quit\r"
кто ж спорит, умеет. Это ещё один коммент вида habrahabr.ru/post/342060/#comment_10517694
Никто не спорит, что это есть, в примерах это тоже есть и я об этом написал.
Так же я написал почему это не стал использовать и почему это централизованный бэкап. При любом изменении вы будете на каждом микротике всё перенастраивать? Для моего скрипта разницы нет, какие там пароли на устройстве, — он авторизуется по ключу.
К тому же надо сервер FTP держать, а зачем?
Никто не спорит, что это есть, в примерах это тоже есть и я об этом написал.
Так же я написал почему это не стал использовать и почему это централизованный бэкап. При любом изменении вы будете на каждом микротике всё перенастраивать? Для моего скрипта разницы нет, какие там пароли на устройстве, — он авторизуется по ключу.
К тому же надо сервер FTP держать, а зачем?
на устройстве у вас тогда будет лежать скрипт с паролем в обычном тексте, который видно даже от аккаунта readonly. А FTP должен быть открыт и принимать соединения от кого попало по сути.
В моём решении достаточно чтобы устройство было доступно по ssh для создания и копирования бэкапа. Ничего городить и открывать не надо и пароли нигде не светятся.
В моём решении достаточно чтобы устройство было доступно по ssh для создания и копирования бэкапа. Ничего городить и открывать не надо и пароли нигде не светятся.
Sign up to leave a comment.
Централизованный бэкап Mikrotik устройств при помощи bash-скрипта