Backing up Mikrotik to Subversion via SSH / SFTP

Introduction:

I will try to share my implementation of the backup of RouterOS configs in Subversion via SSH / SFTP.

My original post can be found on the Mikrotik forum: Backup Mikrotik config to Subversion / SVN repository via SSH

In local spaces, I have come across this approach: Centralized collection of configurations from MikroTik by means of Python , but the idea from ftp does not suit me.
')

About ROS backups:

If you need a complete copy of the ROS configuration, I advise you to have copies of the following:
1. Certificates installed in ROS (to be able to recover on a great platform)
2. Backup config ROS
3. Export config ROS (where you can always peek at what and how you are configured)

The essence of the idea:

Approved by analogy with our Linux servers. We / etc goes to Subversion, where we always get alerts about changes in configs, plus we always have a current reserve that can help out.
Inspired by ideas from the Mikrotik Wiki: Using SSH for system backup

Logics:

1. Making export to a local folder on Linux
2. Perform a comparison with the previous export
3. If there is a difference, we perform a backup (we will also execute export to the device file system)
4. Submit changes to SVN

Requirements:

1. ROS 5.15 with SSH enabled
2. Subversion
3. Linux with ssh, sftp, sshpass and svn client installed

Setup:

1. On the Linux server, we import the ROS public key into the known_hosts file from an account that will perform the backup task for the cron:

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

2. In ROS, we create a user who has the necessary rights to perform the actions we need, and tie him to the address of the server from which the backup task will be performed:

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. In SVN we create a directory for the device, I create it according to the device name:

 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. In Linux, create a directory for the working copy of SVN, I create according to the device name:

 mkdir -p /root/backup/trunk/usingw01/ 

5. In Linux, we create a working copy of the SVN from the folder where we will store our ROS files:

 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. In Linux, create a folder for the backup automation script:

 mkdir /root/backup_scripts 

7. In Linux, create a script:

 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. In Linux, create a cron task that will perform the backup:

 crontab -e 

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

Result:

Tomorrow morning you will receive a copy of the export and a full backup of your ROS config in SVN, in addition, they will be on the device for quick recovery.
You can also configure SVN-notify to receive notifications and diff about the changes made.
In SVN, you can always download the current version of backup and export. You can also see the difference between past configs and see the changes. It’s useful if several people work with the device - everyone will see the changes in the mail and know what has changed and how.

Security:

Note that passwords, for example, PPP in export are stored in clear text. For more security, you can use the key

 hide-sensitive 

when executing export, but this imposes its own limitations on the performance of backups. Those. you will not receive a backup when adding, for example, a user to PPP.
Well, just do not forget about the security of your SVN.

Limitations:

The script will not perform a backup if you add a system user. This is due to the fact that export does not export ROS accounts (for security purposes).
On this occasion, I wrote to the developers and asked them to add to the export information about when the config was last changed. To this I was told that something similar would be in version 5.12 - export compact, but this is not the case and for now these restrictions remain.

Used materials and useful links:

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

I hope the idea of ​​such an approach will be useful to someone.