I think upgrading and backup are two different topics, and while doing a backup at upgrade time is valid there should be no necessity to do so (on this Pi/debian thread anyway) - as a) the script does not touch your flows files b) if an LTS version of nodejs is installed again the script doesn't touch it - the usual sudo apt upgrade may but that's BAU. c) the generated package.json file in the user directory is effectively a list of extra nodes installed and d) the --safe option was self inflicted by yourself modifying flows - and not the upgrade process so no need for it to be the recommended course of action.
But yes I agree a doc on (what to) backup, and how they could be useful for a) recovery and b) migration to another machine would be useful ( to cover flow names, arm6/7, creds files etc)
@dceejay
I disagree, a backup is always a best practice before any type of upgrade in place. That is my enterprise IT experience history chiming in. You never know what or when something will go sideways. Even if the script (Pi bias again) never touches the flow files. That is not the scope or goal of recommending the backup before upgrade, it is to avoid the unexpected.
Why is running --safe once, not a good precaution? If we are talking about protecting people from unexpected events, I would say that step has merit, IMHO.
Above said, whatever you decide to do, and what to include or not, it is a net win, benefit, from my perspective. Thanks for listening to my concerns, again.
all running with --safe does after an upgrade is not run the flow - so all it tells you is that you can still see it in the editor - It won't tell you it's about to go into a spin or crash when you do hit deploy. So you still have to deploy and find out.... so doesn't protect anyone from anything, it's just a recovery mechanism.
Don't get me wrong I think the more backups the better, and doing them at upgrade time is as good a time as any... but when was the last time you did a full backup before Windows update Tuesday ? or your mobile phone upgrade etc...
and don't forget all the docs are open-source too - so please contribute a page.
Sorry about the bold I do not know how that happened.
I ran the script from within my ~/.node-red folder (not sure if that is correct).
Stop Node-RED \u2714
Remove old version of Node-RED \u2714
Remove old version of Node.js -
Leave existing Node.js - Node v8.15.1 Npm 6.4.1
Clean npm cache -
Install Node-RED core \u2714
Move global nodes to local -
Install extra Pi nodes \u2714
Npm rebuild existing nodes -
Add shortcut commands \u2714
Update systemd script \u2714
But when I 'node-red-start' I see:-
Starting as a systemd service.
9 Jul 12:45:58 - [info]
Welcome to Node-RED
9 Jul 12:45:58 - [info] Node-RED version: v1.1.1
9 Jul 12:45:58 - [info] Node.js version: v12.16.2
9 Jul 12:45:58 - [info] Linux 4.19.97-v7+ arm LE
9 Jul 12:45:59 - [info] Loading palette nodes
9 Jul 12:46:03 - [info] Dashboard version 2.19.3 started at /ui
When I '~/.node-red $ nvm use 8.15.1'
Now using node v8.15.1 (npm v6.4.1)
node-red-start
Starting as a systemd service.
9 Jul 12:57:41 - [info]
Welcome to Node-RED
As I recall, the script does not replace anything if it believes it can leave it alone, because it is believed compatible. This is a bit of issue, if you build a Pi SD card image based on ARM v6 and then load the image on and ARM v7 Pi, the ARM v6 binaries work, just fine on ARM v7, but if you are a purest, you want ARM v7 binaries on ARM v7 based Pi. I solved by only running the script on initial boot of the Pi that has a new OS image. I also remotely deploy my flows, my default images do not stage node-red or node.js binaries.
The 512 is the default for most Pi devices, I have everything from Pi4 8GB to a PiZeroW with 512MB, and last I checked the script was consistent at 512. But, I have heard this is changing, that the script maybe more adaptive to available resources.
I have also read per this forum, that 1/2 physical memory is unofficial standard for the less robust Pi devices. I am testing running at 512 even on the PiZeroW devices I have. But, I don't run the editor on the PiZero devices except on rare exception. I disable the editor by default. But doing so is to avoid hammering the PiZero by miskate than saving resources.
The script does not touch the binaries unless needed, I should have been explicit. But you will note that I further said, that the newer script does, as I have been told, adjust some of the settings for different models of Pi devices. The version I have been running always seems to set a default of 512. However, I am building a new image as I type this note, and I expect on my PiZeroW, it will be more adaptive. That is why I noted also, that it is common per others in this forum, to set the limit to half of total memory.
Just a footnote... Ran the latest script, as published, on a PiZeroW device, which only has 512MB RAM total, the node red unit file sets the old memory threshold to 256, not 512 as the previous installation script version did.
