[SOLVED] Backup and restore configuration across versions

[Tim Curtis]

Many of the settings reflected in the UI have underlying config files and processing logic so it's not as simple as just saving off some settings into a zip file.

I've just gone through the upgrade from 6.4.x to 6.5.2, as well as others in the past which required fresh installs, so that was the inspiration for that feature suggestion.  I also had an installation get corrupted, forcing me to start over and go through and make all of the configuration settings again.

I know that the settings are contained in multiple underlying configuration files.  I would expect that implementing the requested feature would require a pair of applications -- one to extract the relevant configuration elements from the files and one to modify the new installation's configuration files accordingly.  Making the modifications could be as simple as invoking SED in some cases while in others it would require something more involved.  But moOde already reads the files, extracts the relevant items, displays them, allows users to modify them (using GUI elements like switches, drop-down menus, and text entry boxes), and writes the modified values back, format-adjusted as necessary.

I spent decades in engineering (primarily embedded systems), so I recognize that the feature I'm requesting probably represents a very large (maybe too large) investment of effort to implement.  But it would be a real time saver for many people, especially those with complex moOde implementations that differ greatly from the stock configuration.  

Just a feature request to consider, even if it the complexity means that it can't be on the short-range radar.

As I mentioned in earlier post the in-place update scripts perform any necessary settings migration and thus a backup/restore settings utility is not really needed except for possibly a disaster recovery scenario but in that case a simple backup of the image would suffice.

The issue really boils down to whether it's wise to include whole OS upgrade as part of in-place update. The Pi Foundation recommends against it to ensure max reliability with a new OS and thats the view that I've adopted. Some users though, @philrandal comes to mind, have had success with OS upgrades. 

Adding that to in-place update though would create risks to users systems becoming corrupted or bricked if OS upgrade does not complete successfully. OS upgrade is a lengthy process requiring solid internet connectivity, lot of free space on the system and if even one of the many repositories that are accessed during the process happens to be too busy to service the request, the entire upgrade is a fail.

Here are some links
https://www.raspberrypi.org/documentatio...pdating.md
https://www.raspberrypi.org/blog/buster-...-raspbian/