De:Defekten Stammbaum wiederherstellen
Obsolete Information This troubleshooting documentation is oriented around a superseded dependency in Gramps. Reliance on the BSDDB database engine was removed in the 5.1 release. |
Erklärung von Stammbaum und GRDB Beschädigung, wie man sie behebt und wie man sie in Zukunft vermeidet.
Stammbaum Beschädigung
Was verursacht diese Beschädigungen?
Das ist nicht wirklich bekannt.
Wie auch immer, Gramps Version 2.2.x macht die Beschädigung von Datenbanken mit Stammbäumen erheblich seltener als mit dem früheren Speicherformat.
- Siehe 8875 Database corruption bugs
Wie erfährst du davon?
Es kann sein das Gramps dir beim Starten über eine Dialogbox mitteilt, dass eine Datenwiederherstellung erforderlich ist:
Gramps hat ein Problem in der darunter liegenden Berkeley Datenbank festgestellt. Dies kann mit dem Stammbaumverwaltung repariert werden. Die Datenbank wählen und auf die Reparatur-Schaltfläche klicken
Aber es kann passieren, das keine Reparieren Schaltfläche verfügbar ist oder du erhältst den Fehler (sichtbar in der Konsole)
(-30975, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument').
Was ist jetzt zu tun?
Es ist ratsam, nicht sofort auf die Database_Formats#Repairing_a_Corrupt_DatabaseReparaturschaltfläche zu klicken. Es sollte funktionieren, aber Gramps könnte denken, das ein Fehler vorhanden ist obwohl dies nicht der Fall ist. Das reparieren deiner Bäume würde in diesem Fall zum Verlust der zuletzt eingegebenen Änderungen führen.
Stattdessen erstelle eine Sicherung des Stammbaums, der Probleme bereitet. Gib im Terminal ein:
gramps -l
Dies gibt dir eine Liste mit allen Stammbäumen und den Verzeichnissen, in denen sie gespeichert sind, normalerweise irgendwo unter dem Verzeichnis ~/.gramps/grampsdb. Schaue in dein Anwenderverzeichnis. Kopiere das Verzeichnis des Stammbaums mit den Problemen, damit du eine Sicherung besitzt:
cp -a <Zielverzeichnis> <Sicherungsverzeichnis>
Wenn die Reparaturschaltfläche für den Gramps Stammbaum verfügbar war, klicke sie. Alles sollte wieder funktionieren. Wenn du merkst, das du Informationen verloren hast oder die Reparaturschaltfläche funktioniert nicht, tue folgendes.
Wenn die Wiederherstellung funktioniert hat, du mit dem Ergebnis aber nicht zufrieden bist, sichere diese Daten und packe deine Sicherung, die du oben erstellt hast wieder zurück an ihren Ursprungsort. Nun hast du wieder den mangelhaften Stammbaum um damit zu arbeiten. Als nächstes besorge dir die bsddb Wiederherstellungswerkzeuge, schau auf deiner Distributionspaketsuchseite. Das Programm heißt db4.8_recover, wobei die Versionsnummer 4.8 eine ältere oder neuere sein kann. Überprüfe deine BSDDB Version im Hilfe -> Über Dialog oder mit dem gramps -v
Kommando.
Starte diese Werkzeug wie folgt:
cd /home/<Benutzer>/.gramps/grampsdb/<Zielverzeichnis> db4.8_recover -c
So müsste es gehen, und Gramps ermöglichen, den Stammbaum zu laden. Wenn nicht, öffne ein Ticket im Gramps Fehlerverfolgungswerkzeug.
Windows OS
- lade die ORACLE Werkzeuge unter: http://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html
- ...TO_COMPLETE...
Ich habe gesicherte gbkp Dateien
Wenn du eine Sicherung besitzt, kannst du versuchen die gesicherten .gbkp
Dateien wiederherzustellen. Führe folgende Schritte durch:
Die Prozedur um deine Daten aus .gbkp
Dateien wiederherzustellen ist:
- Notiere dir den Namen des "Stammbaums", den du wiederherstellen willst, im Stammbaum-Manager".
- Schließe das Programm Gramps.
- Suche nach dem Benutzerverzeichnis in Abhängigkeit von deinem Betriebssystem.
- Suche den Ordner
grampsdb
in deinem Benutzerverzeichnis (Auf manchen Betriebssystemen auch als Ordner bekannt.[1]) - Unter dem Ordner
grampsdb
werden alle deine " Stammbaum"-Datenbanken in separaten Verzeichnissen gespeichert (z.B.: Wenn du 10 Stammbäume hast, hast du 10 Ordner, jeder mit einem automatisch vom System erzeugten Ordnernamen). Finde die Datenbank, die du wiederherstellen willst, indem du die Dateiname.txt
in einem Texteditor öffnest und schaust, ob der Name mit dem Stammbaum übereinstimmt, den du wiederherstellen willst. Wenn dies der Fall ist, notiere dir den Verzeichnisnamen. - Wenn dieser Ordner
.gbkp
-Dateien enthält, kannst du deinen Versuch fortsetzen, den Stammbaum wiederherzustellen. - Kopiere alle
.gbkp
-Dateien in ein neues Verzeichnis, das du in deinem Datenbankverzeichnisgrampsdb
anlegen musst, z.B. gib dem Verzeichnis einen eindeutigen Namena1111
- Kopiere die Datei
name.txt
aus dem ursprünglichen Verzeichnis des Stammbaums in das neue Verzeichnis, das du erstellt hast. - In the new directory open
name.txt
in a text editor and change the content to a unique name. eg: Family Tree 1 to Family Tree 1 recovery attempt - In the new directory create a file with name
need_recover
. Mind the underscore and the lack of an extension. The content of that file is unimportant. (Are you using Microsoft Windows and having difficulty creating this file then see 8665#c44245 for a possible work around) - Starte das Gramps-Programm.
- Select the family tree with the name you adjusted in step 9 eg. Family Tree 1 recovery attempt (Do not double click on the family tree name). There should be a red stop sign next to that family tree name.
- Select the Repair button and the Repair Family Tree? dialog will show, at this point select the Proceed, I have taken a backup button or you can select Stop to exit the repair attempt.
- Das Programm Gramps wird versuchen, den Stammbaum zu reparieren und wiederherzustellen, und wenn es erfolgreich ist, sollte das rote Stoppschild verschwinden.
- From the Family Tree manager select the repaired family tree and you should be able to Load Database the family tree.
- From the menu select Family Trees > Make Backup.. and create a backup as insurance
Mehr Sicherheit einführen
Deine Genealogiedaten enthalten jede menge Arbeit und Arbeitsstunden. So erarbeite ein Sicherungsschema
Wenn du regelmäßig mit Gramps arbeitest: sichere das Verzeichnis, das die Stammbaumdatenbank enthält. Dies sind jedoch sehr große Dateien.
Wenn du weißt, das du Gramps nur ab und zu verwendest oder wenig Platz für regelmäßige Sicherungen deiner Bäume hast, dann erstelle Sicherungen im XML Format (das .gramps Format). Vergiss nicht die Vertraulichkeitsfilter zu deaktivieren... Das XML Format lässt sich auch nach vielen Jahren ohne Probleme auf einem anderen Computer mit einem anderen Betriebssystem öffnen. Dies ist wahrscheinlich für Datenbanken, in denen der Stammbaum gespeichert ist, nicht der Fall. XML ist von Maschinen und Menschen lesbar. Es ist komplett unabhängig. Es ist auch klein. Das folgende ist eine bewährte Verfahrensweise für Sicherungen:
1. Export nach XML von Zeit zu Zeit speziell nach großen Änderungen. 2. Export nach XML vor großen Änderungen wie der Import neuer Daten in eine bestehende Datenbank aus z.B. GEDCOM, Zusammenfassung von Datensätzen, ausführen von Werkzeugen die die Daten massiv ändern können, usw. 3. Export nach XML vor der Aktualisierung von Gramps auf eine neuere Version. Offensichtlich exportiere nach XML mit der alten Version bevor du die neue Version installierst! 4. Export nach XML vor der Aktualisierung des Betriebssystems.
Verwende XML Format außerdem für jede Datenumstellung. Wechsel auf einen anderen Rechner, senden der Daten zu Oma, kopieren der Daten zu einem anderen Anwender auf dem selben Rechner -- all diese Fälle sollten XML verwenden da dort keine binär spezifischen Daten enthalten sind.
Beachte, das XML deine Mediendateien nicht enthält. Die gpkg Ausgabe enthält XML und deine Mediendateien mit dem Nachteil, das sie sehr groß ist. Wenn du bereits ein Sicherungsschema für deine Mediendateien besitzt, besteht keine Notwendigkeit gpkg Dateien ebenfalls zu sichern.
ACI nicht ACID, Upgrade, downgrade
Gramps schützt deine Daten durch Verwendung einer ACI Datenbank. Dies bedeutet, das bei einem Fehler die letzte Übergabe verloren gehen kann, aber nicht mehr. Vor einem Upgrade solltest du jedoch sicherstellen, dass Gramps deinen Stammbaum korrekt geschlossen hat.
Es sollte kein Fehler beim Öffnen eines Stammbaums mit einer neueren Version auftreten. Siehe die langen Recherchen in 3975, welche zeigen, das Version 4.7.25 von Bsddb database engine einen Fehler enthält, der eine seltsame Fehlermeldung erzeugen kann.
Der Versuch einen Stammbaum nach einem downgrade zu öffnen, wird nicht unterstützt. Du erhältst einen Fehler, das die Datenbank mit einer neueren Version erstellt wurde.
Oracle Berkeley DB Command Line Utilities
Use "db_recover -cv
" for more verbose output.
dbdump dumps database in text format and dbload use that:
db_dump database.db > dump.txt
db_load database.db < dump.txt
Deine Protokollsequenznummer ist nicht synchron, daher musst du sie zurücksetzen:
db_load -r lsn database.db < dump.txt
Version 2.2.x: GRDB Beschädigung
Dieser Abschnitt bezieht sich auf Gramps Version 2.2.x. |
Was verursacht diese Beschädigung?
Der Hauptgrund von Beschädigungen von grdb ist das wegbewegen der grdb Datei von ihrer ursprünglichen Position. Ob du die Datei in ein anderes Verzeichnis verschiebst, sie umbenennst, in eine andere Datei kopierst, auf einen anderen Rechner oder anderen Anwenderzugang legst -- all dies "beschädigt" die Datei.
Was passiert ist, die grdb Datei benötigt ihre Datenbankumgebung -- ein Verzeichnis mit Protokolldateien, Sperrdateien, temporären Dateien, usw. Die 2.2.x Gramps Versionen verwenden grdb Dateien und speichern die Umgebung für jede Datei in einem Baum in einem Verzeichnis unter ~/.gramps/env
. Wenn deine grdb Datei /home/anwender/genealogie/MeineDaten.grdb
ist, dann liegt ihre Umgebung im Verzeichnis /home/anwender/.gramps/env/home/anwender/genealogie/MeineDaten.grdb
.
Also verschieben, kopieren oder umbenennen der Datei kopiert die Bytes der Datei aber nicht seine Umgebung. Dies ist der Grund warum die verschobenen Dateien defekt erscheinen.
Ein anderer Grund kann ein Upgrade oder Downgrade deines Betriebssystems zu einem bsddb Backend das nicht vollständig die vorherige Form der Datenbank unterstützt (z.B. geänderte Hash Versionen). Dies sieht auch wie eine Beschädigung in Gramps aus, bedeutet aber tatsächlich, das die bsdb Werkzeuge verwendet werden müssen, um Daten auf eine neue Version zu konvertieren.
Das nicht öffnen können einer /tmp/... Datei in Gramps 3.0.x beim öffnen von grdb Dateien, deutet auf eine Datenbank Beschädigung. Dies ist so, weil die grdb Datei, die du öffnen willst, in das /tmp Verzeichnis kopiert wird und dann geöffnet wird. Alle Fehlschläge ergeben 'tmpxxxxx konnte nicht geöffnet werden'
Was mache ich jetzt?
Das hängt davon ab, ob du die Umgebung für die Datenbank noch besitzt oder nicht. Wenn du nur eine Datei in eine andere kopiert hast, kann es sein, das die Umgebung noch funktioniert. Wenn du die original Datenbank seitdem geändert hast, dann wurde die original Umgebung geändert und es existiert keine zuverlässige Umgebung für die neue Datei. Wenn du dein .gramps
Verzeichnis gelöscht hast (warum nur warum?), dann sind alle Umgebungen verloren. Also handle nach der Situation wie unten beschrieben.
Die Umgebung existiert noch
Wenn du das Umgebungsverzeichnis für diese Datei hast, kopiere es unter den obigen Vorgaben.
- Beispiel
- Du hast
/home/user/genealogy/MyData.grdb
nach/home/user/genealogy/backup/BackupData.grdb
kopiert, und die neue Datei funktioniert nicht. - Lösung
- Kopiere
/home/user/.gramps/env/home/user/genealogy/MyData.grdb
Verzeichnis in/home/user/.gramps/env/home/user/genealogy/backup/BackupData.grdb
und dies sollte das Problem beheben.
Die Umgebung existiert nicht mehr
Wenn du die original Umgebung für diese Datei nicht mehr besitzt, kann es sein das du einen Auszug der Daten erstellst und sie mit Hilfe der Berkeley DB Werkzeuge laden kannst. Abhängig von deinem System können sie db_dump
und db_load
, db41_dump
und db41_load
, db4.4_dump
und db4.8_load
, ... genannt werden. In Ubuntu findest du sie in dem Paket db4.8-util
. Es kann sein, das du abhängig von der Version, die deine Distribution in ihrem Python Paket verwendet, neuere Pakete benötigst. Zum Beispiel für mit Ubuntu Hardy erstellte Dateien benötigst du db4.8-util
. Wie immer sie genannt werden, sie sollten ein Werkzeug für Auszüge (dump) und zum laden (load) enthalten und mindestens die Versionsnummer 4 besitzen. Für Fedora 17 ist es 'db4-utils-4.8.30-10.fc17'. Für Fedora 18 ist es 'libdb4-utils-4.8.30-5.fc18' (beachte den neuen Paketnamen).
Im Prinzip erstellst du einen Auszug (dump) in eine Textdatei und dann erstellst du eine neue grdb Datei aus dieser Textdatei:
$ db4.8_dump SicherungsDatei.grdb > irgeneinedatei.txt $ db4.8_load neuedatei.grdb < irgeneinedatei.txt
und dann Daumendrücken und hoffen, dass die neue Datei neuedatei.grdb
sich in Gramps öffnen lässt.
Wenn du den Fehler erhältst:
db4.4_dump: eidtrans: unsupported hash version: 9
dies ist ein Anzeichen, das du eine neuere Version benötigst. Also verwende db4.6 Werkzeuge:
$ db4.8_dump SicherungsDatei.grdb > irgeneinedatei.txt $ db4.8_load neuedatei.grdb < irgeneinedatei.txt
Beachte: Wenn du downgradest, kann es nötig sein, einen Auszug mit 4.6 Werkzeugen zu erstellen und ihn mit 4.4 oder 4.5 Werkzeugen zu laden.
Wie einer Beschädigung vorbeugen?
Auch wenn das bewegen von Dateien der Hauptgrund für Beschädigungen ist, gibt es offensichtlich noch andere seltenere Gründe die wir nicht vollständig kennen. Das Verhindern von Beschädigungen ist nicht immer möglich.
Was jedoch möglich ist, die Daten regelmäßig zu Sichern. Die Sicherung sollte im XML Format (das .gramps
Format) erfolgen. XML ist von Maschinen und Menschen lesbar. Es ist komplett unabhängig. Es ist auch klein. Das folgende ist eine bewährte Verfahrensweise für Sicherungen:
1. Export nach XML von Zeit zu Zeit speziell nach großen Änderungen. 2. Export nach XML vor großen Änderungen wie der Import neuer Daten in eine bestehende Datenbank aus z.B. GEDCOM, Zusammenfassung von Datensätzen, ausführen von Werkzeugen die die Daten massiv ändern können, usw. 3. Export nach XML vor der Aktualisierung von Gramps auf eine neuere Version. Offensichtlich exportiere nach XML mit der alten Version bevor du die neue Version installierst! 4. Export nach XML vor der Aktualisierung des Betriebssystems.
Verwende XML Format außerdem für jede Datenumstellung. Wechsel auf einen anderen Rechner, senden der Daten zu Oma, kopieren der Daten zu einem anderen Anwender auf dem selben Rechner -- all diese Fälle sollten XML verwenden da dort keine binär spezifischen Daten enthalten sind.