Hi,

I have a doozy of a problem. Had a dataserver crash hard (it
was hacked and the root kit used broke a lot of files), this happened
after a motherboard went on my backup server, corrupting my backup set.
We have gotten most of the data recovered, however the control files.
Pg_control, x_log, c_log, and the entire global directory has been
dumped into lost+found.

So my question is this. Does anybody know how to create a new global
directory using an existing data set (that was not created by dump)? I
do not have a dump of the data, that would be too easy. My outdated
postgres book says this can be done by using -t with pg_ctrl....however,
with the later versions of postgresql, they have taken that switch out.
I have tried googling it and have come up empty.

I'm using postgresql version 7.2.2-1


Any help would be greatly appreciated,

Ed Howard
Systems Administrator
G120 McCarty Hall
392-1881 ext. 319
ethoward@mail.ifas.ufl.edu

"HOWARD,EDWARD T,III" <ETHoward@mail.ifas.ufl.edu> writes:
> I have a doozy of a problem. Had a dataserver crash hard (it
> was hacked and the root kit used broke a lot of files), this happened
> after a motherboard went on my backup server, corrupting my backup set.
> We have gotten most of the data recovered, however the control files.
> Pg_control, x_log, c_log, and the entire global directory has been
> dumped into lost+found.

Yipes. I'm afraid you're very possibly screwed :-(. It would not be
hard to identify pg_control and the pg_xlog files by size and content,
and with sufficient determination you might do the same for all the
files in global/, but there's no real good way to tell one pg_clog
file from another.

However there is a glimmer of hope: there very possibly *is* only one
pg_clog file, if you had a not-too-high-volume server and you'd been
keeping it vacuumed religiously. If so then (in principle) you can
identify all the files and put them back.

> So my question is this. Does anybody know how to create a new global
> directory using an existing data set (that was not created by dump)?

You will not get a useful solution that way. The files are too
interdependent, you can't plug in files from another installation
without breaking things. What you've got to do is reassemble the jigsaw
puzzle by putting each file back in its proper place.

What I'd suggest is that you make a temporary installation in another
place with a fresh initdb and load your latest available backup into it
(you do have *some* backup I trust). That will give you a reference to
compare to as you try to identify the files.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match