1

Ok, so foolish idiot here, trashes his postgresql data directory, right at the very moment when his backup routine is currently in the "delete old files" and "create new files" phase.

As a result, Iv'e destroyed my backup AND simultaneously done an 'rm -f *' on the partition holding the cluster.

Anyhoo, as it's on a separate partition I immediately shutdown postgres (Not that I had much option given that it crapped itself anyway) and unmounted the partition.

Iv'e ran extundelete and ext4magic over it and have recovered a surprising amount of files, but find that I'm still missing some key ones, namely the system catalogs.

Looking at the size of the files it would appear that most of the actual data has been rescued, and it's only the catalog files, listing the schema's and the tables that appear to be borked.

On top of that, ext4magic appears to also have gotten back some files by Inode.

Screen Grab from Midnight Commander

So My question is this, I know more or less what the file/folder structure is from the actual main recovery that ext4magic made, and I'm sure that some of the missing files I need are among those Inode recovered files, but I've no idea how I might be able to figure out what the original file path was/is.

Does anyone know of anyway I might be able to determine this??

Right now the partition has been taken offline, so nothing can interfere with it, the Postgres server is shutdown, and the disk/partition is not damaged, so there's a very high chance that everything is still in the same state as it was right after the file system was rm'ed

Aside from that, if there is no way of linking the file name, then does anyone know of a way I can perhaps interrogate the files directly without using postgres, that might allow me to recover the postgres data from them and aid me in being able to link them all back together?

Iv'e got about 3TB of data in total, and I really don't want to have to rebuild all this lot by hand from source data.

  • 2
    Important things to learn: a) backup routine is currently in the "delete old files" and "create new files" phase. is a really bad order for a backup. Delete old files only after all new files have been sucessfully created. b) Having some form of incremental backups is very important. You would also have lost the data if something had happened to the database before the backup, the backup would run "sucessfully", storing the damaged data and deleting the intact data from the day before.. – Sven Sep 21 '18 at 23:28
  • @sven yes I'm aware of that :-) but it's happened, so I'm after solving the problem. Thanks anyway. – shawty Sep 22 '18 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.