Cómo saber si los respaldos de su empresa realmente funcionan
Un respaldo que nunca se ha restaurado es solo una suposición. Esta es la guía práctica para verificarlo.
El problema más común con los respaldos empresariales
Muchas empresas tienen algún sistema de respaldos en funcionamiento. El script de backup corre cada noche, el disco tiene suficiente espacio, el administrador recibe una notificación de éxito. Todo parece estar bien.
El problema es que "el script terminó exitosamente" no significa lo mismo que "los datos se pueden recuperar". Un respaldo puede completarse sin errores y aun así ser inútil cuando se necesite:
- —El archivo de respaldo se creó pero está corrupto o incompleto.
- —El respaldo incluye los archivos pero no la configuración del sistema.
- —La base de datos se respaldó mientras había transacciones activas, resultando en un estado inconsistente.
- —El proceso de restauración tarda 12 horas y nadie en la empresa sabe ejecutarlo.
- —Los respaldos están en el mismo servidor que los datos originales.
Las tres preguntas que debe poder responder hoy
1. ¿Cuándo fue la última vez que restauraron un respaldo en un ambiente de prueba?
Esta es la pregunta más importante. No "¿cuándo fue el último respaldo exitoso?" sino "¿cuándo fue la última vez que tomaron ese respaldo y lo restauraron completamente en otro servidor para verificar que funcionaba?"
Si la respuesta es "nunca" o "no recuerdo", su empresa no tiene respaldos: tiene archivos cuya utilidad es desconocida.
Frecuencia recomendada para pruebas de restauración:
- Sistemas críticos (base de datos de producción, ERP): mensual.
- Sistemas importantes (correo, archivos compartidos): trimestral.
- Sistemas secundarios: semestral.
- Ante cualquier cambio importante en la infraestructura: inmediato.
2. ¿Cuánto tiempo tomaría recuperar la operación ante un fallo completo?
El RTO (Recovery Time Objective) es el tiempo máximo aceptable de interrupción. Para definirlo, es necesario saber cuánto tiempo toma realmente la restauración, no cuánto tiempo debería tomar en teoría.
Un sistema que tiene respaldos nocturnos pero que tarda 8 horas en restaurarse necesita que alguien esté disponible a las 2 AM para completar la recuperación antes de que abra la empresa. ¿Eso está documentado? ¿Alguien sabe cómo hacerlo?
3. ¿Cuánto tiempo de datos puede perder si algo falla ahora mismo?
El RPO (Recovery Point Objective) es la cantidad máxima de datos que puede perder. Si sus respaldos son nocturnos, en el peor caso perderá un día entero de transacciones. ¿Eso es aceptable para su negocio?
Para bases de datos críticas, la solución es WAL archiving (en PostgreSQL) o binlog replication (en MySQL), que permiten recuperación a punto en el tiempo (PITR) con pérdida de datos de segundos o minutos, no horas.
Cómo hacer una prueba de restauración básica
Una prueba de restauración no requiere interrumpir la producción. Se puede hacer en paralelo:
- 01.
Prepare un entorno de prueba
Una máquina virtual o un servidor temporal. No tiene que ser idéntica en hardware, solo suficiente para correr los servicios.
- 02.
Tome el respaldo más reciente
No cree un respaldo especial para la prueba. Use exactamente el mismo respaldo que usaría en una emergencia real.
- 03.
Restaure siguiendo el procedimiento documentado
Si no tiene un procedimiento documentado, este es el momento para crearlo. Documente cada paso que realiza.
- 04.
Verifique que los datos sean correctos
No asuma que si el servicio arrancó los datos están bien. Ejecute consultas específicas para verificar integridad: fechas de transacciones recientes, registros específicos que sabe que deben existir.
- 05.
Mida el tiempo total
Desde el inicio de la restauración hasta que el sistema está operativo y verificado. Ese es su RTO real.
La regla 3-2-1 y por qué importa
La estrategia 3-2-1 es el estándar para respaldos confiables:
3
Tres copias
Los datos originales más dos copias de respaldo.
2
Dos medios
Al menos dos tipos de almacenamiento o dispositivos distintos.
1
Una copia fuera del sitio
Al menos una copia en una ubicación geográfica diferente.
La copia fuera del sitio es la más importante y la más frecuentemente omitida. Un incendio, una inundación o un ransomware que cifre todos los discos del servidor también afectará los respaldos que estén en el mismo lugar.
El monitoreo de respaldos es tan importante como los respaldos mismos
Un respaldo fallido que nadie detecta es peor que no tener respaldo: genera una falsa sensación de seguridad. El sistema de monitoreo de respaldos debe:
- —Alertar si un respaldo no se ejecutó en el tiempo esperado.
- —Alertar si el almacenamiento de respaldos está al 80% de capacidad.
- —Registrar el tamaño de cada respaldo (una reducción repentina puede indicar un problema).
- —Notificar al responsable correcto, no solo al servidor.
Servicios relacionados