Impact of alternative Database Engines on data recovery workflows?

While look for versioning identification information for a user trying to recover an old Gramps database, noticed that the Database version information might be insufficient.

Since Gramps 5.0 added alternative database engine to BSDDB, are additional steps needed for identifying the englne in addition to the database schema? Does this mean the additional recovery steps need to be documented?

Can 5.1’s default SQLite recover an addon MongoDB database file?

I thought that the Gramps backup files were XML, regardless of which back-end database the user has? The only thing that matters (in terms of being able to restore) is the version of the Gramps software?

Since Gramps does not automatically produce XML backup files, emergency data recovery workflows (typically for uninitiated people who inherited a hard drive with Gramps data) have included dealing with database files. The autoback & backup on exit features were introduced in 5.0 but are not the default.

This is an attempt to document institutional knowledge while the developers who created a feature are still active with the project. (Much easier than restructing legacy knowledge a decade from now.)

On my Mac, in the folder ~/Library/Application Support/Gramps/grampsdb, each family tree has a folder with a cryptic name, and in most of those folders is a file database.txt containing the text “sqlite”. But one of the folders is much older and has files bdbversion.txt (containing “(4, 8, 30)” and schemaversion.txt (containing “19”).

Are those the kinds of things you’re looking for?

The database.txt file is ONE of things that the data recovery documentation should expand upon.

But there is a likelihood that files will become separated. So some taxonomy/classification workflows for database files would be a goal too.

Once a database file is identified for schema, version & database engine; a user could cross-reference which version of Gramps & database engine plugin must be installed to load that database file and generate a .gpkg backup file.

In the folders with the database.txt file containing “sqlite”, the database itself is called sqlite.db. Within the database, in the metadata table, there’s a row for “version” but the value is a BLOB.

The changes to the database file might also entail updating the FAQ answer to the question: “Why is the database format (GRDB) not portable?” and the Import .grdb documentation… both from the GUI and the CLI.

@prculley improved the Convert process for 5.2 too. This MIGHT be a non-issue.