Postgres 9.2数据库遭攻击丢表，借助XLOG与旧备份恢复求助

基于你现有的资源（数月前的dump备份、完整XLOG、攻击时的ECS快照），以下是几个可行的恢复路径，按优先级排序：

方案一：旧备份 + XLOG 时间点恢复（最可靠） #

这是PostgreSQL标准的PITR（时间点恢复）流程，利用旧备份为基础，通过XLOG前滚到攻击发生前的状态：

1. 搭建隔离恢复环境
   部署一个和原环境完全一致的Postgres 9.2实例（相同OS、版本、配置参数，尤其是wal_level、checkpoint_segments等WAL相关参数），绝对不要直接操作生产库。

2. 恢复基础备份
   导入数月前的dump.sql备份：

   psql -U 你的超级用户名 -d 目标数据库名 -f /path/to/dump.sql
   

   导入完成后立即停止该实例。

3. 定位恢复时间点
   从原库的postgresql.log中找到DROP TABLE语句的执行时间（如果开启了log_statement=ddl或log_statement=all），将恢复时间设为该时间点的1-2分钟前，避免包含删除操作。

4. 配置恢复参数

   • 在新实例的数据目录下创建recovery.conf文件（Postgres 9.2使用该文件，而非高版本的recovery.signal），写入：

     standby_mode = 'off'
     recovery_target_time = 'YYYY-MM-DD HH:MI:SS'  # 替换为你确定的恢复时间点
     restore_command = 'cp /path/to/你的XLOG目录/%f %p'  # 替换为实际XLOG文件路径
     

   • 确保postgresql.conf中archive_mode设为on（如果之前没开，临时开启）。

5. 启动恢复
   启动Postgres服务，等待自动完成恢复。恢复结束后实例会自动停止，此时启动实例即可验证数据是否完整。

方案二：ECS快照 + 定位DROP操作LSN恢复 #

如果攻击时的快照已经包含被删表的状态（即快照是攻击后创建的），可以通过快照恢复出实例，再利用XLOG回退到DROP操作前的状态：

1. 从快照恢复隔离实例
   用ECS快照创建一个独立的云服务器，恢复出Postgres实例，启动后立即停止，禁止业务访问。

2. 定位DROP操作的LSN

   • 检查原库的postgresql.log，如果日志行前缀包含%x（即配置了log_line_prefix = '%t [%p]: [%c-%l] user=%u,db=%d,app=%a,client=%h,xid=%x'），可以直接获取DROP操作对应的LSN。
   • 如果没有LSN日志，可通过日志中的DROP语句执行时间，将recovery_target_time设为该时间前的1-2分钟。

3. 配置并执行恢复
   和方案一的步骤4-5一致，将recovery_target_time或recovery_target_lsn设为DROP操作前的节点，通过restore_command加载完整的XLOG文件完成恢复。

方案三：从XLOG提取被删表数据（应急备选） #

如果以上方案无法执行，可尝试直接从XLOG中提取被删表的数据（适合小表，操作较繁琐）：

1. 编译适配Postgres 9.2的XLOG解析工具
   下载Postgres 9.2的源码包，编译pg_xlogdump工具（直接用官方源码编译比第三方工具更可靠）：

   wget https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.gz
   tar zxf postgresql-9.2.24.tar.gz
   cd postgresql-9.2.24
   ./configure --prefix=/usr/local/pgsql-9.2
   make
   # 编译完成后，pg_xlogdump工具在src/bin/pg_xlogdump/目录下
   

2. 解析XLOG提取数据
   使用编译好的pg_xlogdump遍历XLOG文件，查找被删表的INSERT/UPDATE记录，提取SQL语句：

   ./src/bin/pg_xlogdump/pg_xlogdump /path/to/xlog/0000000100000000000000XX | grep -E 'INSERT INTO 你的表名|UPDATE 你的表名'
   

   将提取到的SQL语句整理后，导入到恢复好的基础备份库中。

后续安全加固建议 #

恢复完成后必须立即执行以下操作，避免再次被攻击：

• 限制Postgres服务的访问IP，仅允许可信地址连接。
• 禁用超级用户的远程登录权限，创建专用业务账号并赋予最小权限。
• 开启log_statement=all和审计日志，定期排查异常操作。
• 立即升级到受支持的PostgreSQL版本（9.2已停止安全维护多年，存在大量漏洞）。
• 建立定期全量备份+增量WAL备份的机制，确保备份的时效性和完整性。

内容的提问来源于stack exchange，提问作者Ruiqing Xu