O procedimento para copiar as configurações dos equipamentos Mikrotik de forma pontual é feito com um só comando, no entanto se você quiser fazer um backup fora do equipamento, de forma automatizada e rotineira será preciso um pouco mais de trabalho. Há várias outras formas de se chegar ao mesmo resultado, no entanto, o procedimento a seguir tem atendido bem para fazer o backup diário no meu RB750Gr3.
Backup local das configurações
Os dois comandos abaixo podem ser usados para se fazer o backup do Mikrotik:
/system backup save name=meubackup /export terse file=meubackup
O primeiro comando realiza um backup em formato exclusivo (chamado meubackup.backup) e que só poderá ser lido por outro Mikrotik e é ótimo para restaurar o sistema de um desastre como por exemplo a substituição da caixa após uma pane etc.
Já o segundo salva os comandos na forma como os digitamos no terminal, em um arquivo chamado meubackup.rsc, e é útil quando queremos comparar o que foi alterado na configuração de um dia para o outro e assim descobrir porque o equipamento deixou de fazer algo que estava OK até algum tempo antes.
O problema destes dois comandos como estão é que eles criarão os backups somente quando forem digitados (manualmente) e o arquivo de backup estará dentro da caixa, ou seja se o equipamento for danificado, você não terá backup para restaurar em outro equipamento.
Backup remoto
Para resolver o problema do backup dentro do roteador, a partir de uma máquina Linux padrão nós podemos usar o SSH para executar os comandos de backup e em seguida usar o SCP (SSH Copy) para copiá-los da caixa para a máquina.
Considerando então um roteador que responda na rede pelo nome “router.lan” e com um usuário chamado “admin”, poderíamos executar os seguintes comandos:
ssh admin@router.lan ' /system backup save name=meubackup /export terse file=meubackup ' scp admin@router.lan:meubackup.rsc admin@router.lan:meubackup.backup .
O que estou fazendo ai é enviando os comandos de backup do Mikrotik (aqueles que apresentei na primeira seção) via SSH, e em seguida usando o SCP para copiar os arquivos gerados para fora da caixa.
Por padrão o acesso ao SSH e ao SCP exigem que você informe a senha do usuário admin ou outro usuário que você indique (o que não é problema se você estiver fazendo isso manualmente, mas é péssimo se você quiser automatizar, o que é nosso caso, então antes de continuar dê uma lida neste artigo em que explico como criar e enviar seu certificado RSA para o Mikrotik.
Se estiver tudo certo, você já consegue acessar seu roteador por SSH, com toda a segurança, mas sem necessidade de digitar senha. Os comandos da seção “Backup remoto” devem ser executados imediatamente após serem digitados.
Juntando tudo
Para simplificar as coisas vamos juntar tudo o que comentamos antes em um único script. Então, usando um editor de textos de sua preferência crie um arquivo com o nome backup-mikrotik.sh e com o seguinte conteúdo:
#!/bin/bash
MK_ROUTER="router.lan"
MK_USER="admin"
DATA=$(date +%Y-%m-%d)
BKPDIR="${HOME}/backups/${MK_ROUTER}/${DATA}"
mkdir -p "${BKPDIR}"
cd "${BKPDIR}" || exit 1
MK="${MK_USER}@${MK_ROUTER}"
ssh ${MK} '
/system backup save name=meubackup
/export terse file=meubackup
'
scp ${MK}:meubackup.rsc ${MK}:meubackup.backup .
O arquivo pode ser salvo em qualquer diretório de sua preferência e ter permissão de execução (u+x). Ele faz exatamente o que comentei nas seções anteriores, só com o acréscimo de algumas variáveis, como por exemplo a estrutura de pastas onde o backup será salvo, para simplificar a manutenção e organização.
Como o SSH será autenticado usando a chave pública do meu usuário, eu particularmente mantenho o arquivo em uma pasta “bin” dentro do meu home, que é onde guardo todos os meus scripts e ferramentas personalizadas, mas é você quem decide. O diretório /usr/local/bin costuma ser um bom lugar para isso também.
Há três considerações importantes aqui para que o script funcione:
1 – Você já deve ter enviado o seu certificado de chave pública para o Mikrotik e já consiga acessar o seu roteador sem o pedido de senha;
2 – Uma vez que usamos a chave pública do nosso usuário local, o script só funcionará corretamente se for executado localmente com o nosso usuário. Não adianta executar como root ou outro usuário que não funcionará;
3 – Você deve ter salvo o arquivo em uma pasta que esteja em seu $PATH (o diretório /usr/local/bin é um bom lugar se quiser ficar pensando muito);
4 – Você deve ter usado o comando chmod e dado permissão de execução para o script.
Com isso feito, vamos fazer um teste com o script, digitando o seu nome como abaixo:
backup-mikrotik.sh
A saída do script deverá ser algo como o que segue abaixo
Configuration backup saved
meubackup.rsc 100% 11KB 4.2MB/s 00:00
meubackup.backup
Se não funcionar, verifique as considerações que comentei acima, veja se não houve nada colado errado no script.
Automatizando o backup
A automação será feita via “Cron Daemon”, que é o agendador de tarefas do Linux, mas primeiramente temos que criar um script que execute os comandos comentados antes de uma vez só.
Se o script já funcionou quando você rodou manualmente então ele deverá rodar de forma automática, também, desde que você atenda aos mesmos critérios.
Para simplificar a configuração do cron eu uso a seguinte linha de comandos:
echo '2 9 * * * wbraga /home/wbraga/bin/backup-mikrotik.sh' | sudo tee /etc/cron.d/backup-mikrotik
Este comando vai incluir uma tarefa agendada para as 9:02, todos os dias, que será executada pelo usuário “wbraga” (o meu usuário que tem a chave pública associada no Mikrotik) e que executa o script criado na seção anterior.
Ajuste o horário de sua preferência, o usuário, o caminho e nome do script e o execute. Um arquivo de tarefa chamado “backup-mikrotik” (sem extensão) será criado dentro de /etc/cron.d e seu backup será criado automaticamente no horário estipulado.
Se você tiver alguma determinação para que o backup seja criptografado, você terá algumas opções para isso.
Backup criptografado
Usando recursos apenas do Mikrotik é preciso lembrar que o comando “/export” não permite criptografar a sua saída, enquanto que o “/system backup save”, permite. Então se optar por esta alternativa você terá que abrir mão do dump da configuração.
Para que você possa manter ambos os formatos de backup e ainda assim tê-los criptografado, será preciso fazer a criptografia depois que os arquivos já estiverem em sua máquina (logo após o comando “scp”, no seu script). Ali então você já acrescenta um comando para criptografar os arquivos. Opções?
Comando zip, com uma senha estática definida no script
Apesar de usar uma senha esta é a opção mais insegura, já que a senha está guardada em modo texto puro dentro do seu script de backup, então qualquer pessoa que consiga ler o arquivo encontrará a senha para acessar seus backups. Se você conseguir lidar com isso de alguma forma, esta também é a forma mais simples de ter seus backups criptografados.
zip -P senha arquivo.zip meubackup.backup meubackup.rsc
Comando zip, informando a senha no momento do backup
Esta forma não é boa para automação, já que a senha deverá ser informada manualmente. Com um pouco de criatividade usando expect, e mais algumas ferramentas talvez se consiga um bom resultado.
zip -e arquivo.zip meubackup.backup meubackup.rsc
Comando gpg
Este é o método mais adequado que faz a criptografia usando um certificado de chave pública, até mesmo sem pedir a senha, mas há um esforço maior para sua configuração, já que depende do gpg-agent carregado, configuração de chaves padrão etc.
Como o tema é complexo e há um mundo de possibilidades para usá-lo, está fora do escopo discutir a sua configuração, mas se você souber lidar com isso é uma excelente alternativa
tar cf arquivo.tar meubackup.* gpg --encrypt arquivo.tar
Outros e finalizando
A partir daqui você já tem uma rotina de backup funcional para o seu Mikrotik e os incrementos ficam por conta da sua necessidade e criatividade. Daqui você pode enviar o arquivo para uma conta de e-mail para outra unidade, volume etc. Inclusive voltando a criptografia do backup uma última dica é que se pode simplesmente salvar os arquivos em um volume de disco já criptografado com LVM+LUKS, ou Veracrypt, Truecrypt etc, o que evitaria o problema de lidar com a senha do backup.