Una de las preguntas más frecuentes que se nos hace es: "¿Puedo instalar Barman en el mismo servidor donde se encuentra PostgreSQL?". Los autores de Barman explican la razón por la que decidieron diseñar el software con una arquitectura shared nothing y trabajar desde el principio de forma remota.

Barman fue concebido para ser instalado en un servidor separado, ubicado en el mismo centro de datos en el cual se encuentra el cluster (o los clústeres) de PostgreSQL que se desea respaldar.

Aunque para fines de evaluación, desarrollo y pruebas es posible instalar Barman en el mismo host en el que reside PostgreSQL (utilizando SSH a localhost), para entornos de producción recomendamos utilizar un servidor dedicado para Barman. Tanto los servidores físicos como los virtuales pueden ser una buena opción, siempre y cuando el hardware y el almacenamiento no se compartan con el servidor de la base de datos.

A continuación presentamos una breve lista de razones que justifican esta opción.

1. Los respaldos seguirán estando disponibles tras un fallo de hardware en el servidor PostgreSQL
   

2. Mantener Barman independiente de cualquier servidor que sea parte de un clúster de replicación mejora el mantenimiento del clúster durante las operaciones de switchover y failover, y las hace más rápidas (por haber menos tareas que realizar)

3. Barman actúa como un nodo testigo y, si se integra en la infraestructura de monitorización, aumenta la robustez del clúster (véase el comando barman check y su opción  --nagios )

4. Si Barman se encuentra en un tercer nodo, es posible implementar un cluster de 3 nodos con replicación sincrónica (Barman actúa como fall-back ) y realizar respaldos sin pérdida de datos
   

5. Es posible realizar un respaldo desde un standby, reduciendo el impacto de E/S en el servidor maestro
   

6. Un enfoque basado en la arquitectura shared nothing entre el servidor Barman y Postgres reduce en gran medida el riesgo de pérdida de datos y reduce el impacto en el servidor maestro
   

7. Un servidor Barman separado hace posible que los servidores standby se beneficien de la función  barman-wal-restore y get-wal , la cual incrementa su resiliencia

8. Es posible aprovechar las ventajas de las copias en paralelo
   

9. Un servidor independiente dedicado a los respaldos favorece las pruebas de recuperación y se adapta mejor a los planes de recuperación ante desastres para simulaciones periódicas de recuperación ante fallos
   

Esta es la arquitectura típica que recomendamos e implementamos en las instalaciones de nuestros clientes, la cual permite alcanzar objetivos de continuidad operacional muy elevados, como un RTO y RPO = 0 (o ~0 si no se utiliza la replicación sincrónica).