RFC: luci-mod-system: Allow selective file restore from backups
This is useful when you're importing backups intended for different hardware, for example, where e.g. /etc/config/[network|wireless] are not suitable for the target platform, but everything else useful.
Caveats: subsequent extraction and compression steps happen on the target device, to then feed the selective_backup archive to sysupgrade. ( It's not impossible that a users /etc/sysupgrade.conf that created the original backup stashed gigs of stuff in there... but this is an extreme and unlikely edge case, in which case they're better off using just the original restore ).
Feedback welcome.
The backup restore overview
the selective dialogue
In case nothing was chosen
- [x] This PR is not from my main or master branch :poop:, but a separate branch :white_check_mark:
- [x] Each commit has a valid :black_nib:
Signed-off-by: <[email protected]>row (viagit commit --signoff) - [x] Each commit and PR title has a valid :memo:
<package name>: titlefirst line subject for packages - [x] Tested on: 23.05.5
- [x] ( Preferred ) Mention: @jow- @Ansuel @hnyman
- [x] ( Preferred ) Screenshot or mp4 of changes:
- [x] Description: (describe the changes proposed in this PR)
Better might be to simply amend the sysupgrade script to ingest the -T /tmp/filelist.txt and do a selective extraction from there, obviating the need for the two decompress/compress steps.
I really like this idea. I assume you're waiting atm if https://github.com/openwrt/openwrt/pull/16656 gets merged and if it does rewrite it to use the sysupgrade command instead of creating a new tarball?
Exactly that. I have a rewrite in my local repo. It avoids all the pitfalls and the change delta is way smaller. sysupgrade is basically a big fat front-end script to tar.
If you like it, just jam a thumbs up on the other PR and make some noise there. It might not be the ideal way to do it, but it's the cleanest for this purpose. The busybox tar doesn't have many options to work with, so providing individual filenames at the command prompt isn't there yet, I think.
Note to self: convenience button for selection to exclude wireless and network from a foreign device backup.
convenience button for selection to exclude wireless and network
...and system Almost as dangerous, at least the LED config etc.
All other config files that e.g. affect VPN, DNS can be difficult too, as the lan/wan port names in uci config may be quite different.
The selective restore from another device can be rather challenging.
I feel that more useful than "partial restore into the actual config" could be an easy "restore as reference material to /etc/oldconfig" or something similar. So that some SSH console diff/cp/mv work would be needed, but getting the files to the file system would be easy (and safe).
I looked at that bit: luci loads every file in the /etc/config folder and differing files with synonymous entries would clash. So such a restore requires placement in a different folder. A bit more complicated.
@hnyman regarding LED config - what is your experience of things there? Potential of loading wrong kernel modules?
Not that dangerous, but network and usb LEDs might be defined wrongly.