Copied to Clipboard
Este tipo de medición es exactamente lo que los logs de producción revelan cuando te forzás a mirarlos en frío, sin la adrenalina de un incidente.
FAQ: pgbackrest alternativa postgres backup producción
¿WAL-G es un reemplazo directo de pgbackrest?
Funcionalmente sí, en la mayoría de los casos. Ambos manejan backups base + WAL archiving con PITR. La diferencia principal está en la configuración: WAL-G es más simple de arrancar (un binario, variables de entorno) mientras que pgbackrest tiene un archivo de configuración más expresivo. Si ya tenés pgbackrest configurado, la migración a WAL-G implica reescribir la config y hacer un primer backup base completo desde cero — no podés reutilizar los backups existentes de formato distinto.
¿Barman sigue valiendo la pena si ya tenés infra dedicada?
Sí, especialmente si manejás múltiples instancias de Postgres y necesitás una interfaz operacional centralizada con auditoría. El overhead de tener un servidor Barman separado se amortiza cuando gestionás 5+ instancias desde un solo lugar. Para una sola instancia como la mía, es overkill con costo real.
¿pg_dump alcanza para producción o es solo para desarrollo?
Depende de tu RTO y RPO. Si podés tolerar pérdida de hasta N horas de datos (donde N es la frecuencia de dumps) y un restore de 20-40 minutos no te rompe ningún SLA, pg_dump con rotación automatizada es completamente válido. La limitación real es la ausencia de PITR: no podés recuperar a un punto exacto entre dos dumps. Para bases transaccionales críticas, eso suele ser inaceptable.
¿Cómo configuro WAL archiving en Railway o Supabase?
En Railway con Postgres custom podés configurar archive_mode = on y archive_command si tenés acceso al postgresql.conf. En Supabase el WAL archiving es interno al servicio — podés usar Point in Time Recovery dentro de la plataforma pero no exportar WAL a storage externo directamente. Eso es un vendor lock-in de recovery que vale la pena evaluar según la criticidad del dato.
¿Qué frecuencia de backup base tiene sentido?
Para la mayoría de los casos: backup base diario + WAL continuo. Un backup base semanal con WAL continuo es aceptable si la base crece lento (bajo 500 MB/día de WAL). Con backup base diario, el replay de WAL en restore es mínimo. Con backup semanal, en el peor caso necesitás aplicar 7 días de WAL — eso puede sumar decenas de minutos dependiendo del volumen de escritura.
¿Vale la pena esperar a ver si pgbackrest retoma el mantenimiento?
No. En sistemas de infra, un maintainer que anuncia falta de tiempo disponible raramente vuelve con más energía. La ventana de riesgo entre "proyecto sin mantenimiento activo" y "vulnerabilidad crítica sin parchear" puede ser corta. Migrá ahora con tiempo, no durante un incidente. El costo de migrar en calma es infinitamente menor que el costo de migrar bajo presión — algo que aprendí la noche que tiré un servidor de producción con rm -rf en mi primera semana de laburo.
Qué elegí y por qué no es la respuesta para todos
Me quedé con WAL-G + pg_dump como segunda línea.
WAL-G maneja los backups incrementales con PITR. pg_dump corre cada 24 horas y va a un bucket S3 separado como fallback independiente — sin dependencias de herramientas de terceros, sin binarios especiales, solo pg_dump y aws s3 cp. Si WAL-G desapareciera mañana, tengo un dump de ayer.
El criterio que usé no fue "qué tool tiene más stars" sino "qué tan rápido puedo recuperar y con cuántas dependencias en la cadena de recovery". Menos dependencias en el path crítico es mejor. Cuando tenés que restaurar una base de datos, cada pieza adicional que puede fallar es un problema que no necesitás.
Lo que no elegiría para mi caso: Barman en una sola instancia. El overhead operacional no cierra. Puede tener sentido para equipos con múltiples bases y un DBA dedicado — pero eso no es mi realidad.
Lo incómodo de todo esto: pasé dos años con pgbackrest sin haber medido un restore real. El thread de HN no me rompió la infra — me rompió la tranquilidad falsa. Y eso, a la larga, fue mejor que seguir con una servilleta mojada en el bolsillo.
Si querés revisar qué más puede estar en estado de "funciona hasta que no funciona" en la capa de datos, el post sobre migrar de Notion a Markdown tiene algo de ese mismo sabor: la dependencia silenciosa que solo duele cuando intentás salir.
Y si hacés el switch a WAL-G, medí el restore. No lo asumas. El número real siempre es distinto del número imaginado.
¿Estás migrando de pgbackrest o evaluando opciones? Escribime — estoy armando un repositorio de configuraciones reales de WAL-G para Railway específicamente.
Este artículo fue publicado originalmente en juanchi.dev