* Registry keys in the Backup and Restore plugin

[Mark1834]

I am about to replace my old small SSD system disk with a new disk that is large enough to hold both system and data so I can relegate the slow mechanical disk to purely backup duties (8x the capacity at little more than a third of the price compared with 2011!). It's a good opportunity to do a clean install and get rid of several years of accumulated junk.

As "belt and braces", I have backed up FH settings using both the plugin and my preferred one-click 4 line command script. Out of curiosity, I compared the Registry.keys file produced by the plugin with the two .reg files produced by the command script by copying the listings into Excel and comparing cells.

• Every key in HKEY_CURRENT_USER\SOFTWARE\Calico Pie\Family Historian was copied, as the two listings were identical.
• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Calico Pie\Family Historian\2.0 was omitted completely as it relates to the FH program installation, not user data.
• The two keys storing the FH Root Folder and Default File were omitted by the plugin, presumably because they may be different in the new installation.

Is that a correct summary of what the plugin is doing please?

[tatewise]

Yes, almost perfectly correct.

The three omitted file paths are explained in the Family Historian Copy and Migration Guide under Completing the Migration:

On the target PC ensure the File > Project Window > Location: and Tools > Preferences > Startup > Default Startup File and Tools > Preferences > Backup > Default Backup Folder are specified correctly as these settings are NOT included in the migration data, because they may be unique to the new PC.

i.e.
FH Root Folder
Default File
Backup Directory

[Mark1834]

OK, thanks. I missed the third one as I don't use the FH built-in backup so hadn't defined the backup folder.

Taking that a stage further then, I should be able to edit the registry backup file to remove the unwanted HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Calico Pie\Family Historian\2.0 key and change the two defined paths from old to new values. I can then reinstate all my settings by running the command script in reverse (i.e. cloning the ProgramData and AppData folders back, and installing the modified keys).

All the processing is purely within Windows, so it fully supports any defined file or folder name in any language, and doesn't have to jump through hoops to overcome the limitations of Lua libraries. That's useful to know, as I can continue to use the command script for convenient routine backup, and on the rare occasion that I need to run a restore I simply edit the Registry file beforehand if necessary. It makes the command script universally appropriate for the more experienced user who is happy to carry out minor file edits, not just for disaster recovery (same user, same system).

[Mark1834]

Update - job completed, and it was a remarkably smooth and easy process.

1. Install FH 7.0.9 to the new system drive.
2. Delete the local ProgramData folders for plugins, user-defined queries and fact types and run the simple script that recreates my directory junctions to master copies in OneDrive.

   Code: Select all

   mklink /J "C:\ProgramData\Calico Pie\Family Historian\Plugins" C:\Users\MarkD\OneDrive\FH\Plugins
   mklink /J "C:\ProgramData\Calico Pie\Family Historian\Queries\Custom" C:\Users\MarkD\OneDrive\FH\Queries\Custom
   mklink /J "C:\ProgramData\Calico Pie\Family Historian\Fact Types" "C:\Users\MarkD\OneDrive\FH\Fact Types"
   

3. Edit the file containing the machine registry data as described above and save under a new name to prevent any accidents (delete one key and change absolute path descriptions to the new OneDrive location).
4. Modify the backup script to become a restore script as below and run (here we don't need to change the OneDrive references as they are not absolute paths, whereas they are in the first script as it ensures that the correct folders are used even when run as a different admin user).

   Code: Select all

   Reg import "%OneDrive%\Documents\FH Settings\fhCURRENT_USER.reg"
   Reg import "%OneDrive%\Documents\FH Settings\fhLOCAL_MACHINE (restore version).reg"
   robocopy "%OneDrive%\Documents\FH Settings\fhProgramData" "%PROGRAMDATA%\Calico Pie\Family Historian" /MIR
   robocopy "%OneDrive%\Documents\FH Settings\fhAppData" "%APPDATA%\Calico Pie\Family Historian" /MIR
   

5. Upgrade the new copy to FH 7.0.11 by running the new installation file.

I now have FH 7.0.11 on my new system disk, complete with all my customisations.

As a bonus, if I invoke the boot override when starting up and boot into the old system disk, I still have my fully functional FH.7.0.9 available, complete with customisations and data using its own (different) mapping to OneDrive! Clearly that is not for long term use, and I will wipe the old system disk once I am sure that I have copied everything I need.

And before anybody asks, that's completely legitimate. Both Windows and Family Historian licences describe devices, not software copies, so two copies on one device is one license.

The Backup and Restore plugin is still the preferred and recommended method of transfer for general users, but this could be useful for more experienced computer users who are happy with simple file edits and working at the command line (maybe that's just the over-50s who remember DOS or those who dabble in Linux ). IMO, it's no more complex than using the plugin (and the backup and Registry restore are actually easier), and as I noted above it's universally applicable to any file and folder names in any language.

[tatewise]

FYI:
The Backup and Restore FH Settings plugin is now universally applicable to any file and folder names in any language.
It also handles very long path names (>255 chars) caused by copying from C:\ProgramData\Calico Pie\Family Historian\... to a chosen Backup folder ...\Family Historian\... that has a longer folder path.

[Mark1834]

It’s worth emphasising that these are complementary rather than competing solutions. A plugin is simple to use, but very complex to produce and maintain. Relatively few FH users could create one of this complexity from scratch. Here we use a handful of Windows commands to carry out exactly equivalent processing. They need some experience to get started with, but any intermediate or experienced Windows user will be capable of adapting them to their own requirements once they understand what they are actually doing.

Users can take whichever path they feel more comfortable with.

[tatewise]

Yes, they are complementary and very different beasts.
Another thing the plugin handles is where two copies of FH on different PC have both updated their custom settings.
It recognises when two identically named customisation files have different Modified Dates and lets the user choose which one should take precedence. That can even cope with migrating from one user to another.

If I understand correctly, the Windows command method relies on custom updates being managed more carefully.

[Mark1834]

Here it is set up as a plain mirror, so treats the ProgramData and AppData folders as two big blocks of files. However, there are a huge number of options within the basic robocopy command, so greater control at the file level is certainly possible. It emphasises that this is a solution for users who want flexibility and control and are happy to take ownership of exactly how the process works, while the plugin is for users who are happy to stay within the author's defined scope. Some users might want to build quite complex command scripts, and I suspect more people can do that than can write or modify plugins.

It's no problem having multiple backup sets. For example, I use directory junctions to sync plugins, queries and fact sets between my desktop and laptop, but I don't want the same display options on an ultrawide monitor and a 13" laptop screen. They simply backup the Registry to different files in the same OneDrive folder.

I'm not aware of anything in any of the configuration settings that is tied to a fixed user, so I can't see any issue with restoring under a different user name. That could actually be quite useful if you have multiple accounts on the same PC. In principle, it should be perfectly possible to set it up such that when users log in and out of Windows their settings are automatically synced with a shared folder that everyone has access to. This is left as an exercise for the reader...