分类目录归档：PostgreSQL

注意:PostgreSQL库出现readme_to_recover勒索

发表于 2026 年 1 月 22 日由惜分飞

以前恢复过不少mysql库被删除的勒索case,比如:
read_me_recover_tn勒索恢复
 A_H_README_TO_RECOVER勒索恢复
 A____Z____RECOVER____DATA勒索恢复
今天在PostgreSQL库中也简单了类似的勒索案例

[postgres@xifenfei database]$ psql 
psql (12.8)
Type "help" for help.

postgres=> \l
                                     List of databases
       Name        |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges   
-------------------+----------+----------+------------+------------+-----------------------
 ldar-test         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 postgres          | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 readme_to_recover | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 template0         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
                   |          |          |            |            | postgres=CTc/postgres
 template1         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
                   |          |          |            |            | postgres=CTc/postgres
(5 rows)

postgres=> \c readme_to_recover
You are now connected to database "readme_to_recover" as user "postgres".
readme_to_recover=> \d
         List of relations
 Schema |  Name  | Type  |  Owner   
--------+--------+-------+----------
 public | readme | table | postgres
(1 row)

readme_to_recover=> select * from readme;
                                                                                                   
                                 text_field                                              
-------------------------------------------------------------------------------------------------------
-------------------------------------------------
 All your data is backed up. You must pay 0.0051 BTC to bc1q9p333xxxxxxxxxxxxxj2z5fs27pu3u In 48 hours, 
  your data will be publicly disclosed and deleted . (more information: go to http://2info.win/psg)
 After paying send mail to us: rambler+3d2l7@onionmail.org and we will provide a link for 
   you to download your data. Your DBCODE is: xxxxx
(2 rows)

readme_to_recover=> select oid,relname from pg_class;
   oid   |                    relname                    
---------+-----------------------------------------------
 2196735 | readme
    2619 | pg_statistic
    1247 | pg_type
    4159 | pg_toast_2600
    4160 | pg_toast_2600_index
    2830 | pg_toast_2604
    2831 | pg_toast_2604_index
    4161 | pg_toast_3456
    4162 | pg_toast_3456_index
    2832 | pg_toast_2606
    2833 | pg_toast_2606_index
………………
   13373 | _pg_foreign_tables
   13377 | foreign_table_options
   13383 | _pg_user_mappings
   13391 | user_mappings
   13387 | user_mapping_options
(396 rows)

根据这里的readme的oid值，初步怀疑是drop所有业务表,然后创建了readme表,并且插入了勒索信息.

我做的各种数据库恢复比较多，说实话一直对pg这个特点非常不满意：
1. pg的数据存储本身依赖文件系统，通过oid(来表示库，表示表以及其他各种对象，和很多商业化数据库不一样，对于文件系统过于依赖，这样的情况如果发生了drop/truncate表等操作，表从文件系统中被删除，恢复难度较大
2. pg的表对应本身没有在每个数据块的block记录表的id信息，这样使得无法很好的进行底层基于block的扫描恢复数据，目前我知道的pdu一定的这样的功能，但是那是依赖列匹配，原则上来说对于一个稍微复杂一点的系统，这个恢复思路基本上不可行（因为列相似的数据表可能很多，导致恢复的数据过于混乱）
基于上述的两个特点，如果整个业务库被这种勒索破坏，如果没有备份，想比较好的恢复效果基本上很难（除非你运气非常好，os层面反删除恢复效果特别好，这要取决被删除的表在os上没有覆盖，文件系统元数据没有回收，系统没有识别是ssd环境等因素决定）

基于这种故障在没有备份的情况下很难恢复，那我们要做的就是：
1）有有效的备份或者容灾不被破坏;
1> 数据需要有效的备份,有条件的建议异机或者离线
2> 如果有条件可以部署延迟同步的备库,避免发生故障备库同步被破坏

2）尽可能不让这种故障发生:
1>数据库不要暴露在公网上,减少被攻击和入侵的风险
2>数据库不要使用弱口令,减少被暴力攻破密码的风险
3>注意应用漏洞，减少通过sql注入进行数据库进行破坏
4>注意已知的数据库安全漏洞,防止被利用进行攻击
5>注意操作系统安全,因为登录了数据库服务器对于数据库来说就没有安全可言

发表在 PostgreSQL | 标签为 pg 删表勒索, readme_to_recover | 留下评论

记录一次国产数据库被rm -rf /*删除的救援过程

发表于 2026 年 1 月 3 日由惜分飞

有一套国产数据库运行在arm平台的Kylin Linux上

NAME=&amp;quot;Kylin Linux Advanced Server&amp;quot;
VERSION=&amp;quot;V10 (Lance)&amp;quot;
ID=&amp;quot;kylin&amp;quot;
VERSION_ID=&amp;quot;V10&amp;quot;
PRETTY_NAME=&amp;quot;Kylin Linux Advanced Server V10 (Lance)&amp;quot;
ANSI_COLOR=&amp;quot;0;31&amp;quot;

由于数据库归档日志导致磁盘空间满,在清理归档日志的时候不慎执行了rm -rf /*命令

导致系统无法正常启动,客户尝试通过把磁盘挂载到其他机器上启动,但是无法恢复需要数据.由于客户这个是ssd盘的虚拟化环境,担心可能触发trim和进一步破坏的风险,建议客户尽快把虚拟磁盘下载到本地,然后通过工具分析,发现大量数据已经被删除,特别是数据库目录只剩下部分文件

通过分析data/global/1262文件(pg_database)的出来数据库名字对应关系,然后根据应用提供的需要恢复的数据库名称.在data目录中尝试恢复该目录中oid文件,发现最核心的几个字典文件全部异常(元数据异常)

pg_class	1259	存储数据库中所有关系（表、索引、视图、序列等）的元数据
pg_attribute	1249	存储表的列（属性）信息，每个字段对应一行
pg_namespace	2615	存储模式（Schema）信息
pg_type	        1247	存储数据类型信息（内置类型、自定义类型）

对于这种问题,普通的恢复工具无法解决,协调专业的文件系统恢复专家对其进行处理,比较完美的恢复出来的该目录下面绝大部分文件(包括字典文件)

有了比较完美的恢复出来了需要的数据库文件,然后pdu专家进行该国产库的块结构分析和调整程序并恢复出来数据

完成数据恢复之后,把数据提供给客户,由客户那边安排厂商进行后续应用层面工作(比如和历史数据整合,应用调试等),总体算比较完美帮忙客户完成了本次rm -rf /* 故障救援

发表在 Linux, PostgreSQL恢复 | 标签为 pdu恢复, rm -rf / 故障恢复, rm -rf 国产库恢复, rm 数据库恢复 | 评论关闭

PostgreSQL查询一个表相关的所有oid

发表于 2025 年 12 月 12 日由惜分飞

在pg中查询一个表相关的所有oid(表OID、TOAST表OID、索引OID、TOAST表的索引OID、约束OID)

-- 替换这里的表名和模式名
\set search_path = public;
\set table_name '\'AO_6384AB_DISCOVERED\''
\set schema_name '\'public\''

WITH table_info AS (
    -- 基础表信息：表OID
    SELECT
        c.oid AS table_oid,
        c.relname AS table_name,
        c.reltoastrelid AS toast_oid,
        n.nspname AS schema_name
    FROM
        pg_catalog.pg_class c
    JOIN
        pg_catalog.pg_namespace n ON c.relnamespace = n.oid
    WHERE
        c.relname = :table_name
        AND n.nspname = :schema_name
        AND c.relkind = 'r'
),
index_info AS (
    -- 索引信息：索引OID
    SELECT
        t.table_oid,
        i.oid AS object_oid,
        i.relname AS object_name,
        'index' AS object_type
    FROM
        pg_catalog.pg_class i
    JOIN
        pg_catalog.pg_index idx ON i.oid = idx.indexrelid
    JOIN
        table_info t ON idx.indrelid = t.table_oid
    WHERE
        i.relkind = 'i'
),
toast_info AS (
    -- TOAST表信息：TOAST表OID
    SELECT
        t.table_oid,
        t.toast_oid AS object_oid,
        c.relname AS object_name,
        'toast_table' AS object_type
    FROM
        table_info t
    JOIN
        pg_catalog.pg_class c ON t.toast_oid = c.oid
    WHERE
        t.toast_oid <> 0
),
toast_index_info AS (
    -- TOAST索引信息：TOAST表的索引OID
    SELECT
        t.table_oid,
        i.oid AS object_oid,
        i.relname AS object_name,
        'toast_index' AS object_type
    FROM
        table_info t
    JOIN
        pg_catalog.pg_class c ON t.toast_oid = c.oid
    JOIN
        pg_catalog.pg_index idx ON c.oid = idx.indrelid
    JOIN
        pg_catalog.pg_class i ON idx.indexrelid = i.oid
    WHERE
        t.toast_oid <> 0
        AND i.relkind = 'i'
),
constraint_info AS (
    -- 约束信息：约束OID
    SELECT
        t.table_oid,
        con.oid AS object_oid,
        con.conname AS object_name,
        CASE con.contype
            WHEN 'p' THEN 'primary_key'
            WHEN 'u' THEN 'unique_constraint'
            WHEN 'f' THEN 'foreign_key'
            WHEN 'c' THEN 'check_constraint'
            ELSE 'other_constraint'
        END AS object_type
    FROM
        pg_catalog.pg_constraint con
    JOIN
        table_info t ON con.conrelid = t.table_oid
)
-- 合并所有结果，先输出表本身的信息，再输出其他关联对象
SELECT
    t.table_oid AS object_oid,
    t.table_name AS object_name,
    'table' AS object_type,
    t.schema_name AS schema_name
FROM
    table_info t
UNION ALL
SELECT
    object_oid,
    object_name,
    object_type,
    (SELECT schema_name FROM table_info) AS schema_name
FROM
    index_info
UNION ALL
SELECT
    object_oid,
    object_name,
    object_type,
    (SELECT schema_name FROM table_info) AS schema_name
FROM
    toast_info
UNION ALL
SELECT
    object_oid,
    object_name,
    object_type,
    (SELECT schema_name FROM table_info) AS schema_name
FROM
    toast_index_info
UNION ALL
SELECT
    object_oid,
    object_name,
    object_type,
    (SELECT schema_name FROM table_info) AS schema_name
FROM
    constraint_info
ORDER BY
    object_type;

发表在 PostgreSQL | 标签为 pg表相关oid, 表所有oid | 评论关闭

17813235971

QQ 咨询

分类目录归档：PostgreSQL

注意:PostgreSQL库出现readme_to_recover勒索

记录一次国产数据库被rm -rf /*删除的救援过程

PostgreSQL查询一个表相关的所有oid

文章分类

最近发表

分类目录归档：PostgreSQL

注意:PostgreSQL库出现readme_to_recover勒索

记录一次国产数据库被rm -rf /*删除的救援过程

PostgreSQL查询一个表相关的所有oid

标签云

文章分类

最近发表