Обсуждение: Postgresql global directory
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