View Issue Details

IDProjectCategoryView StatusLast Update
0001564bareos-corefile daemonpublic2023-11-02 10:55
Reporterhostedpower Assigned Tobruno-at-bareos  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionnot fixable 
PlatformLinuxOSDebianOS Version12
Summary0001564: New python PostgreSQL: Errors when restoring
DescriptionWe see some strange errors when effectively restoring the data with the new New python PostgreSQL plugin for the fd

Errors


2023-10-30 19:06:33.391 CET [2241201] LOG: starting PostgreSQL 15.4 - Percona Distribution on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2023-10-30 19:06:33.391 CET [2241201] LOG: listening on IPv4 address "127.0.0.1", port 5432
2023-10-30 19:06:33.393 CET [2241201] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-10-30 19:06:33.399 CET [2241204] LOG: database system was interrupted; last known up at 2023-10-30 18:26:50 CET
2023-10-30 19:06:33.399 CET [2241204] LOG: creating missing WAL directory "pg_wal/archive_status"
2023-10-30 19:06:33.586 CET [2241204] LOG: restored log file "00000002.history" from archive
cp: cannot stat '/var/lib/pgsql_archive/00000003.history': No such file or directory
2023-10-30 19:06:33.588 CET [2241204] LOG: starting archive recovery
2023-10-30 19:06:33.590 CET [2241204] LOG: restored log file "00000002.history" from archive
2023-10-30 19:06:33.611 CET [2241204] LOG: restored log file "000000010000002600000059" from archive
2023-10-30 19:06:33.631 CET [2241204] LOG: redo starts at 26/59000028
2023-10-30 19:06:33.664 CET [2241204] LOG: restored log file "00000001000000260000005A" from archive
2023-10-30 19:06:33.702 CET [2241204] LOG: restored log file "00000002000000260000005B" from archive
2023-10-30 19:06:33.723 CET [2241204] LOG: consistent recovery state reached at 26/590027C8
2023-10-30 19:06:33.723 CET [2241201] LOG: database system is ready to accept read-only connections
2023-10-30 19:06:33.759 CET [2241204] LOG: restored log file "00000002000000260000005C" from archive
cp: cannot stat '/var/lib/pgsql_archive/00000002000000260000005D': No such file or directory
cp: cannot stat '/var/lib/pgsql_archive/00000002000000260000005D': No such file or directory
2023-10-30 19:06:33.784 CET [2241204] LOG: redo done at 26/5C0000D8 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.15 s
2023-10-30 19:06:33.784 CET [2241204] LOG: last completed transaction was at log time 2023-10-30 18:53:49.861901+01
2023-10-30 19:06:33.805 CET [2241204] LOG: restored log file "00000002000000260000005C" from archive
cp: cannot stat '/var/lib/pgsql_archive/00000003.history': No such file or directory
2023-10-30 19:06:33.836 CET [2241204] LOG: selected new timeline ID: 3
2023-10-30 19:06:33.872 CET [2241204] LOG: restored log file "00000002.history" from archive
2023-10-30 19:06:33.873 CET [2241204] LOG: archive recovery complete
2023-10-30 19:06:33.876 CET [2241202] LOG: checkpoint starting: end-of-recovery immediate wait
2023-10-30 19:06:33.900 CET [2241202] LOG: checkpoint complete: wrote 12 buffers (0.0%); 0 WAL file(s) added, 0 removed, 4 recycled; write=0.016 s, sync=0.003 s, total=0.025 s; sync files=12, longest=0.001 s, average=0.001 s; distance=65536 kB, estimate=65536 kB
2023-10-30 19:06:33.906 CET [2241201] LOG: database system is ready to accept connections

Which is correct, those files were misssing, e.g. this for example was not found in the backup:

cp: cannot stat '/var/lib/pgsql_archive/00000003.history': No such file or directory

Not sure where it found the *.history files ,since we cannot find them anywhere as far as I can see.
TagsNo tags attached.

Activities

bruno-at-bareos

bruno-at-bareos

2023-10-31 14:17

manager   ~0005488

We as Bareos don't have any control on the PostgreSQL recovery process in itself after restoring all needed files.

What I can imagine here it a cluster restored after a backup, and here this is the 3rd time the pg is restarted after a restore (selected new timeline ID: 3)
please consult PostgreSQL documentation for that.

The good practice would use the following as process, once a cluster is restored and restarted correctly, all previous archived wal are removed and a new full backup is done.
bruno-at-bareos

bruno-at-bareos

2023-11-02 10:55

manager   ~0005493

Not concerning Bareos.

Issue History

Date Modified Username Field Change
2023-10-31 10:23 hostedpower New Issue
2023-10-31 14:17 bruno-at-bareos Note Added: 0005488
2023-11-02 10:55 bruno-at-bareos Assigned To => bruno-at-bareos
2023-11-02 10:55 bruno-at-bareos Status new => closed
2023-11-02 10:55 bruno-at-bareos Resolution open => not fixable
2023-11-02 10:55 bruno-at-bareos Note Added: 0005493