张晨：让数据恢复变得痛苦的PostgreSQL特性
内容提要
PostgreSQL将每个表存储为独立文件，系统目录（如pg_class、pg_attribute）也如此。在大量表场景下，目录文件可能达数百MB至1GB。若遭勒索软件加密，目录文件损坏会导致数据恢复困难，因初始化依赖它们。对比MySQL和Oracle，它们集中存储字典，风险更集中但恢复更成熟。
延伸解读
系统目录文件为何成为恢复的“死穴”
PostgreSQL将每个表（包括系统目录表）存储为独立文件，在大量表场景下，pg_attribute等目录文件可能达到数百MB甚至1GB。一旦这些文件被加密或损坏，初始化过程就无法进行，因为恢复工具依赖它们重建数据库结构。文章指出，即使数据文件本身有部分完好，目录文件的损坏也会导致整体恢复陷入僵局。
不同数据库的字典存储与风险对比
MySQL将数据字典集中在mysql.ibd文件中，Oracle则存放在SYSTEM表空间中，两者都是集中式存储，风险集中但恢复手段相对成熟。PostgreSQL的目录文件分散且与普通表文件一样暴露，导致勒索软件攻击时所有目录文件可能同时被加密，恢复难度更大。这种设计差异直接影响灾难恢复的可行性和效率。
备份文件也可能成为“受害者”
文章提到，客户拥有的pg_dump逻辑备份文件也被加密，且备份文件头部（包含表关系元数据）恰好被加密，导致即使能提取数据块，也难以识别归属。这提醒我们，备份文件同样需要严格保护，否则在灾难发生时可能无法提供有效帮助。
Q&A
PostgreSQL中每个表存储为独立文件的设计在数据恢复时有什么弊端？
在PostgreSQL中，每个表（包括系统目录表）都存储为独立的文件。当数据目录遭受勒索软件加密或磁盘级破坏时，所有表文件都会受到影响，包括系统目录文件（如pg_class、pg_attribute等）。如果这些目录文件被加密或损坏，数据库初始化将无法进行，因为初始化依赖它们来重建数据库结构，导致数据恢复变得极其困难。
PostgreSQL系统目录文件在大量表场景下可能有多大？
在拥有10万张表、平均每表50列的场景下，pg_class和pg_type各约20-30MB，pg_attribute约850MB至1GB，pg_namespace通常很小（KB到几MB）。因此，核心目录文件可能达到数百MB甚至1GB。
PostgreSQL与MySQL在数据字典存储方式上有何不同？
PostgreSQL将系统目录（如pg_class、pg_attribute）作为独立的表文件存储，分散在数据目录中。而MySQL 8.x将数据字典集中存储在mysql.ibd文件中，由InnoDB管理。PostgreSQL的目录文件分散，容易单独受损；MySQL的字典集中，风险集中但恢复相对成熟。
Oracle的数据字典存储在哪里？与PostgreSQL相比有何特点？
Oracle的数据字典基础表存储在SYSTEM表空间中，由SYS拥有。SYSTEM表空间映射到一个或多个数据文件。与PostgreSQL相比，Oracle的字典集中存储，不会像PostgreSQL那样分散在多个独立文件中，因此风险更集中，但恢复方法相对成熟。
在勒索软件攻击中，PostgreSQL系统目录文件被加密后，为什么恢复变得困难？
因为PostgreSQL的初始化过程依赖系统目录（pg_class、pg_attribute等）来重建数据库结构。如果这些目录文件被加密或损坏，初始化无法进行，无法读取表结构信息，导致无法提取数据。即使有逻辑备份，如果备份文件也被加密，恢复将更加困难。
PostgreSQL的pg_attribute表在大量表场景下为什么可能变得很大？
pg_attribute记录每个表的列定义。如果数据库有10万张表，平均每表50列，那么pg_attribute将有500万行。每行约180-200字节，因此堆体大小可达850MB至1GB。
