Cómo PostgreSQL guarda los datos: estructura de la base y el journal de transacciones (WAL)

Cuando trabajas con una base de datos, todo parece bastante sencillo: añades una fila, actualizas un registro, borras un cliente. Pero detrás de esa simplicidad hay un mecanismo complejo y bien pensado. ¿Dónde se guardan realmente esos datos? ¿Cómo consigue PostgreSQL no perder nada, incluso si el servidor se apaga de golpe?

Para entenderlo, hay que pillar dos cosas clave: dónde están físicamente los datos (tablas, índices, info interna) y cómo funciona el mecanismo que protege esos datos — el journal de transacciones, o sea el WAL (Write-Ahead Logging).

Toda la base de datos de PostgreSQL se guarda como un conjunto de archivos en un directorio especial — data_directory. Normalmente está aquí:

/var/lib/postgresql/17/main

En esa carpeta está el corazón de la base: las tablas, los índices, la metainformación y la configuración. Ahí también está el journal WAL — el mecanismo que recibe primero todos los cambios. Antes de que los datos lleguen a la tabla en disco, se escriben en el WAL. Es como un borrador donde la base apunta cada paso, para que si algo falla se pueda recuperar todo hasta la última operación.

Gracias a este enfoque, PostgreSQL garantiza fiabilidad y resistencia, incluso en las situaciones más chungas.

Tablas

Cada tabla es físicamente un archivo separado o un conjunto de archivos. Estos archivos están en el subdirectorio base/. La estructura es más o menos así:

$PGDATA/base/
├── 16384/
│   ├── 12345   ← tabla
│   ├── 12346   ← índice
│   └── ...

• 16384 — es el identificador interno de la base de datos (OID).
• 12345 — identificador de la tabla concreta.

Si la tabla es grande, PostgreSQL la parte en segmentos de 1 GB:

12345
12345.1
12345.2
...

Los archivos no contienen "filas" como en un CSV de texto — es un formato de "páginas binarias" de 8 KB.

WAL: Write-Ahead Logging — no es solo un "log"

Ahora vamos a una de las partes más importantes y a menudo mal entendidas de PostgreSQL — WAL, o Write-Ahead Logging. Aunque en el nombre pone log, el WAL no es un archivo de log de texto normal, como los logs de errores o de consultas. Es un mecanismo vital de consistencia y recuperación de datos, que funciona a nivel de cambios bajos en el sistema de archivos.

El WAL no es un informe de eventos, sino un registro previo de todos los cambios que PostgreSQL va a hacer en los datos. Este registro se escribe antes de modificar realmente las tablas en disco. Por eso se llama write-ahead — "escribir por adelantado".

Por ejemplo, cuando insertas una nueva fila en una tabla, PostgreSQL:

1. NO actualiza la tabla en disco al instante — eso sería lento y poco seguro.
2. Primero escribe en el WAL que esa fila se va a añadir.
3. Solo después, cuando le viene bien (por ejemplo, en un proceso en segundo plano), los datos acaban en la tabla de verdad.

Funciona como un cheque en el banco: primero lo firmas (WAL), y solo después el banco actualiza la cuenta (tabla). Si algo sale mal — el cheque sigue ahí, y puedes repetir la operación.

Formato y estructura del WAL

• Los archivos WAL se guardan en formato binario.
• Cada archivo es un flujo estrictamente ordenado de operaciones que describen cambios internos en páginas de datos, estructuras de índices, commits, etc.
• Un archivo WAL tiene tamaño fijo — por defecto 16 MB.

Importante: el WAL no contiene "comandos SQL" ni "filas de tabla" como solemos ver. Contiene instrucciones para el motor de PostgreSQL sobre cómo reproducir los cambios, página a página.

¿Qué pasa si hay un fallo?

Si el servidor PostgreSQL se apaga de repente — por ejemplo, por un corte de luz — no está todo perdido. Al arrancar de nuevo, la base no entra en pánico, sino que carga del disco la última versión "estable" de los datos. Luego coge el journal de transacciones (WAL), donde están los últimos cambios, y los aplica con cuidado — mete lo que aún no había llegado a los archivos principales. Al final, la base se recupera a un estado totalmente consistente, como si no hubiera pasado nada.

Otras posibilidades del WAL

Point-In-Time Recovery (PITR). Guardar los archivos WAL permite restaurar la base a cualquier punto en el tiempo entre dos backups completos.

Replicación en streaming. PostgreSQL puede enviar los registros WAL a otro servidor en tiempo real. Así puedes tener una réplica en caliente — una copia de la base sincronizada con la principal.

Recuperación incremental. Junto con un backup completo, el WAL permite restaurar solo los cambios, sin copiar toda la base otra vez.

Creando backups binarios: pg_basebackup

Si ya has trasteado con pg_dump, sabes que va genial para hacer backups lógicos (o sea, copiar la estructura y los datos de la base en forma de consultas SQL). Pero, ¿y si necesitas un backup físico? Por ejemplo, una copia espejo de todos los archivos de la base de datos. Ahí entra la herramienta pg_basebackup.

pg_basebackup es una utilidad para crear copias físicas de los datos de PostgreSQL. Es especialmente útil para bases grandes, donde hay que gestionar bien el proceso de recuperación. Lo mejor de pg_basebackup es que lo hace muy rápido.

Sintaxis básica del comando pg_basebackup

Trabajar con pg_basebackup empieza por entender su comando. Lo ejecutas en tu terminal y tiene esta pinta básica:

pg_basebackup -D /backup_directory -F tar -z -P

Vamos a ver qué hace cada cosa:

• -D /backup_directory — indica el directorio donde se guardarán tus archivos de backup.
• -F tar — formato de los datos. La opción tar crea un archivo comprimido en formato .tar. También puedes usar plain para crear la estructura de archivos de la base.
• -z — comprime el backup, así ahorras espacio en disco. Siempre mola que el backup ocupe menos sitio.
• -P — muestra el progreso en tiempo real. Es como una dosis extra de tranquilidad: ves que el proceso va bien y el servidor no se ha quedado pillado.

Ejemplo de uso:

pg_basebackup -D /backups/university_backup -F tar -z -P

Después de ejecutar el comando, en el directorio /backups/university_backup tendrás una copia de seguridad en formato .tar.

Ventajas de usar pg_basebackup

Eficiencia: los backups incrementales evitan duplicar datos que no han cambiado, ahorrando tiempo y espacio.

Facilidad de uso: la herramienta pg_basebackup se encarga de todos los detalles, incluyendo los archivos WAL.

Fiabilidad: gracias a la integración con la mecánica de PostgreSQL, pg_basebackup crea copias exactas de toda la base de datos, que puedes restaurar fácilmente.

Ejemplos de uso

Y ahora — a la práctica. Aquí tienes ejemplos reales de cómo usar pg_basebackup para crear backups de una base de datos PostgreSQL. Verás cómo hacer un backup básico, cómo añadir compresión y cómo activar el archivado del journal de transacciones (WAL) para poder restaurar "a un punto en el tiempo". Estos comandos te sirven tanto para empezar como para escenarios más avanzados.

Creando un backup básico

pg_basebackup -D /backups/full_backup -F tar -z -P

Resultado: backup completo de la base de datos en un archivo .tar.

Configurando compresión y formato

Vamos a crear un backup de los datos con el nivel de compresión más alto:

pg_basebackup -D /backups/full_backup -F tar -z -Z 9 -P

Aquí -Z 9 indica el nivel de compresión (máximo — 9).

Archivando el WAL

Si configuras el archivado del WAL, la base de datos se puede restaurar a cualquier punto en el tiempo. El comando para configurar el backup del WAL:

pg_basebackup -D /backups/incremental_backup -F tar -z -P --wal-method=archive