Disaster Recovery

Recuperación ante desastres

Resumen

Esta guía de estudio independiente explica cómo planificar la recuperación de un sistema Linux, ejecutar respaldos y comprobar que restauran. Un respaldo no es un archivo que existe: es una copia cuya restauración se ha probado. La planificación identifica servicios críticos e interrupción tolerable. Las herramientas cambian; el método y la verificación permanecen.

No es material oficial ni está afiliada a la Linux Foundation.

Objetivos de aprendizaje

• Distinguir recuperación, continuidad y alta disponibilidad.
• Definir RTO y RPO según el servicio.
• Elegir respaldo completo, incremental o diferencial.
• Crear y restaurar copias con tar, rsync y rsnapshot.
• Diseñar un plan con responsables, ubicaciones y pruebas.

Prerrequisitos y conexiones

Se asume experiencia con archivos, permisos y servicios; repasa Administración de sistemas y Mejores prácticas. Se apoya en Resolución de problemas para diagnosticar por qué falló la recuperación.

Conceptos: continuidad, RTO y RPO

La continuidad busca mantener los servicios críticos durante una interrupción; la recuperación ante desastres se centra en restaurarlos tras un evento grave. La alta disponibilidad reduce la probabilidad de interrupción con redundancia, pero no sustituye un plan de recuperación. Un clúster puede mantener el servicio y, aun así, no proteger contra un borrado lógico replicado a todos los nodos.

El RTO (Recovery Time Objective) es el tiempo máximo para restaurar un servicio. El RPO (Recovery Point Objective) es la pérdida máxima de datos. Ambos derivan de un análisis de impacto: qué proceso se detiene, qué obligación se afecta y qué alternativa existe. No se eligen por comodidad: un RPO de una hora exige copias con esa frecuencia, y un RTO corto, procedimientos probados.

El análisis de impacto identifica dependencias: base de datos, almacenamiento, DNS, autenticación, red y proveedores. Restaurar un servidor web sin su base de datos no recupera el servicio. El plan ordena por dependencias y distingue lo esencial de lo que puede esperar. NIST SP 800-34 describe la planificación de contingencia como un ciclo de desarrollo, implementación, pruebas y mantenimiento; el documento se actualiza con la infraestructura.

RTO y RPO con consecuencias operativas

Los dos objetivos solo valen cuando se traducen en decisiones de ingeniería. La tabla siguiente recoge valores ilustrativos para servicios de distinta criticidad; las cifras concretas las fija el negocio, pero la relación entre plazo y diseño se repite en todos los casos.

Servicio de ejemplo	RTO	RPO	Consecuencia de diseño
Portal corporativo de solo lectura	8 horas	24 horas	Copia nocturna y procedimiento escrito
Tienda en línea	1 hora	15 minutos	Copias cada quince minutos o replicación
Base de datos transaccional	15 minutos	5 minutos	Volcado muy frecuente o réplica ya preparada
Directorio de autenticación	2 horas	30 minutos	Orden de restauración y pruebas periódicas

El RTO no equivale al tiempo de transferencia: incluye detectar el incidente, decidir, localizar el punto de restauración, ejecutarla y comprobar que el servicio responde. Una recuperación técnica de veinte minutos que se detecta una hora después ya incumple un objetivo de treinta minutos. La pérdida real se cuenta desde la última copia válida hasta el momento del corte: con una copia de las 02:00 y un fallo a las 09:00 se pierden siete horas, aunque la política diga únicamente "diario".

Un plazo corto también condiciona lo que debe existir antes del incidente: un sistema base preparado, el software instalado por adelantado y credenciales accesibles de noche o en festivo. Si el análisis de impacto concluye que un objetivo no es alcanzable con los recursos actuales, conviene declararlo y aceptarlo por escrito; un objetivo incumplible y no comunicado equivale a no tener ninguno.

Estrategias de respaldo

Un respaldo completo copia todos los datos seleccionados y permite restaurar sin depender de otros archivos. Un incremental copia lo cambiado desde el último respaldo de cualquier tipo; restaurar exige la cadena completa. Un diferencial copia lo cambiado desde el último completo; restaurar requiere el completo y el último diferencial. Los incrementales ahorran espacio y tiempo, pero complican la restauración; los completos la simplifican a costa de más almacenamiento.

La regla 3-2-1 resume una práctica habitual: tres copias, en dos tipos de medio, con una fuera del sitio. No es una garantía ni un requisito legal universal, pero separa el respaldo del sistema protegido. Una copia en el mismo volumen, servidor o centro de datos no sobrevive a la pérdida de ese soporte. La copia externa debe protegerse con cifrado y control de acceso, porque contiene información sensible.

La retención define cuánto se conservan las copias y cómo se rotan. Debe cubrir los casos previstos, incluidos errores detectados tarde; conservar solo la última impide volver atrás. Documenta qué se copia, qué se excluye, dónde se guarda, quién accede, cómo se cifra y cuándo se destruye. Para bases de datos, coordina con el motor: copiar archivos abiertos sin consistencia puede producir una restauración inválida.

Tipos de respaldo vistos desde la restauración

La descripción de cada tipo cambia según se mire desde la creación de la copia o desde su recuperación; la tabla resume el segundo punto de vista con criterios de decisión.

Tipo	Piezas para restaurar	Riesgo dominante	Cuándo convence
Completo	Un solo archivo o árbol	Ventana de copia prolongada	Volúmenes pequeños y puntos de recuperación esporádicos
Incremental	El completo y toda la cadena hasta el punto buscado	Un eslabón extraviado deja inutilizables los posteriores	Datos grandes que cambian poco entre ejecuciones
Diferencial	El completo y el último diferencial	La pieza diaria crece hasta acercarse al completo	Cadenas cortas donde el espacio extra resulta asumible

Un esquema semanal con completo el domingo e incrementales de lunes a sábado produce siete piezas; recuperar el estado del viernes exige el completo y los cinco incrementales previos, y si uno desaparece, los posteriores ya no reconstruyen ese instante. Con diferenciales diarios bastarían el completo del domingo y el diferencial del viernes, a cambio de piezas que crecen cada día. La elección se decide mirando la restauración, no la duración del trabajo nocturno.

tar, rsync y rsnapshot

tar empaqueta archivos y conserva rutas, permisos y propietarios. tar -czf /backup/etc-2026-10-21.tar.gz -C / etc crea una copia comprimida de /etc sin ruta absoluta, lo que facilita restaurar en otra ubicación. tar -tzf lista sin extraer y tar -xzf ... -C /restore restaura bajo /restore. Para ACL, atributos extendidos y SELinux, considera --acls, --xattrs y --selinux; su disponibilidad depende de la implementación.

sudo tar -czf /backup/etc-2026-10-21.tar.gz -C / etc
tar -tzf /backup/etc-2026-10-21.tar.gz | head
sudo tar -xzf /backup/etc-2026-10-21.tar.gz -C /restore

rsync sincroniza árboles de forma incremental. rsync -aAXH --delete /srv/ backup@host:/backup/srv/ conserva permisos, ACL, atributos y enlaces duros, y elimina en destino lo que ya no existe en origen. --delete convierte el destino en espejo: si el origen está incompleto, el destino también. Ejecuta --dry-run y revisa la lista. -e ssh usa SSH y --numeric-ids evita depender de usuarios locales.

rsync -aAXH --dry-run --delete /srv/ backup@host:/backup/srv/
rsync -aAXH --delete /srv/ backup@host:/backup/srv/
rsync -aAXH --link-dest=/backup/srv/2026-10-20 /srv/ /backup/srv/2026-10-21/

rsnapshot automatiza copias con rsync y enlaces duros. Los archivos sin cambios comparten bloques entre instantáneas, así que una copia diaria no duplica todo. /etc/rsnapshot.conf define snapshot_root, directorios y políticas retain. rsnapshot configtest valida la sintaxis y rsnapshot daily ejecuta la copia. Los enlaces duros solo funcionan dentro del mismo sistema de archivos; no sustituyen una copia externa.

Herramientas frente a escenarios

Cada herramienta resuelve un problema distinto y ninguna cubre sola el ciclo completo; elegir la primera solución por costumbre obliga a rehacer el esquema cuando cambia el requisito.

Herramienta	Resultado que deja	Escenario adecuado	Aspecto que debe cubrir otro mecanismo
tar	Un archivo único con la selección	Sacar /etc del host o versionar una configuración	No conserva por sí solo varios puntos en el tiempo
rsync	Un árbol alineado con el origen	Mantener un espejo actualizado de /srv	El histórico depende de una estrategia externa
rsnapshot	Varios puntos del mismo árbol con enlaces duros	Histórico diario y semanal en un único sistema de archivos	La programación depende de cron o de otro planificador
Instantánea de volumen	Imagen de bloques de un instante	Recuperar aplicación y base de datos en consistencia	La retención larga necesita otra copia en otro soporte
Volcado del motor	Versión portable de los datos	Restaurar en otra versión o instalar en un equipo distinto	No incluye ficheros, permisos ni configuración del sistema

rsync --link-dest permite prescindir de rsnapshot cuando el histórico vive en un sistema de archivos: la ejecución compara con una instantánea anterior y enlaza los archivos que no cambiaron, de modo que cada directorio de fecha solo consume espacio por las diferencias. La comodidad tiene un límite práctico: si ese histórico se copia a otro soporte sin conservar los enlaces, cada punto se materializa por separado y el espacio se multiplica.

Verificación de integridad de cada copia

Una tarea programada que termina sin código de error no prueba que el contenido sea legible. La verificación se separa en tres comprobaciones: que el fichero exista y esté completo, que siga coincidiendo con el origen y que una restauración parcial funcione.

Al crear la copia, calcula una suma de digest junto al archivo y comprueba después:

sha256sum /backup/etc-2026-10-23.tar.gz > /backup/etc-2026-10-23.tar.gz.sha256
sha256sum -c /backup/etc-2026-10-23.tar.gz.sha256

La salida confirma OK cuando el fichero no ha cambiado desde que se generó la suma. Para un archivo comprimido, el listado de contenidos es la segunda comprobación: tar -tzf /backup/etc-2026-10-23.tar.gz | wc -l devuelve el número de entradas y un final truncado se manifiesta como un error de lectura al terminar el listado. Contrastar esa cifra con el origen mediante find /etc -xdev | wc -l orienta sobre si la selección sigue siendo la esperada, sabiendo que las dos cifras no tienen por qué coincidir cuando hay exclusiones.

La tercera comprobación necesita restaurar: extrae el archivo en un directorio temporal, revisa una muestra de ficheros con sus permisos y fechas, y descarta el directorio. Automatizar las tres y alertar cuando alguna falle convierte la verificación en parte de la tarea; una copia incompleta que nadie mira solo se descubre el día que hace falta.

Copias de bases de datos

Copiar los ficheros de una base en funcionamiento produce restauraciones dudosas porque el motor escribe de forma continua. La alternativa habitual es el volcado lógico, que genera un fichero portable con datos y estructura sin importar cómo organiza el motor sus páginas internas.

pg_dump -Fc tienda -f tienda.dump crea un volcado en formato comprimido que se recupera con pg_restore -d tienda tienda.dump, y mysqldump --single-transaction tienda > tienda.sql lee una instantánea consistente sin bloquear las tablas de InnoDB durante la ejecución. Ambos se pueden programar con separación de la copia de ficheros, porque el orden importa: la secuencia entre datos y sistema de archivos debe estar definida y probada, no improvisada la noche del incidente.

La verificación de este tipo de copias exige restaurar en una instancia aparte y ejecutar consultas de conteo o una prueba de lectura real. Un fichero que crece y empieza por la sentencia correcta no demuestra que las transacciones estén completas hasta que alguien lo restaura. Si el volumen impide un volcado completo frecuente, conviene separar las tablas grandes o documentar en el plan la frecuencia realmente alcanzable.

Modos de fallo de un respaldo

Los problemas más costosos aparecen mucho antes del incidente, cuando nadie mira la tarea. Enumerarlos permite diseñar su detección junto con la propia copia.

• Cadena incompleta: falta un eslabón y los puntos posteriores no se pueden restaurar; la detección pasa por inventariar la serie completa tras cada ejecución.
• Fichero truncado: la transferencia se interrumpe y el archivo termina antes de tiempo, y el listado con tar -tzf falla en la última entrada.
• Tarea que falla en silencio: caducó la credencial o se agotó la cuota del destino y nadie lee la salida; obliga a alertar sobre el resultado, no solo sobre el calendario.
• Nombre fijo en cada ejecución: el fichero anterior se sobrescribe y solo queda un punto en el tiempo, con lo que la retención declarada no se cumple.
• Clave de cifrado perdida o rotada: el dato existe pero no se puede abrir; custodiar la clave fuera del mismo almacén y probar su uso pertenece a la verificación.
• Destino sin espacio: la copia deja de crecer mientras el origen sigue cambiando y df -h en el destino explica la mayoría de estos casos.

Plan de recuperación y pruebas

Un plan útil es un documento operativo: alcance, servicios críticos, RTO y RPO, inventario, ubicación de copias, accesos, orden de restauración, responsables, contactos y criterios de éxito. Debe indicar cómo obtener una copia si falla la red habitual y cómo evitar restaurar datos contaminados. Los procedimientos se escriben para otra persona.

El plan también depende de credenciales que alguien tendrá que recuperar a las tres de la mañana: claves SSH, contraseñas del almacén, códigos de la consola del proveedor y la clave de cifrado de las propias copias. Anotar dónde se custodia cada una, quién puede entregarlas y qué ocurre si esa persona no está disponible evita que la recuperación se detenga en la primera pantalla de acceso.

La prueba de restauración convierte el plan en evidencia. Restaura en un entorno aislado con los pasos de producción y mide el tiempo. Verifica archivos, permisos, servicios y consultas de negocio. tar -tzf y rsync --dry-run detectan problemas de estructura, pero no demuestran que la aplicación funcione. Programa pruebas y registra el resultado; una prueba fallida debe generar una acción correctiva.

Las copias deben protegerse contra modificaciones. Si un atacante compromete el servidor y la cuenta de respaldo, puede borrar ambas. Usa cuentas distintas, almacenamiento inmutable y copias offline. RAID no es un respaldo: si se borra un archivo, el borrado se replica en el arreglo. Las instantáneas tampoco sustituyen una copia externa si dependen del mismo dispositivo.

Ejemplos prácticos

Una empresa debe recuperar la configuración de un servidor tras un cambio defectuoso. Antes de cambiarlo, copia /etc con tar, guarda el archivo fuera del host y anota la fecha. Cuando falla, extrae en /restore, compara con rsync --dry-run y restaura solo los archivos afectados. Después valida con la herramienta del servicio y reinicia de forma controlada. La copia permite volver atrás sin reconstruir el sistema.

Para datos compartidos, el equipo configura rsnapshot con copias diarias y semanales en un servidor distinto. Los archivos sin cambios se enlazan y la retención conserva varios puntos en el tiempo. Cada trimestre se restaura una copia en prueba y se comprueban permisos y archivos esperados. El informe se archiva; si falla, se corrige antes del siguiente ciclo.

Un servidor de correo se pierde por fallo de su disco y hay que reconstruirlo en otra máquina. El equipo instala el sistema base, recupera la configuración de /etc desde la copia, restaura los buzones en el orden fijado en el plan y comprueba el envío y la recepción antes de abrir el servicio. La dirección y el registro DNS se actualizan en la ventana previa, y el tiempo total se mide desde la alerta inicial; comparado con el RTO declarado, la prueba revela doce minutos que el plan no contemplaba, así que se corrige el documento y se retiran los pasos que no aportan.

Errores frecuentes

• Guardar el respaldo en el mismo disco o servidor protegido.
• No probar la restauración y descubrir el fallo en el incidente.
• Usar rsync --delete sin revisar el origen.
• Copiar bases de datos abiertas sin coordinación con el motor.
• Ignorar permisos, ACL o SELinux al restaurar.
• Confundir RAID o una instantánea local con un respaldo.
• Conservar solo la última copia.
• Cambiar la ruta o la credencial de la tarea sin actualizar el plan ni las alertas asociadas.

Puntos clave para el examen

• RTO es el tiempo de recuperación; RPO, la pérdida máxima tolerable.
• Completo, incremental y diferencial difieren en qué copian y qué exige restaurar.
• tar empaqueta, rsync sincroniza y rsnapshot organiza copias con enlaces duros.
• La copia debe estar separada del origen, protegida y verificada.
• RAID e instantáneas no sustituyen un respaldo.
• Un plan sin prueba de restauración es una hipótesis, no una capacidad.
• El RTO incluye detección, decisión, restauración y validación; el RPO se cuenta desde la última copia válida.
• Una suma sha256 y un listado completo convierten la comprobación de la copia en una rutina automática.
• El volcado de la base de datos deja fuera ficheros, permisos y configuración del sistema.
• Cada ejecución debe crear un punto con nombre único; sobrescribir deja un solo instante recuperable.
• La custodia de claves y credenciales forma parte del plan, no de la improvisación del incidente.

Recursos externos

• tar(1)
• rsync(1)
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
• rsnapshot
• sha256sum(1)
• pg_dump

Autoevaluación

1. ¿Qué diferencia hay entre RTO y RPO? Respuesta: El RTO mide cuánto puede tardar la recuperación; el RPO, cuántos datos se pueden perder. Ambos se definen desde el impacto del servicio.

2. ¿Qué necesita una restauración a partir de incrementales? Respuesta: El completo inicial y toda la cadena de incrementales hasta el punto deseado. Perder un eslabón impide restaurar ese estado.

3. ¿Por qué rsync --delete exige precaución? Respuesta: Porque convierte el destino en espejo del origen y elimina lo que ya no está allí. Un origen incompleto propaga la pérdida.

4. ¿Qué ventaja aporta rsnapshot frente a copias completas diarias? Respuesta: Usa enlaces duros para compartir archivos sin cambios, conservando varios puntos en el tiempo con menos espacio. Aún necesita una copia externa.

5. ¿Por qué RAID no es un respaldo? Respuesta: Porque protege contra el fallo de un disco, pero replica borrados, corrupción o ransomware. El respaldo debe ser una copia separada y restaurable.

6. ¿Qué compone el RTO además del tiempo de transferencia? Respuesta: La detección, la decisión, la localización del punto, la restauración y la validación del servicio; cada tramo consumido reduce el margen real.

7. ¿Cómo se detecta una copia truncada antes de necesitarla? Respuesta: Listando su contenido con tar -tzf, porque un final corto aparece como un error de lectura al terminar el listado, y contrastando la suma sha256 guardada junto al archivo.

8. ¿Qué cubre un volcado de base de datos y qué deja fuera? Respuesta: Datos y estructura en formato portable, apto para restaurar en otra versión; deja fuera los ficheros del sistema, los permisos y la configuración del servicio.

9. ¿Qué problema práctico tiene dar siempre el mismo nombre al archivo de respaldo? Respuesta: Que cada ejecución sobrescribe la anterior y solo queda un punto en el tiempo, con lo que la retención declarada no se cumple en la práctica.