Backups y replicación de PostgreSQL para alta disponibilidad
Configuramos backups y replicación para PostgreSQL: copias automáticas que permiten recuperar la base a un momento exacto, réplicas que toman el control si el servidor principal falla y servidores de solo lectura para repartir la carga. Probamos la restauración y la conmutación para que el plan funcione cuando lo necesites.
Te respondemos con una propuesta concreta. Sin compromiso.
Backups y réplicas no son lo mismo
Un backup es una copia guardada para volver atrás; una réplica es una copia viva, sincronizada en todo momento con el servidor principal. Se complementan, pero ninguna reemplaza a la otra: si alguien borra una tabla por error, la réplica también la borra en segundos, y solo un backup permite recuperarla. A la inversa, un backup no evita que la aplicación quede fuera de servicio mientras se restaura. Este trabajo forma parte de nuestro servicio de PostgreSQL.
Estrategias de backup en PostgreSQL
| Tipo de copia | Herramientas | Para qué sirve |
|---|---|---|
| Lógica | pg_dump | Copias portables, restaurar tablas puntuales o mover datos a otra versión |
| Física | pg_basebackup, pgBackRest, Barman | Copia completa del servidor, rápida de restaurar en bases grandes |
| Archivo continuo de cambios | pgBackRest, WAL-G | Recuperación a un momento exacto, combinada con una copia física |
En la mayoría de los proyectos combinamos copias físicas con archivo continuo para la recuperación ante desastres, y volcados lógicos periódicos para restauraciones puntuales.
Innovación en emprendimientos
¿Lo pensamos para tu proyecto?
Replicación para alta disponibilidad
La replicación en streaming es la forma nativa de PostgreSQL de mantener una o más réplicas: el servidor principal envía cada cambio a las réplicas apenas ocurre. Con ella resolvemos tres necesidades:
- Servidor en espera listo para tomar el control si el principal falla.
- Réplicas de lectura para reportes, análisis o consultas de solo lectura de la aplicación.
- Conmutación automática, con herramientas que detectan la caída del principal, promueven una réplica y redirigen las conexiones.
También usamos replicación lógica, que copia solo algunas tablas, para casos como sincronizar datos con otro sistema o preparar una actualización de versión de PostgreSQL con un corte mínimo.
Cuándo lo necesitás
- Tu base corre en un solo servidor, sin respaldo en caliente.
- Tenés copias, pero nunca probaste restaurarlas.
- Los reportes frenan la aplicación en horario laboral.
- Un cliente o un contrato te exige continuidad del servicio.
Cómo lo hacemos
- Definimos con vos dos valores: cuántos datos podés permitirte perder y cuánto tiempo puede estar caído el sistema.
- Diseñamos la arquitectura de copias y réplicas que cumple esos valores.
- Implementamos las copias, el archivo continuo, las réplicas y el monitoreo.
- Probamos la restauración a un momento exacto en un servidor aparte.
- Simulamos una caída del principal y medimos cuánto tarda la conmutación.
- Documentamos el procedimiento paso a paso, para que cualquiera pueda seguirlo bajo presión.
Qué recibís
- Copias automáticas fuera del servidor, cifradas y con retención definida.
- Réplicas configuradas y monitoreadas, con alertas de atraso.
- Un procedimiento de recuperación y de conmutación probado.
- El registro de cada prueba, con sus tiempos reales.
Si tu base es MySQL, el enfoque usa otras herramientas; lo explicamos en backups y recuperación de MySQL.
Preguntas frecuentes
¿Tenés otra duda? Escribinos por WhatsApp.
¿Qué es la recuperación a un punto en el tiempo?
Es la posibilidad de restaurar la base tal como estaba en un instante preciso, por ejemplo un minuto antes de que alguien borrara datos por error. Se logra combinando una copia completa con el archivo continuo de los registros de cambios de PostgreSQL, que se aplican sobre esa copia hasta el momento elegido.
¿Puedo usar una réplica para los reportes?
Sí, y es uno de sus mejores usos. Una réplica de solo lectura recibe todos los cambios del servidor principal y permite correr reportes pesados, exportaciones o herramientas de análisis sin cargar la base que atiende a tus usuarios. Hay que tener en cuenta que puede ir unos instantes atrasada respecto del principal.
¿Qué pasa si se cae el servidor principal?
Con una réplica en espera, esa réplica se promueve a servidor principal y la aplicación pasa a conectarse con ella. Ese cambio puede ser manual, siguiendo un procedimiento documentado, o automático, con herramientas que detectan la caída y promueven la réplica solas. Elegimos según cuánto tiempo sin servicio puede tolerar tu negocio.
¿Dónde se guardan las copias de seguridad?
Siempre fuera del servidor de la base, en un almacenamiento de objetos de otro proveedor o de otra región. Las copias van cifradas, con acceso restringido y una política de retención que define cuántas copias diarias, semanales y mensuales se conservan. Así un problema en el servidor o en la cuenta principal no compromete las copias.
¿La replicación hace más lento el servidor principal?
En modo asincrónico el impacto es mínimo, porque el principal no espera a la réplica para confirmar cada operación. En modo sincrónico sí espera, lo que garantiza no perder datos ante una falla pero agrega una demora a cada escritura. Lo definimos según cuánto pesa cada factor para tu aplicación.
Pedí tu presupuesto
Backups y replicación de PostgreSQL para alta disponibilidad, pensado para tu emprendimiento. Contanos qué necesitás y te respondemos con una propuesta.
- Tres pasos, menos de dos minutos.
- Propuesta concreta, sin compromiso.
- Si preferís, lo hablamos por WhatsApp.
- Qué necesitás
- Tu proyecto
- Tus datos
También te puede servir
- Backups automáticos y recuperación de bases de datos MySQL MySQL
- Backups y recuperación de proyectos Supabase en la nube y self-hosted Supabase
- Mantenimiento y monitoreo de bases de datos PostgreSQL PostgreSQL
- Diseño de bases de datos PostgreSQL pensadas para crecer PostgreSQL
- Instalación y configuración de servidores PostgreSQL para producción PostgreSQL
- Actualización de versión de PostgreSQL sin perder datos PostgreSQL