(Win32)Copy blockiert Dateien bei der Erstellung eines Base Backups für PITR

Hallo,

bei der Erstellung eines Base Backups für die Point in Time Recovery sperrt der Copy Befehl scheinbar die einzelnen Dateien, die er gerade kopiert. Unter Unix werden Kopierprogramme wie cpio oder ähnliches empfohlen. Gibt es ein Kopierprogramm/Alternative unter Windows, dass das Kopieren des data-Verzeichnisses ohne Einfluss auf den laufenden Datenbankbetrieb gewährleistet?

Vielen Dank!

Hier noch eine beispielhafte Fehlermeldung:

ERROR: could not open relation 1663/30188/1822415: Permission denied

Ich mag mich irren aber “Permission denied” ist noch mal etwas anderes.
Tritt dieser Fehler nur auf wenn gerade das Backup läuft?

Ansonsten: Cygwin Tools installieren und das “cp” der Unix Version nutzen.

Ja, wenn ich mit
SELECT pg_start_backup(‘label’);
ein Backup starte, dann ist alles noch in Ordnung. Erst wenn ich copy drauf los lasse wird die Datei gesperrt, die gerade kopiert wird.

Ich glaub für Cygwin müsste ich den Server neustarten, was nicht so schön wäre.

Außerdem habe ich noch einen anderen Ansatz. In der Mailinglist habe ich gelesen, dass so eine Fehlermeldung in einem anderen Kontext durch ein
Background-Virenscanner hervorgerufen wurde. Jetzt werd ich mal probieren diesen abzuschalten. Schließlich kann ich ja nicht der Einzige sein, der PostgreSQL unter Windows nutzt und Backups erstellen will.

Und vielleicht löst sich auch das Problem was ich schon vor einiger Zeit unter http://www.pg-forum.de/allgemeines/2363-warning-transaction-log-file-could-not-archived-too-many-failures.html#post11983

beschrieben habe. Es tritt zwar nicht mehr so oft auf, aber manchmal eben doch.

Vielen Dank soweit!

muss nix anderes sein - wenn ein prozess eine datei oeffnet kann der prozess entscheiden ob andere prozesse zugriff haben duerfen (lesen schreiben etc) … im grunde ist das dann auch eine “permission”

ebenso wird ein prozess, der die datei oeffnet, sie ja auch in einem entsprechenden modus oeffnen wollen. wenn der andere prozess (copy) z.B. die datei fuer read - mit share read oeffnet, dann wird PG die gleiche datei nicht fuer read/write oeffnen koennen → permission denied.

und immer gilt - wer zuerst kommt, malt zuerst

deswegen soll der PG-dienst / deamon ja auch abgeschaltet (beendet) sein, wenn man die dateien wegkopieren will

Nein.

Andreas

Dann ists äußerst unsauber implementiert …

Was?

Andreas

moment … mit share read hatte ich eben ein denkfehler … es koennte durchaus sein, dass CP die datei öffnen kann wenn PG share-read erlaubt …

allerdings sollte es zum fehler kommen, wenn CP die datei zuerst oeffnet und auch nur share-read erlaubt - aber PG sie ja pauschal auch zum schreiben oeffnen wollen wird (vermutlich)

das sind unterschiedliche situationen …

Windows, ja. Nicht PostgreSQL.

Ich wüsste nicht, was an: “du darfst der Datenbank die Dateien im laufenden Betrieb wegkopieren und das funktioniert hinterher noch” unsauber ist. So etwas nennt sich Online-Backup und sorgt für massiv verminderte Downtime.

Das Problem ist, vermute ich, eher das Eiterpickel am Arsch, ähm, der Virenscanner vom Fragesteller.

Andreas

daran ist nix unsauber - bis auf die methode schlechthin

was mich stark wundert ist dass man bei einem pg-dump das abknipsen des servers empfielt (aus gutem grund) aber bei einem copy nicht ? das macht irgendwie keinen sinn - zumal pg-dump eher in der lage waere mit dem server geeignet zu kommunizieren


das problem ist aber ein anderes - wenn COPY die datei geoeffnet hat und dann ein PG-prozess erzeugt wird (waerend das copy laeuft) dann wird dieser PG-prozess u.U. die datei nicht so öffnen dürfen wie es gern möchte, weil COPY vermutlich nur “share read” zulaesst → permission denied

ist zuerst ein PG-Prozess am ball … ist die situation eine andere

Wenn du das sagst …


was mich stark wundert ist dass man bei einem pg-dump das abknipsen des servers empfielt (aus gutem grund) aber bei einem copy nicht ?

Wo steht das?


das macht irgendwie keinen sinn

Natürlich macht es keinen Sinn, einen Datenbankserver für ein Backup herunterzufahren - oder hast du etwas anderes gemeint?


das problem ist aber ein anderes - wenn COPY die datei geoeffnet hat und dann ein PG-prozess erzeugt wird (waerend das copy laeuft) dann wird dieser PG-prozess u.U. die datei nicht so öffnen dürfen wie es gern möchte, weil COPY vermutlich nur “share read” zulaesst → permission denied

Unter vernünftigen Betriebssystemen funktioniert das auch mit dem Kopieren geöffneter Dateien. Wenn das unter Windows nicht klappt … liegt das wahrscheinlich nicht an PostgreSQL.

URL für diese Empfehlung?

das problem ist aber ein anderes - wenn COPY die datei geoeffnet hat und dann ein PG-prozess erzeugt wird (waerend das copy laeuft) dann wird dieser PG-prozess u.U. die datei nicht so öffnen dürfen wie es gern möchte, weil COPY vermutlich nur “share read” zulaesst → permission denied

Nein. Probier es aus. Erzeuge in einer TX eine neue Tabelle, ermittle die relfilenode, öffne diese mit vi, inserte etwas in die Tabelle. Geht alles. Auch als jemand, der Windows nicht mag: der dokumentierte Weg vom PITR funktioniert, auch unter Windows. Zumindest so lange, wie man kein Eiterpickel hat…

Andreas

Ich hab den Virenscanner abgeschalten und siehe da, man kann ohne Probleme auch unter Windows einen Binärbackup für PITR erstellen.

Danke für eure Hilfe.

Amen.

Andreas