Respaldos y la ventana de restauración¶

El historial de un objetivo es una cadena: respaldos completos según un calendario y, entre ellos, un flujo de cambios continuo (WAL de Postgres, binlog de MySQL). Se puede restaurar cualquier segundo cubierto por un respaldo completo y los cambios posteriores. Ese intervalo es la ventana de restauración puntual.

gantt
  dateFormat  YYYY-MM-DD HH:mm
  axisFormat  %a %d
  section Full backups
  daily full      :milestone, 2026-10-01 02:07, 0d
  daily full      :milestone, 2026-10-02 02:07, 0d
  daily full      :milestone, 2026-10-03 02:07, 0d
  daily full      :milestone, 2026-10-04 02:07, 0d
  section Change stream
  WAL / binlog segments :active, 2026-10-01 02:07, 2026-10-04 18:00

Respaldos completos¶

Motor	Modo	Herramienta	Restauración
Postgres 15–17	`physical` (por defecto)	`pg_basebackup -Ft -X fetch` sobre el protocolo de replicación	respaldo base + reproducción de WAL hasta el segundo
Postgres 15–17	`logical`	`pg_dump -Fc`, un objeto por base de datos; exclusión de tablas y exportaciones selectivas	`pg_restore`, más reproducción de WAL a través de una cadena física cuando existe
MySQL 8.4	`logical`	`mysqldump --single-transaction --source-data=2` (rutinas, eventos, triggers)	carga + reproducción de binlog hasta el segundo

Cada respaldo registra un inventario: bases de datos, tablas, columnas, índices, estimaciones de filas y tamaños, y la versión de migración cuando existe una tabla de migraciones. Eso es lo que comparan la consola y tenax diff.

El flujo de cambios¶

Cada objetivo con recuperación puntual tiene un streamer:

Postgres: el receptor de WAL propio de Tenax sobre un slot de replicación físico (ADR 0005). El slot garantiza que no se pierde WAL mientras el streamer se reinicia.
MySQL: mysqlbinlog --read-from-remote-server --raw --stop-never desde la posición de binlog del último respaldo completo.

Los segmentos se suben a medida que se completan, y el segmento que aún se está escribiendo se sube cada partialInterval (60 s por defecto), así que también se puede restaurar el último minuto. Cada segmento lleva un resumen: commits, inserts, updates y deletes por tabla, DDL y, opcionalmente, vistas previas enmascaradas de filas.

Si el flujo se rompe (se pierde un slot, se purga un binlog), Tenax marca la cadena como rota, alerta (TenaxStreamChainBroken), inicia una cadena nueva y toma de inmediato un respaldo completo (motivo chain-restart). La ventana anterior sigue siendo restaurable hasta el punto de ruptura.

Retención¶

Los respaldos completos se conservan por niveles; los segmentos solo hasta donde la ventana los necesita; la recolección de basura elimina todo lo demás, y nunca nada fijado.

Preset	Ventana	Diarios	Semanales	Mensuales	Anuales
`prod`	7 días	14	8	12	5
`dev`	3 días	7	4	3	0
`critical`	14 días	30	12	24	7

El primer respaldo completo confirmado de un día es el diario de ese día; el de una semana ISO, su semanal; y así sucesivamente. Un mismo respaldo puede tener varios niveles; no se copia nada. Los pins (tenax pin <id> --reason …) conservan un respaldo sin importar los niveles. La recolección de basura escribe su plan en el bucket antes de borrar, borra los manifiestos antes que los datos y limpia las subidas huérfanas e incompletas al cabo de un día.

Formato de almacenamiento¶

<store prefix>/<org>/<project>/<namespace>/<target>/
  full/<backup-id>/manifest.json            # written last: the commit marker
  full/<backup-id>/data/<database>.zst.age  # dumps or the base backup tar
  full/<backup-id>/inventory.json.zst.age   # also readable with the catalog key
  full/<backup-id>/tags.json                # tiers, pins, verification results
  stream/…/<segment>.zst.age                # WAL / binlog segments and their summaries
  stream/position.json                      # the streamer's confirmed position

Compresión: zstd al nivel de la política, una sola vez, antes del cifrado; activada por defecto (ADR 0013). compression.algorithm: none guarda los datos tal cual.
Cifrado: cada objeto se cifra con age en el cliente para los destinatarios del store. El bucket nunca ve texto en claro.
Integridad: el tamaño y el SHA-256 de cada objeto figuran en el manifiesto y se verifican en cada lectura.
Confirmación: un respaldo solo existe una vez escrito manifest.json. Una caída antes de eso deja huérfanos que la recolección de basura elimina, nunca un respaldo que parezca completo.

Control de carga¶

Los respaldos nunca compiten a ciegas con producción: slots por host, por objetivo y globales, un límite de ancho de banda, una prioridad, un jitter en los calendarios y una protección de carga que pospone un respaldo completo mientras el servidor tiene demasiadas conexiones activas, demasiado retraso de replicación o transacciones largas. Todo se configura en la BackupPolicy.