View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001564 | bareos-core | file daemon | public | 2023-10-31 10:23 | 2023-11-02 10:55 |
Reporter | hostedpower | Assigned To | bruno-at-bareos | ||
Priority | normal | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | not fixable | ||
Platform | Linux | OS | Debian | OS Version | 12 |
Summary | 0001564: New python PostgreSQL: Errors when restoring | ||||
Description | We 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. | ||||
Tags | No tags attached. | ||||
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. |
|
Not concerning Bareos. | |
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 |