La versión corta

Si tienes un SaaS pequeño sobre Postgres, la pregunta no es si vas a respaldar, sino qué combinación de herramientas y frecuencias se ajusta a los datos que realmente te dolería perder. Tres caminos cubren casi cualquier proyecto independiente:

  • Snapshots gestionados: tu proveedor de base de datos (o un servicio de Postgres administrado) hace copias periódicas por ti.
  • Volcados lógicos con cron: un pg_dump programado (o el equivalente de tu plataforma) escribe un archivo portátil que tú controlas.
  • Recuperación a un punto en el tiempo (PITR): la base de datos conserva un registro continuo para que puedas restaurar a cualquier momento, no solo a “el último respaldo”.

La mayoría de los equipos no elige solo uno. La combinación que suele funcionar en un SaaS pequeño es: un snapshot gestionado diario como red de seguridad, un pg_dump diario que puedas mover, y PITR encendido si tu proveedor lo ofrece a buen precio.

El resto de esta guía explica por qué, cada cuánto tiene sentido, y el único hábito que convierte un respaldo de una carpeta llena de archivos a algo que de verdad puede salvar tu negocio: restaurar uno a propósito, de forma periódica.

Por qué esto es un problema de fundador, no solo de DBA

Los respaldos parecen fontanería hasta el día que los necesitas. Entonces son lo único que se interpone entre tú y un evento que rompe la confianza del cliente. Para un fundador en solitario o un equipo pequeño, perder la base de datos se manifiesta en tres cosas a la vez:

  • Caídas que tus usuarios de pago notan en tiempo real.
  • Daño reputacional difícil de arreglar cuando tu base de clientes es pequeña.
  • Trabajo perdido: cada evento, registro, integración y dato que tu app ha recopilado.

Como el equipo es chico, no tienes a una persona de operaciones dedicada a descubrir el problema. También eres tú quien elige la herramienta. Por eso es una decisión de compra disfrazada de decisión técnica: eliges entre infraestructura gestionada, un pequeño script programado, o algo intermedio.

Los tres caminos, explicados en lenguaje claro

1. Snapshots gestionados (el “lo maneja el proveedor”)

La mayoría de los servicios de Postgres administrado y de las grandes nubes pueden tomar snapshots automáticos de forma programada: diarios, por hora, a veces continuos. Se guardan en el almacenamiento del proveedor, normalmente en una zona de disponibilidad distinta.

Por qué gusta a los fundadores:

  • Se configura una vez y te olvidas.
  • Los snapshots suelen ser consistentes a nivel de almacenamiento, así que no te preocupas por una transacción a medias.
  • Restaurar son uno o dos clics en un panel.

Los trade-offs honestos:

  • Dependes de la ventana de retención del proveedor. Si guardan siete snapshots diarios y la corrupción tiene ocho días, estás perdido.
  • Restaurar suele significar restaurar todo el clúster, no una tabla concreta.
  • Confías en un solo proveedor tanto para la base como para la copia. Si su cuenta se ve comprometida, ambas pueden caer.
  • El coste escala con el tamaño de la base y la retención, y puede crecer silenciosamente.

Un snapshot por sí solo rara vez basta para un SaaS pequeño. Es el suelo correcto, pero no el techo.

2. Volcados lógicos con pg_dump y una programación (el “archivo portátil que te pertenece”)

pg_dump es la herramienta incluida en Postgres que exporta tu base como un script o un archivo comprimido. Es el respaldo más portable que Postgres puede producir: el resultado se puede cargar en otra versión de Postgres, en otro host, en otra nube.

Por qué gusta a los fundadores:

  • El resultado es un archivo normal que puedes copiar a cualquier parte: almacenamiento de objetos, otra región, tu portátil para staging.
  • Selectivo: puedes respaldar una base de datos o un esquema, no solo todo.
  • Barato: la herramienta es gratis; el almacenamiento cuesta céntimos por gigabyte.
  • Fácil de automatizar con cron, GitHub Actions o un contenedor programado.

Los trade-offs honestos:

  • Restaurar es más lento que con un snapshot, porque Postgres tiene que reejecutar SQL o reconstruir desde un archivo.
  • La base de datos debe estar en línea para ejecutar pg_dump. Normalmente está bien, pero importa en bases muy grandes donde la ventana del volcado empieza a doler.
  • Un volcado lógico no te da PITR. Obtienes lo que existía en el momento del volcado, nada intermedio.

Para una app independiente de pocos gigabytes, un pg_dump diario es rápido, barato y silenciosamente tranquilizador.

3. Recuperación a un punto en el tiempo (PITR) (el “rebobina el reloj”)

PITR es la capacidad de restaurar la base a un momento exacto, no solo al “último respaldo”. Por dentro funciona combinando un snapshot base con un flujo continuo de registros WAL. La mayoría de los servicios gestionados ofrecen PITR como extra de pago, y la herramienta de código abierto pgBackRest es una vía popular para conseguirlo en Postgres autoalojado.

Por qué PITR importa en un SaaS pequeño:

  • Una migración mala a las 14:00 ya no significa restaurar el volcado de anoche y perder un día entero.
  • Un ransomware o un DELETE con dedo gordo se convierte en un incidente de 15 minutos en lugar de algo que acaba con el negocio.
  • El punto de recuperación que puedes anunciar a clientes pasa de días a horas.

Los trade-offs honestos:

  • PITR suele costar extra: una tarifa del proveedor gestionado, o trabajo de ingeniería real si lo autoalojas con pgBackRest.
  • Aun así necesitas snapshots y archivo de WAL; PITR es una capa por encima, no un sustituto.
  • La retención sigue siendo finita. Si tu archivo de WAL solo guarda 7 días, no puedes rebobinar más.

Una programación de respaldos realista para un SaaS pequeño

“¿Cada cuánto respaldo?” es la pregunta equivocada para empezar. La correcta es: ¿cuánto trabajo estoy dispuesto a perder?

  • Una app de datos de clientes de 10 GB que pierde un día de registros tiene una respuesta muy distinta a un sistema transaccional que pierde una hora de pagos.
  • Define un objetivo de punto de recuperación (RPO): la cantidad máxima de datos que tolerarías perder, y trabaja hacia atrás.

Un punto de partida práctico para un SaaS pequeño:

Capa Frecuencia Herramienta Por qué
Suelo Diaria Snapshot gestionado La red de seguridad del proveedor.
Copia portable Diaria pg_dump a almacenamiento de objetos Un archivo que te pertenece, fuera del host.
Granularidad (opcional) WAL continuo PITR Rebobina a cualquier momento.
En cada despliegue Por release Volcado disparado antes de migraciones Seguro barato durante cambios arriesgados.

Si PITR es demasiado caro ahora, snapshot diario + pg_dump diario es una base respetable. Si perder un día de registros dolería de verdad, añade PITR: esa única mejora suele cambiar todo el perfil de riesgo.

El hábito que importa más que la herramienta: simulacros de restauración

Un respaldo que nunca has restaurado es una esperanza, no un plan. El mayor modo de fallo para equipos pequeños es descubrir, durante una caída, que el respaldo está corrupto, que es de la base equivocada, de la región equivocada, o que el script de restauración no funciona con la versión actual de Postgres.

Una rutina sencilla que de verdad aguanta:

  1. Trimestral, restaura tu último volcado en una base de datos nueva. Usa un nombre distinto, un host distinto si puedes, y una versión reciente de Postgres. Cronométralo.
  2. Compara el conteo de filas de las tablas más importantes (usuarios, pedidos, eventos). No tienen que coincidir al segundo, pero la tendencia debe ser sensata.
  3. Prueba una restauración PITR si la usas: restaura a un momento diez minutos antes, confirma que puedes conectar, y luego elimínala.
  4. Documenta el tiempo que tardó. Ahora tienes un número real para tu objetivo de tiempo de recuperación, no una suposición.
  5. Guarda credenciales y scripts en el mismo lugar donde buscarías durante un incidente real. Una entrada en el gestor de contraseñas etiquetada como “runbook de restauración de BD” es suficiente.

Trata una restauración fallida como la alerta que es. Una cadena de respaldos rota no es algo que arreglas “luego”; es algo que arreglas hoy.

Dónde vive el almacenamiento importa

Respaldos que están en la misma cuenta, región o proveedor que tu base de datos son vulnerables a los mismos incidentes: compromiso de cuenta, caída regional, borrado accidental del proyecto entero. Sácalos fuera.

Para un SaaS pequeño, un bucket de almacenamiento de objetos en otro proveedor o región suele bastar. Cifra los archivos, restringe el bucket y actíta el versionado para que un script malo no sobrescriba silenciosamente todos tus respaldos.

Lista para fundadores antes de elegir

  • ¿Cuál es mi RPO? ¿Horas o minutos? Esto decide si PITR merece el gasto.
  • ¿Cuál es mi RTO? ¿Cuánto puede estar caída la app antes de que los clientes se vayan?
  • ¿Dónde viven los respaldos? ¿En la misma cuenta que la base o en otro sitio?
  • Quién puede restaurar? ¿Solo tú u otra persona del equipo?
  • Cuándo fue la última vez que demostré poder restaurar? Si la respuesta es “nunca”, ese es el primer problema a resolver.

No necesitas un sistema perfecto el día uno. Necesitas uno documentado y que de verdad hayas probado.

Preguntas frecuentes

¿Basta con un snapshot gestionado por sí solo? Es un suelo sensato, pero concentra el riesgo con un proveedor y normalmente no te da PITR. Combinarlo con un pg_dump fuera del host es la configuración habitual de un equipo independiente.

¿Cada cuánto debería ejecutar pg_dump? Para la mayoría de SaaS pequeños, diario es un valor por defecto razonable. Súbelo si tu app escribe muchos datos importantes por hora, o si perder un día de trabajo afectaría de verdad a tus clientes.

¿Realmente necesito PITR en una app pequeña? No necesariamente. Si un volcado diario tiene suficiente granularidad para el valor que genera tu app, sáltalo. Si procesas pagos, formalizas contratos o guardas contenido generado por usuarios de forma continua, PITR suele pagarse solo la primera vez que lo necesitas.

¿Dónde debería guardar los archivos del volcado? Fuera de la cuenta de la base de datos, en almacenamiento de objetos cifrado y con versionado. La idea es que un único fallo a nivel de cuenta no pueda borrar a la vez la base y sus respaldos.

Fuentes