Difference between revisions of "Recover corrupted family tree"

From Gramps
Jump to: navigation, search
(Why this corruption)
m (What do I do now?)
Line 10: Line 10:
  
 
==What do I do now?==
 
==What do I do now?==
 +
===The enironment still exists===
 
If you have environment dir for that file, copy it under the above gudelines.
 
If you have environment dir for that file, copy it under the above gudelines.
;Example: I copied /home/user/genealogy/MyData.grdb to /home/user/genealogy/backup/BackupData.grdb and the new file is not working.
+
;Example: I 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 /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.
+
;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.
  
If you don't have the orignal 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, and so on. Whatever they are called, there should be 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:
+
===The enironment is lost===
 +
If you don't have the orignal 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>, or some such. Whatever they are called, there should be 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_dump BackupData.grdb > somefile.txt
 
     $ db4.4_load newfile.grdb < somefile.txt
 
     $ db4.4_load newfile.grdb < somefile.txt
and then cross your heart and hope that newfile.grdb will open in gramps.
+
and then cross your heart and hope that <code>newfile.grdb</code> will open in gramps.
  
 
==How to prevent corruption?==
 
==How to prevent corruption?==

Revision as of 20:41, 3 July 2007

Attempt to explain GRDB corruption, how to recover it, and how to avoid it in the future.

Why this corruption

By far, 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 current stable gramps releases store 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.

What do I do now?

The enironment still exists

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

Example
I 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 enironment is lost

If you don't have the orignal 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, or some such. Whatever they are called, there should be 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.

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 smalll. Following are the good practices of backups:

  1. Export to XML from time to time, especially after large edits.
  2. Export to XML before making bug 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.