- Joined
- Mar 22, 2024
- Messages
- 4
- Reaction score
- 2
Hello,
we have observed postgres database corruption on one of our 3cx PBX.
3cx logical/app backup worked fine until 2.5.2024 and failed since then, but we have found that the reason for this is apparently a corrupted postgres database.
we did not yet observe any problems with 3cx besides that.
unfortunately , that postgres corruption happened quite a while ago (checked older backups) so we need to recover our postgres db from an (hopefully consistent) file-level backup from last year.
this error shows with the postgres db :
pg_dumpall >db.out
pg_dump: Ausgabe des Inhalts der Tabelle »cl_participants« fehlgeschlagen: PQgetResult() fehlgeschlagen.
pg_dump: Fehlermeldung vom Server: FEHLER: konnte auf den Status von Transaktion 2720270059 nicht zugreifen
DETAIL: Konnte Datei »pg_xact/0A22« nicht öffnen: Datei oder Verzeichnis nicht gefunden.
pg_dump: Die Anweisung war: COPY public.cl_participants (id, call_id, info_id, role, is_inbound, end_status, forward_reason, failure_reason, start_time, answer_time, end_time, billing_code, billing_ratename, billing_rate, billing_cost, billing_duration, recording_url, billing_group) TO stdout;
pg_dumpall: pg_dump für Datenbank »database_single« fehlgeschlagen; beende
we have no clue how this corruption did happen, and trying to recover at the postgres level looks too fance for us ( https://www.postgresql.org/message-id/[email protected] )
could somebody give an advice on how to optimally proceed for recovery procedure ?
i would expect, that besides recovering postgres to an older point in time, we also need to do that for several 3cx dirs/files altogether , and then may later on be able to restore 3cx from the logical 3cx backup
are there any caveats (license?) we should pay attention to ?
regards
Roland
we have observed postgres database corruption on one of our 3cx PBX.
3cx logical/app backup worked fine until 2.5.2024 and failed since then, but we have found that the reason for this is apparently a corrupted postgres database.
we did not yet observe any problems with 3cx besides that.
unfortunately , that postgres corruption happened quite a while ago (checked older backups) so we need to recover our postgres db from an (hopefully consistent) file-level backup from last year.
this error shows with the postgres db :
pg_dumpall >db.out
pg_dump: Ausgabe des Inhalts der Tabelle »cl_participants« fehlgeschlagen: PQgetResult() fehlgeschlagen.
pg_dump: Fehlermeldung vom Server: FEHLER: konnte auf den Status von Transaktion 2720270059 nicht zugreifen
DETAIL: Konnte Datei »pg_xact/0A22« nicht öffnen: Datei oder Verzeichnis nicht gefunden.
pg_dump: Die Anweisung war: COPY public.cl_participants (id, call_id, info_id, role, is_inbound, end_status, forward_reason, failure_reason, start_time, answer_time, end_time, billing_code, billing_ratename, billing_rate, billing_cost, billing_duration, recording_url, billing_group) TO stdout;
pg_dumpall: pg_dump für Datenbank »database_single« fehlgeschlagen; beende
we have no clue how this corruption did happen, and trying to recover at the postgres level looks too fance for us ( https://www.postgresql.org/message-id/[email protected] )
could somebody give an advice on how to optimally proceed for recovery procedure ?
i would expect, that besides recovering postgres to an older point in time, we also need to do that for several 3cx dirs/files altogether , and then may later on be able to restore 3cx from the logical 3cx backup
are there any caveats (license?) we should pay attention to ?
regards
Roland