Backup Automático de MikroTik en la Nube: Guía Completa 2025

En 2023, un proveedor de internet perdió las configuraciones de 34 routers MikroTik en un único evento — una actualización de firmware que salió mal sin punto de restauración. El resultado: 3 días de equipo trabajando 12h/día para reconfigurar todo manualmente. Facturación comprometida, clientes cancelando.

El problema no era falta de experiencia técnica. Era falta de backup automático con versionado. En esta guía, entenderás los métodos disponibles y cómo implementar el más robusto para tu entorno.

Qué contiene el backup del RouterOS

El MikroTik ofrece dos formatos de backup:

• Backup binario (.backup): snapshot completo del sistema — toda la configuración, incluyendo contraseñas y certificados. La restauración es instantánea, pero no es legible como texto y está vinculado a la versión del RouterOS.
• Export (.rsc): archivo de texto con todos los comandos para recrear la configuración. Legible, versionable vía Git, portable entre versiones del RouterOS. Más flexible para auditoría.

Para backup de recuperación rápida en caso de fallo, el binario es más práctico. Para auditoría y versionado inteligente (ver exactamente qué cambió), el export es superior. Idealmente, querrás los dos.

Método 1 — Backup manual (no recomendado)

El enfoque más común en proveedores pequeños: el técnico accede a cada router vía Winbox o SSH y exporta la configuración cuando se acuerda.

Método 2 — Scheduler nativo del RouterOS

El RouterOS tiene un scheduler integrado que puede ejecutar scripts periódicamente. Es posible configurar un script que hace el export y lo envía vía FTP o e-mail.

Ejemplo de script de backup vía e-mail (RouterOS 7.x):

# Crear el 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"
  }

# Programar ejecución diaria a las 03:00
/system scheduler add \
  name="backup-scheduler" \
  start-time=03:00:00 \
  interval=1d \
  on-event="backup-diario"

Esto funciona para un router. Para 50 o 200, necesitas configurar ese script en cada equipo individualmente, gestionar las credenciales de e-mail en cada uno, y monitorear cuáles están enviando o no.

Limitaciones del scheduler nativo

• Sin versionado — cada backup sobreescribe el anterior o acumula archivos sin organización
• Sin alerta cuando un backup falla — solo lo descubres cuando necesitas restaurar
• No centraliza los backups en un repositorio único
• Configuración manual en cada router — inviable para flotas grandes
• Depende de que el e-mail del router esté configurado correctamente (SMTP, TLS, puerto)

Método 3 — Script externo vía SSH (intermedio)

Un servidor externo (VPS o máquina local) se conecta vía SSH a cada router, ejecuta el export y lo guarda localmente. Con cron en el 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

Mejor que el método anterior para centralización, pero aún requiere infraestructura propia, mantenimiento del script, gestión de claves SSH, y no resuelve el problema de routers detrás de CGNAT (sin IP pública accesible).

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

Una plataforma como Mikrosinc resuelve todos los problemas de los métodos anteriores de una vez:

• Backup automático de toda la flota sin configurar script en cada router
• Funciona con CGNAT — el agente establece un túnel de salida, sin necesidad de IP pública
• Versionado con diff — visualiza exactamente qué cambió entre dos backups
• Alertas inmediatos cuando un backup falla o cuando una configuración cambia inesperadamente
• Restauración en 1 clic — selecciona la versión deseada y aplica en el router remoto
• Historial auditable — quién hizo qué, cuándo

Qué considerar en la frecuencia de backup

La frecuencia ideal depende del ritmo de cambios en tu entorno:

• Diario (recomendado para producción): captura cambios del día a día sin sobrecargar
• Después de cada cambio manual: trigger por evento es lo ideal, pero requiere integración vía API
• Semanal: aceptable para routers de clientes sin cambios frecuentes

Lo importante es definir una política de retención: cuántas versiones guardar y por cuánto tiempo. Guardar 90 días de backups diarios es el mínimo razonable para proveedores con SLA de disponibilidad.

Resumen comparativo