我正在尝试从我拥有的数据库中恢复/救援数据库：
我在PGDATA/base（/var/lib/postgresql/9.6/main/base/）中拥有所有最近的文件，但是我没有完整的/var/lib/postgresql/9.6/main/
我有旧备份中的所有文件（并且没有太大不同），我在新安装的PostgreSQL-9.6中恢复了该文件。
我从硬盘驱动器中救出了很多文件（来自ddrescue），我得到了成千上万个没有名称的文件（具有“＃”，然后有一个数字，并且位于lost + found目录中），所以，例如：
pg_class文件pg_clog文件的0000目录编辑：
可能我具有pg_xlog的内容，但是我没有文件名。我有5个文件，大小为16777216字节：
#288294 (date 2019-04-01)
#288287 (date 2019-05-14)
#288293 (date 2019-07-02)
#261307 (date 2019-11-27)
#270185 (date 2020-01-28)
而且我的旧转储是从2019-04-23开始的，所以第一个可以一样吗？
因此，我下一步将尝试使用pg_xlogdump读取这些文件和/或尝试使用这些名称文件为它们命名（以按日期排列00000001000000000000000A并将它们放置到新的pg_xlog目录中，我看到系统对它们进行文件命名了吗？）。我也意识到最后一个有硬盘崩溃的日期，所以我有最后一个。
我从硬盘驱动器中救出的PGDATA/base目录（损坏）包含其中包含很多文件的目录1，12406，12407和37972。我用pg_filedump -fi检查更新的数据是否存储在目录37972中的文件中。
相同（但旧）的数据存储在还原的转储中的目录PGDATA/base/16387中的文件中。
我试图直接将文件从一个文件复制到另一个文件，从而将更新的数据混合到旧数据库中，但是不起作用。解决权限错误后，我可以通过这种方式进入“ Frankenstein”数据库：
postgres@host:~$ postgres --single -P -D /var/lib/postgresql/9.6/main/ dbname
[我试图做一些事情，例如重新索引，但出现此错误：
PostgreSQL stand-alone backend 9.6.16
backend> reindex system dbname;
ERROR: could not access status of transaction 136889
DETAIL: Could not read from file "pg_subtrans/0002" at offset 16384: Success.
CONTEXT: while checking uniqueness of tuple (1,7) in relation "pg_toast_2619"
STATEMENT: reindex system dbname;
肯定pg_subtrans/0002文件是“科学怪人”的一部分，而不是好的文件（因为我还没有找到它，但名称不正确），所以我尝试：先复制另一个看上去相似的文件，然后，在该文件中使用dd生成8192个零，在两种情况下，我都会得到相同的错误（并且在该文件不存在的情况下，请获取DETAIL: Could not open file "pg_subtrans/0002": No such file or directory.）。无论如何，我都不知道那个文件应该是什么。您认为我可以从其他文件中获取数据吗？还是可以使用某些工具找到丢失的文件？因此，pg_filedump告诉我该目录pg_subtrans/0000中另一个文件的空白。
额外注意：我发现了这篇有用的博客文章，内容涉及使用pg_filedump，pg_class的文件，reindex system和其他工具从营救的文件中进行还原，但是我很难理解如何使其适应我的具体且容易解决的问题（我认为我的问题更容易，因为我有转储）：https://www.commandprompt.com/blog/recovering_a_lost-and-found_database/
注定。没有pg_xlog和（特别是）pg_clog中的信息，您将无法取回信息。
[博学的法医专家也许可以挽救您的一些数据，但这不是一个简单的过程。