Backup de base de datos en cluster: las estrategias que sobreviven a las 3 de la mañana

Tres de la mañana. La alerta te despierta porque el endpoint de health check está devolviendo 500 desde hace doce minutos. Abres el terminal somnoliento, te conectas a la base de producción, y la primera query devuelve ERROR: invalid page in block 4421 of relation base/16384/24576. Corrupción física. Postgres aún responde algunas peticiones pero está entregando datos podridos a la mitad de los clientes que caben en la parte sana de las páginas.

Recuerdas el cron de pg_dump que corre a las 3 de la mañana. Miras el reloj: 3h12. El cron empezó hace doce minutos. O sea, el backup que está siendo grabado ahora mismo en S3 es la fotografía de la corrupción. El backup anterior tiene 24 horas. Tienes 24 horas de pedidos, pagos, mensajes y subidas que perder, o una base corrupta que restaurar.

Ese es el escenario en que toda decisión sobre backup se cobra. No es en reunión de arquitectura. No es en retro de sprint. Es a las tres de la mañana, contigo solo en un terminal, decidiendo entre dos malos.

Este post abre los cinco modelos de backup que existen para base de datos en cluster, con los números honestos de cuánto cada uno pierde y cuánto cada uno tarda en volver. Cada estrategia tiene una franja de SaaS donde es la elección correcta — y una franja donde es negligencia. La diferencia es la etapa en que tu empresa está, no el estilo de quien la configuró.

La frase que define todo: backup que nunca fue restaurado es placebo

La mayoría de los equipos tiene opinión confiada sobre backup y práctica frágil. "Tiene cron de pg_dump a S3" es el equivalente operacional de "tiene extintor pero nunca probó que funciona". La confianza viene de tener el archivo ahí en el bucket. La fragilidad viene de nunca haber realmente tirado ese archivo, restaurado en un ambiente aislado, validado conteo de filas, comprobado checksums.

Backup es el tipo de sistema en que la versión "funciona hasta dejar de funcionar" es indistinguible de la versión "funciona de verdad" — hasta el momento exacto en que lo necesitas. Los dos primeros años de un SaaS se viven en el estado de Schrödinger: el backup está vivo y muerto al mismo tiempo, y nadie abrió la caja.

Este texto es el ejercicio de abrir la caja antes del incidente. Las cinco estrategias abajo están organizadas de forma creciente en complejidad y en garantía. Para cada una, la pregunta es: ¿cuántos datos pierdo? ¿cuánto tiempo quedo fuera? ¿cuánto cuesta? y — el criterio que nadie toma en serio hasta necesitarlo — ¿cuánta competencia interna exige?

RPO y RTO sin buzzword

Antes de comparar estrategias, dos números necesitan estar sobre la mesa. Tienen siglas pesadas pero el concepto es simple.

RPO — Recovery Point Objective. Cuántos datos aceptas perder. Es la distancia entre el "ahora" del incidente y el último punto consistente que consigues restaurar. Backup diario a las 3 de la mañana significa RPO de hasta 24 horas — si la corrupción ocurre a las 2 de la mañana del día siguiente, pierdes 23 horas de transacciones. Backup continuo significa RPO de segundos.

RTO — Recovery Time Objective. Cuánto tiempo aceptas estar offline. Es la distancia entre el "empezó el incidente" y el "está sirviendo tráfico de nuevo". Restore de pg_dump en una base de 50 GB toma entre 30 y 60 minutos en una máquina decente. Failover a réplica streaming toma 30 segundos.

Ambos cuestan dinero de formas diferentes. RPO bajo cuesta storage y ancho de banda continuo (cada commit necesita volverse bytes durados en algún lugar antes de ser confirmado al cliente). RTO bajo cuesta hardware redundante — una réplica caliente es literalmente otra base corriendo, consumiendo CPU, RAM y disco en paralelo, sin servir tráfico en momento normal.

Definir RPO y RTO antes de implementar evita el error más común: gastar mucho para resolver el lado equivocado. Equipo que paga US$300 al mes de read replica y aún pierde 24 horas de datos cuando el disco se corrompe gastó mal — compró RTO bajo e ignoró RPO. Equipo que hace pg_dump quincenal en bucket cross-region cifrado también gastó mal — compró durabilidad extrema y aceptó RTO de horas que el cliente B2B no tolera.

Estrategia 1 — Cron + pg_dump a S3

La versión MVP. Un cron job en el servidor de la base, ejecuta pg_dump | gzip | aws s3 cp a las tres de la mañana. Bucket cross-region con lifecycle policy: archivos con más de 30 días migran a storage frío, con más de 90 días son borrados.

RPO real: 24 horas en el camino normal. Puede llegar a 48 si el cron falla una noche y nadie lo nota.

RTO real: 30 a 60 minutos para base de hasta 50 GB. El pg_restore de un dump comprimido corre cerca de la velocidad de I/O del disco — una máquina con SSD decente hace 1 a 2 GB por minuto, contando el tiempo de crear índices.

Funciona para: proyecto personal, MVP, herramienta interna, app donde 24 horas de datos es recuperable humanamente. Plataforma de registro donde el cliente rehace lo que perdió. Herramienta de caché que rehidrata del upstream. SaaS B2C en los primeros 100 usuarios, donde "perdimos un día, perdona" es respuesta aceptable.

Donde duele: backup caliente en base transaccional puede capturar estado inconsistente entre tablas relacionadas si no usas las flags correctas. pg_dump con --serializable-deferrable resuelve consistencia transaccional pero puede bloquear writes pesados. La versión paralela con -j es más rápida pero exige --format=directory, lo que complica el pipe directo a S3 — terminas necesitando disco temporal local.

Y el restore es lento de una manera que sorprende. Base de 200 GB que parecía "solo un poco grande" se vuelve tres horas de restore con índices siendo reconstruidos. Tres horas en que tu plataforma está fuera.

Coste: US$1 a US$6 al mes de storage S3-compatible para retención razonable. Tiempo humano: cero después del setup, diez minutos al mes para revisar log del cron.

Estrategia 2 — pg_basebackup + WAL archiving

La primera vez que el RPO baja de "un día" a "algunos minutos". La idea es separar dos cosas: la fotografía completa de la base (basebackup) y el historial de cambios desde la última fotografía (WAL — Write-Ahead Log, el archivo donde Postgres escribe cada commit antes de aplicarlo en los datos).

Setup: pg_basebackup semanal graba un snapshot completo del directorio de datos. En paralelo, el archive_command de Postgres copia cada archivo WAL cerrado (16 MB cada uno) a S3 conforme son producidos. En condiciones normales, el WAL es cerrado en segundos bajo carga media.

RPO real: 1 a 5 minutos. Es el intervalo entre el último WAL haber sido enviado y el disco haber muerto.

RTO real: 15 a 45 minutos. Restaurar el basebackup, replay de los WALs hasta el punto deseado.

Funciona para: SaaS con 10 a 100 GB de base, primer centenar de clientes pagando. Etapa en que perder 24 horas es catastrófico pero el equipo aún no tiene DBA dedicado.

Donde duele: el archive_command necesita ser tratado como código de producción, no script de fin de semana. Si falla y nadie lo nota, el WAL acumula en el disco de la base hasta reventar, y cuando revienta la base para de aceptar writes. Ya he visto cluster caer a las cuatro de la mañana porque el archive_command llamaba aws s3 cp sin --no-progress y la salida del progreso bloqueaba el stdout en ambiente sin TTY.

El volumen de WAL sorprende. Base con tráfico medio genera 5 a 50 GB de WAL por día, dependiendo de lo que escribe. Multiplicado por retención de 30 días, se vuelve terabytes. Storage barato sigue siendo barato, pero el lifecycle policy del bucket tiene que estar afilado.

Y el restore exige replay secuencial. No puedes saltar WALs. Si un archivo intermedio se perdió (bug en archive, bucket borrado por error, cualquier cosa), el restore para en ese punto y lo que vino después es ilegible. Verificación periódica es obligatoria.

Coste: US$10 a US$40 al mes de storage dependiendo de retención. Tiempo humano: 2 a 4 horas para setup inicial bien hecho, más la primera media hora de cada incidente entendiendo qué WAL necesita.

Estrategia 3 — pgBackRest, WAL-E, restic, xtrabackup

Cuando la estrategia 2 es demasiado buena para hacerse a mano. Herramientas dedicadas que combinan basebackup, WAL archiving, retención, compresión, cifrado y — crucialmente — verificación automática.

pgBackRest es el nombre más maduro para Postgres. Hace todo lo que la estrategia 2 hace, pero con paralelización (varios procesos enviando WAL simultáneamente), validación de checksum en cada archivo, point-in-time recovery (PITR) sin dolor, y — la ganancia operacional grande — un comando único pgbackrest restore que sabe encontrar el backup más reciente, bajar lo que necesita, y replay hasta el instante que pides.

WAL-E es más antiguo pero más simple si solo quieres mandar a S3 y volver.

restic es genérico (no es específico de Postgres), pero tiene deduplicación que es especialmente útil cuando haces dump completo varias veces al día — el segundo dump solo envía los bloques que cambiaron.

xtrabackup es el equivalente para MySQL, con la misma filosofía: backup caliente sin lock, incremental, PITR.

RPO real: minutos, igual estrategia 2. La diferencia es que aquí los "5 minutos" son más confiables porque la herramienta verifica continuamente que el pipeline esté funcionando.

RTO real: 10 a 30 minutos con PITR directo. El comando pgbackrest restore --type=time --target='2025-12-11 03:42:00' resuelve lo que en la estrategia 2 exige media hora de scripts.

Funciona para: SaaS serio, base de 100 GB a 1 TB, equipo que asume responsabilidad formal por tests mensuales de restore.

Donde duele: aprender la herramienta. pgBackRest tiene documentación decente pero el vocabulario es específico — stanza, repo, archive-async. La configuración inicial bien hecha toma 2 a 4 horas, y otro día para correr el primer full + incrementales y tener certeza de que todo cuadra.

La trampa aquí es que la herramienta esconde la complejidad del mecanismo, no la elimina. Cuando algo sale mal, necesitas entender que por debajo sigue siendo basebackup + WAL. La diferencia es que los bugs comunes de la estrategia 2 (archive fallando silenciosamente, WAL faltando) son detectados y alertados por la herramienta antes del incidente.

Coste: storage proporcional al volumen + tiempo de DBA part-time. Hablo en "DBA part-time" aunque nadie con ese título exista en el equipo — es el tiempo que alguien de guardia necesita invertir mensualmente para correr el restore-test.

Estrategia 4 — Streaming replication con failover automático

La primera estrategia en que el RTO baja por debajo de un minuto. En lugar de copiar la base después de que ella terminó de escribir, mantienes una réplica recibiendo el stream del WAL en tiempo real. Cuando el primario muere, un orquestador promueve la réplica a primario, actualiza el enrutamiento, y el servicio vuelve sin intervención humana.

Patroni es el nombre más común para orquestar eso en Postgres. Resuelve elección de líder entre nodos, gestiona replication slots, hace fencing del nodo muerto para evitar dos escrituras simultáneas, y expone un endpoint que tu balanceador de carga consulta para saber qué nodo es el primario corriente.

RPO real: segundos. Replicación síncrona puede llegar a cero (commit en el primario solo confirma después de que la copia llegue a la réplica) pero cuesta latencia en cada write — elección que se hace transacción a transacción en la mayoría de los sistemas.

RTO real: 30 segundos a 5 minutos. Los 30 segundos es el failover automático sin human-in-the-loop. Los 5 minutos es el escenario en que el orquestador detecta el problema, decide que no es falso positivo, promueve la réplica, y la caché de DNS de los clientes expira.

Funciona para: SaaS con primer cliente B2B serio, SLA contractual igual o mayor que 99,5%. Plataforma donde 5 minutos de ventana equivale a una pena contractual.

Donde duele: split-brain durante particionamiento de red. Si el primario queda aislado pero sigue aceptando escrituras, y la réplica es promovida por el orquestador en el otro lado de la partición, terminas con dos verdades divergentes que necesitan ser reconciliadas manualmente cuando la red vuelve. Los orquestadores serios usan un tercer nodo de testigo para evitar eso, pero la configuración es exigente.

Peor aún: la réplica copia corrupción. Si el primario escribió una página podrida, la réplica recibió el WAL idéntico y está igualmente podrida. Streaming replication te protege contra fallo de hardware del primario; no protege contra bug de aplicación que escribió basura, contra DROP TABLE errado, contra ransomware.

Por eso esta estrategia nunca sustituye a las tres anteriores — suma. RTO bajísimo para fallo de hardware, más backup tradicional para fallo lógico.

Coste: dos o tres bases corriendo todo el tiempo (un primario activo, uno o dos standbys). Storage y CPU duplicados o triplicados en relación a la base única. Tiempo humano: setup inicial de una semana, más batería de tests de failover trimestral.

Estrategia 5 — Backup gestionado por tercero

La estrategia en que compras el problema fuera. RDS en AWS, Cloud SQL en Google, Neon, Crunchy Bridge, o un proveedor local que entrega backup automático con PITR. Defines la ventana de retención, ellos cuidan del resto.

RPO real: 5 minutos es el número típico publicado.

RTO real: 30 segundos a 5 minutos para el failover dentro de la misma región. Restore cross-region es otro animal — puede ser una hora, dependiendo del proveedor.

Funciona para: equipo sin expertise interna O cumplimiento que exige vendor con SOC 2 / ISO 27001 emitido. Empresa que preferiría pagar caro para no pensar en el asunto.

Donde duele: coste. Base que costaría US$60/mes en hardware se vuelve US$300 a US$600/mes en RDS equivalente, dependiendo de la configuración de réplica. Lock-in de proveedor — salir de RDS es una migración complicada porque la forma de hacer backup es específica del producto. Y el restore cross-region (que es la parte que el cliente B2B exige en el contrato) frecuentemente es más difícil de lo que parece en los slides comerciales.

La ventaja real es zero ops en condiciones normales. La desventaja real es que cuando estás en incidente, el camino para escalar con el soporte del proveedor puede tomar más tiempo del que tendrías para resolver con auto-hospedado bien configurado.

Coste: US$50 a US$500 al mes para bases pequeñas y medianas. Por encima de eso es cobro proporcional al tamaño.

Tabla comparativa

La versión honesta lado a lado. Cada columna es una de las estrategias arriba.

Repara que ninguna línea tiene un ganador absoluto. La estrategia 5 gana en "tiempo humano" y pierde en "coste de storage". La estrategia 4 gana en RPO y pierde en "complejidad de setup". La elección es siempre sobre qué columna priorizas, dado el etapa de la empresa.

Los cinco errores que matan el backup del colega

A partir de aquí es folclore operacional. Cada uno de esos errores fue cometido por un equipo que tenía confianza en el backup que tenía. Cada uno se volvió post-mortem.

Nunca restauró. Backup que nunca fue restaurado en ambiente aislado es hipótesis. Cron mensual que toma el backup más reciente del bucket, lo sube en una base efímera (una máquina temporal que apagas en seguida), valida conteo de filas de las tablas críticas, comprueba checksum de algunas muestras, y manda email al equipo confirmando éxito. El backup del mes en que ese cron falló es el único backup del que tienes certeza de que va a funcionar. Todo antes es fe.

Backup en el mismo disco o misma región. Disco muere, backup va junto. Región entera de proveedor cloud cae (ya ocurrió varias veces en los últimos cinco años), backup va junto. Cross-region es el mínimo. Cross-provider — backup principal en un proveedor, copia secundaria en otro — es lo que separa "preparado" de "hincha".

Sin retención lógica larga. Siete días de retención parece cómodo hasta que descubres que la corrupción empezó hace ocho días y nadie lo notó. Bug sutil de aplicación que escribe dato inválido en una fila por minuto no dispara alerta, pero en dos semanas envenenó medio millón de registros. Retención corta es negligencia disfrazada de ahorro. Política mínima razonable: 7 días de backup horario, 30 días de diario, 12 meses de mensual.

Sin alerta de fallo. El cron silencioso es el asesino más común. Falló hace treinta días por un cambio de credencial en S3, nadie miró el log, todo el mundo durmió tranquilo. Alerta integrada al sistema de notificación del equipo (no email perdido en la bandeja, sino Slack o equivalente que alguien va a leer) es obligatorio. Y la alerta tiene que ser doble — alerta cuando falla, y alerta cuando no hay éxito hace más de N horas (para detectar el caso en que el cron ni corrió).

Backup sin cifrado. Filtración de bucket S3 público se vuelve filtración de la base entera. Los incidentes de prensa de los últimos años están todos compuestos por "bucket quedó público por dos días y tenía el backup completo". Cifrado en reposo (server-side encryption en el bucket es el mínimo, cifrado cliente-side con clave gestionada por ti es lo adecuado), cifrado en tránsito, y — separado de eso — control de acceso al bucket que sigue el principio del menor privilegio.

La trayectoria de madurez

La pregunta práctica: qué estrategia para qué etapa. Tomando como referencia métricas de ingresos mensuales recurrentes.

MVP hasta US$1k de MRR. Estrategia 1. Cron de pg_dump a S3-compatible, retención de 30 días, alerta básica de fallo. Cuesta prácticamente nada y protege contra el riesgo principal en esa fase, que es "el servidor desapareció". RPO de 24 horas es aceptable porque el cliente en esa fase tiene expectativa de producto que está empezando.

Indie de US$1k a US$6k. Estrategia 2. Añade WAL archiving, derriba RPO de 24 horas a 5 minutos. El salto de complejidad es compensado por el salto de garantía. Cliente que paga US$100 al mes de suscripción B2B empieza a hacer pregunta de SLA — necesitas respuesta mejor que "diario".

Startup early de US$6k a US$40k. Estrategia 3. pgBackRest configurado con restore-test mensual automático. Aquí ya no es opcional — tienes cliente serio, contrato serio, y la fragilidad de la estrategia 2 hecha a mano es riesgo operacional concreto. El setup de medio día se paga en tres meses por el primer incidente que no se vuelve post-mortem público.

Startup con SLA contractual. Estrategia 4 sumada a la 3. Streaming replication con failover automático cuida del hardware; pgBackRest cuida del dato lógico. Las dos juntas resuelven los dos modos de fallo que los contratos B2B serios cobran: indisponibilidad momentánea y pérdida de dato.

Enterprise o cumplimiento pesado. Estrategia 5 O estrategia 4 con auditoría detallada. Aquí la decisión es menos técnica y más regulatoria. Si la auditoría exige proveedor con certificación X, compras gestionado. Si la auditoría acepta auto-hospedado con runbook documentado, operas las estrategias 3 y 4 e inviertes en la trayectoria de auditoría.

Cómo HeroCtl simplifica eso

La motivación del producto es justamente ese esquema arriba — son capas que aparecen repetidamente en todo SaaS, y cada equipo gasta una temporada entera reconstruyendo la misma cañería. HeroCtl resuelve el transporte, la orquestación y la observación de esas capas. Mantiene lo que es específico de la base con el equipo, automatiza lo que es genérico.

Concretamente, en el plan Community (gratuito), corres Postgres como job común en el cluster, con persistencia cifrada en reposo. El cron de backup se vuelve otro job, con retry automático, alerta integrada de fallo (sin necesidad de montar Alertmanager por fuera), y métricas que aparecen en el panel — duración del dump, tamaño del archivo, tiempo desde el último éxito.

En el Business, entra backup gestionado de Postgres y MySQL. La diferencia con "hacerlo tú mismo" es que la verificación de integridad, el restore-test mensual, el cifrado cliente-side con clave gestionada por ti, y la política de retención en tres tiers (horario/diario/mensual) ya vienen configuradas. Defines la ventana y el resto es problema nuestro.

En el Enterprise, entra orquestación de streaming replication entre nodos del cluster — un job describe la topología (primario aquí, standby allá, quién promueve quién), y el cluster cuida del failover cuando el primario muere. Batería de tests de chaos corre contra tu cluster mensualmente, con informe.

En todos los planes, el restore-test puede ser configurado como cron job interno: el cluster sube una base efímera, restaura el backup más reciente, valida lo que definas como "saludable" (una query de checksum, una conteo de filas, lo que tenga sentido), reporta éxito o fallo, y apaga la base efímera. El coste son los minutos de CPU del test, no día de trabajo de ingeniero.

La filosofía es la misma del resto del producto: lo que es genérico para todo SaaS ya está listo; lo que es específico de tu dominio se queda contigo. Backup es genérico. El contenido de la base es tuyo.

FAQ

¿pg_dump basta para empezar? Sí, para MVP hasta primeros clientes pagando. La regla práctica: si perder 24 horas de datos cuesta menos que tres horas de tiempo de ingeniero, pg_dump es la elección correcta. Cuando se invierta (perder dato cuesta más que migrar a la estrategia 2), migra.

¿Cuánto cuesta storage S3-compatible en 2026? Franja actual entre US$0,03 y US$0,08 por GB-mes dependiendo del proveedor y del tier. Backup de base de 50 GB con retención de 30 días más algunos dumps semanales antiguos = ~3 TB-mes equivalente comprimido = US$10 a US$25/mes. Cross-region prácticamente dobla. Tier frío para retención mensual larga derriba a la mitad.

¿Cómo pruebo restore sin afectar producción? Cron job en el cluster que: 1) baja el backup más reciente del bucket; 2) sube un Postgres temporal en otro nodo (o contenedor efímero) sin exponer puerto público; 3) restaura el dump; 4) corre queries de validación (conteo por tabla, checksum de muestras, query crítica del dominio); 5) compara con baselines esperados; 6) reporta resultado en el canal de alertas; 7) destruye el ambiente. Corre mensual, como mínimo. Nunca toca la base de producción en momento ninguno.

Backup cifrado en S3 — ¿cuál es la forma correcta? Tres capas. Server-side encryption del bucket (AES256 o KMS) es la base y es gratis. Cifrado cliente-side con clave gestionada por ti (cifras el archivo antes de subir, con clave que vive fuera del proveedor cloud) protege contra escenario de comprometimiento de credencial. Política de bucket con aws:SecureTransport=true y bloqueo de acceso público explícito. Las tres juntas, sin excepción. Una sola no basta.

¿Read replica cuenta como backup? No. Read replica protege contra fallo de hardware del primario. No protege contra DROP TABLE errado, contra bug que escribe dato inválido, contra corrupción lógica que se replica. Toda corrupción lógica que entra en el primario entra en la réplica en segundos. Read replica es alta disponibilidad, no backup. Las dos cosas coexisten; ninguna sustituye a la otra.

¿Cross-region replication es necesario? Para cliente B2B serio, sí. Para MVP, no. La frontera práctica: si un único proveedor cloud cayendo por 4 horas es suficiente para que rompas contrato, cross-region es mínimo. Si 4 horas fuera aún se pueden explicar por email, cross-region puede esperar.

¿Cuánto tiempo tarda restaurar 100 GB de Postgres? Depende mucho del disco. SSD NVMe local: 20 a 40 minutos contando creación de índices. SSD remoto (volumen de proveedor cloud): 40 a 90 minutos. HDD: no quieres saber. Compresión del dump típicamente derriba a la mitad del tamaño original; base de 100 GB se vuelve dump de 30 a 50 GB. Crea índices en paralelo (pg_restore -j) para acelerar 30 a 50%.

Cierre

Backup es menos sobre estrategia técnica y más sobre disciplina de test. Las cinco estrategias arriba son todas decentes en alguna etapa. La diferencia entre el equipo que sobrevive al incidente y el equipo que pierde cliente no está en cuál de ellas escogió — está en haber restaurado un backup recientemente lo suficiente para confiar.

Si tu respuesta a "¿cuándo fue el último restore-test?" empieza con "déjame ver", tienes trabajo para esta semana. No es la próxima sprint. Es esta semana. El escenario de las tres de la mañana no está agendado.

HeroCtl corre en cualquier servidor Linux con Docker. Instalas en un laboratorio, subes un Postgres como job, configuras backup automático, agendas restore-test mensual, y en una tarde tienes el esquema de la estrategia 3 entero funcionando. Sin montar cinco productos diferentes, sin aprender vocabulario de orquestador especializado.

curl -sSL get.heroctl.com/install.sh | sh

Para contexto sobre cuándo tiene sentido correr Postgres en el propio cluster vs. comprar gestionado, lee Postgres en producción: gestionado vs auto-hospedado. Para entender por qué la ventana de deploy es el otro lado de la moneda del backup (porque el deploy malo es la forma más común de generar el incidente que va a exigir restore), lee Rolling deploy seguro: por qué el tuyo puede no serlo.

Backup que nunca fue restaurado es placebo. La diferencia entre placebo y remedio aparece exactamente una vez, exactamente cuando no puedes elegir.