☰

PostgreSQL 8.1 hat nicht genügend Speicherplatz und wurde gestoppt, das Datenverzeichnis ist leer

tag-icon • tag-icon linux postgresql disk-space-utilization gentoo data-recovery
PostgreSQL 8.1 hat nicht genügend Speicherplatz und wurde gestoppt, das Datenverzeichnis ist leer

Ich habe PostgreSQL 8.1 auf Gentoo/Linux 2.6.14r5 verwendet. Der Speicherplatz meines DB-Servers sieht wie folgt aus:

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

Ich kann ./etc/init.d/postgresql nicht neu starten, da das Unterverzeichnis data unter /var/lib/postgresql leer ist. PostgreSQL8.1 wurde von 8.0 aktualisiert, daher gibt es ein data.old in /var/lib/postgresql. Wenn ich „du -b“ ausführe, ist das Ergebnis unten:

     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    .

Wenn ich „pg_dump -h my.host.ip.0 -p 5432 -U postgres -F t -b -v -f "/some/directory/backup.file" mydb“ ausführe, lautet die Meldung:

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

bitte helft mir! Jede Idee ist willkommen!

Danke!

Antwort1

Schließlich habe ich es herausgefunden. Das liegt daran, dass sich der Festplattenpartitionsordner 1663/16394/17943auf einer anderen physischen Festplatte befand. Also musste ich ihn zuerst mounten und dann den nächsten Schritt ausführen.

Das war ein sehr altes System. Zum Glück musste ich mich nicht mehr darum kümmern.

Antwort2

War Ihr Postgres-Server über das Internet erreichbar? Kürzlich wurde eine Sicherheitslücke in Postgres veröffentlicht, aber Version 8.1 wird seit 2010 nicht mehr unterstützt und hat daher keine Sicherheitsupdates erhalten. Die Verwendung dieser Version ist nicht sinnvoll, wenn Ihr Betriebssystemanbieter keine Backport-Updates bereitstellt – wie dies beispielsweise bei RHEL5 oder CentOS5 der Fall ist. Ihr Betriebssystemkernel stammt aus dem Jahr 2006 – erhält Ihr Betriebssystem noch Sicherheitsupdates?

Es sieht so aus, als wäre Ihr System kompromittiert und alle Ihre Daten einfach gelöscht worden. Wenn Sie keine Backups haben, ist es vermutlich nicht wiederherstellbar (für Normalsterbliche jedenfalls). Wenn Ihr Datenbankserver noch läuft, können Sie versuchen, Daten aus einzelnen Tabellen zu sichern – es sieht so aus, als wäre der _selections_by_content_last30daysBackup _selections_by_content_last30dayserfolgreich gewesen, bei actionlogder Tabelle war es jedoch nicht so. Wenn Ihre Datenbank noch läuft, sind möglicherweise einige Dateien offen, die gelöscht wurden, aber erst freigegeben werden, wenn sie gestoppt wird – möglicherweise sind dort wiederherstellbare Daten vorhanden.

Daten aus der alten Version 8.0 können noch wiederhergestellt werden, aber es ist ein komplizierter Vorgang, da Sie die alte Version oder Postgres kompilieren und installieren müssen, um darauf zuzugreifen. Es ist besser, dies auf einem anderen Server zu tun – kopieren Sie sie so schnell wie möglich an einen sicheren Ort!

verwandte Informationen