Re: comenzado con barman

Normally, recovery will proceed through all available WAL segments, thereby
restoring the database to the current point in time (or as close as
possible given the available WAL segments). Therefore, a normal recovery
will end with a “file not found” message, the exact text of the error
message depending upon your choice of restore_command.* You may also see an
error message at the start of recovery for a file named something like
00000001.history. This is also normal and does not indicate a problem in
simple recovery situations; see Section 25.3.6
<https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-TIMELINES>
for discussion.*
https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-PITR-RECOVERY

El jue, 6 mar 2025 a las 12:08, Jaime Soler (<jaime(dot)soler(at)gmail(dot)com>)
escribió:

> Échale un vistazo a esta doc donde explica lo mismo que te comenté
> anteriormente respecto de los timelines:
> https://www.enterprisedb.com/docs/supported-open-source/barman/single-server-streaming/step04-restore/
>
>
> El mié, 5 mar 2025 a las 22:41, kernel kernel (<jucabapa(at)gmail(dot)com>)
> escribió:
>
>> Pero no encuentra el fichero.history Es correcto?
>> Y descomento las líneas del archive_comand ? Que pasa en las copias del
>> barman si recupere a un timeline anterior? Tengo que borrar las copias y
>> volver ha hacer una nueva copia completa?
>>
>> Alguna buena guía en castellano?
>> Gracias!!!
>>
>> El 5 mar 2025, a las 20:24, Jaime Soler <jaime(dot)soler(at)gmail(dot)com> escribió:
>>
>> 
>> El restore ha sido correcto, simplemente te queda ejecutar la función
>> pg_wal_replay_resume(), para que se levante la base de datos en modo
>> escritura. La línea de log donde buscaba el fichero .00002.history es una
>> forma de identificar cual es el último timeline en la instancia.
>>
>>
>>
>> El mié, 5 mar 2025 a las 18:00, kernel (<jucabapa(at)gmail(dot)com>) escribió:
>>
>>>
>>> El 05/03/2025 a las 15:46, Felipe Nicolas Alvarado Diaz escribió:
>>>
>>> Hola,
>>>
>>> Podrías adjuntar el comando que estás utilizando para recuperar, y que
>>> te devuelve en el log de barman cuando lo ejecutas.
>>> También podrías adjuntar que te devuelve el "barman check all" y "barman
>>> list-backup all".
>>>
>>> Saludos.
>>>
>>> El mié, 5 mar 2025 a las 9:03, kernel (<jucabapa(at)gmail(dot)com>) escribió:
>>>
>>>> Hola,
>>>>
>>>> Estoy intentando montar barman, y hay algo que no debo de estar
>>>> haciendo correctamente, he probado varias veces y siempre obtengo el mismo
>>>> error, cuando recupero a una fecha determinada
>>>>
>>>> '/var/lib/pgsql/16/data/barman_wal/00000002.history': No existe el
>>>> fichero o el directorio
>>>>
>>>> Entiendo que ademas de la ultima copia completa también tengo los
>>>> archivos wal que han ido pasando a la maquina del barman, cuando hago el
>>>> recuperación veo que me deja los archivos en el barman_wal.
>>>>
>>>> Hay algo que no estoy haciendo mal, si recupera la ultima copia no hay
>>>> problema , es cuando le pido unos minutos después de la ultima copia.
>>>>
>>>> Un Saludo
>>>>
>>>>
>>>>
>>> Hola,
>>>
>>> Te envio la informacion de la que dispongo
>>>
>>>
>>> **** BARMAN ****
>>>
>>> barman check master
>>>
>>> Server master:
>>>
>>> PostgreSQL: OK
>>>
>>> superuser or standard user with backup privileges: OK
>>>
>>> PostgreSQL streaming: OK
>>>
>>> wal_level: OK
>>>
>>> replication slot: OK
>>>
>>> directories: OK
>>>
>>> retention policy settings: OK
>>>
>>> backup maximum age: OK (no last_backup_maximum_age provided)
>>>
>>> backup minimum size: OK (37.0 MiB)
>>>
>>> wal maximum age: OK (no last_wal_maximum_age provided)
>>>
>>> wal size: OK (16.2 KiB)
>>>
>>> compression settings: OK
>>>
>>> failed backups: OK (there are 0 failed backups)
>>>
>>> minimum redundancy requirements: OK (have 3 backups, expected at
>>> least 0)
>>>
>>> pg_basebackup: OK
>>>
>>> pg_basebackup compatible: OK
>>>
>>> pg_basebackup supports tablespaces mapping: OK
>>>
>>> systemid coherence: OK
>>>
>>> pg_receivexlog: OK
>>>
>>> pg_receivexlog compatible: OK
>>>
>>> receive-wal running: OK
>>>
>>> archive_mode: OK
>>>
>>> archive_command: OK
>>>
>>> continuous archiving: OK
>>>
>>> archiver errors: OK
>>>
>>> **** BARMAN ****
>>>
>>> barman list-backup master
>>>
>>> master 20250305T163129 - F - Wed Mar 5 16:34:28 2025 - Size: 37.0 MiB -
>>> WAL Size: 16.2 KiB
>>>
>>> master 20250227T142808 - F - Thu Feb 27 14:28:12 2025 - Size: 22.4 MiB -
>>> WAL Size: 2.0 MiB
>>>
>>> master 20250227T134237 - F - Thu Feb 27 13:42:40 2025 - Size: 22.4 MiB -
>>> WAL Size: 1.1 MiB
>>>
>>>
>>>
>>> **** MASTER ****
>>>
>>> systemctl stop postgresql-16
>>>
>>> cd /var/lib/pgsql/16
>>>
>>> rm -rf data
>>>
>>> **** BARMAN ****
>>>
>>> barman recover --remote-ssh-command "ssh postgres(at)192(dot)168(dot)222(dot)66"
>>> master /var/lib/pgsql/16/data --target-time '2025-03-05 09:10:00+01:00'
>>>
>>> Starting remote restore for server master using backup 20250227T142808
>>>
>>> Destination directory: /var/lib/pgsql/16/data
>>>
>>> Remote command: ssh postgres(at)192(dot)168(dot)222(dot)66
>>>
>>> Doing PITR. Recovery target time: '2025-03-05 09:10:00+01:00'
>>>
>>> Copying the base backup.
>>>
>>> Copying required WAL segments.
>>>
>>> Generating recovery configuration
>>>
>>> Identify dangerous settings in destination directory.
>>>
>>>
>>>
>>> IMPORTANT
>>>
>>> These settings have been modified to prevent data losses
>>>
>>>
>>>
>>> postgresql.conf line 826: archive_command = false
>>>
>>>
>>>
>>> Restore operation completed (start time: 2025-03-05
>>> 16:50:12.045029+01:00, elapsed time: 7 seconds)
>>>
>>> Your PostgreSQL server has been successfully prepared for recovery!
>>>
>>>
>>>
>>> **** MASTER ****
>>>
>>> systemctl start postgresql-16
>>>
>>>
>>> LOG:
>>>
>>> 2025-03-05 17:52:45.811 CET [16130] LOG: iniciando PostgreSQL 16.8 on
>>> x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat
>>> 11.5.0-5), 64-bit
>>> 2025-03-05 17:52:45.811 CET [16130] LOG: escuchando en la dirección
>>> IPv4 «0.0.0.0», port 5432
>>> 2025-03-05 17:52:45.811 CET [16130] LOG: escuchando en la dirección
>>> IPv6 «::», port 5432
>>> 2025-03-05 17:52:45.814 CET [16130] LOG: escuchando en el socket Unix
>>> «/run/postgresql/.s.PGSQL.5432»
>>> 2025-03-05 17:52:45.818 CET [16130] LOG: escuchando en el socket Unix
>>> «/tmp/.s.PGSQL.5432»
>>> 2025-03-05 17:52:45.821 CET [16134] LOG: el sistema de bases de datos
>>> fue interrumpido; última vez en funcionamiento en 2025-02-27 14:28:08 CET
>>> 2025-03-05 17:52:45.821 CET [16134] LOG: creando el directorio WAL
>>> faltante «pg_wal/archive_status»
>>> cp: no se puede efectuar `stat' sobre
>>> '/var/lib/pgsql/16/data/barman_wal/00000002.history': No existe el fichero
>>> o el directorio
>>> 2025-03-05 17:52:46.117 CET [16134] LOG: comenzando el proceso de
>>> recuperación hasta 2025-03-05 09:10:00+01
>>> 2025-03-05 17:52:46.117 CET [16134] LOG: iniciando recuperación de
>>> backup con LSN de redo 0/9000028, LSN de checkpoint 0/9000060, en timeline 1
>>> 2025-03-05 17:52:46.127 CET [16134] LOG: se ha restaurado el archivo
>>> «000000010000000000000009» desde el área de archivado
>>> 2025-03-05 17:52:46.153 CET [16134] LOG: redo comienza en 0/9000028
>>> 2025-03-05 17:52:46.165 CET [16134] LOG: se ha restaurado el archivo
>>> «00000001000000000000000A» desde el área de archivado
>>> 2025-03-05 17:52:46.205 CET [16134] LOG: se ha restaurado el archivo
>>> «00000001000000000000000B» desde el área de archivado
>>> 2025-03-05 17:52:46.236 CET [16134] LOG: se completó la recuperación de
>>> backup con LSN de redo 0/9000028 y LSN de término 0/9000100
>>> 2025-03-05 17:52:46.236 CET [16134] LOG: el estado de recuperación
>>> consistente fue alcanzado en 0/9000100
>>> 2025-03-05 17:52:46.236 CET [16130] LOG: el sistema de bases de datos
>>> está listo para aceptar conexiones de sólo lectura
>>> 2025-03-05 17:52:46.250 CET [16134] LOG: se ha restaurado el archivo
>>> «00000001000000000000000C» desde el área de archivado
>>> 2025-03-05 17:52:46.301 CET [16134] LOG: se ha restaurado el archivo
>>> «00000001000000000000000D» desde el área de archivado
>>> 2025-03-05 17:52:46.371 CET [16134] LOG: deteniendo recuperación antes
>>> de comprometer la transacción 745, hora 2025-03-05 16:29:46.749885+01
>>> 2025-03-05 17:52:46.371 CET [16134] LOG: pausando al final de la
>>> recuperación
>>> 2025-03-05 17:52:46.371 CET [16134] HINT: Ejecute
>>> pg_wal_replay_resume() para promover.
>>> 2025-03-05 17:53:02.070 CET [16242] ERROR: el punto de inicio
>>> solicitado 0/12000000 está más adelante que la posición de sincronización
>>> (flush) de WAL de este servidor 0/D42E0A8
>>> 2025-03-05 17:53:02.070 CET [16242] SENTENCIA: START_REPLICATION SLOT
>>> "barman" 0/12000000 TIMELINE 1
>>> 2025-03-05 17:54:02.265 CET [16473] ERROR: el punto de inicio
>>> solicitado 0/12000000 está más adelante que la posición de sincronización
>>> (flush) de WAL de este servidor 0/D42E0A8
>>> 2025-03-05 17:54:02.265 CET [16473] SENTENCIA: START_REPLICATION SLOT
>>> "barman" 0/12000000 TIMELINE 1
>>> 2025-03-05 17:55:01.516 CET [16712] ERROR: el punto de inicio
>>> solicitado 0/12000000 está más adelante que la posición de sincronización
>>> (flush) de WAL de este servidor 0/D42E0A8
>>> 2025-03-05 17:55:01.516 CET [16712] SENTENCIA: START_REPLICATION SLOT
>>> "barman" 0/12000000 TIMELINE 1
>>>
>>>
>>> Aqui se queda , no dice cuando ha terminado
>>>
>>>
>>>