Antes de iniciar la instalación de Barman en un servidor Linux, necesitamos información adicional sobre sus necesidades de recuperación ante desastres. Además, quisiéramos colaborar con ustedes para entender y/o ayudarles a definir sus procesos de recuperación ante desastres.
Este documento detalla la información necesaria para iniciar de forma correcta una instalación de Barman. Por favor, rellenen la última página del documento lo mejor posible con la información solicitada.
Acceso al servidor
Para instalar y configurar Barman necesitaremos acceder a los servidores Barman y PostgreSQL a través del protocolo SSH. Por favor, indíquennos si podemos acceder a ellos directamente utilizando un pool de direcciones IP estáticas de confianza o si necesitaremos acceder a través de una VPN.
Por qué es necesario un servidor independiente para Barman
SystemGuards recomienda encarecidamente tener un servidor separado dedicado a Barman, posiblemente en un almacenamiento diferente al del servidor PostgreSQL.
Disponer de un servidor separado hace que la arquitectura general de los servidores PostgreSQL sea más sencilla y, por lo tanto, más fácil de mantener, especialmente cuando se trata de servidores standby.
Normalmente se sugiere compartir sólo la red entre el servidor PostgreSQL y Barman, para reducir el riesgo de pérdida de datos tras un fallo o un desastre, ambos inevitables.
Gracias a su funcionalidad "get-wal ", el archivo WAL de Barman puede ser utilizado como un contenedor "sin límites" por todos los servidores standby, y como método de respaldo en caso de problemas con la replicación en flujo (ver la sección "Integración con servidores standby " más abajo).
Además, otra razón importante es que el servidor Barman puede utilizarse como sala de control para las operaciones de recuperación, así como para el monitoreo (muy importante en caso de que se decida compartir el mismo servidor Barman con más servidores PostgreSQL).
SystemGuards sugiere mantener el servidor Barman cerca de los servidores PostgreSQL (si no en el mismo centro de datos. Por lo menos, hay que asegurarse de que la conectividad es suficiente, especialmente si la intención es utilizar Barman en un contexto de "cero pérdida de datos " con RPO=0.
De qué servidor(es), Barman realizará respaldos
SystemGuards necesitará las direcciones IP y los nombres de host de los servidores PostgreSQL de los que se desea hacer un respaldo con Barman, incluyendo su versión de PostgreSQL. Si está disponible, también se solicita la dirección IP y el nombre de host del servidor Barman.
Espacio en disco necesario para Barman
Barman se utilizará para realizar respaldos de uno o más servidores PostgreSQL existentes. Para estimar la cantidad de espacio en disco necesario para Barman, es importante que SystemGuards sepa lo siguiente:
- Tamaño total de todas las bases de datos en el servidor PostgreSQL
- Índice de producción de WAL
- Frecuencia de los respaldos completos (semanal/diaria)
- Políticas de retención requeridas por la empresa (por ejemplo, 4 semanas o los últimos 2 respaldos)
- Previsión de incremento del volumen de la base de datos
Es posible utilizar el colector de datos de SystemGuards para obtener información sobre el servidor de producción PostgreSQL, en particular el tamaño de la instancia y la producción de WAL. Recomendamos recolectar al menos dos muestras para poder estimar el número de WALs generados por el servidor PostgreSQL dentro de ese marco de tiempo. Es importante seleccionar un período de tiempo adecuado para las muestras de datos.
¿Máquina virtual o servidor físico?
¿Barman funcionará en una máquina virtual o en un servidor físico dedicado? SystemGuards sugiere elegir el enfoque que mejor se adapte a las necesidades de la empresa. Barman simplemente necesita espacio en disco y núcleos (dependiendo del número de servidores PostgreSQL que necesitan ser respaldados y de su tamaño).
Distribuciones de Linux
SystemGuards desarrolla y da soporte a los paquetes Barman para las principales distribuciones de Linux. Es necesario saber en qué distribución se instalará el servidor Barman.
Tipo de almacenamiento
Por favor, indíquenos cuál va a ser su estrategia de almacenamiento con Barman, como discos locales en un servidor físico, o un volumen NFS en una máquina virtual en VMWare, etc.
Método de respaldo
Barman admite los dos siguientes métodos de respaldo:
- rsync/ssh: este método requiere una conexión SSH sin contraseña entre el servidor Barman (usuario barman) y el servidor PostgreSQL (usuario postgres). Una de las ventajas de este método es que es que permite realizar respaldos incrementales (a través de enlaces físicos) y la compresión de red.
- postgres: este método se basa en pg_basebackup, la principal aplicación para realizar respaldos físicos, que se distribuye junto con PostgreSQL. pg_basebackup requiere una conexión de replicación en flujo de PostgreSQL entre el servidor Barman y el servidor PostgreSQL. Aunque este método no requiere una conexión SSH, no soporta el respaldo incremental y la compresión de red. Se requiere PostgreSQL 9.1 (o versiones superiores). Esta es la única opción si ejecuta PostgreSQL en Windows.
Servidor(es) de recuperación dedicado(s)
Un respaldo que no ha sido probado no es un respaldo válido
(Lema de SystemGuards)
Se sugiere que uno o más servidores estén dedicados a la recuperación, incluyendo la Inteligencia de Negocios o para finalidades de ensayo. Gracias a los scripts de enlace estándar, Barman permite a los usuarios configurar una reconstrucción automatizada de los servidores PostgreSQL de recuperación, lo cual hace posible realizar pruebas no supervisadas de los respaldos.
Integración con infraestructuras de monitoreo
El monitoreo es la característica más importante de una infraestructura de TIC (Tecnologías de la Información y la Comunicación) con requisitos de continuidad de negocio. Una de las principales razones que motivaron la creación de Barman es la integración con herramientas de monitoreo.
El comando barman check ha estado presente desde el primer prototipo de Barman y es un método muy práctico para comprobar que todos los componentes principales de una solución de recuperación ante desastres para PostgreSQL estén funcionando sin problemas. Si Nagios/Icinga están en uso, Barman puede trabajar nativamente como un agente NRPE. Comuníquennos si tienen previsto monitorear Barman de forma proactiva - tal como recomendamos.
Objetivo de Punto de Recuperación (RPO)
RPO es el acrónimo en inglés de Objetivo de Punto de Recuperación (Recovery Point Objective). Se trata de una métrica de continuidad de negocio que define el "período máximo previsto durante el cual podrían perderse datos de algún servicio de TI debido a un incidente grave". Correctamente configurada, una solución de código abierto compuesta por Barman y PostgreSQL, combinada con la replicación en flujo, puede alcanzar un RPO de 0. Indíquennos el RPO deseado para su base de datos PostgreSQL.
Objetivo de Tiempo de Recuperación (RTO)
RTO es el acrónimo en inglés de Objetivo de Tiempo de Recuperación (Recovery Time Objective). Se trata de una métrica de continuidad de negocio que define la "duración objetivo del tiempo y del nivel de servicio en el que un proceso de negocio deberá ser restaurado tras un desastre (o interrupción) con el fin de evitar consecuencias inaceptables asociadas a una interrupción de la continuidad de negocio ". En Barman, esto se mide generalmente por el tiempo que se necesita para recrear un servidor PostgreSQL desde cero y recuperar los últimos datos disponibles (o hasta un punto en el tiempo) de un respaldo disponible. Indíquennos su RTO deseado.
S3 Retransmisión
Hágannos saber si desean que Barman transfiera tanto los archivos WAL como los respaldos base a su bucket de Amazon S3 en el cloud, haciendo que su solución de recuperación ante desastres sea más resiliente.
Integración con servidores standby
Barman almacena los archivos WAL de todos los respaldos. Por lo tanto, dependiendo de la configuración de la política de retención, es posible contar con archivos WAL de varios días/semanas/meses.
Gracias al comando get-wal de Barman y al paquete barman-cli (que debe instalarse en todos los servidores PostgreSQL), en caso de problemas de conexión temporales o prolongados con la replicación en flujo, el servidor standby puede extraer de Barman los archivos WAL requeridos.
Hágannos saber si este es su caso de uso y/o si planean integrar Barman con repmgr, una tecnología (de código abierto) líder para la alta disponibilidad en PostgreSQL, desarrollada y mantenida por 2ndQuadrant.
Formación y simulaciones para la recuperación ante desastres
En SystemGuards valoramos las pruebas periódicas y las simulaciones de desastres. Por favor, hágannos saber si desean obtener una formación básica sobre Barman y la recuperación ante desastres, así como asistencia con su plan de recuperación ante desastres de PostgreSQL. Pregunten por nuestro programa de formación sobre Barman y procedimientos de simulación de recuperación ante desastres.
Preguntas adicionales
No duden en consultarnos si necesitan más información sobre Barman y cómo proceder con su instalación.
Cuestionario inicial sobre Barman
- ¿Dónde se encuentra el servidor de Barman?
- En el mismo centro de datos que PostgreSQL
- En un centro de datos diferente pero en la misma área metropolitana
- En un centro de datos remoto
- ¿Cómo accederemos a sus servidores? Para instalar y configurar Barman necesitaremos acceder a los servidores Barman y PostgreSQL a través de SSH. Por favor, dígannos si podemos acceder a ellos directamente usando un pool de direcciones IP estáticas de confianza o si necesitaremos acceder a través de una VPN.
- Enumeren las direcciones IP y los nombres de host de los servidores PostgreSQL que deben ser respaldados con Barman (incluyendo su número de versión):
- ¿Dónde alojarán a Barman?
- Máquina virtual
- Servidor físico
- ¿Qué distribución de Linux instalarán en el servidor de Barman?
- CentOS 7
- RHEL 7
- Ubuntu 16.04
- Otro (especifiquen)
- ¿Qué tipo de almacenamiento utilizarán?
- Discos locales
- Volumen NFS en una máquina virtual en VMWare
- Otros (especifiquen)
- Por favor, indiquen el espacio en disco necesario para lo siguiente
- Tamaño total de todas las bases de datos en el servidor PostgreSQL
- Ritmo de producción de WAL
- Frecuencia de los respaldos completos (semanal/diaria)
- Políticas de retención requeridas por su empresa (por ejemplo, 4 semanas o los 2 últimos respaldos)
- Índice de incremento estimado del volumen de la base de datos
- ¿Qué método de respaldo prefieren utilizar?
- rsync/ssh
- pg_basebackup de PostgreSQL
- ¿Cuál es su Objetivo de Punto de Recuperación (RPO) deseado?
- ¿Cuál es su Objetivo de Tiempo de Recuperación (RTO) deseado?
- ¿Estan pensando en transferir sus archivos a S3?
- ¿Necesitan integración con una infraestructura de monitoreo?
- ¿Tendrán un servidor o servidores dedicados para la recuperación?
- ¿Necesitarán integración con servidores standby?
- ¿Desean recibir formación sobre recuperación ante desastres y simulaciones?