Difference between revisions of "Recover corrupted family tree"

From Gramps
Jump to: navigation, search
(I have backup gbkp files)
 
(31 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
{{grampsmanualcopyright}}
 
{{grampsmanualcopyright}}
 
+
{{out of date}}
 
{{languages|Recover_corrupted_family_tree}}
 
{{languages|Recover_corrupted_family_tree}}
  
Explanation of '''family tree''' and '''GRDB corruption''', how to recover from it, and how to avoid it in the future.
+
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.
  
 
== Family Tree corruption ==  
 
== Family Tree corruption ==  
Line 22: Line 22:
  
 
=== What to do now? ===
 
=== What to do now? ===
 
+
[[File:Dbmanager07.png|400px|right]]
It is advisable not to click the repair button right away. It should work, but 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.
+
'''It is advisable not to click the [[Database_Formats#Repairing_a_Corrupt_Database|repair button]] right away.''' It should work, but 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:
 
Instead, take a backup of the family tree that is given problems. In a terminal do:
Line 29: Line 29:
 
  gramps -l  
 
  gramps -l  
  
This will give you a list with all family trees and the directory where they are stored, normally somewhere in the directory  ~/.gramps/grampsdb. Copy the directory of the tree with problems so as to have a backup:
+
This will give you a list with all family trees and the directory where they are stored, normally somewhere in the directory  ~/.gramps/grampsdb. Look at your [[Gramps_4.1_Wiki_Manual_-_User_Directory|user directory]]. Copy the directory of the tree with problems so as to have a backup:
 
   
 
   
 
  cp -a <target directory> <backup directory>
 
  cp -a <target directory> <backup directory>
  
 
If the recover button was present on the Gramps family tree, click it. All should work again. If you notice you lost information, or the repair button does not work, then do the following.
 
If the recover button was present on the Gramps family tree, click it. All should work again. If you notice you lost information, or the repair button does not work, then do the following.
If recovery worked, but you do not like the result, backup this data and place your backup taken above back in its original position. You now have again the bad family tree to work on. Next, obtain the bsddb recovery tools, see your distributions package search page. The program is called db4.8_recover, where 4.8 might be an older or newer version number.  
+
If recovery worked, but you do not like the result, backup this data and place your backup taken above back in its original position. You now have again the bad family tree to work on. Next, obtain the BSDDB recovery tools, see your distributions package search page. The program is called db4.8_recover, where 4.8 might be an older or newer version number. See your BSDDB version into {{man menu|Help -> About}} dialog or with <code> gramps -v</code> command.  
  
 
Run this tool as follows:
 
Run this tool as follows:
Line 41: Line 41:
 
  db4.8_recover -c
 
  db4.8_recover -c
  
That should do the trick, and allow GRAMPS to load the family tree. If not, then start a ticket on the gramps bug tracker.
+
That should do the trick, and allow Gramps to load the family tree. If not, then start a ticket on the Gramps bug tracker.
  
=== I have backup gpkg files ===
+
====Windows OS====
If you have a backup, you can try to recover the backup gpkg files. Do the following steps:
+
{{out of date|says # ...TO_COMPLETE...}}
The procedure to recover your data from gbkp files is:
+
 
# Copy the gbkp files to a new directory in your database directory, eg directory ''a1111''
+
# download Oracle tools on: http://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html
# Copy name.txt, open it in the new directory and set the content to a unique name.
+
# ...TO_COMPLETE...
# Create a file with name '''need_recover'''. Mind the underscore and the lack of an extension. The content of that file is unimportant.
+
 
# Start Gramps, click on the family tree with the name you adjusted in step 2. There should be a red stop sign with that filename. Click on the Recover button. The red stop sign should disappear and you should be able to load that family tree.
+
=== I have backup gbkp files ===
 +
If you have a backup, you can try to recover the backup <code>.gbkp</code> files. Do the following steps:
 +
The procedure to recover your data from <code>.gbkp</code> files is:
 +
# Make note of the "Family Tree" name you are trying to recover, from the "Family Tree Manager".
 +
# Close the Gramps program.
 +
# Locate your [[Gramps_4.1_Wiki_Manual_-_User_Directory|User Directory]] dependent on your operating systems.
 +
# Locate the <code>grampsdb</code> folder under your User Directory (''Also known as folders on some operating systems.[http://superuser.com/a/247396]'')
 +
# Under the <code>grampsdb</code> folder are stored all your "Family Tree" databases each in separate directories (eg:If you have 10 Family Trees you will have 10 folders each with an automatically created system generated folder name), locate the database you are trying to recover by opening <code>name.txt</code> file in a text editor and seeing if the name matches the Family Tree you are trying to recover. If it does match, make note of the directory name.
 +
# {{man menu|If that folder contains <code>.gbkp</code> files, you can continue your attempt to recover the Family Tree.}}
 +
# Copy all the <code>.gbkp</code> files to a new directory that you must create in your database <code>grampsdb</code> directory, eg. give the directory a unique name ''<code>a1111</code>''
 +
# From the original Family tree directory copy the <code>name.txt</code> file to the new directory you created.
 +
# In the new directory open <code>name.txt</code> 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 '''<code>need_recover</code>''' . {{man menu|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 {{bug|8665#c44245}} for a possible work around)
 +
# Start the Gramps program.
 +
# Select the family tree with the name you adjusted in step 9 eg. '''Family Tree 1 recovery attempt''' {{man label|(Do not double click on the family tree name)}}. There should be a red stop sign next to that family tree name.  
 +
# Select the {{man button|Repair}} button and the {{man label|Repair Family Tree?}} dialog will show, at this point select the {{man button|Proceed, I have taken a backup}} button or you can select {{man button|Stop}} to exit the repair attempt.
 +
# The Gramps program will attempt to repair and recover the family tree and if successful the red stop sign should disappear.
 +
# From the Family Tree manager select the repaired family tree and you should be able to {{man button|Load Database}} the family tree.
 +
# From the menu select {{man menu|Family Trees > Make Backup..}} and create a backup as insurance.
  
 
=== Implement more security ===
 
=== Implement more security ===
Line 56: Line 74:
 
If you work on Gramps regularly: backup the directory holding the family tree databases. These are very large files however.
 
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 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...
+
If you know you work on 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 5 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]] :
+
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.
 
   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.
 
   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!
+
   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.  
 
   4. Export to XML before upgrading your OS.  
  
Line 76: Line 94:
  
 
== Version 2.2.x: GRDB corruption ==
 
== Version 2.2.x: GRDB corruption ==
 +
{{man note|This section refers to Gramps Version 2.2.x}}
 +
 
===What causes this 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.
 
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 <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.
+
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 <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.
 
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.
+
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'
+
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?===
 
===What do I do now?===
Line 91: Line 111:
  
 
====The environment still exists====
 
====The environment still exists====
If you have environment directory for that file, copy it under the above gudelines.
+
If you have environment directory for that file, copy it under the above guidelines.
 
;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.
 
;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.
 
;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====
 
====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.8-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.8-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'.
+
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.8-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.8-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:
 
Basically, you just dump the grdb into a text file, then create a new grdb from that text file:
     $ db4.8dump BackupData.grdb > somefile.txt
+
     $ db4.8_dump BackupData.grdb > somefile.txt
 
     $ db4.8_load newfile.grdb < somefile.txt
 
     $ db4.8_load newfile.grdb < somefile.txt
 
and then cross your heart and hope that <code>newfile.grdb</code> will open in Gramps.
 
and then cross your heart and hope that <code>newfile.grdb</code> will open in Gramps.
Line 118: Line 138:
 
# Export to XML from time to time, especially after large edits.
 
# 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 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 to a newer version. Apparently, export to XML with old version before you install the new one!
+
# Export to XML before upgrading 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.
 
# Export to XML before upgrading your OS.
  

Latest revision as of 00:32, 29 August 2015

Gnome-important.png Special copyright notice: All edits to this page need to be under two different copyright licenses:

These licenses allow the Gramps project to maximally use this wiki manual as free content in future Gramps versions. If you do not agree with this dual license, then do not edit this page. You may only link to other pages within the wiki which fall only under the GFDL license via external links (using the syntax: [http://www.gramps-project.org/...]), not via internal links.
Also, only use the known conventions

Gramps-notes.png
This page's factual accuracy may be compromised due to out-of-date information. Please help improve the Gramps Wiki as a useful resource by updating it.

Explanation of family tree and GRDB corruption, how to recover from it, and how to avoid it in the future.

Family Tree corruption

What causes this corruption?

Not really known. Database corruption with family trees is however far less likely than with the previous format of storing your family tree Gramps version 2.2.x uses

How do you know about it?

Gramps might give you on startup that recovery is needed via a dialog box:

Gramps has detected a problem in the underlying Berkeley database.
This can be repaired by from the Family Tree Manager.
Select the database and click on the Repair button

But it might happen no Repair button is present, or you obtain the error (visible in terminal)

(-30975, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument').

What to do now?

Dbmanager07.png

It is advisable not to click the repair button right away. It should work, but 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:

gramps -l 

This will give you a list with all family trees and the directory where they are stored, normally somewhere in the directory ~/.gramps/grampsdb. Look at your user directory. Copy the directory of the tree with problems so as to have a backup:

cp -a <target directory> <backup directory>

If the recover button was present on the Gramps family tree, click it. All should work again. If you notice you lost information, or the repair button does not work, then do the following. If recovery worked, but you do not like the result, backup this data and place your backup taken above back in its original position. You now have again the bad family tree to work on. Next, obtain the BSDDB recovery tools, see your distributions package search page. The program is called db4.8_recover, where 4.8 might be an older or newer version number. See your BSDDB version into Help -> About dialog or with gramps -v command.

Run this tool as follows:

cd /home/<user>/.gramps/grampsdb/<target directory>
db4.8_recover -c

That should do the trick, and allow Gramps to load the family tree. If not, then start a ticket on the Gramps bug tracker.

Windows OS

Gramps-notes.png
This page's factual accuracy may be compromised due to out-of-date information. Please help improve the Gramps Wiki as a useful resource by updating it.
  1. download Oracle tools on: http://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html
  2. ...TO_COMPLETE...

I have backup gbkp files

If you have a backup, you can try to recover the backup .gbkp files. Do the following steps: The procedure to recover your data from .gbkp files is:

  1. Make note of the "Family Tree" name you are trying to recover, from the "Family Tree Manager".
  2. Close the Gramps program.
  3. Locate your User Directory dependent on your operating systems.
  4. Locate the grampsdb folder under your User Directory (Also known as folders on some operating systems.[1])
  5. Under the grampsdb folder are stored all your "Family Tree" databases each in separate directories (eg:If you have 10 Family Trees you will have 10 folders each with an automatically created system generated folder name), locate the database you are trying to recover by opening name.txt file in a text editor and seeing if the name matches the Family Tree you are trying to recover. If it does match, make note of the directory name.
  6. If that folder contains .gbkp files, you can continue your attempt to recover the Family Tree.
  7. Copy all the .gbkp files to a new directory that you must create in your database grampsdb directory, eg. give the directory a unique name a1111
  8. From the original Family tree directory copy the name.txt file to the new directory you created.
  9. 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
  10. 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)
  11. Start the Gramps program.
  12. 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.
  13. 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.
  14. The Gramps program will attempt to repair and recover the family tree and if successful the red stop sign should disappear.
  15. From the Family Tree manager select the repaired family tree and you should be able to Load Database the family tree.
  16. From the menu select Family Trees > Make Backup.. and create a backup as insurance.

Implement more security

Your genealogy data contains a lot of work and man hours. So work out a backup scheme

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 sporadically only, or have no space to backup your trees regularly, then do 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 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, 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

Gramps-notes.png
This section refers to Gramps Version 2.2.x

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 guidelines.

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.8-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.8-util. 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.8_dump BackupData.grdb > somefile.txt
   $ db4.8_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.8 tools:

   $ db4.8_dump BackupData.grdb > somefile.txt
   $ db4.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 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.