Postgresql 9.0.8 Physical Backup auf Windows Server 2008 R2 führt zu „Zugriff verweigert“

Question

Ich habe ein Skript zum Ausführen einer physischen Sicherung einer Postgresql 9.0.8-Datenbank erstellt, indem ich dem Rezept „Standalone Hot Physical Database Backup“ im PostgreSQL 9 Administration Cookbook (Riggs/Krosing) gefolgt bin, es aber für Windows Server 2008 R2 angepasst habe.

Für Schritt 4 des Rezepts, bei dem rsync zum Kopieren aller Datendateien (außer dem Verzeichnis pg_xlog) verwendet wird, verwende ich robocopy.exe (da rsync ein *nix-Dienstprogramm ist und ich Windows verwende). Das Problem ist, dass häufig eine der Dateien nicht kopiert werden kann und die Meldung „Zugriff verweigert“ angezeigt wird. Das manuelle Kopieren der Datei schlägt mit „Zugriff verweigert“ fehl.langnachdem das Backup-Skript fehlgeschlagen ist – es handelt sich also nicht um ein zeitweiliges Problem, das erneut versucht werden kann. Die Datei kann erst nach einem Neustart des PostgreSQL-Prozesses kopiert werden. Es ist immer eine andere Datei. Letzte Nacht war es %PGDATADIR%\5432\base\24609\38122 .

Ich würde gerne hören, ob Sie dies erlebt haben und was Sie getan haben, um das Problem zu beheben. Ich denke über Folgendes nach:

1. Starten Sie den PostgreSQL-Server direkt vor dem Backup neu (ich gebe zu, das ist ein Hack)
2. Verwenden Sie ein Dienstprogramm zum Kopieren geöffneter Dateien, z. B. VSHADOW, DISKSHADOW und Hobocopy (Hinweis: nicht Robocopy).
3. Gibt es vielleicht eine Möglichkeit, PostgreSQL anzuweisen, alle Sperren freizugeben?
4. [hinzugefügt] siehe unten - sieht aus, als ob regelmäßiges "Staubsaugen" das Symptom beseitigt

Answer 1

OK, das Wichtigste zuerst - legen Sie Ihr Kochbuch weg. Lesen Sie stattdessender Abschnitt des Postgres-Handbuchs über das Sichern. Lesen Sie das ganze Kapitel – es ist nicht so lang.
(Sie werden wahrscheinlich einige Ähnlichkeiten zwischen diesem und dem Buch bemerken – die meisten Postgres-Bücher sind bloß aufgehübschte Versionen des Handbuchs – aber Sie sollten das Handbuch immer als primäre Referenz verwenden.).

Die gesamte Terminologie, die ich im Folgenden verwende, stammt aus dem Handbuch (wenn Sie also dachten, Sie könnten die Leseaufgabe überspringen, können Sie das nicht – wenn Sie es tun, werden Sie wahrscheinlich furchtbar verwirrt zurückbleiben).

---

Nun zu Ihrem eigentlichen Problem – eine Unix-Lösung lässt sich oft nicht direkt auf Windows portieren, und dies ist einer dieser Fälle: Ein *nix-System schnappt sich ohne weiteres eine Datei, die gerade bearbeitet wird – Windows gibt den angezeigten Fehler aus.

Wie Sie damit umgehen, hängt davon ab, welche Art von Sicherung Sie durchführen.

Sicherungen auf Dateisystemebene

Wenn Sie eine„Sicherung auf Dateisystemebene“Dumussfahre den Server herunter. Punkt, Ende der Diskussion, keine anderen Optionen. Die Datenbank muss vollständig heruntergefahren werden, damit diese Art von Backup zuverlässig ist (und wenn das Backup, das du erhältst, nicht zuverlässig ist, was hat das dann für einen Sinn?).

Kontinuierliche Archivierung / Point-in-Time-Wiederherstellung und Slave-Server

Wenn Sie eineBasissicherungim Rahmen der EinrichtungZeitpunktbezogene Wiederherstellung& Log-Versand Sie haben zwei Möglichkeiten:

• Fahren Sie den Server trotzdem herunter.
• Verwenden Sie ein Tool, das geöffnete Dateien kopieren kann (Option (2) aus Ihrer Frage)

Anschließend fahren Sie mit der restlichen Dokumentation für Point-in-Time Recovery/Log Shipping fort und erstellen einen Slave-Server.
Wenn Sie Ihren Datenbankserver auf die Festplatte kopieren möchten, stoppen Sie einfach den Slave, sichern Sie ihn und starten Sie ihn neu – die Welt dreht sich auf Ihrem Master-Server weiter, und der Slave holt beim Neustart nach, was er verpasst hat.

Sie können auch das Basis-Backup plus die gerollten Transaktionsprotokolle, die Sie normalerweise an den Slave senden würden, als gutes, zuverlässiges Datenbank-Backup verwenden. Dies scheint dem, was Sie mit Ihrer Frage erreichen möchten, am nächsten zu kommen, aber ich würde stattdessen das von mir beschriebene Slave-Backup empfehlen – mehr Vorteile (Sie haben einen Hot Standby) und weniger Arbeit für den Master-Server (keine zusätzlichen Checkpoints zum Rollen des Transaktionsprotokolls des Backups).

Etwas anderes

Wenn Ihnen keines der oben genannten Angebote zusagt, müssen SieSQL-Dumps.
Es gibt Nachteile: Postgres muss jede Tabelle sperren, wenn sie ausgelesen wird (was bedeutet, dass Schreibvorgänge in Ihre Datenbank blockiert werden) und SQL-Auslesen ist langsamer als die anderen Optionen.
Wenn Ihre Datenbank eine gewisse Größe hat, würde ich diese Methode nicht empfehlen.