RootForum Community

Yohoo!

Ein Backup von MYSQL ist ja nicht ganz trivial, wie man gerade auch im Rootforum immer wieder liest.

Jetzt meine Frage, wie das mit PostgreSQL aussieht. Weniger, WIE man ein Backup macht, sondern ob es so geht, wie ich das beschreibe:

Die PostgreSQL laeuft auf einer virtuellen Maschine unter VMware ESX. Ist es ausreichend, einen Snapshot zu machen und diesen zu sichern? Also die virtuelle Platte im laufenden Betrieb zu sichern? Oder geht die Datenbank bzw. das Backup dabei korrupt?

Ich weiss z.B. das MS SQL es garnicht mag, wenn man im laufenden Betrieb die .vmdk sichert. Dann gibt es meist eine korrupte Datenbank nach dem Restore.

Wie sieht das bei PostgreSQL aus?

Auch wenn hier nicht viel los ist, vielleicht weiss es ja doch jemand....

knebb wrote:Die PostgreSQL laeuft auf einer virtuellen Maschine unter VMware ESX. Ist es ausreichend, einen Snapshot zu machen und diesen zu sichern? Also die virtuelle Platte im laufenden Betrieb zu sichern? Oder geht die Datenbank bzw. das Backup dabei korrupt?

Davon ist grundsätzlich abzuraten. Bei PostgreSQL ist es bei eingeschaltetem WAL zwar nicht ganz so dramatisch wie bei MySQL (ich würde sagen, in ~80% aller Fälle bekommt die DB ein automatisches Recovery hin), aber die anderen 20% sind eigentlich die, wegen denen man ein Backup überhaupt erst erstellt

Am besten funktioniert IMO bei PostgreSQL ein Continuous Backup über das WAL - man muss sich ja bloß ein kleines Skript schreiben, das bei der Rotation angetriggert wird (die Funktion stellt PostgreSQL von Haus aus bereit) und eine Kopie der letzten WAL-Datei an eine andere Stelle kopiert. Restore dauert aber bei einer großen DB so sehr lange. Deswegen kommt man IMO nicht umhin, den DB-Server alle paar Wochen zu Stoppen und einen Snapshot zu sichern. Danach kann man das WAL purgen, dann dauert ein Restore auch nicht mehr so lange.

knebb wrote:Ein Backup von MYSQL ist ja nicht ganz trivial, wie man gerade auch im Rootforum immer wieder liest.

Ein Backup von MySQL ist genau so trivial wie eines von Postgres, jedenfalls wenn man bei beiden Datenbanken transaktionale Datenbanken verwendet und die Platten-Syncs auf Strikt stehen läßt. Dann macht man nämlich einfach einen LVM Snapshot und gut ist - der Snapshot kann in einer zweiten Instanz gestartet und pre-recovered werden oder man schreibt ihn einfach so raus und recovered ihm beim Restore.

Der Sinn einer Datenbank mit Log und Transaktionen ist genau der, daß man diese Recovery zuverlässig machen kann. Wenn das nicht funktioniert, braucht man den Overhead von Commit und Redo/Undo gar nicht zu machen.