Резервное копирование Mikrotik в Subversion посредством SSH/SFTP

Вступление:



Попробую поделиться своей реализацией резервного копирования конфигов RouterOS в Subversion посредством SSH/SFTP.

Мой оригинальный пост можно найти на форуме Mikrotik: Backup Mikrotik config to Subversion/SVN repository via SSH

На местных просторах я встречал вот такой подход: Централизованный сбор конфигураций с MikroTik'ов средствами Python, но идея с ftp мне не подходит.

Про бэкапы ROS:


Ежели вам нужна полная копия конфигурации ROS, я советую иметь копии следующего:
1. Сертификатов установленных в ROS(для возможности восстановления на отличной платформе)
2. Backup конфига ROS
3. Export конфига ROS(где вы всегда сможете подсмотреть что и как у вас настроенно)

Суть идеи:


Подошёл по аналогии с нашими Linux серверами. У нас /etc уходит в Subversion, где мы всегда получаем оповещения об изменениях в конфигах, плюс у нас всегда есть актуальный резерв, который может выручить.
Вдохновился идей из Mikrotik Wiki:Using SSH for system backup

Логика:


1. Делаем export в локальную папку на Linux
2. Выполняем сравнение с предыдущим export
3. Если есть разница, то выполняем backup(так же выполним export на файловую систему устройства)
4. Отправляем изменения в SVN

Требования:


1. ROS 5.15 с включённым SSH
2. Subversion
3. Linux c установленным ssh, sftp, sshpass и svn клиентом

Настройка:


1. На Linux сервере импортируем публичный ключ ROS в known_hosts файл из под учётной записи, которая будет выполнять сron задачу резервного копирования:

ssh-keyscan -v -p 22 -t dsa 192.168.0.1 >> ~/.ssh/known_hosts


2. В ROS создаём пользователя, у которого будут необходимые права для выполнения необходимых нам действий, и привяжем его к адресу сервера, с которого будет выполняться задача резервного копирования:

export = ssh, ftp,read, sniff
backup = ssh, test, policy
get export via sftp = ssh, ftp
get backup via sftp = ssh, ftp, sensitive


/user group add name=backup policy=ssh,ftp,read,sniff,test,policy,sensitive
/user add name=backuper password="password" group=backup address=192.168.0.2 disabled=no


3. В SVN создаём директорию для устройства, я создаю согласно имени устройства:
svn mkdir --parents https://svn.domain.com/svn/admin/trunk/usingw01 --no-auth-cache --username user --password '*****' --message "Created empty directory for usingw01 - `date +"%Y-%m-%d %H:%M:%S"`"


4. В Linux создаём директорию для рабочей копии SVN, я создаю согласно имени устройства:
mkdir -p /root/backup/trunk/usingw01/


5. В Linux cоздаём рабочую копию SVN из папки, в которой у нас будут храниться файлы нашей ROS:
cd /root/backup/trunk/usingw01
svn checkout https://svn.domain.com/svn/admin/trunk/usingw01 . --trust-server-cert --non-interactive --no-auth-cache --username usingw01 --password 'svnpassword'


6. В Linux создаём папку для скрипта автоматизации резервного копирования:
mkdir /root/backup_scripts


7. В Linux создаём скрипт:
vi /root/backup_scripts/backup_usingw01_to_svn.sh


#!/bin/sh
#
routername="usingw01"
sshhost="192.168.0.1"
sshport="22"
sshuser="backuper"
sshpassword="password"
svnlocalpath="/root/backup/trunk/$routername"
svnusername="usingw01"
svnpassword="svnpassword"
current_export_name="$routername-config-export-current.rsc"
precedent_export_name="$routername-config-export-precedent.rsc"
current_backup_name="$routername-config-backup-current.backup"
#
#
sshpass -p $sshpassword ssh $sshuser@$sshhost -p $sshport export >$current_export_name
diff -I "by Router" $current_export_name $svnlocalpath/$precedent_export_name
#
if [ "$?" -ne "0" ]; then
sshpass -p $sshpassword ssh $sshuser@$sshhost -p $sshport export file=$current_export_name
sshpass -p $sshpassword ssh $sshuser@$sshhost -p $sshport system backup save name=$current_backup_name
sshpass -p $sshpassword sftp -oPort=$sshport $sshuser@$sshhost:$current_backup_name
#
mv -f $current_export_name $svnlocalpath/
mv -f $current_backup_name $svnlocalpath/
rm -f $svnlocalpath/$precedent_export_name
svn add --force $svnlocalpath/$current_export_name
svn add --force $svnlocalpath/$current_backup_name
svn commit $svnlocalpath --trust-server-cert --non-interactive --no-auth-cache --username $svnusername --password $svnpassword --message "Automated commit of $routername at `date +"%Y-%m-%d %H:%M:%S"`"
#
mv -f $svnlocalpath/$current_export_name $svnlocalpath/$precedent_export_name
exit 1
#
#
fi
mv -f $current_export_name $svnlocalpath/$precedent_export_name
exit 0
#


8. В Linux cоздаём cron задачу, которая будет выполнять резервное копирование:
crontab -e

00 04 * * * sh /root/backup_scripts/backup_usingw01_to_svn.sh


Результат:


Завтра утром вы получите копию экспорта и полного бэкапа своего конфига ROS в SVN, кроме того они будут находиться на устройстве для быстрого восстановления.
Вы так же можете настроить SVN-notify для получения уведомлений и diff о произведённых изменениях.
В SVN вы всегда можете скачать актуальную версию backup и export. Так же вы можете смотреть разницу между прошлыми конфигами и видеть изменения. Полезно ежели с устройством работают несколько человек — все будут видеть изменения на почте и знать, что и как изменилось.
image

Безопасность:


Учтите, что пароли, например, PPP в export хранятся в открытом виде. Для большей безопасности вы можете воспользоваться ключём
hide-sensitive
при выполнении export, но это накладывает свои ограничения на выполнение резервных копий. Т.е. вы не будет получать резервную копию при добавлении, например, пользователя в PPP.
Ну и так же не забываем про безопасность своего SVN.

Ограничения:


Скрипт не выполнит резервного копирования ежели вы добавите системного пользователя. Связанно это с тем, что export не выполняет экспортирование учётных записей ROS(в целях безопасности).
По этому поводу я писал разработчикам и просил их добавить в export информацию о том, когда был в последний раз изменён конфиг. На это мне ответили, что что-то похожее будет в версии 5.12 — export compact, но это есть не то и пока эти ограничения остаются.

Использованные материалы и полезные ссылки:


1. Manual:Configuration Management
2. Difference between backup and export-how to monitor changes
3. Backup and Restore Certificates
4. remote creating backup-file

Надеюсь идея такого подхода будет кому-нибудь полезна.
Поделиться публикацией

Комментарии 11

    –2
    Используйте кат пожалуйста
    <habracut>
    Используется только в текстах постов, скрывает под кат часть текста, следующую за тегом (будет написано «Читать дальше»).
    <habracut text="Подробности" />
    Так можно превратить надпись «Читать дальше» в любой текст.
      +1
      Спасибо, подправил.
      В момент черновика использовал
      <habracut/>
      В тематическом хабе он что-то не заработал.
      0
      1. Сертификатов установленных в ROS(backup нам этого не даст)

      Разве? В виде файлов сертификаты как-раз останутся, только их придется заново импортировать и потеряются их имена.
        0
        Разве? В виде файлов сертификаты как-раз останутся, только их придется заново импортировать и потеряются их имена.

        Это скопировать файлы сертификатов на рутер и выполнить import + decrypt?
          0
          Да, именно так.
          В вашем способе я правда не заметил чтобы отдельным образом сохранялись сертификаты или проглядел между строк?
            +2
            Да, я лишь посоветовал подумать о копии сертификатов.
            У меня они все в отдельном месте пока(от всего).
            Можно их положить рядом с конфигами на SVN. Я об этом давно думаю, но пока не сделанно. Но вообще хорошо в одном месте иметь полность готовую конфигурацию, т.е. вместе с сертификатами.
            0
            Точнее после выполнение restore с файлом .backup сертификаты уже будут лежать в виде файлов и после этого можно делать import + decrypt, отдельно выдергивать сертификаты в виде файлов не нужно.
              0
              Точнее после выполнение restore с файлом .backup сертификаты уже будут лежать в виде файлов и после этого можно делать import + decrypt, отдельно выдергивать сертификаты в виде файлов не нужно.

              Верное ли я вас понимаю?
              1. У вас на рутере есть 2 файла сертификатов, их можно увидеть по file print
              2. Вы далеате backup
              3. Удаляете эти 2 файла сертификатов
              4. Выполняете restore
              5. После restore вы хотите увидеть по file print снова 2 сових файла сертификатов, которые можно будет импортнуть?
                0
                Прошу прощения, перепутал — увидеть сертификаты можно будет по certificate print и имена у них останутся прежние.
          +1
          Ссылка #3 из материалов, там как раз и обсуждался похожий момент.
          У меня были сложности с восстановлением сертификатов на RB1200 после восстановления из backup.
          Удалил сертификаты, скопировал файлы, выполнил import + decrypt.
          Всё заработало. Это было во времена ROS 5.10.

          Сейчас же проверил на RB751+ROS 5.15:
          После восстановленния из backup сертификат поднялся и заработал. На этом можно и остановиться, если не предпологать перенос конфигурации на другую платформу.
          Подправлю ка я:
          backup нам этого не даст
          на
          для возможности восстановления на отличной платформе

          Спасибо.
            0
            Подправил немного скриптик бэкапа, теперь он почём зря не дёргает локальный диск устройства.
            Export происходит в файл на Linux и только ежели есть разница происходит создание файлов на диске устройства.
            Потихоньку мучаю суппорт своими пожеланиями:

            ciscoasa5510# sh startup-config
            : Saved
            : Written by admin at 15:34:33.914 EDT Wed May 23 2012


            Это то чего сейчас нехватает для эффективного резервного копирования конфигурации ROS приведённым методом.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое