Fehler beim Restore einer Datensicherung

[Lemmy]

Servus,

habe hier einen Firebirdserver (2.1.7) bei einem Kunden (bei allen anderen klappts :-))

wenn ich folgendes abschicke:


gbak -c -r -v -user sysdba -password XXXX c:\programdata\...\x.fbk 127.0.0.1/53050:c:\programdata\....\xy.fdb

dann wird die Datenbank erzeugt, das Backup eingespielt, am Ende kommt aber:

Code:

gbak: ERROR:I/O error for file ""
gbak: ERROR:   Error while trying to create file
gbak: ERROR:   Das system kann den angegebenen Pfad nicht finden.

Die Software (DB-Client) läuft sonst einwandfrei, kein Problem.

Untersuchungen:
Firebird-Dienst: läuft under Lokales System
Firebird.conf: Keine auffälligkeiten
firebird.log: keine Auffälligkeiten
fbclient.dll in der korrekten Version vorhanden


Virenscanner (Kaspersky :-(() vorhanden, aber auch keine Änderung wenn ich die Schutzfunktionen abschalte oder den betroffenen Verzeichnissen Ausnahmegenehmigung erteile.

Die nächste Option (Kaspersky zu deinstallieren) würde ich gerne erst machen wenn ich sonst keine Wahl mehr habe. Wobei mir nicht ganz klar ist, weshalb der FBServer ne Datei ohne Namen erstellen will - und woher er dafür den "Auftrag" hat....

Kennt hier zufällig jemand diese Melung oder hat noch einen Vorschlag?

[Jasocul]

Ich habe leider keine Ahnung davon, aber vielleicht ist das mein Vorteil :wink:

Zitat:

gbak: ERROR:I/O error for file ""

Da fehlt der Dateiname. Das kann nicht funktionieren. Stimmt da was mit den Parametern nicht?

[kretabiker]

ist den Pfadangaben vielleicht irgendwo ein Leerzeichen enthalten?

[kretabiker]

und Port 53050? Nicht 3050?

[Lemmy]

Zitat:

Zitat von Jasocul (Beitrag 1418758)

Ich habe leider keine Ahnung davon, aber vielleicht ist das mein Vorteil :wink:

Zitat:

gbak: ERROR:I/O error for file ""

Da fehlt der Dateiname. Das kann nicht funktionieren. Stimmt da was mit den Parametern nicht?

Parameter alles ok, sonst wäre ja auch die zu erzeugende Datenbankdatei am ENde nicht da (s.o.)

Zitat:

Zitat von kretabiker (Beitrag 1418759)

ist den Pfadangaben vielleicht irgendwo ein Leerzeichen enthalten?

nein, wie gesagt die zu erzeugende Datenbankdatei ist am ende ja da, sprich das Restore läuft grundsätzlich und legt auch alles an, nur beim letzten Commit scheint irgend was (nur was?) schief zu laufen.

Zitat:

Zitat von kretabiker (Beitrag 1418760)

und Port 53050? Nicht 3050?

ja, 53050 :-)

[TigerLilly]

-c -r widerspricht sich möglicherweise

[hoika]

Hallo,
-c Create
-r Replace

Das ist so korrekt, eine existierende Datei soll überschrieben werden.
Das alleinige -c würde das Überschreiben verweigern, aus Sicherheitsgründen.

ProgramData: könnte ein Rechteproblem sein? Wobei ja der Server alle Rechte hat.
Nimm doch mal testweise C:\Temp als Ziel-Pfad.

Hast Du denn das ganze Log da? Was ist denn die vorletzte Zeile?

[Moombas]

Ich würde bei

Code:

gbak: ERROR:I/O error for file ""

eher auf eine Leerzeile als ein Leerzeichen tippen. Hast du darauf mal geprüft? Es sieht so aus als würde er versuchen "" (nichts) nach "" (nichts) zu kopieren.

[Lemmy]

Zitat:

Zitat von hoika (Beitrag 1418765)

ProgramData: könnte ein Rechteproblem sein? Wobei ja der Server alle Rechte hat.
Nimm doch mal testweise C:\Temp als Ziel-Pfad.

wie oben schon geschrieben: Die Datenbankdatei ist anschließend im korrekten Verzeichnis da!

Zitat:

Zitat von hoika (Beitrag 1418765)

Hast Du denn das ganze Log da? Was ist denn die vorletzte Zeile?

nein, nicht das ganze log, nur nen Screenshot, vorher war aber nix relevantes (d.h. kein Fehler):

Code:

gbak:    activating anc dreating deferred index....
gbak:    activating anc dreating deferred index....
gbak:    activating anc dreating deferred index....
gbak:    commiting metadata
gbak: ERROR:I/O error for file ""
gbak: ERROR:  Error while trying to create file
gbak: ERROR:  Das system kann den angegebenen Pfad nicht finden. 
gbak:Exiting before completion due to errors

Zitat:

Zitat von Moombas (Beitrag 1418766)

Ich würde bei

Code:

gbak: ERROR:I/O error for file ""

eher auf eine Leerzeile als ein Leerzeichen tippen. Hast du darauf mal geprüft? Es sieht so aus als würde er versuchen "" (nichts) nach "" (nichts) zu kopieren.

Aufruf steht oben, da steht keine Leerzeile drin, sondern konkrete, existierende Dateinamen.

[jobo]

Ich würde auch mal auf nicht-druckbares-Zeichen oder so tippen.
Die Zeile wurde evtl. aus einem Wiki (HTML) kopiert und in die DOS Box gepastet?
So könnte das Problem jedenfalls enstehen.

Also zur Stichprobe in den Editor der Wahl kopieren (ggF. absichtlich auch nicht UNICODE fähige Editor) oder dann mal den Eintrag als Hex Darstellung ansehen.

Ansonsten:
-c -r, create, replace bedeutet im Zweifel "Löschen" und das hat wiederum eine Bewandtnis mit den effektiven Dateirechten auf dem (Windows?)-System? > Rechte prüfen am besten durch die entsprechende Dateioperation als der User, der auch das Backup ausführt.

[Lemmy]

Zitat:

Zitat von jobo (Beitrag 1418770)

Die Zeile wurde evtl. aus einem Wiki (HTML) kopiert und in die DOS Box gepastet?

nope, direkt eingegeben.

Sorry, den Part habe ich nicht genannt: Das Problem kann ich mit meiner Anwendung die das Backup/REstore per UIB macht nachstellen. UIB greift dabei auf die API in der fbClient.dll zu. das gbak-Beispiel habe ich nur deshalb so prominent aufgezeigt, weil man das einfach nachstellen kann....

[Delphi.Narium]

Kann man denn (unabhängig von dem Fehler) anschließend z. B. mit FlameRobin (o. ä.) auf die Datenbank zugreifen?

Der Fehler tritt ja erst nach dem commiting metadata auf.

Was wird von gbak (o. ä.) nach diesem Commit gemacht?

Welche Arbeiten stehen nachher noch an? (Finde auf die schnelle keine passende Doku.)

Das Problem muss also nicht die konkret genannte Datenbankdatei sein, sondern kann in weiterfolgenden Arbeiten liegen.

Gibt es da in der Konfiguration noch irgendwas anderes, was für Probleme sorgen könnte?

Im Zweifelsfalle mal alle *.conf-Dateien durchschauen, ob von denen eine auf irgendwas verweist, was es nicht gibt oder sonstwie einen Fehler enthält.

Die Fehlermeldung lässt vermuten, dass auf irgendwas zugegriffen werden soll, zu dem die Angabe eines gültigen Dateinamens oder einer existierenden Datei fehlt.

Gegebenenfalls mal das Protokoll mit der Fehlermeldung neben eines ohne Fehlermeldung halten und schauen, was im Nichtfehlerfalle von gbak noch protokolliert wird. Den Fehler würd' ich eher dort vermuten.

Bei 'ner Minidatenbank von mir finde ich hinter dem commiting metadata z. B.:

Code:

gbak:fixing views dbkey length
gbak:updating ownership of packages, procedures and tables
gbak:adding missing privileges
gbak:fixing system generators
gbak:finishing, closing, and going home
gbak:adjusting the ONLINE and FORCED WRITES flags

Mal das komplette Protoll zu 'ner Testdatenbank:

Code:

E:\FirebirdDatenbanken>c:\Datenbanksoftware\Firebird_3_0\gbak.exe -r -p 16384 -v -user sysdba -password masterkey .\TESTDB.FDB.backup .\TESTDB.FDB 
gbak:opened file .\TESTDB.FDB.backup
gbak:transportable backup -- data in XDR format
gbak:      backup file is compressed
gbak:backup version is 10
gbak:created database .\TESTDB.FDB, page_size 16384 bytes
gbak:started transaction
gbak:restoring domain RDB$15
gbak:restoring domain RDB$16
gbak:restoring table TEST
gbak:    restoring column ID
gbak:    restoring column INHALT
gbak:committing metadata
gbak:    restoring privilege for user SYSDBA
gbak:    restoring privilege for user SYSDBA
gbak:    restoring privilege for user SYSDBA
gbak:    restoring privilege for user SYSDBA
gbak:    restoring privilege for user SYSDBA
gbak:    restoring privilege for user SYSDBA
gbak:    restoring privilege for user PUBLIC
gbak:    restoring privilege for user SYSDBA
gbak:    restoring privilege for user PUBLIC
gbak:creating indexes
gbak:committing metadata
gbak:fixing views dbkey length
gbak:updating ownership of packages, procedures and tables
gbak:adding missing privileges
gbak:fixing system generators
gbak:finishing, closing, and going home
gbak:adjusting the ONLINE and FORCED WRITES flags

Das gbak:committing metadata ist dadrin zwei mal zu finden. Wo ist bei Deinem Fall die Fehlermeldung? Hinter dem ersten oder hinter dem zweiten gbak:committing metadata?

Hinter dem ersten? Fehlt die security3.fdb? Oder sie ist (warum auch immer) nicht im Zugriff?

[Jasocul]

Ich bin jetzt mal als Firebird-Laie durch die Doku gegangen. Manchmal hilft ja der unbedarfte Blick.

Dein Befehl:

Zitat:

gbak -c -r -v -user sysdba -password XXXX c:\programdata\...\x.fbk 127.0.0.1/53050:c:\programdata\....\xy.fdb

Ist für Firebird 1.0 und 1.5 korrekt.
Für Firebird 2.x muss es beim create so lauten:
gbak -c -v -user sysdba -password XXXX c:\programdata\...\x.fbk 127.0.0.1/53050:c:\programdata\....\xy.fdb
D.h.: Der Paramter "r" wird nicht verwendet.
Beim Wiederherstellen einer vorhanden DB muss es folgendermaßen sein:
gbak -r o -v -user sysdba -password XXXX c:\programdata\...\x.fbk 127.0.0.1/53050:c:\programdata\....\xy.fdb

Inwiefern die Parameter kollidieren und vielleicht den Fehler verursachen, weiß ich nicht.
Hier gefunden unter "Examples". Einfach ein bisschen runter scrollen.

[Lemmy]

Zitat:

Zitat von Delphi.Narium (Beitrag 1418780)

Kann man denn (unabhängig von dem Fehler) anschließend z. B. mit FlameRobin (o. ä.) auf die Datenbank zugreifen?

Hab ich dummerweise nicht mehr geprüft :-(

Zitat:

Zitat von Delphi.Narium (Beitrag 1418780)

Der Fehler tritt ja erst nach dem commiting metadata auf.

Was wird von gbak (o. ä.) nach diesem Commit gemacht?

gute Frage. Die Antwort würde mir sicherlich weiter helfen :-)

Zitat:

Zitat von Delphi.Narium (Beitrag 1418780)

Gibt es da in der Konfiguration noch irgendwas anderes, was für Probleme sorgen könnte?

Im Zweifelsfalle mal alle *.conf-Dateien durchschauen, ob von denen eine auf irgendwas verweist, was es nicht gibt oder sonstwie einen Fehler enthält.

nüscht. Die Firebird.conf ist identisch mit der auf meiner Kiste.

Zitat:

Zitat von Delphi.Narium (Beitrag 1418780)

Die Fehlermeldung lässt vermuten, dass auf irgendwas zugegriffen werden soll, zu dem die Angabe eines gültigen Dateinamens oder einer existierenden Datei fehlt.

Gegebenenfalls mal das Protokoll mit der Fehlermeldung neben eines ohne Fehlermeldung halten und schauen, was im Nichtfehlerfalle von gbak noch protokolliert wird. Den Fehler würd' ich eher dort vermuten.

Code:

gbak:    activating and creating deferred index FK_D_VLT_VERLAUF_TXT_1 
gbak:    activating and creating deferred index FK_D_KSD_SAMMERKL_ID 
gbak:    committing metadata 
gbak:finishing, closing, and going home 
* Wiederherstellung abgeschlossen 12:46:10

Zitat:

Zitat von Delphi.Narium (Beitrag 1418780)

Bei 'ner Minidatenbank von mir finde ich hinter dem commiting metadata z. B.:

...

Hinter dem ersten? Fehlt die security3.fdb? Oder sie ist (warum auch immer) nicht im Zugriff?

s.o.: Firebrid 2.1.7

[kretabiker]

ich würde jetzt zwei Dinge probieren:
- Restore der DB in einen anderen Pfad auf dem Server mit möglichst einfacher Pfadangabe
- Einkopieren - kein Restore, sondern wirklich ein Copy-Paste - einer funktionierenden (Echt-)Datenbank - am gewünschten Ziel/einem anderen Ort und versuchen, darauf mit einem Tool zuzugreifen

Vielleicht zeigen sich dann andere (Fehler-)Meldungen.

[jaenicke]

Der Process Monitor könnte helfen... um zu schauen auf welche Dateien da zugegriffen wird usw.

[hstreicher]

was mir noch so dazu einfällt:

passt die Firebird.msg zur Firebird Version , das ist eine häufige Ursache für falsche/unvollständige Fehlermeldungen.

Firebrd verwendet öfter Temporäre Dateien , ist evtl auf dem Laufwerk auf dem die erzeugt werden der Platz zu knapp?

mal das Restore mit einer aktuellen Version (2.5.8) versucht evtl gbts ne brauchbare Fehlermeldung


mfg Hannes

[Lemmy]

Zitat:

Zitat von hstreicher (Beitrag 1418930)

was mir noch so dazu einfällt:

passt die Firebird.msg zur Firebird Version , das ist eine häufige Ursache für falsche/unvollständige Fehlermeldungen.

Firebrd verwendet öfter Temporäre Dateien , ist evtl auf dem Laufwerk auf dem die erzeugt werden der Platz zu knapp?

die msg. wird mit dem "offiziellen" Setup mit geliefert, da machen wir nicht dran rum.

Zitat:

Zitat von hstreicher (Beitrag 1418930)

mal das Restore mit einer aktuellen Version (2.5.8) versucht evtl gbts ne brauchbare Fehlermeldung

das wäre ggff. noch eine Möglichkeit

[Lemmy]

so neue Erkenntnisse, war eben nochmal auf dem REchner:

Zugriff auf die wiederhergestellten Datenbankdateien mit dem Abbruch am Ende ist möglich.

Neuinstallation vom FB Server war nicht erfolgreich, gleicher Fehler
Umstellung auf Standardport war nicht erfolgreich, gleicher Fehler
div. Änderungen am installierten Kaspersky waren nicht erfolgreich (alle wieder zurück genommen).

Am Ende den FB Embedded 2.1.7 installiert und entsprechend konfiguriert und alles läuft wie geschmiert...

Keinen blassen Schimmer wer beim Server seine Drecksfinger noch im Spiel hat, dass der so absemmelt. Leider ist der Embedded nur eine Zwischenlösung, weil wir in 1-2 Monaten einen funktionierenden FBServer auf dem Rechner brauchen...

[IBExpert]

Moin,

potentielle Kandidaten für I/O Error können sein

-du hast secondary files defininert (sollte ggf in rdb$files erkennbar sein)
-du hast external tables definiert (infos dazu in rdb$relation_fields)
-du hast shadows definiert (sollte ggf in rdb$files erkennbar sein)
-du hast pfadangaben in udfs gemacht (infos dazu in rdb$functions)

sysinternals.com processmonitor sollte dir auf dem gbak / firebird prozess oder wenn embedded in deinem prozess zeigen, wo der da rumwühlt

[Lemmy]

Servus,

so lange der Kunde da nicht die Finger im Spiel hat, sollten sowohl Shadow-Dateien wie auch external Tables bei uns nicht existieren, hab auch nichts gefunden.

Der ProcessMonitor brachte mich aber weiter: Beim Versuch des fbServer ins temporäre Verzeichnis (c:\windows\temp) zu schreiben hagelte es div. Fehler. Als ich das Temp-Verzeichnis umgestellt hatte wie Systemvariable Firebird_tmp lief die ganze Schoße ohne Probleme!

Herzlichen Dank für den Tipp!