Gramps data migration tool

Ideas
1

A user just posted a question about recovering their Tree after a computer OS being crashed. They had mounted the corrupted OS boot drive as an external drive & wanted to restore the Gramps data to a fresh computer.

It seemed like this might be a task we all will have to do sooner or later.

Could there be a tool built for this specific purpose?

To move the data, they needed to:

  • Identify the version of Gramps
  • Identify the database backend
  • Locate the database files
  • Locate the backups (decide if the backups are current)
  • Locate the media files
  • Transfer copies of the appropriate files to the new system
  • Restore the ALL the Trees in the database old folder to the database version in the fresh install of Gramps
  • Make current backups

The gramp.ini file has a lot of this information. So a tool that sought out copies of that file & parsed all discovered copies might be able to do most of the location tasks.

However, I noticed that the .ini file does not include some important info for migrating data. Like the version of Gramps, the database engine version, the volumeID for drive letters (or a some sort of relative offset for the path for the gramps.ini with respect to the backup, database & media paths).

There are additional niceties such a tool could do:

  • Install the same dependecies
  • Install the same add-ons
  • Restore preferences (main & add-on)
  • Restore report options
  • Restore holiday calendars
  • Restore report options
  • Restore custom filters
  • Restore books
  • Restore localization
1 Like
2

I wonder if some of the Gramps script list options couldnt be adapted to this purpose?

If a database path could be specified (which temporarily overrides the gramps.ini path) then the
gramps -L
and
gramps -l
might list the Trees and identify versions with statistics?

If I temporarily set the gramps.ini database path to such an external drive, would these tools work?

Or would Gramps choke if the database files are from a different version? Would it try to update them to the current version and potentially corrupt them?

Could I (somehow) automatically script Gramps to look in a database path & export all the Trees to .gpkg files?

3

Another subject to consider is migrating data as the Gramps Data Model evolves.

Version Old New Corrective action
5.2.0 Other gender association Person gender list No defined solution.
5.2.0 Godparent association Godparent role No defined solution. See Discussion
5.2.0 Event: Source Citation list
5.0.0 MD5 attribute Media checksum delete old attribute (SuperTool script)
Media Verify tool to build new checksum
5.0.0 BSDDB SQLite database convert via Manage Family Trees dialog option
4.2.0 PlaceName enhanced manual addition of string, lang. code, data range
4.1.0 Place hierarchy
3.4.0 shared citations
3.4.0 citation attachments (media, data)
3.4.0 Source References Citations
3.3.0 tagging
3.3.0 surname list
4

Probably but it’s way beyond me. However I don’t see it’s worth the effort of someone capable of doing it. It’s trying to solve a problem that has already been solved, through the use of proper backup software. Restoring from a proper backup is trivial compared to having to pick through the rubble of a corrupted installation.

It never ceases to amaze me that people don’t have proper backup routines in place, especially for precious data like their genealogy files.

5

Recovery of an old backup (or an inherited backup) can be confusing because, not only is the user unfamiliar with Gramps (or the particular release revision), there are dialects of the data model or XML; as well as the database format and database engine. And not all versions of Gramps are fluent in all those dialects.

6

That’s a completely different scenario to the situation that prompted this topic. In that case the OS had died. A decent backup would have restored everything, inc. the OS, without having to pick through the wreck of the crash.

However, the tool you suggest might have merit in these new cases you now mention.