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.
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.
0 Answers