<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>PDU Blog - PostgreSQL Data Recovery</title>
    <link>https://pduzc.com/blog</link>
    <description>Technical articles about PostgreSQL data recovery, database internals, and data rescue techniques</description>
    <language>en</language>
    <lastBuildDate>Fri, 20 Mar 2026 14:19:02 GMT</lastBuildDate>
    <atom:link href="https://pduzc.com/blog/feed.xml" rel="self" type="application/rss+xml" />
    
    <item>
      <title><![CDATA[Inside the Kernel: The Complete Path to PostgreSQL Delete Recovery — From FPW to Data Resurrection]]></title>
      <link>https://pduzc.com/blog/kernel_del_recovery</link>
      <guid isPermaLink="true">https://pduzc.com/blog/kernel_del_recovery</guid>
      <description><![CDATA[In PostgreSQL, a DELETE operation does not immediately erase data from disk. The MVCC mechanism retains deleted rows as dead tuples, and reading these dead tuples is one viable approach to data recovery.
However, this approach has a clear time limitation: once autovacuum completes its cleanup, the dead tuples are physically removed, and recovery methods based on data files become ineffective.
At this point, the WAL (Write-Ahead Log) offers an alternative recovery path. Specifically, the **FPW (Full Page Write)** mechanism within WAL is the foundation of this approach. PostgreSQL DELETE recovery tools — including [PDU (PostgreSQL Data Unloader)](https://github.com/wublabdubdub/PDU-PostgreSQLDataUnloader) — rely on this technique. Its key property: **as long as the WAL files generated during the deletion period still exist, the data can be fully recovered regardless of how much time has passed.**
This article dissects that recovery path function by function, based on **PostgreSQL 18** source code.]]></description>
      <pubDate>Thu, 05 Mar 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>PostgreSQL</category>
      <category>Kernel Internals</category>
      <category>WAL</category>
      <category>FPW</category>
      <category>Delete Recovery</category>
      <category>Source Code</category>
    </item>

    <item>
      <title><![CDATA[Expert-Level PostgreSQL Deleted Data Recovery in Just 5 Steps — No Kernel Knowledge Required]]></title>
      <link>https://pduzc.com/blog/5steps_delrecovery</link>
      <guid isPermaLink="true">https://pduzc.com/blog/5steps_delrecovery</guid>
      <description><![CDATA[It is 3 AM. A rogue DELETE just wiped 500,000 customer records. Traditional recovery takes hours and risks collateral damage. This guide shows you how to recover accidental DELETEs and UPDATEs in five steps using PDU — no kernel expertise, no downtime, data back in under a minute.]]></description>
      <pubDate>Thu, 05 Mar 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>Data Recovery</category>
      <category>WAL</category>
      <category>PDU</category>
      <category>DELETE</category>
      <category>PITR Alternative</category>
    </item>

    <item>
      <title><![CDATA[How to Turn PostgreSQL Unconventional Recovery into an Elegant Art]]></title>
      <link>https://pduzc.com/blog/instant_recovery_art</link>
      <guid isPermaLink="true">https://pduzc.com/blog/instant_recovery_art</guid>
      <description><![CDATA[When the database won't start and there's no backup available, most teams assume the game is over. But that's not true—the data is still on disk, it just lost the ability to speak. PostgreSQL data files remain transparent and readable, but here's the problem - without the data dictionary, you cannot understand what those bytes actually mean. This article explores the core challenges of unconventional recovery, including how to rebuild table structures from corrupted data dictionaries, handle dropped columns and TOAST tables, keep moving forward under imperfect conditions, and why recovery speed itself is part of your capability. This is not a game of luck—it is an elegant art that can be mastered.]]></description>
      <pubDate>Fri, 09 Jan 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>Unconventional Recovery</category>
      <category>Data Dictionary</category>
      <category>Data Recovery</category>
      <category>Instant Recovery</category>
      <category>Disaster Recovery</category>
    </item>

    <item>
      <title><![CDATA[Not a Backup Replacement: What PostgreSQL Instant Recovery Actually Solves]]></title>
      <link>https://pduzc.com/blog/instant_recovery_and_backup</link>
      <guid isPermaLink="true">https://pduzc.com/blog/instant_recovery_and_backup</guid>
      <description><![CDATA[When people first hear about instant recovery, they often assume it is a replacement for backup—or worse, a risky shortcut only experts should attempt. But the truth is exactly the opposite. Instant recovery does not challenge any design boundary of PostgreSQL. It simply rejects a premise the kernel never promised - that the database must be in a bootable state. This article explains, from the perspective of PostgreSQL internals, why instant recovery is a capability that was always meant to exist, how it differs fundamentally from backup recovery, and why time itself is often the scarcest resource at an incident scene.]]></description>
      <pubDate>Fri, 09 Jan 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>Instant Recovery</category>
      <category>Backup</category>
      <category>Database Internals</category>
      <category>Disaster Recovery</category>
    </item>

    <item>
      <title><![CDATA[Not All Unrecoverable PostgreSQL Data Is Actually Lost]]></title>
      <link>https://pduzc.com/blog/instant_recovery</link>
      <guid isPermaLink="true">https://pduzc.com/blog/instant_recovery</guid>
      <description><![CDATA[Most teams assume data loss means restore from backup. This article introduces the Instant Recovery mindset, explains why PostgreSQL makes it possible, and how PDU turns recoverability into a practical, predictable process.]]></description>
      <pubDate>Tue, 06 Jan 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>Instant Recovery</category>
      <category>PDU</category>
      <category>Database Internals</category>
    </item>

    <item>
      <title><![CDATA[Mission Impossible: How We Recovered 1TB of Data in 48 Hours]]></title>
      <link>https://pduzc.com/blog/recovery-1tb-data</link>
      <guid isPermaLink="true">https://pduzc.com/blog/recovery-1tb-data</guid>
      <description><![CDATA[A corrupted disk. A dead database. Unusable backups. 1.5TB of critical business data hanging by a thread. This is the story of how PDU turned an impossible situation into a triumph.]]></description>
      <pubDate>Mon, 05 Jan 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>Data Recovery</category>
      <category>PostGIS</category>
      <category>Disaster Recovery</category>
    </item>

    <item>
      <title><![CDATA[World First! Secrets Behind PostgreSQL Fragment Scanning Recovery]]></title>
      <link>https://pduzc.com/blog/dropscan_recovery</link>
      <guid isPermaLink="true">https://pduzc.com/blog/dropscan_recovery</guid>
      <description><![CDATA[DROP TABLE with no backup? Most consider it game over. Discover how PDU achieves the "impossible" - scanning raw disk blocks and matching table structures to resurrect your lost data.]]></description>
      <pubDate>Mon, 05 Jan 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>DROP TABLE</category>
      <category>Fragment Scanning</category>
      <category>Disk Recovery</category>
      <category>PDU</category>
      <category>Database Internals</category>
    </item>

    <item>
      <title><![CDATA[How to Recover PostgreSQL When Data Dictionary Gets Corrupted - A Real Case Study]]></title>
      <link>https://pduzc.com/blog/dict_corrupt_recovery</link>
      <guid isPermaLink="true">https://pduzc.com/blog/dict_corrupt_recovery</guid>
      <description><![CDATA[When pg_type and pg_attribute are partially destroyed, how do you piece together a corrupted database? This real-world case reveals an ingenious workaround that saved 46% of the data.]]></description>
      <pubDate>Mon, 05 Jan 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>Data Dictionary</category>
      <category>Disaster Recovery</category>
      <category>Database Corruption</category>
      <category>PDU</category>
    </item>

    <item>
      <title><![CDATA[Extreme Recovery Series: 4 Hours to Rescue Core Data from a Domestic PG Database]]></title>
      <link>https://pduzc.com/blog/4hour-core-data</link>
      <guid isPermaLink="true">https://pduzc.com/blog/4hour-core-data</guid>
      <description><![CDATA[A client accidentally ran rm -rf /*, wiping out the entire OS and database. After disk recovery experts salvaged the data files, PDU adapted to this domestic PostgreSQL variant and completed full data recovery in just 4 hours.]]></description>
      <pubDate>Mon, 05 Jan 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>rm -rf</category>
      <category>Data Recovery</category>
      <category>Domestic Database</category>
      <category>Disaster Recovery</category>
    </item>

    <item>
      <title><![CDATA[Goodbye Boring Command Line: How to Debug PostgreSQL with VSCode GUI]]></title>
      <link>https://pduzc.com/blog/vscode-debug-postgresql</link>
      <guid isPermaLink="true">https://pduzc.com/blog/vscode-debug-postgresql</guid>
      <description><![CDATA[A comprehensive guide on debugging PostgreSQL source code using VSCode and Linux virtual machines, covering environment setup, Remote-SSH configuration, GDB debugging, and debugging peripheral tools like pg_waldump.]]></description>
      <pubDate>Sun, 05 Jan 2025 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>VSCode</category>
      <category>Debugging</category>
      <category>Development Tools</category>
    </item>
  </channel>
</rss>