Hi,
I started tonight with the idea to back-up my global variables to a file, something that I can then restore on the unfortunate outcome of a critical failure of my system. I take regular backups of my flows, but not of the variables stored in them.
This was unfortunately driven by a critical failure of my system that occurred last Sunday!
I appreciate that most people don't need to back-up global variables, but my solution allows for user input via UIs to change global and flow variables and I need a way to retain those user changes. Put another way, it would be quite unpleasant, time consuming and impractical to have to re-instate the user changes upon a restore.
I am happy to tackle this any-which-way i.e. maybe there is a better way to do it, however I started tonight with the following code to back-up all my globals to a file.
[
{
"id": "0e24839b54f8e811",
"type": "function",
"z": "530240e994fd158a",
"name": "function 18",
"func": "// Function to retrieve all global variables and store them in an array\nfunction getAllGlobalVariables() {\n let globalVariables = global.keys(); \n let globalValues = []; \n\n // Loop through each global variable name\n globalVariables.forEach(function(variableName) {\n let variableValue = global.get(variableName); \n globalValues.push({ name: variableName, value: variableValue }); \n });\n\n return globalValues; \n}\n\nlet allGlobalVars = getAllGlobalVariables();\nmsg.payload = allGlobalVars\nmsg.fileName = \"/home/user/backups/global.json\"\nreturn msg",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 1790,
"y": 1000,
"wires": [
[
"b9ef31998bfd7f28"
]
]
},
{
"id": "b01a9377ca50517c",
"type": "inject",
"z": "530240e994fd158a",
"name": "",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 1580,
"y": 1000,
"wires": [
[
"0e24839b54f8e811"
]
]
},
{
"id": "b9ef31998bfd7f28",
"type": "file",
"z": "530240e994fd158a",
"name": "",
"filename": "fileName",
"filenameType": "msg",
"appendNewline": true,
"createDir": false,
"overwriteFile": "true",
"x": 1980,
"y": 1000,
"wires": [
[]
]
}
]
The next step is to be able to restore the file to a build which would likely have 2x structures:
-
reinstate entire system from clone disc image - so most, but not necessarily all of the variables would already exist
-
reinstate just node-red flows to an existing running system - tbh, not sure how this eventuates other than that somehow node-red becomes corrupt, which after 3.5 years of very heavy usage, it has never done.
So, the primary objective is probably 1. above.
Before I go and spend more hours writing the code to restore the variable from the file I created (which btw, I feel would be a daunting task given all of the different structures of global variables that I currently have defined), I was wondering if someone else has tackled this problem already.
The next step in my endeavour would be to iterate over the flow variables and do the same - backup to file and restore on failure.
This is why I stated the following above: "I am happy to tackle this any-which-way i.e. maybe there is a better way to do this.
PS: I wonder if it's easier to just copy the entire node-red context folder at the time of backing up the flows and retain them both as a coupled backup? I guess that would work for a disaster recovery situation i.e. import flows into a new instance of node-red (do any manual config) + copy he backup of the context folder to the same instance... viola?
On that train of thought, if I was daring enough / knew that my current instance of node-red had the same data structure as the current instance of node-red flows, could I just (stop the node-red service) clear the context folder out and copy the backup across ... would it "just" work.
My node-red setup deals with transient states regardless, so it's not an issue that the restored data would not reflect transient values... the solution initialises all transient variables on start-up, or at least that's how it's intended to work 
EDIT: Upon writing this post, I have convinced myself that backing up the context folder is a good things, so have gone and done that "just in case"... looking forward to hearing about whether this was a good idea or not and why.
