Fehler beim Restore einer Datensicherung

[Lemmy]

Zitat von jobo:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von 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?

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

Zitat von hstreicher:

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