Eu usei o PostgreSQL 8.1 no Gentoo / Linux 2.6.14r5. O espaço em disco do meu servidor de banco de dados é semelhante ao seguinte:
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
Não consigo reiniciar o ./etc/init.d/postgresql porque os dados do subdiretório em / var / lib / postgresql estão vazios. O PostgreSQL8.1 foi atualizado a partir de 8.0, então existe um data.old em / var / lib / postgresql. Quando executo 'du -b', o resultado está abaixo:
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 .
Quando executo 'pg_dump -h my.host.ip.0 -p 5432 -U postgres -Ft -b -v -f "/some/diretorio/backup.file" mydb', a mensagem está abaixo:
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
por favor me ajude! Qualquer ideia será apreciada!
Obrigado!
Seu servidor do Postgres era acessível pela Internet? Recentemente, foi publicada uma vulnerabilidade do Postgres, mas a versão 8.1 não é suportada desde 2010, por isso, não recebeu atualizações de segurança. O uso dessa versão não é razoável se o fornecedor do sistema operacional não fornecer atualizações com backport - como, por exemplo, o RHEL5 ou o CentOS5. Seu kernel do SO é de cerca de 2006 - o seu sistema operacional ainda recebe atualizações de segurança?
Parece que o seu sistema foi comprometido e todos os seus dados foram simplesmente eliminados. Se você não tem backups, então eu suponho que seja irrecuperável (por meros mortais). Se o seu servidor de banco de dados ainda estiver em execução, você pode tentar despejar dados de tabelas únicas - parece que _selections_by_content_last30days e _selections_by_content_last30days foram despejados com sucesso, e actionlog table não foi. Se o seu banco de dados ainda estiver em execução, ele poderá ter alguns arquivos abertos que foram excluídos, mas que não serão realmente liberados até que ele pare - pode haver alguns dados recuperáveis lá.
Os dados da versão 8.0 anterior ainda podem ser recuperados, mas é uma operação complicada, já que você precisará compilar e instalar a versão antiga ou o postgres para acessá-la. É melhor fazer isso em outro servidor - copie-o em algum lugar seguro o mais rápido possível!