<?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>Thu, 15 Oct 2026 02:33:14 GMT</lastBuildDate>
    <atom:link href="https://pduzc.com/blog/feed.xml" rel="self" type="application/rss+xml" />
    
    <item>
      <title><![CDATA[Why I Dare to Call Myself a “PostgreSQL Database Recovery Expert”]]></title>
      <link>https://pduzc.com/blog/why-i-call-myself-postgresql-recovery-expert</link>
      <guid isPermaLink="true">https://pduzc.com/blog/why-i-call-myself-postgresql-recovery-expert</guid>
      <description><![CDATA[After becoming a PostgreSQL ACE, Zhang Chen explains why he uses the title “PostgreSQL Database Recovery Expert” and how PDU evolved from offline extraction and WAL mining to fragment scanning and recovery without a data dictionary.]]></description>
      <pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>PostgreSQL ACE</category>
      <category>PostgreSQL unconventional recovery</category>
      <category>PDU</category>
      <category>Open Source</category>
    </item>

    <item>
      <title><![CDATA[The PostgreSQL Feature That Makes Data Recovery Painful]]></title>
      <link>https://pduzc.com/blog/postgresql-single-file-ransomware-recovery</link>
      <guid isPermaLink="true">https://pduzc.com/blog/postgresql-single-file-ransomware-recovery</guid>
      <description><![CDATA[Starting from a ransomware recovery case, this article explains how PostgreSQL single-file-per-relation storage can make catalog recovery especially difficult, and compares that exposure with MySQL and Oracle.]]></description>
      <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
      <author>noreply@pduzc.com (Zhang Chen)</author>
      <category>PostgreSQL</category>
      <category>Data Recovery</category>
      <category>Ransomware</category>
      <category>System Catalog</category>
    </item>

    <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) — 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 Engineering Practice]]></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 cannot start and no backup is available, many teams assume recovery is over. In many cases the data is still on disk, but the data dictionary is no longer usable. This article examines core challenges in unconventional recovery: rebuilding table structures from damaged dictionaries, handling dropped columns and TOAST tables, continuing under imperfect conditions, and why recovery speed is itself part of the capability.]]></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[Extreme Recovery: 1TB of Data Recovered 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[Disk bad blocks damaged the data dictionary, leaving a 1.5TB PostgreSQL database unable to start and backups unusable. This article records how PDU completed the emergency recovery within 48 hours.]]></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[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-Hour Core Data Recovery 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[After a client accidentally ran rm -rf /* and lost the operating system and database, disk recovery specialists recovered the data files. PDU then completed adaptation and data recovery for the domestic PG database in 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>