Ansible PostgreSQL: Automatiza Backups De Bases De Datos 2025

Ansible PostgreSQL es la solución definitiva para automatizar backups de bases de datos de manera profesional y confiable. En esta guía completa, aprenderás a crear playbooks robustos para respaldar PostgreSQL, configurar políticas de retención automáticas, y gestionar restauraciones de emergencia con total confianza y seguridad operativa.

Los backups manuales de bases de datos son propensos a errores humanos, consumen tiempo valioso del equipo DevOps y no escalan cuando gestionas múltiples instancias PostgreSQL. Ansible transforma este proceso crítico en automatización declarativa, idempotente y reproducible.

¿Qué es Ansible PostgreSQL para Backups Automatizados?

Ansible PostgreSQL combina la potencia de Ansible como plataforma de automatización con los módulos especializados de la colección community.postgresql para gestionar el ciclo completo de vida de backups de bases de datos. Esta integración permite automatizar tareas complejas como dumps programados, compresión, transferencia a almacenamiento remoto y validación de integridad.

Las ventajas principales incluyen:

Idempotencia garantizada: Los playbooks ejecutan cambios solo cuando es necesario
Consistencia multi-entorno: Mismo código para desarrollo, staging y producción
Disaster recovery automatizado: Restauraciones reproducibles en minutos
Escalabilidad horizontal: Gestiona decenas de servidores PostgreSQL desde un solo control node
Auditoría completa: Cada ejecución queda registrada con logs estructurados

Arquitectura de Backups con Ansible PostgreSQL

La arquitectura típica de Ansible PostgreSQL para backups consta de tres componentes principales:

En el Control Node (donde ejecutas Ansible)

Ansible Core 2.14 o superior: ansible --version
Python 3.8 o superior
Colección community.postgresql instalada: ansible-galaxy collection install community.postgresql
Acceso SSH configurado a los managed nodes

En los Managed Nodes (servidores PostgreSQL)

PostgreSQL 12 o superior instalado y funcionando
Python 3 con módulo psycopg2: apt install python3-psycopg2 libpq-dev (Debian/Ubuntu) o yum install python3-psycopg2 (RHEL/CentOS)
Usuario postgres con permisos de lectura en las bases de datos
Espacio en disco suficiente para almacenar backups temporales

Conocimientos Previos Recomendados

Sintaxis básica de YAML para escribir playbooks
Fundamentos de PostgreSQL: pg_dump, pg_restore, roles y permisos
Gestión de credenciales con Ansible Vault (crítico para producción)

Instalación y Configuración Inicial de Ansible PostgreSQL

Comencemos configurando el entorno para automatizar backups con Ansible PostgreSQL:

Paso 1: Instalar la Colección PostgreSQL

# Instalar colección community.postgresql
ansible-galaxy collection install community.postgresql

# Verificar instalación
ansible-galaxy collection list | grep postgresql

Paso 2: Crear Estructura de Directorios

# Estructura recomendada para proyecto de backups
mkdir -p ansible-postgresql-backup/{playbooks,inventory,group_vars,roles,backups}
cd ansible-postgresql-backup

# Crear inventario
cat > inventory/hosts.ini <<EOF
[postgresql_servers]
db1.example.com ansible_user=ubuntu
db2.example.com ansible_user=ubuntu

[postgresql_servers:vars]
ansible_python_interpreter=/usr/bin/python3
EOF

Paso 3: Configurar Variables de Grupo

# group_vars/postgresql_servers.yml
---
postgres_user: postgres
postgres_databases:
  - production_db
  - analytics_db

backup_dir: /var/backups/postgresql
backup_retention_days: 7
backup_compression: true

# Credenciales (cifrar con ansible-vault en producción)
postgres_password: "{{ vault_postgres_password }}"

Crear Playbook de Backup con Ansible PostgreSQL

Ahora vamos a crear el playbook principal para automatizar backups de Ansible PostgreSQL. Este playbook es production-ready e incluye manejo de errores, validación y logging:

---
# playbooks/postgresql_backup.yml
- name: Backup PostgreSQL databases with Ansible
  hosts: postgresql_servers
  become: yes
  vars:
    timestamp: "{{ ansible_date_time.iso8601_basic_short }}"

  tasks:
    - name: Ensure backup directory exists
      file:
        path: "{{ backup_dir }}"
        state: directory
        owner: postgres
        group: postgres
        mode: '0700'

    - name: Install psycopg2 dependency
      apt:
        name:
          - python3-psycopg2
          - libpq-dev
        state: present
        update_cache: yes
      when: ansible_os_family == "Debian"

    - name: Create backup for each database
      community.postgresql.postgresql_db:
        name: "{{ item }}"
        state: dump
        target: "{{ backup_dir }}/{{ item }}_{{ timestamp }}.sql.gz"
        login_user: "{{ postgres_user }}"
        login_password: "{{ postgres_password }}"
      loop: "{{ postgres_databases }}"
      become_user: postgres
      register: backup_result

    - name: Verify backup file size
      stat:
        path: "{{ backup_dir }}/{{ item }}_{{ timestamp }}.sql.gz"
      loop: "{{ postgres_databases }}"
      register: backup_stats
      failed_when: backup_stats.stat.size < 1024  # Mínimo 1KB

    - name: Fetch backups to control node
      fetch:
        src: "{{ backup_dir }}/{{ item }}_{{ timestamp }}.sql.gz"
        dest: "./backups/{{ inventory_hostname }}/"
        flat: yes
      loop: "{{ postgres_databases }}"

    - name: Remove old backups (retention policy)
      find:
        paths: "{{ backup_dir }}"
        patterns: "*.sql.gz"
        age: "{{ backup_retention_days }}d"
      register: old_backups

    - name: Delete old backup files
      file:
        path: "{{ item.path }}"
        state: absent
      loop: "{{ old_backups.files }}"
      when: old_backups.files | length > 0

    - name: Log backup completion
      debug:
        msg: "Backup completed for {{ postgres_databases | join(', ') }} at {{ timestamp }}"

Este playbook de Ansible PostgreSQL implementa las siguientes características críticas para producción:

Timestamp ISO 8601: Nombres de archivo únicos con fecha/hora
Compresión automática: Extensión .gz activa compresión gzip
Validación de tamaño: Falla si el backup es sospechosamente pequeño
Fetch a control node: Copia local para doble respaldo
Retención automática: Limpia backups antiguos según política
Idempotencia: Seguro ejecutar múltiples veces

Ejecutar Backup Manual con Ansible PostgreSQL

Para ejecutar el playbook de backup manualmente:

# Backup manual de todas las bases de datos
ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup.yml

# Backup de servidor específico
ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup.yml --limit db1.example.com

# Dry-run para verificar sin cambios
ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup.yml --check

# Ejecutar con más verbosidad para debugging
ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup.yml -vvv

Salida esperada de ejecución exitosa:

PLAY [Backup PostgreSQL databases with Ansible] *********************************

TASK [Ensure backup directory exists] *******************************************
ok: [db1.example.com]

TASK [Create backup for each database] ******************************************
changed: [db1.example.com] => (item=production_db)
changed: [db1.example.com] => (item=analytics_db)

TASK [Verify backup file size] **************************************************
ok: [db1.example.com] => (item=production_db)
ok: [db1.example.com] => (item=analytics_db)

PLAY RECAP **********************************************************************
db1.example.com            : ok=8    changed=2    unreachable=0    failed=0

Programar Backups Automáticos con Ansible PostgreSQL y Cron

Para backups verdaderamente automatizados, necesitas programar la ejecución del playbook Ansible PostgreSQL con cron. Hay dos enfoques recomendados:

Opción 1: Cron en el Control Node (recomendado)

# Editar crontab en control node
crontab -e

# Backup diario a las 2:00 AM
0 2 * * * cd /path/to/ansible-postgresql-backup && /usr/bin/ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup.yml >> /var/log/ansible-postgres-backup.log 2>&1

# Backup cada 6 horas
0 */6 * * * cd /path/to/ansible-postgresql-backup && /usr/bin/ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup.yml

Opción 2: Cron en Managed Nodes con Ansible

Alternativamente, puedes usar Ansible PostgreSQL para configurar cron jobs directamente en los servidores de bases de datos:

---
# playbooks/setup_backup_cron.yml
- name: Configure automated PostgreSQL backups
  hosts: postgresql_servers
  become: yes

  tasks:
    - name: Install backup script
      copy:
        dest: /usr/local/bin/postgres-backup.sh
        mode: '0755'
        content: |
          #!/bin/bash
          TIMESTAMP=$(date +%Y%m%d_%H%M%S)
          BACKUP_DIR="/var/backups/postgresql"

          for DB in production_db analytics_db; do
            pg_dump -U postgres $DB | gzip > $BACKUP_DIR/${DB}_${TIMESTAMP}.sql.gz
          done

          # Remove backups older than 7 days
          find $BACKUP_DIR -name "*.sql.gz" -mtime +7 -delete

    - name: Schedule daily backup at 2 AM
      cron:
        name: "PostgreSQL automated backup"
        minute: "0"
        hour: "2"
        job: "/usr/local/bin/postgres-backup.sh >> /var/log/postgres-backup.log 2>&1"
        user: postgres
        state: present

El enfoque de control node es preferible para equipos DevOps porque:

Centraliza la lógica de backup en un solo lugar
Facilita auditoría y troubleshooting
Permite integración con herramientas de monitoreo centralizadas
Simplifica gestión de credenciales con Ansible Vault

Restaurar Base de Datos con Ansible PostgreSQL

Un sistema de backups no está completo sin un proceso de restauración probado. Este playbook de Ansible PostgreSQL automatiza la restauración desde backups:

---
# playbooks/postgresql_restore.yml
- name: Restore PostgreSQL database from backup
  hosts: postgresql_servers
  become: yes
  vars_prompt:
    - name: database_name
      prompt: "Enter database name to restore"
      private: no

    - name: backup_file
      prompt: "Enter backup filename (e.g., production_db_20250124_020000.sql.gz)"
      private: no

    - name: confirm_restore
      prompt: "WARNING: This will DROP and recreate the database. Type 'yes' to confirm"
      private: no

  tasks:
    - name: Verify confirmation
      fail:
        msg: "Restore cancelled. User did not confirm."
      when: confirm_restore != "yes"

    - name: Check backup file exists
      stat:
        path: "{{ backup_dir }}/{{ backup_file }}"
      register: backup_check
      failed_when: not backup_check.stat.exists

    - name: Drop existing database (if exists)
      community.postgresql.postgresql_db:
        name: "{{ database_name }}"
        state: absent
        login_user: "{{ postgres_user }}"
        login_password: "{{ postgres_password }}"
      become_user: postgres

    - name: Create fresh database
      community.postgresql.postgresql_db:
        name: "{{ database_name }}"
        state: present
        owner: "{{ postgres_user }}"
        encoding: UTF8
        lc_collate: en_US.UTF-8
        lc_ctype: en_US.UTF-8
        login_user: "{{ postgres_user }}"
        login_password: "{{ postgres_password }}"
      become_user: postgres

    - name: Restore database from backup
      community.postgresql.postgresql_db:
        name: "{{ database_name }}"
        state: restore
        target: "{{ backup_dir }}/{{ backup_file }}"
        login_user: "{{ postgres_user }}"
        login_password: "{{ postgres_password }}"
      become_user: postgres
      register: restore_result

    - name: Verify restore success
      community.postgresql.postgresql_query:
        db: "{{ database_name }}"
        login_user: "{{ postgres_user }}"
        login_password: "{{ postgres_password }}"
        query: "SELECT COUNT(*) as table_count FROM information_schema.tables WHERE table_schema = 'public'"
      become_user: postgres
      register: table_count

    - name: Display restore summary
      debug:
        msg:
          - "Restore completed successfully"
          - "Database: {{ database_name }}"
          - "Backup file: {{ backup_file }}"
          - "Tables restored: {{ table_count.query_result[0].table_count }}"

Características de seguridad del playbook de restauración:

Confirmación interactiva: Requiere confirmación explícita del operador
Validación de archivo: Verifica que el backup existe antes de proceder
Drop y recreate: Garantiza estado limpio antes de restaurar
Verificación post-restore: Cuenta tablas para validar éxito
Logging detallado: Muestra resumen completo al finalizar

Ejecutar restauración:

# Restauración interactiva
ansible-playbook -i inventory/hosts.ini playbooks/postgresql_restore.yml --limit db1.example.com

# Restauración con parámetros (CI/CD)
ansible-playbook -i inventory/hosts.ini playbooks/postgresql_restore.yml \
  -e "database_name=production_db" \
  -e "backup_file=production_db_20250124_020000.sql.gz" \
  -e "confirm_restore=yes"

Integración con S3 para Ansible PostgreSQL

Para entornos enterprise, es crítico almacenar backups offsite. Este playbook extiende Ansible PostgreSQL con subida automática a AWS S3:

---
# playbooks/postgresql_backup_s3.yml
- name: Backup PostgreSQL and upload to S3
  hosts: postgresql_servers
  become: yes
  vars:
    timestamp: "{{ ansible_date_time.iso8601_basic_short }}"
    s3_bucket: "my-company-db-backups"
    s3_region: "us-east-1"

  tasks:
    - name: Install boto3 for S3 operations
      pip:
        name: boto3
        state: present

    - name: Create PostgreSQL backups
      community.postgresql.postgresql_db:
        name: "{{ item }}"
        state: dump
        target: "{{ backup_dir }}/{{ item }}_{{ timestamp }}.sql.gz"
        login_user: "{{ postgres_user }}"
        login_password: "{{ postgres_password }}"
      loop: "{{ postgres_databases }}"
      become_user: postgres

    - name: Upload backups to S3
      amazon.aws.s3_object:
        bucket: "{{ s3_bucket }}"
        object: "postgresql/{{ inventory_hostname }}/{{ item }}_{{ timestamp }}.sql.gz"
        src: "{{ backup_dir }}/{{ item }}_{{ timestamp }}.sql.gz"
        mode: put
        encrypt: yes
        region: "{{ s3_region }}"
      loop: "{{ postgres_databases }}"
      environment:
        AWS_ACCESS_KEY_ID: "{{ lookup('env', 'AWS_ACCESS_KEY_ID') }}"
        AWS_SECRET_ACCESS_KEY: "{{ lookup('env', 'AWS_SECRET_ACCESS_KEY') }}"

    - name: Configure S3 lifecycle policy
      amazon.aws.s3_lifecycle:
        name: "postgresql-backup-retention"
        bucket_name: "{{ s3_bucket }}"
        transition_days: 30
        transition_storage_class: glacier
        expiration_days: 365
        state: present
      delegate_to: localhost
      run_once: true

Este playbook avanzado implementa:

Cifrado en tránsito y reposo: S3 encryption habilitado
Organización jerárquica: Estructura postgresql/hostname/backup.sql.gz
Lifecycle policies: Transición automática a Glacier tras 30 días
Retención de 1 año: Eliminación automática de backups antiguos
Credenciales seguras: Variables de entorno en lugar de hardcoding

Para configurar, exporta credenciales AWS antes de ejecutar:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup_s3.yml

Optimización y Best Practices para Ansible PostgreSQL

Implementar Ansible PostgreSQL en producción requiere seguir estas mejores prácticas críticas:

Seguridad

Ansible Vault obligatorio: Nunca almacenes credenciales en texto plano

# Cifrar archivo de variables sensibles
ansible-vault encrypt group_vars/postgresql_servers.yml

# Ejecutar playbook con vault
ansible-playbook -i inventory/hosts.ini playbooks/postgresql_backup.yml --ask-vault-pass

Least privilege: Usuario PostgreSQL con permisos mínimos de lectura
SSH con llaves: Deshabilita autenticación por contraseña
Cifrado de backups: Usa extensiones .gpg para backups sensibles

Rendimiento

Backups incrementales: Para bases de datos grandes (>100GB), considera usar pg_basebackup con WAL archiving
Compresión adaptativa: .gz para rápido, .xz para máxima compresión
Paralelización: Usa --jobs=4 con pg_dump en versiones PostgreSQL 14+
Throttling de red: Limita ancho de banda con throttle: 1 en módulo fetch

Mantenimiento

Versionado con Git: Trackea cambios en playbooks con control de versiones
Testing de restauración: Ejecuta restore tests mensuales en entorno staging
Monitoreo de backups: Integra con Prometheus/Grafana para alertas
Documentación de runbooks: Documenta procedimientos de disaster recovery

Roles Reutilizables

Para proyectos complejos, estructura el código como roles de Ansible:

roles/
├── postgresql_backup/
│   ├── tasks/
│   │   ├── main.yml
│   │   ├── backup.yml
│   │   ├── retention.yml
│   │   └── s3_upload.yml
│   ├── defaults/
│   │   └── main.yml
│   ├── handlers/
│   │   └── main.yml
│   └── templates/
│       └── backup_report.j2
└── postgresql_restore/
    └── tasks/
        └── main.yml

Luego invoca roles desde playbooks simples:

---
- hosts: postgresql_servers
  roles:
    - postgresql_backup

Troubleshooting Común con Ansible PostgreSQL

Error: «psycopg2 module not found»

Causa: Falta dependencia Python en managed node.

Solución:

# Debian/Ubuntu
ansible postgresql_servers -m apt -a "name=python3-psycopg2 state=present" -b

# RHEL/CentOS
ansible postgresql_servers -m yum -a "name=python3-psycopg2 state=present" -b

Error: «Peer authentication failed for user postgres»

Causa: Configuración de pg_hba.conf no permite autenticación con contraseña.

Solución: Modifica pg_hba.conf para usar md5 o scram-sha-256:

# /etc/postgresql/14/main/pg_hba.conf
local   all   postgres   md5
host    all   all   127.0.0.1/32   md5

# Reiniciar PostgreSQL
sudo systemctl restart postgresql

Error: «Permission denied» al crear backup

Causa: Usuario postgres no tiene permisos de escritura en backup_dir.

Solución:

# Crear directorio con permisos correctos
sudo mkdir -p /var/backups/postgresql
sudo chown -R postgres:postgres /var/backups/postgresql
sudo chmod 700 /var/backups/postgresql

Backup extremadamente lento

Causa: Base de datos grande sin optimización de pg_dump.

Solución: Usa formato custom con compresión paralela:

- name: Fast backup with parallel compression
  community.postgresql.postgresql_db:
    name: "{{ item }}"
    state: dump
    target: "{{ backup_dir }}/{{ item }}_{{ timestamp }}.pgc"
    target_opts: "--format=custom --compress=9 --jobs=4"
    login_user: "{{ postgres_user }}"
  loop: "{{ postgres_databases }}"

Verificar logs de backups

# Ver logs de playbook
tail -f /var/log/ansible-postgres-backup.log

# Ver logs de PostgreSQL
sudo tail -f /var/log/postgresql/postgresql-14-main.log

# Verificar última ejecución de cron
grep "PostgreSQL automated backup" /var/log/syslog

Monitoreo de Backups con Ansible PostgreSQL

Implementa monitoreo proactivo de backups con este playbook que envía métricas a Prometheus:

---
# playbooks/postgresql_backup_monitor.yml
- name: Monitor PostgreSQL backup health
  hosts: postgresql_servers
  become: yes

  tasks:
    - name: Check latest backup age
      find:
        paths: "{{ backup_dir }}"
        patterns: "*.sql.gz"
        age: -25h  # Menos de 25 horas
      register: recent_backups

    - name: Alert if no recent backup
      fail:
        msg: "CRITICAL: No recent backup found in last 25 hours!"
      when: recent_backups.matched == 0

    - name: Calculate total backup size
      shell: du -sb {{ backup_dir }} | cut -f1
      register: backup_size
      changed_when: false

    - name: Check disk space remaining
      shell: df -B1 {{ backup_dir }} | tail -1 | awk '{print $4}'
      register: disk_free
      changed_when: false

    - name: Alert if disk space low (<10GB)
      fail:
        msg: "WARNING: Only {{ (disk_free.stdout|int / 1024 / 1024 / 1024) | round(2) }}GB free"
      when: disk_free.stdout|int < 10737418240

    - name: Export metrics to node_exporter textfile
      copy:
        dest: /var/lib/node_exporter/textfile_collector/postgres_backup.prom
        content: |
          # HELP postgres_backup_size_bytes Total size of PostgreSQL backups
          # TYPE postgres_backup_size_bytes gauge
          postgres_backup_size_bytes{host="{{ inventory_hostname }}"} {{ backup_size.stdout }}

          # HELP postgres_backup_count Number of backup files
          # TYPE postgres_backup_count gauge
          postgres_backup_count{host="{{ inventory_hostname }}"} {{ recent_backups.matched }}

          # HELP postgres_backup_disk_free_bytes Free disk space for backups
          # TYPE postgres_backup_disk_free_bytes gauge
          postgres_backup_disk_free_bytes{host="{{ inventory_hostname }}"} {{ disk_free.stdout }}

Combina este playbook con Prometheus y Grafana para dashboards visuales y alertas automáticas por email/Slack cuando fallan backups.

Casos de Uso Avanzados de Ansible PostgreSQL

1. Backup Selectivo por Esquema

Para bases de datos con múltiples esquemas, respalda solo lo necesario:

- name: Backup specific schemas only
  community.postgresql.postgresql_db:
    name: production_db
    state: dump
    target: "/backups/production_public_{{ timestamp }}.sql.gz"
    target_opts: "--schema=public --schema=analytics"
    login_user: postgres

2. Backup de PostgreSQL en Docker

Si tu PostgreSQL corre en contenedores, adapta el playbook:

- name: Backup PostgreSQL running in Docker
  shell: |
    docker exec postgres_container pg_dump -U postgres production_db | \
    gzip > /backups/docker_postgres_{{ timestamp }}.sql.gz
  args:
    creates: /backups/docker_postgres_{{ timestamp }}.sql.gz

Para gestión completa de contenedores, consulta nuestra guía de Ansible Docker Deployment.

3. Replicación de Backups Multi-Región

- name: Replicate backup to multiple S3 regions
  amazon.aws.s3_object:
    bucket: "db-backups-{{ item.region }}"
    object: "{{ backup_file }}"
    src: "{{ local_backup_path }}"
    mode: put
    region: "{{ item.region }}"
  loop:
    - { region: "us-east-1" }
    - { region: "eu-west-1" }
    - { region: "ap-southeast-1" }

4. Backup con Notificación Slack

- name: Send backup notification to Slack
  uri:
    url: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
    method: POST
    body_format: json
    body:
      text: "✅ PostgreSQL backup completed"
      attachments:
        - color: "good"
          fields:
            - title: "Database"
              value: "{{ database_name }}"
            - title: "Size"
              value: "{{ (backup_size.stdout|int / 1024 / 1024) | round(2) }}MB"
            - title: "Timestamp"
              value: "{{ timestamp }}"
  when: backup_result is success

Conclusión

Ansible PostgreSQL transforma la gestión de backups de bases de datos de un proceso manual propenso a errores en una operación completamente automatizada, auditable y confiable. Has aprendido a crear playbooks production-ready que incluyen backup, restauración, retención automática, integración con S3, monitoreo y troubleshooting.

Los beneficios clave incluyen:

Reducción de tiempo operativo: De horas manuales a minutos automatizados
Eliminación de errores humanos: Procesos idempotentes y reproducibles
Disaster recovery garantizado: Restauraciones probadas y documentadas
Escalabilidad: Gestiona 1 o 100 servidores PostgreSQL con el mismo código
Compliance automatizado: Retención, cifrado y auditoría integrados

Los próximos pasos recomendados son implementar testing automatizado de restauraciones en staging, integrar monitoreo con Prometheus/Grafana, y explorar técnicas avanzadas como Point-in-Time Recovery (PITR) con WAL archiving. Para automatización de infraestructura complementaria, revisa nuestros artículos sobre Ansible Kubernetes y Terraform AWS EC2.

Preguntas Frecuentes sobre Ansible PostgreSQL

¿Qué versión de Ansible necesito para postgresql_db?

Ansible Core 2.14 o superior es recomendado. La colección community.postgresql requiere Ansible 2.10 como mínimo, pero versiones más recientes incluyen mejoras de rendimiento y seguridad críticas para producción.

¿Los playbooks de Ansible PostgreSQL son idempotentes?

Parcialmente. Las operaciones de backup siempre crean un nuevo archivo (no son idempotentes), pero tareas como crear directorios, instalar dependencias y configurar cron sí lo son. Esto es el comportamiento esperado para backups con timestamp.

¿Cómo gestiono secretos de PostgreSQL con Ansible Vault?

Crea un archivo cifrado para credenciales: ansible-vault create group_vars/vault.yml, define vault_postgres_password: "supersecret", y referencia como postgres_password: "{{ vault_postgres_password }}" en playbooks. Ejecuta con --ask-vault-pass.

¿Puedo usar Ansible PostgreSQL con RDS de AWS?

Sí, pero con limitaciones. RDS no permite acceso directo al filesystem del servidor, por lo que debes usar pg_dump desde el control node conectándote remotamente al endpoint RDS. No puedes usar become_user=postgres ni fetch desde el servidor.

¿Cómo testeo backups antes de confiar en producción?

Implementa un playbook de testing automatizado que: 1) Crea backup de staging, 2) Restaura en una base de datos temporal, 3) Ejecuta queries de validación (COUNT de tablas, checksums de datos), 4) Limpia recursos temporales. Ejecuta mensualmente con --check primero.

¿Qué formato de backup es mejor: SQL plano o custom?

Depende del caso de uso. SQL plano (.sql) es legible y portable, ideal para desarrollo. Formato custom (.pgc) soporta compresión integrada, backups paralelos y restauración selectiva de tablas, preferible para producción con bases de datos grandes.

Ansible PostgreSQL: Automatiza Backups de Bases de Datos 2025