Backupstrategie

Hi

Ich betreibe ein Projekt für Emailservices und benutze DBmail als Imapserver und eine PostgreSQL Datenbank als Storage für die eMails. Das Projekt habe ich gestartet um praktische Erfahrungen damit im real Life zu machen.
Jedenfalls bei einer 1 GB großen Datenbank dauert es einige Minuten diese mit pgdump zu Sichern oder Wiederherstellen zu können. Suboptimal wenn man nur Tabellen wiederherstellen möchte. Nun, irgendwann soll die DB so um die 200+ GB groß werden. Ich glaube das wird dann wirklich kritisch werden.
Ich habe jetzt angefangen diesbezüglich nach einer Lösung zu suchen. Allerdings bin ich noch recht ideenlos.
Ich stelle hier mal eine Frage Betreff der besten Backupstrategegie in den Raum. Vieleicht bekomme ich hier ein paar Tips und Denkanstösse.

Die Frage nach der Strategie sollen lieber andere Leute hier beantworten…

Zu der Frage nach “nur bestimmte Tabellen” wieder herstellen:

Wenn Du ein pg_dump im “custom format” machst (Parameter -F), so kannst (musst) Du pg_restore verwenden um das Backup wieder einzuspielen. pg_restore kann einzelne Tabellen (Parameter -t) oder nur bestimmte Objekte (Parameter -L) zurückspielen.

Ob pg_dump mit custom format für eine 200 GB DB geeignet ist (sprich schnell genug) kann ich allerdings nicht sagen.

Für größere Datenmengen (20GB+) bietet sich sicher WAL-Shipping, also das kontinuierliche Sichern der Transaktionslog, an. In dem Fall erstellst du einmalig eine Filesystemkopie des Datenverzeichnisses (nur im Backup-Modus!) und schreibst dann die TX-Logs auf deinen Backup-Server. Kannst du auch unter PITR (Point In Time Recovery) nachlesen.

Der ‘ads’ verweist immer gerne auf die Doku :astonished: , also: PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: Continuous Archiving and Point-In-Time Recovery (PITR)

Hallo Murphy

Danke für deinen Rat! Ich werde mich die Tage damit beschäftigen.
Eine Frage habe aber ich jetzt schon. Mein Projekt ist ein noch nicht realisiertes Startup. Ich betreibe derzeit so etwas in der Art vergleichbar mit Grundlagenforschung. Meine Infrastrukturen sind wirklich minimal. Macht es Sinn so etwas zumindest am Anfang auf ein und dem selben PgSQL Server zu betreiben?

Klar, um sich mit der Technologie vertraut zu machen, kannst du das auch auf dem DBS-System machen, ist halt nur keine Sicherheit im Falle eines Serverausfalls.

Ich habe halt muffe wenn die DB im Eimer ist das ich dann richtig doof da stehe. Wenn der Server down ist dann ist das so. Wichtig ist das ich die DB innerhalb von 3-4 Stunden in einen konsistenten Zustand versetzen kann mit so wenig Datenverlust wie möglich.
Wenn da erst mal Einkünfte erziehlt werden sind zwei Datenbankserver die redunant arbeiten und evtl PITR einfach nur Pflicht.
Aber das wird noch wirklich was dauern.

Grundsätzlich klingt das aber so, als wenn ein Datenverlust ein Problem ist - mal ganz emotionslos formuliert. Und wenn dem so ist, dann verbietet sich ein Backup (welcher Form auch immer) auf dem Datenbanksystem. Stell’ einen einfachen Rechner ohne viel Power aber mit guten Platten daneben und schreibe die Daten darauf hin weg - kostet nicht viel, ist aber sicher. Wenn du die Daten verlierst und nicht nur 3-4 Stunden brauchst, wäre es dir 500 EUR wert gewesen :slight_smile: Zumal du, wie du selbst sagst, keine/wenig Kenntnisse in der Wiederherstellung der Daten mit PG hast.

Die zwei Datenbanken auf dem gleichen Server können durchaus ein Problem sein - spätestens wenn du Tablespaces einsetzt.

Für die Datensicherung solltest du sowohl WAL-Shipping haben, um zeitnah alles wiederherzustellen - als auch einen regelmäßigen Dump mittels pg_dump. Der kommt dann auf ein Streamerband und wird extern gelagert.


Generell solltest du dich mit dem Thema aber auseinandersetzen. Einen Server zum Testen hinstellen, mal die Datenbank kaputt machen und alles wiederherstellen. Mal ein Backup (sowohl ein Online-Backup als auch einen Dump) wieder einspielen. Ect. Damit du Erfahrungen sammelst, wie das funktioniert. Im Fehlerfall hast du keine Zeit dafür, glaub mir :wink: