Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «Sistemas Distribuidos para Misiones Espaciales».
Las bases de datos del clúster que usan un log de escritura anticipada (WAL, write-ahead log) permiten copiarse en caliente, sin detener el servicio: se toma una copia consistente de los archivos mientras la base sigue aceptando escrituras, porque el WAL garantiza que la copia refleja un punto coherente en el tiempo. Cada backup se acompaña de un manifiesto de conteos: cuántas filas tiene cada tabla relevante en el momento de la copia. Ese manifiesto no es un detalle burocrático — es lo primero que se compara tras un restore, para detectar de inmediato si el backup quedó truncado o corrupto.
La regla central de esta lección: un backup no probado no es backup
Un proceso que copia archivos y los sube a almacenamiento externo, sin haber demostrado nunca que esos archivos pueden restaurarse a un sistema funcional, no es una garantía de recuperación — es una esperanza sin verificar. La única forma honesta de confiar en un backup es probarlo: el restore drill. Consiste en restaurar el backup a un entorno efímero (desechable, aislado del de producción) y correr smoke tests que verifiquen que el sistema restaurado responde correctamente a operaciones básicas — y el resultado de esos smoke tests produce un veredicto automatizado por código de salida (0 = el restore es válido, distinto de 0 = falló, con detalle de qué falló). Este drill corre en un cron mensual, no solo "cuando alguien se acuerda": la disciplina de probar backups tiene que ser tan automática como la de tomarlos.
Replicación continua: la idea de Litestream
Para bases SQLite (usadas por algunas apps del clúster por su simplicidad de despliegue), una alternativa complementaria al backup periódico es la replicación continua al estilo de Litestream: cada cambio en el WAL se transmite de forma continua a un almacenamiento externo, de modo que el punto de recuperación más reciente disponible está siempre a segundos de distancia del estado actual, en vez de a horas (el intervalo entre backups periódicos). Esto reduce drásticamente el RPO (ver más abajo) sin necesidad de migrar a un motor de base de datos distinto.
Retención con criterio: purgar payload, nunca borrar filas
No todos los datos merecen el mismo tratamiento de retención, y una decisión mal pensada aquí puede romper silenciosamente a otras apps del clúster. Los payloads pesados (por ejemplo, una grabación IQ completa asociada a un evento antiguo) pueden purgarse — se elimina el contenido pesado y se deja un registro liviano de que existió — sin borrar la fila que lo contiene. La razón es sutil pero crítica: los consumidores del bus que operan en modo isla (recuperando eventos por polling, con su propio cursor numérico) dependen de que la numeración seq sea continua; un DELETE de filas rompería esa numeración y confundiría a cualquier consumidor que reanude su cursor más tarde. Purgar el contenido pesado preservando la fila (y su seq) logra el ahorro de espacio sin ese efecto secundario. En el otro extremo, hay datos que jamás caducan: el catálogo científico y las cadenas de procedencia (lección 7) se conservan indefinidamente, porque son precisamente el tipo de dato cuya integridad histórica es el punto entero de tenerlo.
RPO y RTO: dos preguntas distintas, ambas explícitas
Todo plan de custodia de datos serio responde a dos preguntas por separado, con números concretos: el RPO (recovery point objective) — cuántos datos como máximo es aceptable perder, medido en tiempo ("como mucho perdemos 15 minutos de datos") — y el RTO (recovery time objective) — cuánto tiempo como máximo puede tardar el sistema en volver a estar operativo tras un incidente ("el servicio debe estar de vuelta en menos de 2 horas"). Son ejes independientes: un sistema puede tener un RPO muy ajustado (casi no pierde datos, gracias a replicación continua) y sin embargo un RTO más largo (tarda en levantar la infraestructura de nuevo), o viceversa. Definir ambos por separado, y con honestidad sobre lo que la infraestructura actual realmente puede sostener, es lo que distingue un plan de custodia real de una aspiración vaga.
La regla de oro de datos sensibles: las grabaciones IQ crudas jamás salen de su host
El clúster tiene una regla de minimización de datos sin excepciones para su dato más pesado y potencialmente sensible: las grabaciones IQ crudas capturadas por la estación terrena jamás salen del host donde se capturaron. Lo que viaja al resto del clúster (al clasificador, al catálogo) son artefactos derivados — espectrogramas, características extraídas, metadatos — nunca la grabación cruda completa. Esto no es solo una precaución de privacidad: también acota drásticamente cuánto volumen y qué tipo de dato sensible circula por el bus, simplificando todo el resto del modelo de seguridad y custodia.
Repasa el vocabulario de esta lección:
1 de 5
¿Por qué un backup que nunca se ha restaurado y probado no cuenta como una garantía real de recuperación?
8. Custodia de datos: un backup no probado no es backup