Changes

Jump to: navigation, search

Recover corrupted family tree

No change in size, 01:29, 21 June 2015
Gramps
=== What to do now? ===
It is advisable not to click the repair button right away. It should work, but GRAMPS Gramps might believe an error is present while this is in reality not true. Repairing your tree then will lead to loss of the last typed changes.
Instead, take a backup of the family tree that is given problems. In a terminal do:
db4.8_recover -c
That should do the trick, and allow GRAMPS Gramps to load the family tree. If not, then start a ticket on the gramps Gramps bug tracker.
====Windows OS====
If you work on Gramps regularly: backup the directory holding the family tree databases. These are very large files however.
If you know you work on GRAMPS Gramps sporadically only, or have no space to backup your trees regularly, then do [[How_to_make_a_backup|backup]] in XML format (the .gramps format). Do not forget to disable privacy filters...
The XML format will open up just fine over many years on another computer with another OS. This will probably '''not''' be the case for the databases a family tree is stored in. XML is machine- and human-readable. It is completely self-sufficient. It is also small. The following are good practices of [[How_to_make_a_backup|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 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.
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 Gramps releases uses grdb files and stores the environment for each file, under a tree in a <code>~/.gramps/env</code> directory. If your grdb file is <code>/home/user/genealogy/MyData.grdb</code> then its environment is in the <code>/home/user/.gramps/env/home/user/genealogy/MyData.grdb</code> 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 GRAMPSGramps, 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 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?===
# Export to XML from time to time, especially after large edits.
# 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.
# Export to XML before upgrading GRAMPS Gramps to a newer version. Apparently, export to XML with old version before you install the new one!
# Export to XML before upgrading your OS.

Navigation menu