Family Historian User Group

In Displaying dates of death of siblings in Properties Facts window (17279)

tatewise wrote: ↑

05 Dec 2019 22:39

FH Backups only backup Project data, i.e. the content of the Project folder.

You sometimes wonder whether it is worth having an enhancement so that FH writes out its "configuration data" to a file that might get backed up!

Presumably the configuration data is kept in registry settings for performance reasons?

That is potentially the start of a new topic, and I may split it off in a new thread if it gets too protracted.

Yes, AS has the Tools > Backup/Restore A.S. Options commands for its Windows Registry settings.

You will have to ask Calico Pie why FH saves its customisation & preference settings where it does.
See how_to:understanding_scope_of_features|> Understanding the Scope of Features for full details of all locations and their scope.
I doubt if performance has any impact on FH settings in the Windows Registry as they are changed very rarely, and loaded into memory initially, then saved when FH is closed.

That is why I wrote the Backup and Restore Family Historian Settings Plugin to capture the Windows Registry and all other settings, and save them together for ease of backup.

tatewise wrote: ↑

06 Dec 2019 12:26

...
That is why I wrote the Backup and Restore Family Historian Settings Plugin to capture the Windows Registry and all other settings, and save them together for ease of backup.

Appreciated, but so many seem to not use it, or wait until it is too late! I was just wondering whether in effect your plugin (Backup elements) should actually be part of the core product with some form of default frequency/location?

Unfortunately, far too many users appear to have no sound backup regime at all.
Not just for FH related data, but for everything else too

The ability to invoke Plugins other than from the Tools menu has been discussed before.
One option in the Wish List is Ref 547 Run Plugins via Expressions, but a method of triggering Plugins from events such as Open, Close, Autosave or Snapshot would also be useful.
You are suggesting something akin to the Snapshot regime for the GEDCOM file, but applied to the Windows Registry settings, etc.

It is very hard to legislate for others whether they are more or less diligent than you.

But many users are told with respect to Windows Registry "here be dragons" and they don't (knowingly) touch anything to do with the registry. Which would seem to be a reasonable approach!

Once you have moved on a bit you might use a backup routine which involves plugging in a drive and running a utility where you are not really sure what it does, but you hope for the best. Again this is not that unreasonable as a little knowledge can be a dangerous thing. (I remember a junior manager in a marketing department who got a tape drive to back up the department's IBM AT (all 20Mbytes?), did what he thought was a backup and then decided to test it by formating C and attempting a restore!)

If you have moved to this state (of doing a backup), having a program that (out of the pack - vanilla instal) occasionally dumps its configuration files into the path that gets backed up, does put the user in a position where if the worst happens (and they have a recent back up) they can be talked through recovering their configuration.

Using a plugin in a future auto-invoke environment would achieve this end, but would the target users set up the plugin and the auto-invoke? I don't think so, which is why I was pondering whether at least the backup element of your current plugin should become part of the core product.

Extending the Snapshot regime to cover configuration might be a way to do this (I have not looked under the hood to work out where they are! perhaps I should). Again it is probably something that the target user (genealogists who are not techies - why should they be) would not know about, but since it happens (out of the box? I can't remember activating it), it is there and after disaster someone might be able to talk them through the restoration process.

Any restoration process can be a bit time consuming; the critical bit is that some form of back up happens. When I had a "sewing machine style" Compaq at work I used to back up onto a floppy with xcopy every night and then full back up every month (which was not too onerous). When I had a disk crash, it took a time to do the restore (last full back up and then one floppy xcopy back up for every day of the current month), but it was a dependable process and worked the one time I needed it.

When talking about people not having a backup regime at all, I meant for their files, especially the important stuff such as photos and genealogy data. (Here I don't mean FH Backups to the same disk drive, but external backups to another media such as DVD or the cloud.)

Backups of the Windows Registry keys for FH are not particularly crucial (yes, most users should not go there).
Those keys are restored to defaults by installing FH and many of them only record unimportant stuff like the coordinates of windows when last used. Almost all the rest can be quickly set by running through Tools > Preferences.
Only a tiny number have any great significance.
Far more important are all the custom files created in the C:\ProgramData\Calico Pie\Family Historian\ folder.

Having said all that, your suggestion of some sort of automatic backup of settings to file has merit.
BUT if the user has no general file backup regime, that is still worthless if their PC or disk crashes.

FYI: The Snapshots are governed by the Tools > Preferences > General tab, Advanced button, and the Help button explains all. The files are kept in the Snapshot folder (alongside the Media folder) inside the ...fh_data folder where the GEDCOM file resides. The concept was prompted by accidental corruptions of the master GEDCOM file, either by users running Plugins that delete stuff, etc, or by external agencies.

Have followed this discussion with interest; and as an obsessive user of Backups and (Manual) Synchronisation across multiple systems I can see merit in the suggestion that inbuilt backup systems for software applications should consider saving 'vital' software settings as well as data. However, that ignores the fact that OS providers always recommend full System Backups to aid recovery in the event of catastrophic events, which automatically takes care of all software settings files if properly configured. Windows and MacOS both have inbuilt software applications to maintain such backups; and there are also many third party tools for all Operating Systems that perform similar functions and also provide other enhancements, for those that prefer them. If people don't make use of such facilities, even when they are provided, then I can't see a strong argument for individual commercial application developers spending development time on building and maintaining individual backup systems for anything other than 'zipping' copies of the essential data produced by their applications? In short, what is the case for a multiplicity of individual system settings backups? Users would soon get bored with such an approach even if they bothered in the first place. Microsoft provides no specific inbuilt method/system for backing-up its application settings/user templates for Office etc. which provides a strongly negative role model, implying that this is not seen as a useful or productive use of developers time to create a pre-built facility within their apps. For Windows Users who want specific backups of many Application settings, templates and Registry files, I'd suggest looking at CloneApp - http://www.mirinsoft.com/ms-apps/cloneapp which also enables users to create plug-in scripts for any apps not already included in the Freeware software.

I would expect Calico Pie (the FH System designer(s)) to be looking at/considering both the User Wish List and the Plug-ins that individuals have invested time in to determine whether any of the ideas generated could/should be incorporated in the standard product in some shape or form, but I don't think an enhanced backup system would be high on my personal priority list, even though I do regularly use the existing Plug-in before and after making system changes.

Mervyn

mjashby wrote: ↑

07 Dec 2019 11:31

...
If people don't make use of such facilities [provided backup facilities], even when they are provided, then I can't see a strong argument for individual commercial application developers spending development time on building and maintaining individual backup systems for anything other than 'zipping' copies of the essential data produced by their applications?
...

I can see this argument - I provoked this original sub-thread in the light of my perception that we get a lot of queries about people either recovering from a systems crash or transferring their FH environment onto a new computer. In these cases the root of the problem is that people have not made use of FH backup facilities (and as you point out, in some cases, not used the OS inbuilt facilities).

I suspect with increased broadband speeds and "capacity" more and more people will be getting "everything backed up to the cloud", which possibly means in the case of the crash they can restore their entire system. (My italics)

In the corporate world, with controlled "clean" configurations, a post crash full restore is probably easiest and quickest (which may be important). In the consumer world, where speed is not necessarily quite as important, I wonder whether post crash the best thing to do is to:

1. rebuild a clean version of the OS,
2. install clean versions of those applications (that the user still needs) to give a clean foundation and
3. then restore user data.

The question then is whether "user data" (should) include user configuration data - or whether that negates the idea of creating a clean foundation!

Without constant back up to a NAS or the cloud, full systems backups can be time-consuming and laborious - and those sort of things don't get done! There is also an argument that your backup should be to an offline detachable media so that it cannot be attacked by malware, particularly ransomware (which if it can find your hard disk, it will also find and lock any attached backup storage!). For consumers, there is a lot to be said for a routine where say once a week you plug in a USB drive and within say half an hour you will have copied sufficient to enable you to do the sort of rebuild noted above.

I have spent considerable time on my environments (previously Windows 7, now Linux) ensuring that configuration files (and other details) are in paths that get backed up. That made changing OS a remarkably easy operation.

in terms of the time that system developers should spend, I am not sure how much it is a case of spending time developing backup routines as designing their systems such that configuration data is put (or copied) somewhere where it can be easily backed up (whilst being safe from numpties trying to directly edit it! Such things have to be, not just idiot proof but also, clever-proof).

Following on from David's post it is possible if the will was there to have robust backup restore options.

This is one of the reasons I switched to a Mac. I recently had an SSD failure on my 8 year old MacBook Air. I have an external disk that is connected to this laptop and it does a TimeMachine backup, to this external drive, which is built in to the OS, which it performs every hour. I fitted a new SSD and did a recovery install of the OS and applications from the external drive. It took about 90 minutes and I was exactly back where I was before the failure. That included Crossover and FH as well as my other apps. There was no need to enter any serial numbers passwords etc everything was back to how it should be.

So it can be done at an OS level if there is the will. It would have worked just as well if I had purchased a new laptop and done the setup from TimeMachine which is offered when setting up a new Mac. If Windows had this facility then a lot of these problems would not exist.

The system Colin describes is very similar to the one I use, i.e. I'm also a Mac User and use 'Time Machine' which once configured requires very little user maintenance/interaction time (no expensive NAS Drive or Internet/Cloud costs involved); but in my case I also have a portable synchronisation Drive which also serves as a further backup for my user files and any system files , templates etc. I may wish to preserve and or, possibly, restore to the same or another machine. Windows has similar inbuilt software to Time Machine in 'File History' although it is more limited in coverage as it doesn't take care of software system files/settings, but combining the File History application with regularly updated Windows System Recovery media, and the careful use of Windows snapshots/Restore Points can provide an effective substitute.

As for trying to argue with any developer that that their software application might be improved by providing in-built systems settings backup facilities I believe the most likely response from most would be something like: "So it's suggested that we could/should provide (and therefore also provide support for) an application settings backup process for users who can't be bothered to maintain full system backups, which would preserve all of their settings in a single process for all installed software?"

Mervyn