Cerramos el módulo con la lección que convierte a Rutas Norte en una plataforma en la que se puede confiar. Ya tenemos los datos fuera del contenedor, en un volumen que sobrevive al pod, expandible y con snapshots. Pero la lección anterior terminó con una advertencia que lo relativiza todo: un snapshot vive en el mismo sistema de almacenamiento que el original, así que no sobrevive a la pérdida de una zona, al borrado de una cuenta ni a una corrupción descubierta tres semanas tarde. Una copia de seguridad de verdad es otra cosa: sale del clúster, va a un sistema independiente, incluye también los objetos de la API, se coordina con la aplicación para ser consistente, tiene retención definida y —esto es lo único innegociable— se prueba restaurándola. En esta lección construirás las dos piezas que Rutas Norte necesita: el volcado lógico programado de postgres-reservas y la copia de la plataforma completa con Velero, y harás el simulacro de desastre borrando un entorno entero para recuperarlo con cronómetro.

1. Qué hay que salvar realmente en un clúster
2. Snapshot no es copia de seguridad: la regla 3-2-1
3. RPO y RTO aplicados a Rutas Norte con números
4. Copia lógica: pg_dump desde un Job programado
5. Compresión, cifrado y restauración del volcado
6. Velero: qué hace y cómo está construido
7. Instalación y primera copia de un namespace
8. Hooks pre y post: la copia consistente
9. Copias programadas con retención
10. Restaurar en otro namespace
11. El simulacro de desastre
12. Qué no se restaura solo y el runbook mínimo
13. Retención, coste y datos personales

La primera pregunta no es "cómo hago copias" sino "de qué". En un clúster de Kubernetes hay tres cosas distintas, y cada una necesita una técnica diferente:

Tres observaciones que orientan todo lo demás. Git no basta: los manifiestos permiten recrear la forma de la plataforma, pero no contienen los Secrets (que dejamos deliberadamente fuera de Git en 03-02), ni los certificados emitidos por cert-manager (04-05), ni por supuesto los datos. La copia de etcd es cosa del administrador del clúster, no del equipo de aplicación, y en un clúster gestionado ni siquiera tienes acceso a etcd: por eso el enfoque práctico para Rutas Norte es copiar objetos de la API por namespace, que además es portable entre clústeres. Y lo verdaderamente irreemplazable son los datos: un Deployment se recrea en segundos; una reserva vendida y cobrada, no.

Retomamos la advertencia de 05-05 y le damos forma operativa con la regla clásica, que sigue siendo el mejor resumen. 3-2-1: al menos 3 copias de los datos, en 2 soportes o sistemas distintos, con 1 de ellas fuera del emplazamiento principal. Aplicada a Rutas Norte:

La cuarta fila es la que convierte el conjunto en una estrategia: sin ella, todo lo demás desaparece junto con la infraestructura que protege. Dos refuerzos que hoy se consideran obligatorios: la inmutabilidad —el almacén de objetos en modo bloqueo (Object Lock / WORM), para que ni siquiera unas credenciales robadas puedan borrar o cifrar las copias— y la separación de credenciales: la cuenta que escribe las copias no debe poder borrarlas, y el destino debe estar en otra cuenta o suscripción.

Dos siglas que hay que separar bien porque se confunden constantemente:

Y ahora los números, que es lo que convierte la conversación en algo útil. Rutas Norte vende unas 60 reservas por hora en día laborable normal, y unas 400 en puente o inicio de vacaciones, con picos de 700.

Cada fila implica una conversación de negocio, no técnica: ¿cuánto cuesta perder 9.600 reservas? No es solo el importe; es reconstruir a mano, atender reclamaciones, clientes que se presentan en la estación sin billete y daño reputacional en plena temporada alta.

Decisión de Rutas Norte:

El RTO medido en el ejercicio de 05-05 —del orden de dos minutos en local— era el de restaurar un volumen. El RTO real de un desastre incluye detectar, decidir, restaurar, verificar y reabrir el servicio. Por eso hay que medirlo con un simulacro (apartado 11), no estimarlo.

La copia lógica es un fichero con las instrucciones necesarias para reconstruir la base de datos. Sus ventajas frente a un snapshot de bloques son decisivas:

No compiten: se complementan. El snapshot es rápido para deshacer; el volcado es la copia que de verdad demuestra que los datos están bien.

Primero, el volumen donde se escriben los volcados: k8s/base/copias-postgres-pvc.yaml, un PVC llamado copias-postgres de 50 GiB, ReadWriteOnce, con las etiquetas habituales más app.kubernetes.io/component: copias-de-seguridad. Va en la clase rutasnorte-rapida (con Retain) porque si se pierden las copias, la red de seguridad desaparece.

Y ahora el CronJob. Nota: el objeto CronJob se estudia a fondo en 06-03; aquí lo usamos como herramienta, quedándonos con lo imprescindible para leerlo.

Las decisiones que hay dentro, una a una:

• concurrencyPolicy: Forbid: si un volcado tarda más de una hora, el siguiente no arranca. Dos pg_dump simultáneos duplicarían la carga sobre la base de datos justo cuando ya va lenta.
• set -euo pipefail y la verificación con pg_restore --list: sin lo primero, un pg_dump fallido puede dejar un fichero truncado y el Job terminar en Completed, dándote copias que no valen; lo segundo comprueba que el volcado es al menos legible. La verificación de verdad es restaurarlo (apartado 11).
• --no-owner --no-privileges: el volcado no arrastra propietarios ni permisos, lo que permite restaurarlo en otro clúster con otro usuario. Y con la ServiceAccount propia (03-06) el pod solo tiene lo que necesita, mientras que la retención local de 72 h convierte el PVC en la copia caliente para restaurar rápido; la retención larga vive fuera del clúster.

Y hay que recordar las NetworkPolicies de 04-06: el pod del CronJob es nuevo en el namespace y deny-all lo bloqueará. Hay que autorizar explícitamente su conversación:

Verificación:

El formato -Fc comprime pero no cifra. Y ese fichero contiene el nombre, el DNI, el teléfono y el correo de todos los clientes de Rutas Norte: es exactamente el tipo de artefacto que no puede quedar en claro en ningún soporte. La solución práctica es cifrar con una clave pública cuya clave privada no está en el clúster:

La variable CLAVE_PUBLICA_COPIAS llega por secretKeyRef desde un Secret copias-clave-publica. Y ahí está el punto importante: en el clúster solo vive la clave pública, así que quien comprometa el clúster puede escribir copias pero no puede leerlas. La clave privada se custodia fuera (gestor de secretos corporativo, caja fuerte), y su procedimiento de acceso debe estar documentado, porque una copia que nadie puede descifrar el día del desastre no es una copia.

Se lanza un pod auxiliar con la imagen postgres:16.4 que monte el PVC copias-postgres en /copias (con kubectl run ... --overrides o un Job de un solo uso), y desde dentro:

Restaura siempre a una base de datos nueva y verifica antes de sustituir. Restaurar directamente sobre la base de producción con --clean es la forma más rápida de convertir un incidente recuperable en uno irreversible.

Opciones de pg_restore que ahorran tiempo el día malo:

--jobs=4 restaura en paralelo y reduce mucho el RTO en bases grandes; --table=reservas restaura una sola tabla, que es el caso más común (alguien borró una tabla); --schema-only y --data-only separan estructura y datos; y --list con --use-list permiten inspeccionar el contenido y restaurar solo una parte.

El volcado lógico protege los datos de la base. No protege los Secrets, ni los PVC, ni los Ingress, ni los certificados, ni el resto de objetos del namespace. Para eso está Velero, la herramienta estándar de copia y migración de recursos de Kubernetes.

Velero hace tres cosas. Copia los objetos de la API de un namespace (o del clúster entero), filtrados por etiquetas o por tipo, a un almacén de objetos (S3, Azure Blob, GCS, MinIO). Copia los datos de los volúmenes por dos vías: pidiendo snapshots al driver CSI, o copiando fichero a fichero con Kopia/Restic al mismo almacén de objetos, que es lo que de verdad saca los datos del sistema de almacenamiento. Y restaura todo eso, en el mismo clúster o en otro, con reasignación de namespaces y filtros.

La distinción que hay que tener clara desde el principio:

Para Rutas Norte: snapshots CSI para lo diario (rápido, para deshacer) y copia al almacén de objetos para la copia semanal de larga retención, que es la que cumple el "1" de la regla 3-2-1.

Para practicar en minikube usaremos MinIO como almacén de objetos compatible con S3, desplegado en el propio clúster. En producción sería un bucket real en otra región y otra cuenta.

La primera copia, del namespace de preproducción:

Fíjate en lo que ha capturado: los Secrets, que no están en Git; los PVC; las NetworkPolicies; los ServiceAccounts. Y los datos del volumen, 18,4 GB copiados fichero a fichero al almacén de objetos.

Las dos variantes de volúmenes son --snapshot-volumes=false (solo objetos de la API: rapidísimo, pero sin datos) y --snapshot-volumes=true (snapshots CSI: rápido, pero los datos se quedan en el mismo sistema de almacenamiento).

Aquí resolvemos el problema de consistencia que dejamos abierto en 05-05. Los hooks de Velero ejecutan un comando dentro del contenedor antes y después de copiar el volumen, lo que permite dejar la base de datos en un estado coherente.

Se declaran como anotaciones en el pod, o en el propio backup. La forma declarativa, en el podTemplate del Deployment:

Qué hace cada uno. pg_backup_start (nombre a partir de PostgreSQL 15; antes era pg_start_backup) pone el servidor en modo copia: fuerza un checkpoint y garantiza que los ficheros del directorio de datos formen un conjunto restaurable, aunque sigan llegando escrituras. Y pg_backup_stop cierra ese modo: es imprescindible que se ejecute siempre, porque una base de datos que se queda en modo copia acumula WAL sin liberar y acaba llenando el disco; por eso el hook post se ejecuta aunque la copia falle.

Alternativa más simple y a menudo preferible para bases medianas: el hook pre hace directamente un pg_dump a un emptyDir que Velero también copia. Sacrifica algo de tiempo a cambio de una copia lógica verificable.

Una copia manual sirve para aprender; lo que protege es una programación con retención automática, que Velero resuelve con Schedule y el TTL, que borra la copia y sus datos al expirar.

El calendario resultante de Rutas Norte:

Solo la fila pro-semanal cumple el "1" de la regla 3-2-1. Las demás son comodidad y velocidad.

Vigilancia obligatoria: una copia que falla en silencio es peor que no tener copias, porque genera confianza infundada. Se detecta con velero backup get | grep -v Completed y se investiga con velero backup describe <nombre> --details y velero backup logs <nombre> | grep -i error. Esa comprobación debe ser una alerta automática, no una revisión manual; se monta con las herramientas de 07-04.

Restaurar sobre el namespace original en producción es la operación más delicada. La práctica correcta es restaurar primero en otro sitio y verificar:

Opciones de restauración que se usan a diario:

Y el aviso que ahorra un susto: por defecto Velero NO sobrescribe los objetos que ya existen. Si restauras sobre un namespace vivo, verás un montón de avisos "already exists" y creerás que la restauración falló, cuando lo que ha hecho es protegerte. Para una recuperación real, el namespace destino debe estar vacío o hay que usar --existing-resource-policy=update conscientemente.

Una copia no probada no es una copia. Esta es la práctica obligatoria del módulo, y en Rutas Norte se ejecuta cada trimestre sobre rutas-norte-pre, con cronómetro y con acta.

El acta del simulacro debe recoger, como mínimo: fecha y responsable, copia utilizada, RTO medido, RPO efectivo (el tiempo transcurrido entre la copia y el desastre), qué no volvió solo, incidencias y acciones derivadas. En el segundo ejercicio la redactarás entera.

El apartado "qué no volvió solo" es el más valioso del acta. Es literalmente imposible de conocer sin hacer el simulacro, y es lo que convierte una recuperación teórica en una recuperación real.

Un documento corto, en el repositorio, que alguien de guardia a las tres de la mañana pueda seguir sin pensar:

Las copias cuestan dinero, y sin retención automática el gasto crece sin freno. Con postgres-reservas en unos 20 GiB, los 72 volcados horarios ocupan unos 30 GiB (comprimen a ~410 MB cada uno), los 7 snapshots diarios unos 25 GiB por ser incrementales, y las 13 copias semanales unos 260 GiB en el almacén de objetos. Palancas para ajustarlo: usar clases de almacenamiento frías para lo antiguo, aprovechar la deduplicación de Kopia, y no copiar lo que se puede regenerar (redis-cache no entra en ninguna copia, por lo decidido en 05-03).

Y aquí está lo que no puede quedar como detalle técnico. Las copias de seguridad de Rutas Norte contienen datos personales de clientes: nombre, DNI, teléfono y correo de cada persona que ha comprado un billete. Eso significa que cada copia es un tratamiento de datos personales con los mismos deberes que el sistema original, y en algunos aspectos más exigentes, porque las copias se multiplican, se replican y se olvidan.

Los requisitos mínimos que Rutas Norte aplica:

ADVERTENCIA DE CUMPLIMIENTO NORMATIVO

Todo lo anterior es arquitectura técnica, no asesoramiento legal. Los plazos de retención, la ubicación geográfica de las copias, el tratamiento del derecho de supresión sobre datos ya copiados, la base legal del tratamiento y las obligaciones ante una brecha de seguridad deben ser revisados y aprobados por el responsable de cumplimiento normativo y de protección de datos de la organización antes de poner en marcha esta configuración en producción. Los valores de este curso (72 horas, 7 días, 90 días) son ejemplos didácticos elegidos para ilustrar la mecánica de la retención, no recomendaciones legales: el plazo correcto depende de la normativa aplicable, del sector y de la finalidad declarada de cada tratamiento, y conservar datos personales más tiempo del necesario es tan incumplimiento como no protegerlos.

Consejos:

1. Automatiza la verificación, no solo la copia. Un Job semanal que restaure el último volcado en un namespace de pruebas y compare el recuento de filas convierte "creemos que tenemos copias" en "sabemos que tenemos copias".
2. Documenta el RPO y el RTO reales, no los deseados, y revísalos tras cada simulacro. Son el dato que necesita el negocio para decidir cuánto invertir.
3. La copia debe poder restaurarse sin la persona que la configuró. Si el procedimiento vive en la cabeza de alguien, no existe: escríbelo en el runbook, en el repositorio. Y cuando dudes entre gastar en copias o en cualquier otra cosa, gasta en copias: es el único componente de la plataforma cuya ausencia no se nota hasta que es demasiado tarde.

En rutas-norte-dev, monta la cadena completa de copia lógica:

1. Crea el PVC copias-postgres de 5 GiB en la clase rutasnorte-rapida.
2. Adapta el CronJob del apartado 4 a dev, con schedule: "*/10 * * * *" para no esperar una hora.
3. Lanza una ejecución manual y comprueba en los registros que el volcado se ha creado y verificado.
4. Borra la tabla reservas y restáurala a una base de datos nueva desde el volcado, sin tocar la original.
5. Comprueba que los datos coinciden y explica por qué es importante restaurar a una base nueva.

Ejecuta el simulacro completo del apartado 11 sobre rutas-norte-pre (créalo con los cinco componentes si no lo tienes) y redacta el acta con: inventario previo, copia usada, RTO medido, RPO efectivo, qué no volvió solo, incidencias y acciones derivadas.

Compara después el RTO medido con el objetivo de 8 horas fijado para pre en el apartado 3 y razona si la política es adecuada o hay que cambiarla.

El comité de dirección de Rutas Norte pregunta: "si mañana perdemos el centro de datos entero, ¿cuánto tardamos en volver a vender y cuántas reservas perdemos?". Prepara la respuesta en forma de documento breve:

• A. Tabla de qué se copia, con qué método, frecuencia, retención y de qué protege cada copia.
• B. RPO y RTO comprometidos, con el número de reservas perdidas en el peor caso (puente, 400 reservas/hora).
• C. Los tres elementos que no se restauran solos y quién es responsable de cada uno.
• D. Un apartado sobre datos personales que incluya qué contienen las copias, cómo se protegen y qué debe validar el responsable de cumplimiento normativo.

Ejercicio 1

Por qué a una base nueva. Tres razones. Primera, si el volcado estuviera corrupto o incompleto, restaurar encima con --clean habría destruido lo que quedaba: te quedarías sin lo dañado y sin la copia. Segunda, la base dañada es la evidencia para el post-mortem: sin ella no sabrás qué pasó ni desde cuándo. Y tercera, permite comparar antes de cortar: recuento de filas, fecha máxima, integridad referencial. La sustitución final es un renombrado de dos segundos, así que el ahorro de tiempo de restaurar encima es despreciable frente al riesgo.

Ejercicio 2

Acta tipo:

Valoración de la política: el RTO objetivo de pre era de 8 horas y el medido es de 23 minutos, así que se cumple con enorme margen. Pero la conclusión útil es otra: el mismo procedimiento aplicado a producción no daría 23 minutos, porque en pro el volumen es diez veces mayor, hay que actualizar DNS con su propagación, regenerar secretos externos y verificar el negocio de extremo a extremo. La acción correcta es repetir el simulacro sobre una copia de producción restaurada en un namespace aparte, que es lo que da el número real de las 2 horas comprometidas.

Ejercicio 3

A. Qué se copia:

B. Compromisos:

La última fila es la respuesta a la pregunta del comité, y es incómoda a propósito: la copia que sobrevive a perder el centro de datos es la semanal, de modo que en el peor caso se perderían hasta siete días de reservas. Si eso no es aceptable —y no debería serlo—, hay dos inversiones que lo arreglan: pasar la copia externa a diaria (RPO de 24 h) y, sobre todo, archivar el WAL de PostgreSQL de forma continua a un almacén de objetos externo, que llevaría el RPO a minutos. Es la mejora prioritaria del plan.

C. Lo que no se restaura solo:

D. Datos personales:

Las copias contienen nombre, DNI, teléfono y correo de todos los clientes que han comprado un billete, además del historial completo de reservas. Protecciones aplicadas: cifrado en reposo de los volcados con clave pública (privada custodiada fuera del clúster), cifrado del bucket, cifrado en tránsito, credenciales de solo escritura para el proceso de copia, acceso a la restauración limitado por RBAC y registrado, retención automática por TTL y anonimización obligatoria de cualquier clon destinado a entornos no productivos.

Lo que debe validar el responsable de cumplimiento normativo, antes de poner nada de esto en producción:

1. Que los plazos de retención (72 h, 7 días, 90 días) son los legalmente correctos para esta finalidad, ni más ni menos.
2. Que la región del almacén de copias está dentro del ámbito geográfico permitido y declarado.
3. El procedimiento ante el derecho de supresión: qué se hace con las copias que ya contienen los datos de quien lo ejerce, y cómo se documenta.
4. La base legal del tratamiento y su reflejo en el registro de actividades, incluyendo las copias como tratamiento.
5. El protocolo de notificación de brechas si una copia se ve comprometida.
6. Las condiciones del encargado del tratamiento con el proveedor de la nube que aloja las copias.

Este documento es una propuesta técnica y no sustituye esa revisión.

Rutas Norte es ya una plataforma en la que se puede confiar. Sabes qué hay que salvar —los manifiestos, que ya están en Git; el estado de la API, con los Secrets y los PVC que Git no contiene; y los datos de los volúmenes, lo único verdaderamente irreemplazable— y que cada uno exige una técnica distinta. Tienes interiorizada la regla 3-2-1 y sabes que, de todas las copias de Rutas Norte, solo la semanal al almacén de objetos de otra región cumple el "1"; las demás son comodidad y velocidad. Y manejas RPO y RTO con números concretos: a 400 reservas por hora en un puente, una copia diaria significa perder hasta 9.600 reservas, y eso convierte una discusión técnica en una decisión de negocio que alguien tiene que tomar y firmar.

Has construido las dos piezas. La copia lógica: un CronJob horario que ejecuta pg_dump -Fc, verifica el volcado con pg_restore --list, lo cifra con una clave pública cuya privada no vive en el clúster, aplica retención local y —detalle que se olvida siempre— tiene su propia NetworkPolicy para atravesar el deny-all de producción. Y la copia de la plataforma con Velero: su arquitectura de controlador, node-agent y plugins; las dos vías para los volúmenes, con la diferencia decisiva de que solo la copia al almacén de objetos saca de verdad los datos del sistema de almacenamiento; los hooks pre y post con pg_backup_start/pg_backup_stop que resuelven la consistencia que dejamos abierta en 05-05, y la advertencia de que el post debe ejecutarse siempre so pena de llenar el disco de WAL; los Schedule con TTL que hacen la retención automática; y la restauración con --namespace-mappings para verificar antes de tocar nada real.

Y has hecho lo que separa una copia de una copia útil: el simulacro. Borrar rutas-norte-pre entero y recuperarlo con cronómetro, midiendo un RTO real y descubriendo la lista de lo que no vuelve solo —el certificado, la IP del LoadBalancer, el DNS, los secretos externos, los recursos de clúster—, que es literalmente imposible de conocer sin ejecutarlo. De ahí sale el runbook que alguien de guardia puede seguir a las tres de la mañana. Junto a todo ello queda la advertencia que no es técnica: las copias contienen datos personales de clientes, deben cifrarse, tener plazo de borrado, no salir del ámbito legal previsto, y la política de retención y el tratamiento de esos datos deben ser revisados y aprobados por el responsable de cumplimiento normativo antes de llevar nada de esto a producción.

Con esto termina el módulo 5. La deuda que arrastrábamos desde el módulo 2 está saldada por completo: postgres-reservas guarda sus datos en un volumen que sobrevive al pod, aprovisionado dinámicamente por una StorageClass con Retain, expandible en caliente, con snapshots antes de cada cambio arriesgado y con copias verificadas dentro y fuera del clúster.

Queda un techo que hemos encontrado tres veces y siempre hemos aplazado con la misma frase. En 05-03 descubriste que un Deployment tiene una sola plantilla, de modo que todas sus réplicas piden el mismo PVC y por eso postgres-reservas está condenado a replicas: 1 con strategy: Recreate. Una base de datos de producción necesita más: identidad estable, arranque ordenado y un volumen propio por réplica. Eso lo da el volumeClaimTemplate de los StatefulSets, y con él arranca el módulo 6, Conceptos Avanzados: StatefulSets, DaemonSets, Jobs y CronJobs —donde por fin llega informes-ocupacion, el sexto componente de la plataforma—, init containers y sidecars, planificación con afinidad y taints, recursos personalizados y operadores. Empezamos por StatefulSets.