Arkeia

[minimike]

Hi

Ich bin gerade auf der Suche nach einer Backuplösung für PostgreSQL Datenbanken. Es geht darum große Datenbanken die sich im Minutentakt ändern möglichst ohne Downtime zu Backupen. Oder aber wieder Herstellen wenn es denn wirklich mal so übel kommen sollte. Ich habe die Werbung von Arkeia gelesen. Mich hat allerdings gestört das es keine Preise nach zu Lesen gab. Hat jemand Backupsoftware von Arkeia im Einsatz? Und taugt das was?

http://www.arkeia.com

[AlterSack]

Es gibt keine Möglichkeit, eine Datenbank ohne Downtime wiederherzustellen.

Die einfachste Möglichkeit, PostgreSQL bandgerecht zu backuppen, ist pg_dump, bzw pg_dumpall. Während pg_dump nur eine einzelne Datenbank (oder sogar nur eine einzelne Tabelle) dumpen kann, wird mit pg_dumpall alles zu der jeweiligen Engine gehörende in einen File gebannt, einschließlich User, Templates etcpp. Wiederherstellen läßt sich das, indem man den Dumpfile einfach in psql piped.

Wenn es eine große Datenbank ist, kann die Wiederherstellung recht länglich sein. In diesem Falle kannst Du in den Mailarchiven und der PostgreSQL-Dokumentation mal nach den Stichworten archive_mode, PITR und WAL-Replication suchen.

Vielleicht willst Du aber lieber gleich einen Mirror bauen, und von dem dann sichern, in diesem Fall kannst Du ebenfalls mit PITR arbeiten oder Dir mal Slony näher anschauen. Dann hast Du auf der Arbeitsmaschine während des Backup natürlich überhaupt keine Performance-Beeinträchtigungen. Mit PITR kannst Du den Mirror über Cronjob mit maximal 2 Minuten Datenverlust aktuell halten. Der Mirror ist aber natürlich readonly, solange der Master läuft, aber für Backups reicht das ja aus. Mit Slony habe ich keine Erfahrungen.

Bei keinem dieser Verfahren benötigst Du für den Backup eine Downtime. Natürlich ist ein Backup immer eine Belastung, so daß die Performance während des Backups etwas leidet, aber es kann, wenn das System nicht schon ohne Backup am Rande seiner Leistungsfähigkeit arbeitet, problemlos weitergearbeitet werden. Keinesfalls möglich ist das einfache wegkopieren des Datenverzeichnis einer laufenden Engine, daraus kommt keine lauffähige Datenbank zustande (dafür gibt's PITR)!

Wir hatten vor langer Zeit mal Arkeia im Einsatz, es war hübsch, bunt und teuer. Wir verwenden pg_dump, pg_dumpall und amanda für Backups, und PITR für einen Mirror, und bisher haben wir noch nie den Fall gehabt, daraus die DB nicht verlustfrei wiederherstellen zu können. Was aber bei der PostgreSQL überhaupt auch nur zweimal wegen defekter RAID-Controller notwendig war in 8 Jahren. Häufiger verwenden wir die Dumps, um die Datenbanken vom scharfen auf ein Testsystem zu transferieren.

Ein paar Zahlen: Unsere Datenbanken sind zusammen derzeit ca. 16GB groß, keine BLOBs. Die Sicherung der kompletten Daten mit pg_dumpall dauert einschließlich bzip2-Komprimierung ca. 15 Minuten und erzeugt einen knapp 8GB großen File. Das System ist ein Xeon Dualcore mit 2.66GHz und 4GB RAM, RAID5-Plattensystem mit 4 SCSI-Platten, insgesamt nichts wirklich großartiges also.

[minimike]

Nun PITR macht nach meinem derzeitigen Verständniss nur mit einem seperaten Server seinen Sinn. Ich muss erst einmal passende Umsätze generrieren um dafür die Kosten zu rechtfertigen. Bis dahin versuche ich was mit einem Cronjob zu basteln.
Wenn das mal fertig ist werden aber mindestens 2 PostgreSQL Server für failover eingerichtet und ein weiterer steht für Backups bereit.

[AlterSack]

PITR kann durchaus auch mit nur einer Maschine einen Sinn machen, wenn man auf eine separate Platte archiviert. Sollte das Hauptplattensystem mal zusammenbrechen, kann man die Datenbank auf einem anderen Rechner aus den PITR-Dumps mit sehr wenig Datenverlust wiederherstellen. Ein Dump mit pg_dump bedeutet bei der Wiederherstellung immer so viel Datenverlust, wie zwischen letztem Dump und Crash umgesetzt wurde. Je nachdem, was Du mit der Datenbank vorhast, und was der Kunde an Datensicherheit verlangt, kann das Wurscht sein oder das Ende der Beziehung zum Kunden mit anschließenden kundenseitigen Schadenersatzforderungen bedeuten. Dabei ist es meist gar nicht so wichtig, wie lange die Wiederherstellung dauert, solange keine bereits eingegebenen Daten verloren gehen.

Für die normale allnächtliche Standard-Bandsicherung würde ich allerdings einfach pg_dump bzw. pg_dumpall benutzen und den Dump dann auf Band oder externe Platte ziehen.

[minimike]

Also ich habe einen Raid1 mit LVM. LVM Snapshots eignen sich nicht wirklich für Datenbankbackups. Sind aber für gewöhnliche Feld, Wald und Wiesenbackups eine feine Sache. Also du meinst es würde Sinn machen zum Beispiel ein Volume nur für Backups/PITR anzulegen? Sofern sich der LVM nicht auflöst oder der Ram eine Umlaufbahn um die Sonne dreht wäre das machbar.
Ach ja ich habe gerade endlich die Preise für Arkeia gefunden. Für die Kohle bekomme ich ein Jahr lang zwei Server bezahlt und geh noch mit 50 € in die Nacktbar

[AlterSack]

Kein Volume - eine separate Platte ohne LVM.

Stell Dir den worst case vor: Es ist nachmittags 17:00, und der Datenbankserver gibt komplett den Geist auf, die Platten sind zerrimmelt, das Motherboard in Rauch aufgegangen. Du hast nur noch diese eine Platte, auf der der PITR-Backup Deiner Datenbank ist (neben den regulären Dumps, die aber zweite Wahl sind, da zwischen der Sicherung gestern um 22:00 und dem Crash schon werweißwieviele Daten in die Datenbank gelaufen sind).

Auf der Platte liegt ein wiederherstellbarer Dump, der nur ein paar Minuten Datenverlust aufweist. Du kannst sie so nehmen und in einen anderen Rechner mit einer PostgreSQL-Installation einbauen, und die Datenbank wiederherstellen lassen. Wenn da aber ein LVM draufliegt, wird's problematisch, es sei denn, Du hast Dir die Parameter irgendwo notiert oder im Kopf, denn bevor Du an die Daten kommst, muß Du das LVM etablieren. An die Daten einer einfachen, lediglich partitionierten und formatierten Platte kommt man erheblich leichter ran.