Обсуждение: BUG #16844: Relation mapping file "global/pg_filenode.map" contains invalid data

The following bug has been logged on the website:

Bug reference:      16844
Logged by:          Lucas Valardao
Email address:      lucas.valardao@gmail.com
PostgreSQL version: 9.6.0
Operating system:   Windows Server 2012 R2
Description:

Good morning, dear!

We went through a hacker attack at our company, and corrupted some data
folders.

Is there any way to correct this error: "Relation mapping file
"global/pg_filenode.map" contains invalid data".

We have no backup, this would be our last hope!

Thanks for listening.

At Thu, 28 Jan 2021 13:16:32 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in 
> The following bug has been logged on the website:
> 
> Bug reference:      16844
> Logged by:          Lucas Valardao
> Email address:      lucas.valardao@gmail.com
> PostgreSQL version: 9.6.0
> Operating system:   Windows Server 2012 R2
> Description:        
> 
> Good morning, dear!
> 
> We went through a hacker attack at our company, and corrupted some data
> folders.
> 
> Is there any way to correct this error: "Relation mapping file
> "global/pg_filenode.map" contains invalid data".

This is not a bug report. You should have posted this into -general
list.

> We have no backup, this would be our last hope!

Note that you should take a copy of the whole cluster before trying
restoration.

The file contains physical-file mappings for shared catalog tables.

The most easy way I think that possibly restores the file is just
copying the same file from a freshly-create cluster on the same
platform (It might be platform-dependent, but I'm not sure.) and the
same server major version.  If you're lucky enough it might work.

If it doesn't work, the file has been updated since the broken cluster
was created.  In that case, there might be a "RelMap" WAL record in
your recent WAL files by a quite low possibility. The record contains
the whole content of the file. Records corresponding to
global/pg_relfilenode.map has databaseid = 0.

pg_xlogdump .../pg_xlog/000xxxxxx | grep RelMap

rmgr: RelMap      len (rec/tot):    553/   553, tx:        510, lsn: 0/01639208, prev 0/016391D0, desc: UPDATE database
0tablespace 1663 size 512
 

(this is not a real one since no workable 9.6 for me for now.)

There's no established way to restore the file from a WAL record
content manually, but the steps would be like the follows.

1. You can find the record location from the WAL description. In the
 above case, you will find the record at 0x639208 in the file.

2. The file content starts by a fixed magic header byte sequence.
   "00 59 27 17"  (0x592717). and the size should be 512 bytes.

Otherwise..., the last choice is inspecting the cluster in
binary-level to infer the relation map then create the file from
scratch... Almost impossible.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

On Thu, Jan 28, 2021 at 6:40 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> Otherwise..., the last choice is inspecting the cluster in
> binary-level to infer the relation map then create the file from
> scratch... Almost impossible.

pg_hexedit includes a tool that can output the contents of a
pg_filenode.map file. It wouldn't be that hard to put one together if
you were extremely motivated.

However, even that probably would not be enough. I don't see any
reason to imagine that that's the only file that's corrupt.

-- 
Peter Geoghegan

At Thu, 28 Jan 2021 18:53:18 -0800, Peter Geoghegan <pg@bowt.ie> wrote in 
> On Thu, Jan 28, 2021 at 6:40 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > Otherwise..., the last choice is inspecting the cluster in
> > binary-level to infer the relation map then create the file from
> > scratch... Almost impossible.
> 
> pg_hexedit includes a tool that can output the contents of a
> pg_filenode.map file. It wouldn't be that hard to put one together if
> you were extremely motivated.

Oops! That was a trap robbed my time. A rush work is attached.

> However, even that probably would not be enough. I don't see any
> reason to imagine that that's the only file that's corrupt.

Agreed. I don't beleve the file is the only one that has been broken.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center