PostgreSQL visszaállÍtása

Adatbázis: SQL, XML DB

Sziasztok,

a következő a problémám: Van egy program, ami PostgreSQL-t használ adatok tárolására. Windows 7-en futott, PostgreSQL 9.2. Egy ismerősöm újra akarta rakni a windowst, ezért lemásolta a postgreSQL data könyvtárát backup-nak, majd újratelepítette a windows-t meg a PostgreSQL-t. Rámásolta a lementett data könyvtárat az új install-ra. A probléma az, hogy most az új windows-on a PostgreSQL látja, hogy ott van az adatbázis, de nem látja a táblákat :)

Mint utóbb kiderült, úgy mentette le a data könyvtárat, hogy nem állította le a PostgreSQL server-t :) Van arra valami mód, hogy vissza tudjuk állítani az adatokat? Magának az adatnak ott kell lennie, mert kb 32 Gb foglal :)

Előre is köszi.

  • 4665 megtekintés

( Little Dragon | 2013. 12. 16., h – 22:41 )

Csak egy vad ottlet: A data konyvtaron, jobb click, Properties, Security, Advanced, Owner, Edit, csereld at a tulajdonost arra az account-ra amely a postgresql service-t futtatja (replace owner on subdirtectories and objects: yes). Mivel uj telepites (windows es uj az account is) a SID mas lesz meg akkor is ha az account nev megegyezik, ezert lehet, hogy siman nincs joga irni a konyvtar tartalmat. Ha szerencsed van es minden file epen maradt (ertsd nincs "torn page", vagy hasonlo), akkor meg akar mukodhet is. Nem tudom hogy van-e valami DB konzisztencia ellenorzes PostgreSQL-en, ha van, akkor futtasd.

FYI: Nem vagyok expert PostgreSQL temaban.

ha a masok altal javasoltak nem segitenek akkor esetleg megprobalhatod torolni a file-t, ahogy a lenti idezet mondja, csak legyen rola egy masolat.

Nem tudom, hogy a file mit szolgal, de itt (http://www.postgresql.org/message-id/50378E29.2000704@timbira.com) ezt talaltam, az utolso mondat erdekes (ugy tudom ebbol a filebol ketto is lehet ket kulon konyvtarban):

> Maybe this is a bug.
> if stats collector process don't product pg_stat_tmp/pgstat.stat file, the
> autovacuum launcher process will output those WARNING message?
>
It is possible but... Did you see any ERROR message(s) related to statistics
collector before those ones? To solver your problem, you can remove the
pgstat.stat file that it will be created again next time server starts. Of
course, you will loose the statistics, hence remember to VACUUM ANALYZE your
cluster.

( pepelopez | 2013. 12. 17., k – 14:53 )

Ugyan azt a verziójú PostgreSQL telepítse fel, utána másolja be.
Így nekem már sikerült bsd-n. Fontos a verzió és arhitectura egyezzen, utána pg_dump/pg_restore

+1
Ennyire mélyen nem ismerem a postgres lelkivilágát, de bőven elképzelhető hogy a file-okba itt ott memória blokkokat ír ki, aminél bizony előfordul, hogy a rendszer adottságai miatt align/padding van (bizonyos memória területeket a helyükre illeszt azért hogy pl. egy integer ne szóhatáron legyen). Próbálja ki 32 biten

// Happy debugging, suckers
#define true (rand() > 10)

( bviktor | 2013. 12. 17., k – 19:28 )

Mint utóbb kiderült, úgy mentette le a data könyvtárat, hogy nem állította le a PostgreSQL server-t :)

Az meg a kisebbik baj, a nagyobbik, hogy nem pg_dump(all)-t hasznalt. Ez a fajlmasolosdi max SQLite-nal lenne elfogadhato, bar ott se ez a javasolt modszer.

Ha fajlokkal szeretnek szenvedni, akkor fajlokban tarolnam, nem adatbazisban -> File-ban tarolod tovabbra is, strukturaltan, amit egy interface-en keresztul ersz el. Ha nem tudod mit beszelsz, inkabb meg se szolalj, toled folyamatosan az ilyen baromsagok omlenek

// Happy debugging, suckers
#define true (rand() > 10)

meg fogsz lepodni, de lockol. Database-t nem, tablakat igen, reszlegesen, de bizonyos esetben a konzisztencia megorzese erdekeben kenytelen vagy teljes write lockot alkalmazni. Ennel egyszerubb snapshotot vegezni es csak a deltakat elmozgatni ha rendszeres backup kell (meg ugy egyebkent is), vagy mar helybol replikalsz. A ki dump be dump nem jo moka bizonyos meret felett

// Happy debugging, suckers
#define true (rand() > 10)

ha fileonkent mented a 32GB -s vagy nagyobb adatbazisodat, akkor

a, serul az adatbazis ( lasd a topicot )
b, a mentes idejere leallitod a db szervert - igy meg ugyanott vagy, mint ha a dump lockolja a tablakat.

arrol nem is szolva, hogy rendes adatbazisszerver azert tud olyat, hogy a dump felé vegig a db megnyitaskor ervenyes allapotot mutatja, mikozben mindenki mas dolgozhat kedvere.

en mar egy ideje a c verziot hasznalom, replikalva van az adatbazis, es a replikarol keszul a dump...

c -> lasd fentebb, mar irtam
a -> igen, ezert irtam snapshotot, raadaskent binaris file-ra is letezik az a szo hogy incrementalis backup, igy nem kell 32GB-t mozgatnod minden alkalommal
b -> nem kell leallitani, meg is lehet kerni azt az adatbazis szervert hogy ugyan legyen mar szives kiirni az adatokat (amit egyebkent is perzisztálva tárol), igy adatvesztés nem lesz.

// Happy debugging, suckers
#define true (rand() > 10)

Igen, a t. Win7 user a dump-ig sem jutott el, vagy hogy leallitsa a szervert, de majd deltat fog hasznalni, meg incrementalis backup-ot, meg megkeri a db-t, hogy flush-oljon, uggyvan, uggyvan. Tenyleg mennyivel jobb ez, mint egyetlen parancsot kiadni, es egyetlen tomoritett fajlt megkapni a vegen, valoban.

Mivel a mostani szál, amiról szó van, innen indult: "Ez igy nem teljesen allja meg a helyet. Valos backup megoldas a fajl szintu tarolas, masolas. Termeszetesen a dokumentacio elolvasasa es abban foglaltak betartasa utan."

Ahogy te is, én is általánosságban beszéltem a backupolás lehetőségeiről, aminél te kijelentetted hogy a file alapú archiválás az ördögtől való, én meg azt mondtam hogy nem, sőt, még jobb is mint dumpolgatni

// Happy debugging, suckers
#define true (rand() > 10)

( Safi v | 2013. 12. 18., sze – 10:11 )

Az igazsághoz hozzá tartozik, hogy egy évvel ezelőtt már működött így a dolog. Akkor 8.4es Postgres futott, és meg van az egy évvel korábbi data könyvtár is, azt bemásolva egy 8.4es postgres alá jó az adatbázis. A 9.2-es nem megy, ami az idei állapot.

Az adatok amúgy nem kritikusak, csak azért jó volna ha megvolnának :D

Közben megoldódott..
Az volt a baj, hogy csak az tudta, hogy a 9.2-es verzió volt, de hogy azon belül melyik azt nem.
De szerencséjére nem csak a data mappát másolta le, hanem a komplet postgres install-t, így az exe-k is megvoltak. Szóval azt elidítva most működik. Csinalok róla rendes dump-ot és majd azt beimportálom az installált verzióba.