Резервное копирование 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. Так же вы можете смотреть разницу между прошлыми конфигами и видеть изменения. Полезно ежели с устройством работают несколько человек — все будут видеть изменения на почте и знать, что и как изменилось.

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

Учтите, что пароли, например, 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

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