Neuaufbau - Kein Recovery (NodeRed) mit BackitUp möglich

[mickym]

Ich habe die letzten beiden Tage mein System neu von "Scratch" neu aufgebaut - bei mir war das wie zu Erwarten kein Tasks von wenigen Stunden, das hat aber mit dem iobroker nur zur Hälfte was zu tun. Allerdings bin ich froh, dass ich immer noch ein laufendes System hatte, um fehlende Dateien zu kopieren, da leider mit BackItUp - mein System unwiederbringlich kaputt gewesen wäre, da leider überhaupt keine Datei meiner Hauptinstanz von NodeRed gesichert wurden. Doch alles der Reihe nach - ich schreib das jetzt als Erfahrungsbericht, bevor alles verloren geht. Ich habe mein System wiederhergestellt und hab deswegen einigen Verbesserungsvorschläge für den backitup Adapter und werde dann auch ggf. entsprechende Issues aufmachen. Erschreckend, um es vorwegzunehmen war jedoch, dass ich alle meine Flows verloren hätte, wenn ich mich nur auf den BackitUP Adapter verlassen hätte. Genaueres im Verlauf dieses Posts.

Wer mich hier im Forum kennt, weiß ja, dass ich einen Neuaufbau des Systems gescheut habe, wie die Pest, deshalb stellt sich vielleicht der eine oder andere die Frage, warum ich das gemacht habe. Andererseits ist man wesentlich entspannter ein System neu aufzubauen, wenn man weiß, dass man ein funktionierendes System in der Hinterhand hat.

Hauptgrund war, dass es seit Februar 2022 auch offiziell ab dem Raspberry 3 und 4 eine 64-bit Version des Betriebssystems gibt und ich zum einen denke, dass dies auf lange Sicht dann eh irgendwann mal eine Umstellung bedarf und angeblich die 64bit-Version schneller laufen soll.
Neben der Möglichkeit 64bit Programme laufen zu lassen, soll der Geschwindigkeitsvorteil bis zu 48% betragen:
https://buyzero.de/blogs/news/antworten-auf-eure-fragen-zum-raspberry-pi-os-64-bit

Um es vorwegzunehmen - vom Speicherbedarf merke ich keinen Unterschied. Bei der Geschwindigkeit habe ich manchmal den Eindruck, es würde ein bisschen flüssiger laufen, aber kann auch Einbildung sein. Jedenfalls ist der Unterschied nicht so gravierend, wie 48% vermuten lassen.

Doch bevor ich hier über meine Erfahrungen berichte und vielleicht ein paar Tipps geben kann, muss ich ja erst mal vorstellen, was auf meinem Raspberry Pi4 mit 4 GB läuft. Ich habe nicht soviele Adapter, aber doch einige Dienste. Das Swappen ist grundsätzlich bei mir ausgeschaltet, um die SD Karte nicht unnötig zu belasten.

Der Hauptspeicher ist mit gut 80% gut ausgelastet, muss man sich anschauen, ob man das Swappen wieder aktiviert.

Bevor ich anfange - hier mal eine Beschreibung, was auf das System drauf musste, was angepasst werden musste und meine einzelnen Schritte.

Auch wenn es hier verpönt wird, weil man ja einen Headless Server in der Regel betreibt, hängt bei mir ein Bildschirm am Raspberry, der mir den Status des Systems anzeigt und deshalb einen Browser und Desktop benötigt. Der Bildschirm ist aber im Stand-By (dunkel) und wird über einen Bewegungsmelder gesteuert, so dass dieser nur an ist, wenn sich jemand in dem Zimmer bewegt.
Ich will auch keine Diskussion darüber führen, ob das nun sinnvoll ist oder nicht.

So was musste also wieder auf das System drauf:

1. Desktop OS Raspbian mit xrdp
2. Zugriff auf Windows Systeme zur Sicherung von einzelnen Dateien und ggf. Datenaustausch vom Raspberry aus,
3. MySQL Installation mit Konfiguration, dass Datenbanken auf externem USB-Stick gespeichert werden und nicht auf der SD-Karte
4. mqtt-Broker mit mosquitto und verschlüsselter Verbindung zu einer externen mqtt-Bridge für owntracks Kommunikation
5. FHEM Installation zur Ansteuerung der MAX-Cubes (Hauptgrund), aber auch als Systemmonitor (SYSMON) für beide Raspberries. ssh Remote für Zugriff auf entfernten Raspberry
6. iobroker Installation und Recovery mit BackitUp und Remote ssh für Zugriff auf entfernten Raspberry
7. Zigbee2Mqtt Installation
8. Firefox Installation als präferierter Browser für das NodeRed Dashboard.
9. Abschließende Arbeiten

So nun zu den einzelnen Phasen und ein paar Dinge, die ich gemacht habe, weil ich sie als nützlich empfunden habe. Auch wenn ich mit den nächsten Aussagen hier wieder anderer Meinung als so mancher hier an Board bin, ist es praktisch die /root Partition klein zu halten. Bei mir sind es nur 16 GB SD Karten, die aber auch nur zur Hälfte gefüllt sind. Es war goldwert nach diesen Phasen immer wieder mit einem Image abzusichern. Ich hatte 11 Images und schon ist man so bei ca. 160 GB, das man zur Verfügung haben sollte. Mit dem Win32 Disk Imager, war so ein Image auf meinem Hochleistungslaptop jeweils in gut 3 Minuten fertig. Grundsätzlich sogut der apt Paketmanager zwar funktioniert, löscht man aber ein Verzeichnis, bekommt man fehlerhaft installierte Pakete nicht mehr aus dem System. Wenn man ca. 15 Minuten probiert hat, ist es effizienter wieder auf das letzte Image zurückzuladen und neu anzufangen. Ich habs jedenfalls mehrfach nicht geschafft, sowas wieder aus dem System zu bringen - da bin ich zu sehr Linux Laie, obwohl ich ja schon immer besser werde.

So nun zu den einzelnen Phasen und was dort alles gemacht wurde:

1. Desktop OS Raspbian mit xrdp

Im Gegensatz zu dem oben verlinkten Bericht, ist die 64 Bit Version vom Raspbian keine Betaversion, sondern wird offiziell unterstützt und angeboten. Wie immer nicht von irgendwelchen dubiosen Links oder Videos runterladen, sondern immer das Original: https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-64-bit

Das Archiv wird gepackt heruntergeladen und ist ca. 800 MB groß. Daraus einfach das Image rauskopieren, ist dann ca. 4,5 GB groß.

Kann man dann auch mit dem Win32Disk Imager auf die SD Karte schreiben. Leeres ssh File drauf machen und booten.
Nach dem Einstellen der persönlichen Bedürfnisse und Länder- und Spracheinstellungen habe ich noch folgendes gemacht:

• als erstes Hostname ändern (damit dieser nicht in irgendwelchen Konfigurationsdateien verewigt wird und man dann einen hohen Aufwand hat, alle möglichen Dateien zu editieren.
• bei den neuen Installationen muss mit orca -s auch noch die Ansagen ausschalten. War total ungewohnt, dass nach der Installation jemand alles auf dem Bildschirm vorliest.
• nachdem sich die Installation einfach den restlichen Speicherplatz krallt, habe ich anschließend über einen Paritition Manager die Partitionen wieder so verkleinert, dass ca. 500 MB nicht genutzt werden, so dass die Images auch auf verschiedene Marken von SD Karten passt.
  
• das Swappen wird wie gesagt abgeschaltet und geht ziemlich einfach in dem man den Service stoppt und disabled:
  deinstalliert wurde nichts, so dass man bei Bedarf das auch wieder leicht aktivieren kann.

sudo systemctl stop dphys-swapfile
sudo systemctl disable dphys-swapfile

• anschließend wurde wie gesagt xrdp installiert und ein user angelegt, den man für die RDP Kommunikation nutzt. Habe ich ja schon mal geschrieben, dass das nun erforderlich ist. Was mich etwas Zeit gekostet hatte, dass ich den User am Anfang ohne Home-Directory erstellt hatte, das ist aber erforderlich, damit sich der Desktop aufbauen kann. Eigene Blödheit, aber ich habs ja nun aufgeschrieben.

2. Zugriff auf Windows Systeme zur Sicherung von einzelnen Dateien und ggf. Datenaustausch vom Raspberry aus,

• der Zugriff auf die übrigen Resource ist relativ einfach gewesen, indem man einfach die entsprechenden Einträge aus einer bestehen fstab kopiert und ggf. die Windows Credentials in einer eigenen Datei abgespeichert sind.
• USB Stick permanent als Datenträger für Daten eingebunden

3. MySQL Installation mit Konfiguration, dass Datenbanken auf externem USB-Stick gespeichert werden und nicht auf der SD-Karte

• Installiert wird das einfach mit

sudo apt install mariadb-server

• das Umbiegen auf einen externen Datenträger ist etwas mehr tricky. (musste ich auch 2 mal machen ) Nach der Installation das /var/lib/mysql in das neue Verzeichnis kopieren. Dann kann man auch direkt die alten Datenbanken in das Verzeichnis kopieren. Ich habe bewusst 2 Verzeichnisse auf dem USB Stick gehabt, sodass man beiden Installationen (32bit und 64 bit) auf unterschiedliche Verzeichnisse zugreift und sich nichts zerschiesst.
  In dem Verzeichnis: /etc/mysql/mariadb.conf.d dann einfach die 50-server.cnf bearbeiten und dort das data-dir umbiegen und die lokale Bindung auskommentieren, wenn man von anderen Maschinen auf die Datenbank zugreifen will. - Damit war das auch erledigt.

4. mqtt-Broker mit mosquitto und verschlüsselter Verbindung zu einer externen mqtt-Bridge für owntracks Kommunikation

• das klappte auch gut: Mit sudo apt mosquitto installieren und dann einfach alle Konfigurationsdateien auf /etc/mosquitto mit den Unterverzeichnissen kopieren. Dort sind auch die Verschlüsselungszertifikate für die Kommunikation mit der Bridge enthalten.

5. FHEM Installation

• das hat mich auch mindestens 3 Anläufe gekostet, da ich mir immer den Paketmanager kaputt gemacht habe und ich dann die Verweise auf kaputte Pakete nicht mehr entfernt bekam.
• großes Problem, dass ich FHEM nicht mehr so wie vor 3 Jahren installieren konnte, war dass apt-key nicht mehr unterstützt wurde bzw. mir dann wieder eine Anleitung gefehlt hat, die die entsprechenden Schlüssel zur Verfügung stellte. Anleitungen mit dkpg kann man auch vergessen, da fehlen dann wieder Bibliotheken, die vorher installiert sein müssen usw. - alles Murks.
• Für die es interessiert hier eine Anleitung mit der es gut funktioniert hat:

apt update
apt install gpg
wget -O- https://debian.fhem.de/archive.key | gpg --dearmor > /usr/share/keyrings/debianfhemde-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/debianfhemde-archive-keyring.gpg] https://debian.fhem.de/nightly/ /" >> /etc/apt/sources.list
apt update
apt install fhem

• Danach sind der User fhem angelegt und die Services definiert - sodass man nichts mehr machen muss. Alle anderen Installationsmethoden waren für mich nicht brauchbar. Und wie gesagt das apt-key was man in älteren Anleitungen findet, funktioniert nicht mehr.
• Dann wollte ich die rsa key für die remote ssh Kommandos generieren. Habe ich als user fhem gemacht, wurde im Homeverzeichnis von fhem gemacht (das ist das /opt/fhem) Verzeichnis, usw. . Es funktionierte einfach nicht. ssh Schlüssel nicht gefunden. Dann wirklich das .ssh Verzeichnis kopiert und in händisch in das /opt/fhem Verzeichnis kopiert. Dann muss man aber wieder die Rechte anpassen. Die id_rsa (also der private Schlüssel) darf nur für den user zugreifbar sein. Also sudo chmod 600 id_rsa im /opt/fhem/.ssh Verzeichnis. - Man könnte das Backup zwar anpassen, aber generell wird halt nicht das ganze fhem Bezeichnis gesichert.
• Ansonsten einfach mit dem tar Befehl das ganze /opt/fhem Verzeichnis überschreiben. Es sind alle Geräte und Parameter wieder vorhanden. Ist ja zum größten Teil eh in der fhem.cfg

=================================================================================

6. iobroker Installation und Recovery mit BackitUp und Remote ssh für Zugriff auf entfernten Raspberry

So das ist sicher der interessanteste Teil.

• Die Installation mit dem Einzeiler hat wirklich gut funktioniert und auch nodejs, npm wurde in den empfohlenen Versionen herunter geladen:

curl -sLf https://iobroker.net/install.sh | bash -

• Was ich nicht mehr in Erinnerung hatte, war dieser Assistent beim ersten Start vom iobroker und wofür man ein Administratorpasswort eingeben musste, auch wenn ich keine Authentisierung verwende.
• Dann noch den Discovery Adapter deinstalliert und den Restore angestossen via BackitUp Adapter.
• Ich habe nun nicht viele Adapter installiert, sodass es wohl mit steigender Anzahl ggf. auch mehr Probleme zu erwarten sind:

iobroker update
Used repository: Stable (default)
Adapter    "admin"        : 5.3.8    , installed 5.4.9
Adapter    "backitup"     : 2.4.10   , installed 2.4.10
Adapter    "dwd"          : 2.8.3    , installed 2.8.3
Adapter    "flot"         : 1.11.0   , installed 1.11.0
Adapter    "info"         : 1.9.19   , installed 1.9.19
Adapter    "javascript"   : 5.7.0    , installed 5.7.0
Controller "js-controller": 4.0.23   , installed 4.0.23
Adapter    "linux-control": 1.1.3    , installed 1.1.3
Adapter    "mercedesme"   : 0.0.56   , installed 0.0.56
Adapter    "mqtt"         : 3.0.6    , installed 4.0.7
Adapter    "node-red"     : 3.3.1    , installed 3.3.1
Adapter    "pi-hole"      : 1.3.4    , installed 1.3.4
Adapter    "ping"         : 1.5.3    , installed 1.5.3
Adapter    "simple-api"   : 2.7.0    , installed 2.7.0
Adapter    "socketio"     : 4.2.0    , installed 4.2.0
Adapter    "sql"          : 2.1.7    , installed 2.1.7
Adapter    "tr-064"       : 4.2.16   , installed 4.2.16
Adapter    "vis"          : 1.4.15   , installed 1.4.15
Adapter    "vis-hqwidgets": 1.2.0    , installed 1.2.0
Adapter    "web"          : 4.3.0    , installed 4.3.0
Adapter    "ws"           : 1.3.0    , installed 1.3.0
Adapter    "yahka"        : 0.13.1   , installed 0.13.1

• Etwas gewöhnungsbedürftig ist, dass nachdem der Restore als complete angezeigt wird, die eigentliche Adapterinstallation beginnt. Ich hatte mit 3-4 Adaptern bzw. dem Restore Probleme, wobei der Restore mit NodeRed schon am gravierensten war.

• Das erste Problem ist, dass der Adapter der Probleme macht, gar nicht in der Liste ist, da er nur auf dem Beta-Repository verfügbar ist. Es handelt sich um den sourceanalytics - Adapter. Ehrlich gesagt verstehe ich sowas nicht ganz. Im Prinzip müsste eigentlich das BackitUp sowohl das stable, als auch das beta Repository durchsuchen. Durch die Version ist ja festgelegt, was zu installieren ist. Jedenfalls muss man das Beta-Repository anhaken, aber auch dann funktioniert die Installtion nicht. Man muss eine neue Instanz von dem Adapter nach Installation erstellen. Anschließend kann die Instanz wieder gelöscht werden und der Adapter funktioniert wie er soll.

• Der zweite Problemfall war der vis Adapter, der sich einfach nicht installieren ließ - zumindest nicht in der aktuellen Version 1.4.15. Vielleicht sollte man ein Restore mit dem BackitUp mal ins Testprogramm aufnehmen, bevor die Version in das stable Repository wandert. Im Prinzip ist es nicht ganz so schlimm, weil man wirklich auf Kommandozeile eine vorhergehende Version installieren muss - wie hier empfohlen. Die Version 1.4.0 des vis-Adapters funktioniert und lässt sich dann auch problemlos updaten. Mit einer zukünftigen Version, wird dieses Problem wahrscheinlich verschwinden.

• Ein weiterer Kritikpunkt ist, dass im iobroker Home-Verzeichnis auch Dateien gesichert werden sollten. Zum Beispiel wenn ein .ssh Verzeichnis vorhanden ist. Ansonsten hat eben linux-control - Adapter ein Problem, wenn ein ssh Remote Zugriff definiert wurde. So war es am besten das .ssh Verzeichnis wieder händisch in das /home/iobroker Verzeichnis zu kopieren und wieder - analog wie zum FHEM Problem - mit sudo chmod 600 id_rsa im /home/iobroker/.ssh Verzeichnis die Rechte anzupassen.

• Der nächste Problemfall war der vis-materialdesign - Adapter. Diesen Adapter gibt es schlicht und ergreifend nicht mehr und ließ sich nicht mehr wiederherstellen. Ich denke, dass es dafür einen Nachfolger mit anderem Namen gibt, aber ist halt vielleicht doch dumm, wenn man auf den Adapter angewiesen ist. da ich kaum was mit vis mache, habe ich den Adapter halt gelöscht.

• So nun zum Node-Red Adapter. Seit der Version 3.3.1 kann man Node-Red ja auch in mehreren Instanzen installieren, was sehr praktisch ist. So habe ich eine Instanz als Testinstanz, die ich im Gegensatz zur Projektfunktion ja nun parallel betreiben kann. Die Testinstanz von Node-Red hat nicht mit der Projektfunktion gearbeitet, die Hauptinstanz hatte die Node-Red Projektfunktion aktiviert. So um es gleich vorweg zunehmen: Diejenigen, die die Node-Red Instanz ohne Projektfunktion betreiben, haben kein großes Problem. Die Flows wurden wiederhergestellt, allerdings könnte man das nun doch anwenderfreundlicher machen.

Diesen Zwang sich zwischen dem Pallettenmanager oder die module in die Adapterkonfiguration einzutragen zu entscheiden, verstehe ich ehrlich gesagt nicht. Ich verstehe zwar, dass man die nodejs module nicht zum Bestandteil des Backups macht, allerdings könnte man die package.json sichern und anschließend ein npm install anschliessen. Jedenfalls habe ich das gemacht und die fehlenden Nodes wurden automatisch installiert. Ich verstehe es nicht, warum die package.json NICHT Bestandteil des Backups sind.

Das wie ursprünglich behauptet, das ganze iobroker-data Verzeichnis gesichert wird, ist jedenfalls NICHT der Fall.

So und nun leider zum traurigsten Fall: Leute, die die Projektfunktion in NodeRed aktiviert haben

SCHAUEN LEIDER komplett in die Röhre! - Es wurde nichts gesichert.

Das projects Verzeichnis, dass alle Flows enthielt war leer.
Das lib Verzeichnis, dass die eigene Flow Bibliothek enthält war leer.
Einige Nodes legen in entsprechenden Verzeichnissen Konfigurationsdaten ab - waren nicht vorhanden oder leer.
Das Projects Verzeichnis enthält zudem quasi ein lokales git Reprository indem die Verlaufsstände zur Wiederherstellung gespeichert sind - wird alles nicht gesichert.

Das geht alles verloren! In meinen Augen muss ALLES gesichert werden, ausser dem node_modules Verzeichnis. Und auch hier gilt wie oben. Wenn man die package.json mit sicher kann ein anschliessendes npm install in dem Verzeichnis alles wiederherstellen auch die fehlen Nodes:

npm ls
node-red-project@0.0.1 /opt/iobroker/iobroker-data/node-red
├── @mdi/font@5.9.55
├── node-red-contrib-bigtimer@2.8.2
├── node-red-contrib-buffer-parser@3.2.2
├── node-red-contrib-cron-plus@1.5.7
├── node-red-contrib-crypto-js@0.1.1
├── node-red-contrib-fs-ops@1.6.0
├── node-red-contrib-harmony-websocket@2.2.6
├── node-red-contrib-light-scheduler@0.0.18
├── node-red-contrib-tail-file@1.2.6
├── node-red-contrib-ui-contextmenu@2.0.1
├── node-red-contrib-ui-time-scheduler@1.17.1
├── node-red-contrib-web-worldmap@2.28.3
├── node-red-contrib-whin@0.1.15
├── node-red-dashboard@3.1.7
├── node-red-node-email@1.17.0
├── node-red-node-feedparser@0.3.0
├── node-red-node-mysql@1.0.3
├── node-red-node-ping@0.3.1
├── node-red-node-snmp@1.0.2
├── node-red-node-tail@0.3.2
├── node-red-node-ui-table@0.3.12
└── speedtest-net@2.2.0

Ausserdem ist die Datei .gitconfig aus dem /home/iobroker Verzeichnis zu sichern. Ich musste die Daten zwar nochmal eingeben, konnte dann aber in die Projekte wechseln.

So nun kommt etwas wichtiges, was kein Problem des BackitUp Adapters ist, aber das wenige auf dem Schirm haben - zumindest seit der Version 2 werden die credentials zusätzlich verschlüsselt. Wenn man also das Verschlüsselungspasswort nicht weiß, müssen alle Credentials neu angegeben werden.

In Projekten ist also das flows_cred.json nochmals verschlüsselt.

Wenn man den Schlüssel nicht mehr weiß - und ein neues Passwort vergibt sind alle Credentials weg. Was bedeutet das:

In jeder Node - die Anmeldedaten enthält in dem Flow müssen ALLE Credentials neu eingeben werden.
Dazu gehören:
alle Email Nodes
alle HTTP Request Nodes, die Basisauthentifizierung nutzen
alle Mqtt Nodes bzw. deren Konfiguration zum mqtt-Broker
alle SQL Nodes

usw.

Hat mich mindestens eine weitere Stunde gekostet, bis das wieder in Ordnung war.

So, dass ist leider das traurige an dem Zwischenfazit: Meine GANZE Logik für die Hausautomation in NodeRed abgebildet, wäre verloren, wenn ich mich nur auf den BackitUp Adapter verlassen hätte. Ich werde ggf. noch ein Issue auf gitHub aufmachen, wobei ich sicher nicht nochmal Stunden opfern würde. Im Prinzip muss einfach bis auf die Module alles gesichert werden.

=================================================================================

7. Zigbee2Mqtt Installation

Am Besten hin und wieder ein backup des Datenverzeichnis machen. Das geht auch easy über die GUI.

Ansonsten wie bei der Neuinstallation alle Schritte durchführen: https://www.zigbee2mqtt.io/guide/installation/01_linux.html#installing

Bevor man den Service startet einfach alle Dateien aus der Datensicherung (wie eben beschrieben) in das /opt/zigbee2mqtt/data Verzeichnis kopieren und anschließend den Service starten.

8. Firefox Installation

Das macht man auch am Besten über eine Paket-Installation:

sudo apt install firefox-esr-l10n-de

für die Installation des Firefox Browsers mit deutschem Sprachpaket.

Andere Sprachpakete siehe hier: https://packages.debian.org/search?keywords=firefox-esr-l10n

9. Abschließende Arbeiten

Ein iobroker fix erstellt eine iobroker Datei unter /etc/sudoers.d

Damit der iobroker user andere Services (im NodeRed Flow) managen kann, muss ggf. die iobroker Datei unter /etc/sudoers.d ändern.

Auch wenn die Meldung von dem BackitUp Adapter, dass Backups auf dem gleichen Datenträger keinen Sinn machen, prinzipiell richtig sind, sollte man die Abstellen können. Der Adapter bekommt bei mir gar nicht mit, dass er auf einem anderen device sichert, da ich einen symbolischen Link auf ein Verzeichnis auf dem USB Stick eingerichtet habe.

Dazu sich zum Benutzer iobroker wechseln und den symbolischen Link erstellen:

sudo -su iobroker
cd /opt/iobroker
mv backups backups.org
ln -s /data/backup/iobroker backups

erzeugt dann so eine Struktur

 ls -la
insgesamt 972
drwxrwxr-x+   6 iobroker iobroker   4096  9. Aug 23:47 .
drwxr-xr-x    6 root     root       4096  9. Aug 15:01 ..
lrwxrwxrwx    1 iobroker iobroker     21  9. Aug 23:47 backups -> /data/backup/iobroker
drwxrwxr-x+   2 iobroker iobroker   4096  9. Aug 09:59 backups.org
-rwxrwxrwx+   1 iobroker iobroker    237  9. Aug 20:54 INSTALLER_INFO.txt
lrwxrwxrwx    1 iobroker iobroker     22  9. Aug 20:54 iob -> /opt/iobroker/iobroker
-rwxr-xr-x+   1 iobroker iobroker    309  9. Aug 20:54 iobroker
drwxrwxr-x+  10 iobroker iobroker   4096  9. Aug 23:50 iobroker-data
drwxrwxr-x+   2 iobroker iobroker   4096 10. Aug 02:45 log
drwxrwxr-x+ 749 iobroker iobroker  24576  9. Aug 11:16 node_modules
-rw-rwxr--+   1 iobroker iobroker    155  9. Aug 20:54 .npmrc
-rw-rwxr--+   1 iobroker iobroker    746  9. Aug 11:16 package.json
-rw-rwxr--+   1 iobroker iobroker 927906  9. Aug 11:16 package-lock.json

=================================================================================
FAZIT:

So ich bin am Ende mit meiner 2 tägigen Arbeit. Ich weiß, die meisten von euch bauen Ihr System in 1 Stunde wieder auf und haben auch keine GUI auf ihren Servern.

Ich kann aber - im Nachhinein - auch wenn ich mich immer gewehrt habe, trotzdem jedem raten, mal sein System von Grund auf neu aufzubauen und das zu protokollieren . Ich muss das alles noch zusammenschreiben. Und ich bin noch nicht mal sicher, ob nicht die eine oder andere Überraschung noch auf mich wartet.

Jedenfalls ist es besser, das zu machen, wenn man noch ein funktionierendes System in der Hinterhand hat, als ggf. im Streß eines aktuellen Problemfalls.

Die 64bit Variante des OS ist bisher noch nicht so richtig spürbar. Ich hoffe jedenfalls, dass für den EINEN oder ANDEREN eine interessante Information dabei war.

[mickym]

So ich habe nun 2 Issues auf github eröffnet:

1. Bug - No restore for NodeRed instances with activated project function

https://github.com/simatec/ioBroker.backitup/issues/731

2. Feature request - Restoring NodeRed - automatically restore missing modules and data outside adapter config

Es geht ja wirklich alles verloren. Daten von spezifischen Nodetypen, aber auch das lib Verzeichnis mit eigenen Flow-Bibliotheken werden nicht zurück gesichert.

https://github.com/simatec/ioBroker.backitup/issues/730

mickym2 created this issue in simatec/ioBroker.backitup

closed No restore for NodeRed instances with activated project function #731

mickym2 created this issue in simatec/ioBroker.backitup

closed Restoring NodeRed - automatically restore missing modules and data outside adapter config #730

[mickym]

Was lässt sich sonst zur 64-Bit Version sagen.

• Also der Speicherverbrauch ist tatsächlich spürbar um einiges höher (ca. 20%) - d.h. ich komme mit 80% schon nahe an die Systemgrenzen, das war vorher so knapp unter 60%.
• Die Grundlast was die CPU Last betrifft ist identisch
• Die Lastspitzen haben jedoch wesentlich abgenommen, die sind vorher auch mal deutlich über 50% gewesen und das ist nun nicht mehr der Fall. Insofern fühlt es sich performanter an.