저는 Gentoo/Linux 2.6.14r5에서 PostgreSQL 8.1을 사용했습니다. 내 DB 서버의 디스크 공간은 다음과 같습니다.
db postgresql # df -l
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 9775248 2018528 7756720 21% /
udev 1557872 88 1557784 1% /dev
shm 1557872 0 1557872 0% /dev/shm
/dev/sda4 281096760 244270836 36825924 87% /var/lib/postgresql
/dev/sdb1 961402192 244780080 667785712 27% /mnt/sdb1
/var/lib/postgresql 아래의 하위 디렉터리 데이터가 비어 있기 때문에 ./etc/init.d/postgresql을 다시 시작할 수 없습니다. PostgreSQL8.1은 8.0에서 업데이트되었으므로 /var/lib/postgresql에 data.old가 있습니다. 'du -b'를 실행하면 결과는 다음과 같습니다.
postgresql # du -b
471 ./.ssh
580 ./data
7697 ./paul/Fifthwindow-RogersBuck
19673 ./paul/Fifthwindow-Tattoo/Output
20633 ./paul/Fifthwindow-Tattoo
13762 ./paul/Fifthwindow-Beard/Output
14493 ./paul/Fifthwindow-Beard
3036 ./paul/Fifthwindow-Touch1/Output
10789 ./paul/Fifthwindow-Touch1
56931 ./paul
3624120 ./data.old/base/1
3624120 ./data.old/base/10792
3624120 ./data.old/base/10793
48 ./data.old/base/16394/pgsql_tmp
248802448893 ./data.old/base/16394
48 ./data.old/base/backup
248813321469 ./data.old/base
11370 ./data.old/paul/output_files
14332 ./data.old/paul
122952 ./data.old/pg_subtrans
48 ./data.old/pg_twophase
57416 ./data.old/pg_multixact/members
49224 ./data.old/pg_multixact/offsets
106736 ./data.old/pg_multixact
4880603 ./data.old/global
316494192 ./data.old/pg_clog
48 ./data.old/pg_xlog/archive_status
536872320 ./data.old/pg_xlog
48 ./data.old/pg_tblspc
249678076379 ./data.old
27023 ./scripts/cron/daily
917 ./scripts/cron/weekly
28036 ./scripts/cron
861 ./scripts/runOnce
599794 ./scripts/manual
628811 ./scripts
171463723 ./output
249850258001 .
'pg_dump -h my.host.ip.0 -p 5432 -U postgres -F t -b -v -f "/some/directory/backup.file" mydb'를 실행하면 다음 메시지가 나타납니다.
pg_dump: dumping contents of table _selections_by_content_last30days
pg_dump: dumping contents of table _selections_by_content_last365days
pg_dump: dumping contents of table actionlog
pg_dump: ERROR: could not count blocks of relation 1663/16394/17943: No such file or directory
pg_dump: SQL command to dump the contents of table "actionlog" failed: PQendcopy() failed.
pg_dump: Error message from server: ERROR: could not count blocks of relation 1663/16394/17943: No such file or directory
pg_dump: The command was: COPY public.actionlog (eventdetail, eventdatetime, eventtypeid, consoleid, albumid, trackid, sequenceid, sessionid, contentid, actionlogid, fileid) TO stdout;
pg_dump: *** aborted because of error
도와주세요! 어떤 아이디어라도 감사하겠습니다!
감사해요!
답변1
마침내 나는 그것을 알아 냈습니다. 그 이유는 디스크 파티션 폴더가 1663/16394/17943다른 물리적 하드 드라이버에 있었기 때문입니다. 그래서 먼저 마운트한 후 다음 단계를 수행해야 했습니다.
그건 아주 오래된 시스템이었죠. 다행히 더 이상 신경 쓸 필요가 없었습니다.
답변2
Postgres 서버를 인터넷에서 액세스할 수 있었습니까? 최근 Postgres 취약점이 공개됐으나 8.1 버전은 2010년부터 지원되지 않아 보안 업데이트를 받지 못했습니다. OS 공급업체가 RHEL5 또는 CentOS5와 같이 백포트된 업데이트를 제공하지 않는 경우 이 버전을 사용하는 것은 비합리적입니다. 귀하의 OS 커널은 2006년경의 것입니다. 귀하의 OS는 여전히 보안 업데이트를 받고 있습니까?
시스템이 손상되어 모든 데이터가 삭제된 것 같습니다. 백업이 없으면 복구할 수 없다고 생각합니다(단순한 필사자의 경우). 데이터베이스 서버가 아직 실행 중인 경우 단일 테이블에서 데이터 덤프를 시도할 수 있습니다. 이는 _selections_by_content_last30days성공적 _selections_by_content_last30days으로 덤프되었지만 actionlog테이블은 덤프되지 않은 것처럼 보입니다. 데이터베이스가 계속 실행 중인 경우 삭제된 열려 있는 파일이 있을 수 있지만 중지될 때까지 실제로 해제되지는 않습니다. 거기에 복구 가능한 데이터가 있을 수 있습니다.
이전 8.0 릴리스의 데이터는 여전히 복구 가능하지만 액세스하려면 이전 버전이나 postgres를 컴파일하고 설치해야 하므로 작업이 복잡합니다. 다른 서버에서 이 작업을 수행하는 것이 더 좋습니다. 가능한 한 빨리 안전한 곳에 복사하세요!