PostgreSQL Recovery
PostgreSQL keeps most of a database's actual content in table and index files that often survive intact even when the cluster itself won't start. AS assesses the data directory and WAL logs directly before attempting any recovery.
When you need this
- PostgreSQL cluster won't start after a crash or power loss
- Data directory corrupted or showing 'database system was not properly shut down'
- WAL (write-ahead log) files damaged or missing
- pg_control file corrupted
- Point-in-time recovery (PITR) failing partway through a WAL replay
- Streaming replication broken or standby permanently out of sync
- pg_dump or pg_restore failing on a damaged backup
- TOAST table corruption affecting large column values
- Tables or rows deleted without a usable backup
- Storage beneath the data directory failed
What we do
Data directory assessment
The cluster's data directory is examined directly to determine whether table and index files are intact behind a damaged control file or catalog.
WAL log analysis
Write-ahead log files are examined for recoverable transactions where the server itself won't replay them automatically.
Catalog and control file recovery
Where pg_control or system catalog files are damaged, we work to reconstruct enough for the cluster to start or for data to be extracted directly.
Direct table extraction
Where the cluster can't be brought up cleanly, table and index files can often be read and exported directly.
Backup and TOAST recovery
Damaged pg_dump output is analysed for the recoverable portion, and TOASTed (large) column data is assessed separately from the main table files it references.
PostgreSQL heap files are made of fixed-size pages — damage to some pages doesn't prevent reading the intact ones directly, bypassing the database engine.
How it works
- Step 1
Consultation and scope
We establish what failed, what has been tried, and which data matters most. This shapes a targeted plan rather than a generic one.
- Step 2
Secure imaging and diagnosis
Where possible the source media is imaged before any work, so the original is never altered. Diagnosis then determines the safest recovery method.
- Step 3
Recovery
Data is extracted from the image or source using methods matched to the failure — logical, structural or hardware-level as required.
- Step 4
Verification
Recovered data is checked for integrity and completeness, and a file list is shared so you can confirm what matters is there.
- Step 5
Secure delivery
Verified data is returned through an agreed secure method, with guidance on validation before it goes back into production.
What affects the outcome
Outcomes are never guaranteed. Every case is assessed on its own condition, and we tell you what is realistic before you commit.
- Physical condition of the media and the extent of any damage
- Whether the media has been written to, reformatted or re-initialised since the failure
- Encryption, corruption or partial overwriting of the data
- Availability of source data such as images, backups, logs or transaction records
- Attempts made before assessment (rebuilds, repair tools, repeated reboots)
Frequently asked questions
PostgreSQL says the database system was not properly shut down — is data lost?
Usually not by itself. That message means PostgreSQL wants to run recovery from the WAL logs; the underlying data files are typically still intact. We assess before anything is changed.
Can you recover from a damaged WAL file specifically?
Often partially — recoverable transactions before the point of damage can usually still be extracted, even if replay can't complete normally.
Our pg_dump backup won't restore — is it a total loss?
Not always. A damaged dump file can often be analysed for the portion that's still structurally intact, rather than requiring the entire file to be perfect.
What about corrupted TOAST data (large text/blob columns)?
TOAST tables are assessed separately from the main table — a damaged TOAST entry doesn't necessarily mean the rest of the row or table is affected.
Our point-in-time recovery (PITR) fails partway through WAL replay — can you still recover?
Usually, yes. A failed PITR replay just means the automated process stopped at a damaged or missing WAL segment — the base backup and every WAL file up to that point are typically still valid, and we can often recover to the last good point or work around the damaged segment directly.
Related services
Not sure what you're dealing with?
Describe the situation and we'll tell you what's realistic.