Я использовал PostgreSQL 8.1 на Gentoo / Linux 2.6.14r5. Дисковое пространство моего сервера 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
Я не могу перезапустить ./etc/init.d/postgresql, потому что данные подкаталога в / var / lib / postgresql пусты. PostgreSQL8.1 был обновлен с версии 8.0, поэтому файл data.old находится в / var / lib / postgresql. Когда я выполняю '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
пожалуйста, помогите мне! Любая идея будет оценена по достоинству!
Спасибо!
Наконец-то разобрался. Это потому, что папка раздела диска 1663/16394/17943
был на другом физическом жестком драйвере. Поэтому мне пришлось сначала смонтировать его, а затем сделать следующий шаг.
Это была очень старая система. К счастью, мне больше не пришлось об этом заботиться.
Был ли ваш сервер Postgres доступен из Интернета? Недавно была опубликована уязвимость Postgres, но версия 8.1 не поддерживается с 2010 года, поэтому обновлений безопасности она не получала. Использование этой версии нецелесообразно, если поставщик вашей ОС не предоставляет обновленные версии, как, например, RHEL5 или CentOS5. Ядро вашей ОС относится примерно к 2006 году - ваша ОС все еще получает обновления безопасности?
Похоже, ваша система была взломана, и все ваши данные просто удалены. Если у вас нет резервных копий, я полагаю, что их невозможно восстановить (для простых смертных). Если ваш сервер базы данных все еще работает, вы можете попытаться сбросить данные из отдельных таблиц - это выглядит так: _selections_by_content_last30days
и _selections_by_content_last30days
был успешно сброшен, и actionlog
стол не было. Если ваша база данных все еще работает, у нее могут быть открытые файлы, которые были удалены, но фактически не будут освобождены до тех пор, пока не остановятся - там могут быть некоторые данные, которые можно восстановить.
Данные из старой версии 8.0 все еще можно восстановить, но это сложная операция, так как вам нужно будет скомпилировать и установить старую версию или postgres, чтобы получить к ней доступ. Лучше сделать это на другом сервере - как можно скорее скопируйте в безопасное место!