15,534
edits
Changes
→What causes this corruption?
{{languages|Recover_corrupted_family_tree}}
Explanation of '''family tree''' and '''[[Recover_corrupted_family_tree#Version_2.2.x:_GRDB_corruption |GRDB]] corruption''', how to recover from it, and how to avoid it in the future.
==Why =What causes this corruption?===By far, the 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 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 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'
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 <code>.gramps</code> 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 gudelinesguidelines.
;Example: You copied <code>/home/user/genealogy/MyData.grdb</code> to <code>/home/user/genealogy/backup/BackupData.grdb</code> and the new file is not working.
;Solution: Copy <code>/home/user/.gramps/env/home/user/genealogy/MyData.grdb</code> directory into <code>/home/user/.gramps/env/home/user/genealogy/backup/BackupData.grdb</code> 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 <code>db_dump</code> and <code>db_load</code>, <code>db41_dump</code> and <code>db41_load</code>, <code>db4.4_dump</code> and <code>db4.4_load</code>, ... In Ubuntu you find them in the package <code>db4.48-util</code>. 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 <code>db4.68-util</code>. Whatever they are called, there should be a dump tool and a load tool, and they should be version 4 or later. For Fedora 17 this is 'db4-utils-4.8.30-10.fc17'. For Fedora 18 this is 'libdb4-utils-4.8.30-5.fc18' (note the new package name).
Basically, you just dump the grdb into a text file, then create a new grdb from that text file:
$ db4.4_dump 8_dump BackupData.grdb > somefile.txt $ db4.4_load 8_load newfile.grdb < somefile.txtand then cross your heart and hope that <code>newfile.grdb</code> will open in GRAMPSGramps.
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 8 tools: $ db4.6_dump 8_dump BackupData.grdb > somefile.txt $ db4.6_load 8_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 [[How_to_make_a_backup|backup ]] the data regularly. The [[How_to_make_a_backup|backups ]] should be in XML format (the <code>.gramps</code> format). XML is machine- and human-readable. It is completely self-sufficient. It is also small. The following are good practices of backups:
# 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.
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.
==Can you guys not solve this ? See also==Starting with GRAMPS 3.0, this has been * [[Database Formats#Family Tree Manager|completely reworked]] using the simpler [[Gramps 3.0 Wiki Manual - Manage Family Trees#Starting How to make a New Family Tree|Family Tree Managerbackup]].