이 문제로 Postgres 메일링 리스트에 포스팅 해보았으나,
희망적인 대답이 나오지는 않더군요.
결국 닭질을 시작했습니다.
왜냐하면, 다섯명이서 거의 한달간 입력한 자료인데,
그것을 다시 그사람들에게 입력해 달라고 하기에는
너무도 가혹한 짓인 것 같아서 /./
문제의 테이블이 vacuum 되기 전이다는 것을 감안해서,
데이터가 변동되기 전에 제빨리, 테이블 파일을 복사를 해서,
오늘 하루 종일, 그 파일의 구조 분석에 들어갔고,
한 6시간 뒤즈음에 100% 복구를 했습니다.
덕분에, hexcode를 얼마나 많이 보았는지 모르겠습니다. /./
이 사태를 치르고 나니, 오직 생각 나는 것은
백업철저! 이것 뿐이더군요. /./
잡담: 개인적으로 기능적으로 공개용 RDBM 치고는 Postgres 만한것이
없어서 Postgres를 제일 많이 사용하는데, 이 사태를 격고 나니,
Oracle의 undo log가 무진장 부럽더군요. /./
정재익 님께서 쓰시길::
> 오옷.. 그런 엄청난 실수를...
> 안타깝게도 commit 이 마지막 보루입니다.
> 논리적으로 다시 살릴수는 없습니다.
> PostgreSQL의 경우 로깅 시스템이 아직 불완전하여 살릴수가 없습니다.
> 날아간 자료에 조의를... /./
> 필히 데이터는 백업을 받으시기 바랍니다. 현재로서는 그 방법 말고는 좋은 방안이 없는 것 같습니다.
|