Backup Automático de MikroTik na Nuvem: Guia Completo 2025

Em 2023, um provedor de internet no interior de São Paulo perdeu as configurações de 34 roteadores MikroTik em um único evento — uma atualização de firmware que deu errado sem ponto de restauração. O resultado: 3 dias de equipe trabalhando 12h/dia para reconfigurar tudo manualmente. Faturamento comprometido, clientes cancelando.

O problema não era falta de experiência técnica. Era falta de backup automático com versionamento. Neste guia, você vai entender os métodos disponíveis e como implementar o mais robusto para seu ambiente.

O que o backup do RouterOS contém

O MikroTik oferece dois formatos de backup:

• Backup binário (.backup): snapshot completo do sistema — toda a configuração, incluindo senhas e certificados. Restauração é instantânea, mas não é legível como texto e está vinculado à versão do RouterOS.
• Export (.rsc): arquivo de texto com todos os comandos para recriar a configuração. Legível, versionável via Git, portável entre versões do RouterOS. Mais flexível para auditoria.

Para backup de recuperação rápida em caso de falha, o binário é mais prático. Para auditoria e versionamento inteligente (ver exatamente o que mudou), o export é superior. Idealmente, você quer os dois.

Método 1 — Backup manual (não recomendado)

A abordagem mais comum em provedores pequenos: o técnico acessa cada roteador via Winbox ou SSH e exporta a configuração quando lembra.

Método 2 — Scheduler nativo do RouterOS

O RouterOS tem um scheduler integrado que pode executar scripts periodicamente. É possível configurar um script que faz o export e envia via FTP ou e-mail.

Exemplo de script de backup via e-mail (RouterOS 7.x):

# Criar o script de backup
/system script add \
  name="backup-diario" \
  source={
    /export file="backup-$[/system identity get name]-$[/system clock get date]";
    /tool e-mail send \
      to="noc@seuprovedor.com.br" \
      subject="Backup $[/system identity get name]" \
      file="backup-$[/system identity get name]-$[/system clock get date].rsc"
  }

# Agendar execução diária às 03:00
/system scheduler add \
  name="backup-scheduler" \
  start-time=03:00:00 \
  interval=1d \
  on-event="backup-diario"

Isso funciona para um roteador. Para 50 ou 200, você precisa configurar esse script em cada equipamento individualmente, gerenciar as credenciais de e-mail em cada um, e monitorar quais estão enviando ou não.

Limitações do scheduler nativo

• Sem versionamento — cada backup sobrescreve o anterior ou acumula arquivos sem organização
• Sem alerta quando um backup falha — você só descobre quando precisa restaurar
• Não centraliza os backups em um repositório único
• Configuração manual em cada roteador — inviável para frotas grandes
• Depende do e-mail do roteador estar configurado corretamente (SMTP, TLS, porta)

Método 3 — Script externo via SSH (intermediário)

Um servidor externo (VPS ou máquina local) conecta via SSH em cada roteador, executa o export e salva localmente. Com cron no servidor:

#!/bin/bash — backup_mikrotik.sh
ROUTERS=("192.168.1.1" "192.168.1.2" "192.168.1.3")
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/opt/backups/mikrotik/$DATE"
mkdir -p $BACKUP_DIR

for ROUTER in "${ROUTERS[@]}"; do
  ssh -o StrictHostKeyChecking=no \
    admin@$ROUTER \
    "/export" > $BACKUP_DIR/$ROUTER.rsc 2>/dev/null
done

Melhor que o método anterior para centralização, mas ainda exige infraestrutura própria, manutenção do script, gestão de chaves SSH, e não resolve o problema de roteadores atrás de CGNAT (sem IP público acessível).

Método 4 — Plataforma NOC SaaS com backup integrado (recomendado)

Uma plataforma como o Mikrosinc resolve todos os problemas dos métodos anteriores de uma vez:

• Backup automático de toda a frota sem configurar script em cada roteador
• Funciona com CGNAT — o agente estabelece um túnel de saída, sem necessidade de IP público
• Versionamento com diff — visualize exatamente o que mudou entre dois backups
• Alertas imediatos quando um backup falha ou quando uma configuração muda inesperadamente
• Restauração em 1 clique — seleciona a versão desejada e aplica no roteador remoto
• Histórico auditável — quem fez o que, quando

O que considerar na frequência de backup

A frequência ideal depende do ritmo de mudanças no seu ambiente:

• Diário (recomendado para produção): captura mudanças do dia a dia sem sobrecarregar
• Após cada mudança manual: trigger por evento é o ideal, mas exige integração via API
• Semanal: aceitável para roteadores de clientes sem mudanças frequentes

O importante é definir uma política de retenção: quantas versões guardar e por quanto tempo. Guardar 90 dias de backups diários é o mínimo razoável para provedores com SLA de disponibilidade.

Resumo comparativo