I had not made much, if any, use of the Backup with Media function because of its destruction of the original media paths by consolidating everything in the one folder when I had my own backup procedure that faithfully preserves the structure. I thought to try the RootsMagic function today because I was curious to know if it also backed up the 'Not a Match' file that is written when you do Duplicate Search Merge and mark pairs as "Not a match". It doesn't and I encountered other issues besides.
- Backup with media provides no progress indicator, let alone even a "Please wait" message. The backup dialog closes and you are back to the main screen with which you cannot interact. Windows Task Manager reports that RootsMagic is "Not responding" and so one assumes the program is stuck and forces a shutdown because backup with media is so slow. RootsMagic may not have stopped - it may be working invisibly in the background. You can tell by inspecting the folder containing the database.rmgc file for a folder named "TempRMBackup". Inside this folder should be a copy of the database.rmgc file and a "Media" folder in which all the media files are being collected. This folder should continue to grow as files are added by the hidden process. If you inspect the latter, you will be startled by the names of the files, e.g., "2F6D960D2AC5C36036A32DD37B0E9351.jpg", one that you would never have assigned. Don't worry, File Restore will restore the media file names to what they were originally except it will add serial numbers for duplicate names for files that were originally in separate folders. The TempRMBackup folder is then compressed into the databasebackup.rmgb file and destroyed by RootsMagic's internal ZIP function. You can inspect the .rmgb file with a ZIP utility such as 7zip and see these cryptic file names.
- Backup does not include the database.DUP file, the file containing all your "Not a match" pairs you have identified during Duplicate Search Merge operations. Consequently, Restore to another location will lose the "Not a match" flags that preclude these pairs from showing up in subsequent DSMs. I think it should be included in the basic backup and restore.
- Backup does not validate your backup filename. You can enter characters in the backup dialog for the name you want to give to the backup file and there is no validation; e.g., I unthinkingly added the time 10:45 to the automatic name. Not until after the system has gone through a long 'Not responding' process does it then attempt to create the .rmgb file from the TempRMBackup set only to have Windows return an error which is reported obtusely by RootsMagic as something like "backup encountered an error". It should screen the filename on data entry.
- Restore is awfully slow. On my database, it takes tens of minutes yet 7zip can extract everything from the .rmgb file in 75 seconds. The difference is that Restore has to rename the files back to the original name from that cryptic hexadecimal name but that should be trivial. My guess is that the cryptic name is a hash of something, maybe nothing more than the record number of the file in the MultiMediaTable. But I see SQLite journal files being written throughout this long restore as though there is major database updating going on. Yet I cannot find in the database file that 7zip extracted from the backup anything that has changed from the original. There is something terribly inefficient in this process.
Good news is that if you do restore from a media-included backup and your original media files are still in the same place, the restored database still points to the original structure, not to the Media folder that Restore creates under the folder where the restored database is located. It is only when the original structure is missing that the media item is repointed to the Media subfolder.
