EC2 - Wie kann man PostgreSQL-Daten korrekt sichern?

Hier ist das Setup: 1 kleine Amazon Linux (EBS-gestützte) EC2-Instanz mit 3 zusätzlichen Volumes. Dies ist sowohl ein Webserver als auch ein Datenbankserver. Ein Volume für Code, eines für das PostgreSQL (8.4) -Datenverzeichnis und ein Volume zum Speichern von WAL-Dateien aus PostgreSQL.

(1) Das Volume mit WAL-Dateien verfügt auch über eine Basissicherung des Datenverzeichnisses, die nach einem pg_start_backup () kopiert wird. Anschließend wird die kontinuierliche Archivausgabe von PostgreSQL (WAL-Dateien) gespeichert. Gibt es einen Grund, eine Synchronisierung durchzuführen und das Dateisystem einzufrieren, um einen Snapshot dieses Volumes zu erstellen (mit xfs_freeze, wenn es sich um XFS handelt, oder mit dmsetup, wenn es sich um EXT4 handelt)? Oder kann ich einfach einen Live-Schnappschuss machen? WAL-Dateien werden mit einer Rate von einer pro Minute versendet. Ist es möglich, dass ein Snapshot initiiert wird, während eine einzelne WAL-Datei kopiert wird, was zu beschädigten Daten führt?

(2) Das Volume, das das Live-PostgreSQL-Datenverzeichnis enthält, wird ebenfalls (täglich) gesichert. Bevor ich einen Snapshot dieses Volumes mache, gebe ich einen pg_dump aus und die resultierende SQL-Datei wird im Datenverzeichnis gespeichert. Ist es sinnvoll, Vorkehrungen zu treffen, um sicherzustellen, dass die tatsächlichen Datenbankdaten konsistent sind? Wäre es richtig anzunehmen, dass durch das Erstellen eines Live-Snapshots (a) Konfigurationsdateien (postgresql.conf, pg_hba.conf, pg_ident.conf) ordnungsgemäß gesichert und (b) die SQL-Dump-Datei gesichert werden. Das Sichern dieser beiden Dinge, SQL-Dump-Datei und Konfigurationsdateien, wäre der Hauptpunkt für das Snapshot-Erstellen dieses Volumes. Die Datenbank ist nicht sehr groß, daher macht es mir nichts aus, dass Datendateien diesen Schnappschuss aufblähen. Und in diesem Fall kann ich einfach einen Live-Schnappschuss machen - richtig?

(2a) Wäre es einfach besser, das Datenverzeichnis auf dem Root-Volume zu belassen und ein Sicherungsskript zu haben, das die SQL-Dump-Datei sowie die Konfigurationsdateien auf ein anderes Volume kopiert und dieses Volume nach Abschluss des Kopiervorgangs als Snapshot erstellt?

(3) Was das Volume mit dem Code betrifft, gibt es wieder einen Grund, das Dateisystem zu synchronisieren und einzufrieren? Oder kann nur ein Live-Schnappschuss gemacht werden? Diese Daten sollten ziemlich "statisch" sein.

(4) Ist dies ein solides Sicherungsschema? Das Root-Volume wird nicht regelmäßig gesichert, da ich nur ein Computer-Image behalten werde, nachdem es eingerichtet und konfiguriert wurde.

Vielen Dank

Siehe das feine Handbuch . Wenn mein Rat in irgendeiner Weise im Widerspruch zu seinem steht, ist es richtig.

1. Eine Synchronisierung ist keine schlechte Idee, es sei denn, Ihr Kopiertool fsync () verwendet jede WAL-Datei, die es schreibt, und das Verzeichnis, in dem es sich befindet, bevor Sie die nächste kopieren. Eine unvollständige letzte WAL-Datei spielt keine Rolle. im schlimmsten Fall löschen Sie es einfach. Pg wird im Allgemeinen an einer unvollständigen WAL ersticken - obwohl keine Prüfsumme durchgeführt wird, so dass Sie könntenSeien Sie wirklich unglücklich und lassen Sie es versuchen, Mülldaten anzuwenden, die zufällig wie echte WAL-Datensätze aussahen. In Ihrer Position würde ich das Volume vor einem Snapshot synchronisieren, um sicherzustellen, dass ungeschriebene fehlerhafte Puffer im RAM das Dateisystem-Image auf der Festplatte treffen. Ein Einfrieren würde helfen, unordentliche, aber nicht tödliche, teilweise geschriebene WALs zu vermeiden. Es ist also keine schreckliche Idee, aber nicht wichtig. Entscheidend ist eine unbeschädigte Zeitleiste bis zur Wiederherstellung. Persönlich schreibe ich meine WALs in einen temporären Dateinamen und benenne sie erst dann in ihren endgültigen Namen um, wenn sie vollständig kopiert wurden. Wenn Sie dies tun, müssen Sie nicht einfrieren.

2. Klingt richtig. Ein Live-Snapshot ist wie ein Plug-Pull-Test auf einem Live-System mit Durchschreib-Caching. Ihre Datenbank sollte bei der Wiederherstellung aus einem Live-Snapshot wie nach dem Plug-Pull einwandfrei wiederhergestellt werden. Ich würde empfehlen, dass Sie Tests von Wiederherstellungen aus Snapshots automatisieren. (Hinweis: Ein Snapshot-Wiederherstellungstest ist kein vollständiger Ersatz für Plug-Pull-Tests, da er nicht das mögliche Caching von Festplatten, RAID-Controllern usw. berücksichtigt.) Nicht nur die Konfigurationsdateien und der Speicherauszug, sondern auch die Datenbank selbst sollten nach Ihrem Snapshot in Ordnung sein. Überlegen Sie, ob Sie das Volume vor dem Snapshot synchronisieren möchten, um sicherzustellen, dass alle Speicherauszugsdaten usw. tatsächlich auf die Festplatte gelangt sind.
   
   2a. Könnte etwas Speicherplatz sparen. Sonst wenig Unterschied. Sie können die Schnappschüsse viel länger aufbewahren, ohne dass die gesamte Live-Datenbank darauf läuft.

3. Warum sogar ein Schnappschuss Ihres Codevolumens? Eine einfache Kopie auf Dateiebene ist möglicherweise in Ordnung. Auf jeden Fall sollte ein Live-Schnappschuss sein.

4. Dies ist kein solides Sicherungsschema. In einem kritischen Bereich schlägt dies fehl: Es werden keine Wiederherstellungstests und -validierungen durchgeführt. Sie sollten Ihre Backups immer regelmäßig testen , um sicherzustellen, dass Sie sie wirklich wiederherstellen können.

   Persönlich empfehle ich, dass Sie WAL-Versand verwenden oder Datenbank-Dumps an einen anderen Host senden , vorzugsweise einen, der nicht auf Amazon EC2 oder zumindest in einer anderen Region verfügbar ist. Dieser Host sollte automatisierte Wiederherstellungstests durchführen, Ihnen Berichte über die Ergebnisse senden und auch manuell überprüft werden.

   Ihre Snapshots (mit Dumps) befinden sich zwar in S3 und sind dort sicher, dies bedeutet jedoch nicht, dass sie verfügbar sind, wenn Sie sie dringend benötigen. Die Ansprüche von Amazon auf Haltbarkeit sind beruhigend, aber Ihre Daten können während eines zeitlich schlecht abgestimmten Ausfalls des S3-Dienstes immer noch sicher und für Sie völlig unzugänglich sein.