Re: Postgresql global directory
От | Tom Lane |
---|---|
Тема | Re: Postgresql global directory |
Дата | |
Msg-id | 24923.1103656881@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Postgresql global directory ("HOWARD,EDWARD T,III" <ETHoward@mail.ifas.ufl.edu>) |
Список | pgsql-admin |
"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
В списке pgsql-admin по дате отправления: