The first thing you could do is make it easier to download the current version of the script!
I did create the file with Unix line endings and it "looks" the same as what you have posted here, however, when I attempt to execute it I get:
scripts/upgrade-help: 12: scripts/upgrade-help: Syntax error: "(" unexpected (expecting "fi")
I edited the second line after the then, adding double quotes around the echo command's content since it includes parentheses and is making your install unhappy.
For what it's worth, this one didn't throw an error on my Raspbian. What o/s & shell are you using?
Hey, I'm still at the gathering-requirements stage. ha
OctoPi 0.14.0 and I believe I'm using bash. I'm not smart enough to use anything else but the default 
When I used nano to fix the line throwing the error, I notice that it colorizes the script and I see multiple occurrences of "reserved" words in the echo strings. I'd suggest that you put quotes around all of them just to be safe.
Noted.
- quotes for the
echocommands - Save the
/etc/wpa_supplicant/wpa_supplicant.conffile... but isn't that a chicken-and-egg? How can you come back in to run the restore script if you're not already in? Maybe... we need to look for an edited/boot/octopi-wpa-supplicant.txtand download that for the user. And if there isn't one, we need to build one from the/etc/wpa_supplicant/wpa_supplicant.conffile.
I guess there's no easy method of backing up and restoring user access control, right? I couldn't tell you if that's got anything to do with the .octoprint folder but maybe it's not.
I must have guessed wrong when I saw the posted script. I thought it was ready for testing and feedback but it doesn't appear to be (I've found more errors on the backup side).
As for saving the /boot files, I think they should at least be in a separate tarball. Those are files that would be edited while the SD card is plugged into the system that created the SD card from the image file. I would make the assumption that the /boot files were edited successfully in the process of getting the current SD card working. BTW, don't forget to save this script file as well!
I'm looking at this from the perspective of a new version of OctoPi was just released. How do I get my current OctoPrint configuration moved to the new OctoPi image with the minimum amount of effort.
Food for thought... Is there enough room left in the /boot partition to put the tarball(s) in there?
Not on my system 
tarball is 176M, free space on /boot 21M.
I'm in the same boat as you: I'm staring at an upgrade event but I want to minimize the pain for myself. So I thought, well I might as well script this for the times in the future where I'll need this, too.
If... I put the tarball(s) on the /boot partition, isn't that lost with the new OctoPi reload-from-img? I was thinking that the best way would be to download the tarball(s) to the user's workstation, give them some guidance when that's necessary and automate the rest.
I would guess that ultimately Gina/Guy would get this into the OctoPi image itself.
I was just thinking of an alternative to using scp to save the files. In my case, its WinSCP since my workstation is running Windows 10.
Something like run the backup script, shutdown the RPi, move the SD card to the workstation, copy files off of /boot, overwrite the SD card with new one, put files back into /boot, move card back to RPi, boot, run the restore script.
Its a mute point, however, as /boot isn't big enough to hold it.
The /boot/config.txt and /boot/cmdline.txt might be all that you need to backup, especially if you've added an LCD/TFT screen or similar.
In case you're still interested... here is the repository which I've created for the script. Please review and let me know if there's anything amiss.
I have not exercised the restore side of this myself yet; the last thing I did was to remove the "echo" from before those two dangerous commands. I intend to run it through a full test cycle sometime this weekend using a new microSD card and pulling down the latest OctoPi image.
I have adjusted the syntax in many places to minimize problems. I've added a README.md to explain things.
1 Like
I've gotta go mow the lawn, I'll check it out when I get back. Is this something I plug into octoprint, or run from the raspbian CLI ? Or is this something where you remove the SD card and run completely outside the OS ?
I can answer that one. This is a script you run from the CLI (i.e. from an SSH terminal session).
Yes.
- Remote into the Pi and follow the instructions to add the script
- Run the script and follow the bouncing prompts
(The script will tell you when you need to run something from your workstation or from the Pi itself.)
Other than it wanting to stop the octoprint service itself, the backup side of this is non-destructive. It will prompt you first, though. I would suggest that the backup side of the script should be run once a week or so for good housekeeping.
Sounds like fun
Lemme pick an octo-victim and I'll, um, ask another question when it becomes far too complicated, like, ya know, which side is the gas tank on ?
v1.0.2 is now available and I have run it through a test cycle. This version seems to work as expected.
Read the walk-through documentation
- It's not a bad effort but I'm still daunted about the sheer number of commands necessary to rev things up a level
- On the plus side, it's well-documented about the process and may prompt you to save something that you otherwise would have forgotten
Did you see this?
I did not. Very cool. 