De:Defekten Stammbaum wiederherstellen

From Gramps
Revision as of 09:46, 10 July 2012 by Leonhaeuser (talk | contribs) (Mehr Sicherheit einführen)
Jump to: navigation, search

(wird aktuell übersetzt kann ein paar Tage dauern 08.7.2012)

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. Die Beschädigung von Datenbanken mit Stammbäumen ist aber erheblich seltener als mit dem früheren Verfahren mit dem Daten unter Gramps 2.2.x gespeichert werden.

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 Reparaturschaltflä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 Reparaturschaltflä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. 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.6_recover, wobei die Versionsnummer 4.6 eine ältere oder neuere sein kann.

Starte diese Werkzeug wie folgt:

cd /home/<Benutzer>/.gramps/grampsdb/<Zielverzeichnis>
db4.6_recover -c

So müsste es gehen, und Gramps ermöglichen, den Stammbaum zu laden. Wenn nicht, öffne ein Ticket im Gramps Fehlerverfolgungswerkzeug.

Ich habe gesicherte gpkg Dateien

Wenn du eine Sicherung besitzt, kannst du versuchen die gesicherten gpkg Dateien wiederherzustellen. Führe folgende Schritte durch: Die Prozedur um deine Daten aus gbkp Dateien wiederherzustellen ist:

  1. Kopiere die gbkp Dateien in ein neues Verzeichnis in deinem Datenbankverzeichnis, z.B. Verzeichnis a1111
  2. Erstelle eine Datei name.txt in dem neuen Verzeichnis als Inhalt der Datei wähle einen eindeutigen Namen (dies ist der Name, mit dem der Stammbaum in deiner Stammbaumliste auftaucht).
  3. Erstelle eine Datei mit dem Namen need_recover. Beachte den Unterstrich und das Fehlen einer Dateierweiterung. Der Inhalt der Datei ist unwichtig.
  4. Starte Gramps, klicke auf den Stammbaum mit dem Namen, den du in Schritt zwei festgelegt hast. Als Status sollte der Stammbaum ein rotes Stoppschild besitzen. Klicke auf die Wiederherstellen Schaltfläche. Das Stoppschild sollte verschwinden und du solltest den Stammbaum laden können.

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 über 5 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 to XML before making big changes, such as importing new data into an existing database from e.g. GEDCOM, merging records, running tools that may heavily modify the data, etc.
  3. Export to XML before upgrading GRAMPS to a newer version. Apparently, export to XML with old version before you install the new one!
  4. Export nach XML vor der Aktualisierung des Betriebssystems. 

Also, use XML format for any data migration. Moving to another machine, sending data to grandma, copying to another user on the same machine -- all of these cases should use XML, as there is no binary specific data.

Note that XML does not contain your media files. The gpkg output format contains XML and your media files, with the disadvantage of this being very large. If you already have a backup scheme for your media files, there is no need to also backup gpkg files.

ACI not ACID, upgrade, downgrade

Gramps protects your data using an ACI database. This means the last commit can be lost on an error, but not more than that. You should before an upgrade make sure Gramps closed your family tree correctly however.

There should be no error in opening a family tree with a newer version. See the long research in 3975, which does indicate version 4.7.25 of Bsddb contains a bug that can give a strange error message.

Trying to open a family tree after a downgrade is not supported. You will obtain an error that the database is created with a newer version.

Version 2.2.x: GRDB corruption

What causes this corruption?

The leading cause of grdb corruption is moving the grdb file from its original location. Whether you move the file to another directory, rename it, copy into another file, transfer to another machine, or another user account -- all of those will "corrupt" the file.

What happens is that the grdb file needs its database environment -- a directory with log files, lock files, temp files, etc. The 2.2.x gramps releases uses grdb files and stores the environment for each file, under a tree in a ~/.gramps/env directory. If your grdb file is /home/user/genealogy/MyData.grdb then its environment is in the /home/user/.gramps/env/home/user/genealogy/MyData.grdb directory.

So moving, copying, or renaming the file will copy the file's bytes, but not its environment. This is why the moved file appears corrupted.

Another cause can be an upgrade or downgrade of your operating system to a bsddb database backend that does not support fully the previous form of the database (eg, changed hash versions). This will also seem like a corruption in GRAMPS, but actually means the bsddb tools must be used to convert to data to a new version.

Not being able to open a /tmp/... file in GRAMPS 3.0.x on opening grdb files indicates database corruption. This is because the grdb file you want to open is copied to the /tmp dir, and then opened. All failure results in the '/tmp/tmpxxxxx could not be opened'

What do I do now?

The answer depends on whether or not you have the environment for that database. If you just copied one file into another then the environment may still work. If you modified the original database since then, the original environment has changed and there's no good environment for the new file. If you removed your .gramps directory (why oh why?) then all environments are lost. So act depending on the situation, as explained below.

The environment still exists

If you have environment directory for that file, copy it under the above gudelines.

Example
You copied /home/user/genealogy/MyData.grdb to /home/user/genealogy/backup/BackupData.grdb and the new file is not working.
Solution
Copy /home/user/.gramps/env/home/user/genealogy/MyData.grdb directory into /home/user/.gramps/env/home/user/genealogy/backup/BackupData.grdb and this should fix the problem.

The environment is lost

If you don't have the original environment for that file, you may try dumping and loading your data using Berkeley DB tools. Depending on your system, they may be called db_dump and db_load, db41_dump and db41_load, db4.4_dump and db4.4_load, ... In Ubuntu you find them in the package db4.4-util. You might need more recent versions depending on the version your distribution uses in its python package. So for eg Ubuntu Hardy created files, you will need db4.6-util. Whatever they are called, there should be a dump tool and a load tool, and they should be version 4 or later.

Basically, you just dump the grdb into a text file, then create a new grdb from that text file:

   $ db4.4_dump BackupData.grdb > somefile.txt
   $ db4.4_load newfile.grdb < somefile.txt

and then cross your heart and hope that newfile.grdb will open in GRAMPS.

If you obtain the error:

db4.4_dump: eidtrans: unsupported hash version: 9

this is an indication you need a more recent version. So use db4.6 tools:

   $ db4.6_dump BackupData.grdb > somefile.txt
   $ db4.6_load newfile.grdb < somefile.txt

Note: If you downgrade your distribution, it might be needed to do dump with 4.6 tools, and load with 4.4 or 4.5 tools.

How to prevent corruption?

While moving the file is the leading cause of corruption, apparently there are other less frequent causes that we don't fully know. So preventing corruption is not always possible.

What is possible though is to backup the data regularly. The backups should be in XML format (the .gramps format). XML is machine- and human-readable. It is completely self-sufficient. It is also small. The following are good practices of backups:

  1. Export to XML from time to time, especially after large edits.
  2. Export to XML before making big changes, such as importing new data into an existing database from e.g. GEDCOM, merging records, running tools that may heavily modify the data, etc.
  3. Export to XML before upgrading GRAMPS to a newer version. Apparently, export to XML with old version before you install the new one!
  4. Export to XML before upgrading your OS.

Also, use XML format for any data migration. Moving to another machine, sending data to grandma, copying to another user on the same machine -- all of these cases should use XML.