Respaldos de servidores Linux: confirma que puedes restaurar

Un respaldo solo sirve si recupera el servicio

Un archivo de copia exitoso no demuestra por sí mismo que una empresa pueda recuperar su aplicación, configuración y datos. La verificación útil combina tres pasos: confirmar que la copia existe, revisar su integridad y restaurar una muestra en un destino separado.

Antes de elegir frecuencia, define con el responsable del servicio dos límites: el RPO, cuánto dato reciente se puede perder, y el RTO, cuánto tiempo puede tardar la recuperación. No hay valores universales: dependen del impacto, las dependencias y la capacidad operativa de cada empresa.

Haz inventario antes de copiar directorios

Identifica qué permite reconstruir la operación y quién valida cada elemento. Un inventario inicial puede incluir:

• Configuración: servicios, reglas de red, certificados y archivos de despliegue necesarios.
• Aplicación: código, artefactos, archivos cargados y datos que no pueden regenerarse.
• Datos: bases de datos, colas y archivos de negocio; confirma consistencia con el motor y la forma de escritura.
• Dependencias: versiones, paquetes, DNS, licencias y pasos de arranque que condicionan la recuperación.
• Secretos: conserva claves y credenciales en un almacén protegido, separado de las copias públicas o del repositorio de código.

No asumas que copiar en caliente el directorio de datos de una base produce una copia válida. Usa el mecanismo de respaldo del motor o una captura consistente y ensaya su restauración. Documenta exclusiones para evitar respaldar cachés, temporales o volúmenes que cambian mientras se copian.

Aísla las copias del servidor protegido

Si la copia solo está montada con permisos de escritura desde el mismo servidor, una intrusión o un error administrativo puede afectar producción y respaldo a la vez. CISA recomienda conservar copias offline y cifradas, y probar periódicamente su disponibilidad e integridad. Según el entorno, combina un destino remoto con controles que restrinjan quién puede borrar o modificar las copias.

Restic puede usar repositorios locales y remotos. Para SFTP, su documentación indica configurar primero el acceso SSH con clave pública y luego inicializar el repositorio. El siguiente fragmento es ilustrativo: cambia usuario, host, rutas, credenciales y fuentes tras validar el diseño en tu entorno.

restic -r sftp:backup@servidor-copias:/srv/restic/servidor01 init
restic -r sftp:backup@servidor-copias:/srv/restic/servidor01 backup /etc /srv/mi-aplicacion
restic -r sftp:backup@servidor-copias:/srv/restic/servidor01 snapshots

Protege la contraseña del repositorio con un gestor de secretos o un archivo de credenciales con permisos restrictivos; no la escribas en el comando ni la guardes junto a los datos que intentas recuperar. Restringe la identidad SFTP al destino necesario y conserva una vía de acceso de emergencia probada.

Verifica la copia sin sobrescribir producción

Lista snapshots, ejecuta la comprobación de integridad disponible y registra errores con fecha, host y copia afectada. Restic distingue la revisión del repositorio de la lectura completa de sus datos: restic checkrevisa estructura e índices; restic check --read-data también lee los datos y puede requerir más tiempo y transferencia.

Después restaura una snapshot a un directorio temporal o a una máquina de recuperación, nunca encima del servicio activo durante la primera prueba:

restic -r sftp:backup@servidor-copias:/srv/restic/servidor01 check
restic -r sftp:backup@servidor-copias:/srv/restic/servidor01 restore latest --target /tmp/restauracion-prueba

Comprueba permisos, propietarios, archivos esperados y consistencia de la aplicación. Para una base de datos, valida que los datos restaurados puedan abrirse con el procedimiento compatible con su versión. Guarda evidencia del resultado y corrige el runbook si la restauración necesitó pasos que no estaban documentados.

Programa el trabajo y alerta sobre fallas

Un timer o cron puede iniciar el respaldo, pero la programación no confirma que terminó bien. Evita ejecuciones simultáneas del mismo conjunto, conserva registros, alerta a una persona responsable cuando el proceso falla y revisa que la última copia esté dentro del RPO acordado. La política de retención debe responder a necesidades de recuperación y capacidad; no borres snapshots antiguas hasta comprender qué se elimina y verificar una restauración reciente.

1. Registra fuente, destino, frecuencia, retención y responsable.
2. Confirma cada ejecución y alerta si falta una snapshot esperada.
3. Revisa periódicamente integridad, espacio y acceso al destino remoto.
4. Restaura archivos y servicios de muestra en un entorno separado.
5. Actualiza el procedimiento tras cambios de sistema, rutas o dependencias.

Para inspeccionar recursos y servicios antes de definir alertas, consultamonitoreo de servidores Linux. Si una unidad no inicia, usa la guía dediagnóstico de systemd. Elaine System puede revisar el alcance de una estrategia deadministración de infraestructuracon contexto y límites acordados.

¿RAID sustituye un respaldo?

No. RAID puede ayudar a mantener disponibilidad ante ciertos fallos de disco, pero no conserva por sí solo versiones recuperables frente a borrados, corrupción lógica, credenciales comprometidas o errores de operación. Mantén copias separadas y prueba su restauración.

¿Cada cuánto se debe probar la restauración?

Define una frecuencia según RPO, RTO, cambios del sistema y riesgo del servicio. Al menos, repite la prueba cuando cambie el método de respaldo, el destino o una dependencia crítica. Una copia que nunca se restaura sigue siendo una hipótesis.