UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mickym]

@snowboarder2611 das macht nichts. Du kannst ruhig die Boot Partition auswählen, es wird immer ein Gesamtimage gezogen, siehst auch an der Größe des -Images.

[Snowboarder2611]

@mickym
ich kann ja unter den Laufwerken, wo ich auch meine PC Festplatte sehe, keine SSD sehen. Die USB Platte wird überhaupt nicht angezeigt.

@Homoran
Damit ich ja wieder sauber anfangen konnte, habe ich ja mein vorher aud SD laufende System (sauber gelaufen) als Clone auf die SSD bringen. Leider weiß ich nicht mehr, das genauch an Fehler da war. Ich kam zumindest nicht mehr über Web auf meine Broker Oberfläche. Leider habe ich auch nicht gefunden, wie ich, wenn ioBroker mal abgeschmiert ist, diesen neu aufsetzen soll. Denn der Broker ist nicht mehr gelaufen. Status war meiner Meinung nach, dass er nicht läuft. Auch ein manueller Start war nicht möglich. Ich dachte, man kann den Broker komplett löschen und dann neu aufsetzen ohne Pi OS.

Aber jetzt bekomme ich die Platte ja unter Windows nicht angezeigt. Erst dann könnte ich die Platte wieder Clonen.

[mickym]

@snowboarder2611 Dann musst ggf. über Deine Datenträgerverwaltung der Laufwerk oder Partition einen Laufwerksbuchstaben zuweisen.

[Thomas Braun]

@snowboarder2611 Clownen :clown_face:

Ich würde das sauber frisch auf dem Ziellaufwerk installieren, ioBroker druff, Backup rein, fertig.

BTW: Die SSD siehst du deswegen nicht (komplett), weil Windows mit dem ext4-Dateisystem von Linux nix anfangen kann.

[Homoran]

@snowboarder2611 sagte in SSD Karte als Backup Image Clonen:

ch kam zumindest nicht mehr über Web auf meine Broker Oberfläche

Ist eines der häufigsten Fragen hier im Forum Und bisher haben wir bis auf ganz wenige Ausnahmen alle Systeme wieder ans Laufen bekommen.
Insbesondere wenn die Hauptursache für diesen Fehler -ein plötzlicher Stromausfall- innerhalb kurzer Zeit danach angegangen wird und nicht vorher das System endgültig kaputtgespielt wird.
Dann ist nach 15 Minuten das System wieder da.

@snowboarder2611 sagte in SSD Karte als Backup Image Clonen:

Denn der Broker ist nicht mehr gelaufen

Alles jetzt Glaskugellesen, aber in deinem Interesse: Melde dich dann

@mickym sagte in SSD Karte als Backup Image Clonen:

Dann musst ggf. über Deine Datenträgerverwaltung der Laufwerk oder Partition einen Laufwerksbuchstaben zuweisen.

bei EXT4 kann Windoof die gar nicht sehen.
Da braucht es dann andere Linux-Lesende Programme

[mickym]

@homoran Nein einen Laufwerksbuchstaben kann man auch zuweisen - ohne das man die Partition lesen kann.

Im Übrigen ich verstehe ja das jedes Mal wenn jemand Klonen in den Mund nimmt ihr mit dem besser auf sauberem System aufsetzen kommt. Aber lasst das doch die Leute entscheiden. Wenn ich im Supermarkt nach Nudeln frage, brauche ich auch keinen Angestellten der mir erklärt das Reis gesünder ist.

Ich habe mir auch mal überlegt wieder alles von Grund auf aufzusetzen - aber im Moment habe ich zuviele Abhängigkeiten auf meinem iobroker System und das geht von der Zertifikatsverwaltung, über mosquitto, mysql Installation usw.

Das alles wieder nachzuziehen dauert immens lange - und nicht jedes Image ist unsauber, weil noch was anderes als iobroker auf dem System läuft. Es hat nicht jeder ein System mit 10 virtuellen Maschinen auf den eine nur mit dem iobroker installiert ist.

Wie gesagt, ich verstehe Euer Argument - aber man muss es auch nicht bei jedem "Clownen" wiederholen.

Wenn jemand bewußt Klonen will, dann gehe ich mal davon aus, dass er weiß was er damit tut - und ja unter Umständen auch Dinge mitnimmt, die er entweder bewußt oder auch unbewußt mitnimmt.

[Thomas Braun]

@mickym

Clownen macht aber nur wirklich Sinn, wenn das target gleich ist. Eine SD-Karte zu clonen und dann auf eine SSD zu knallen, die komplett andere Parameter hat ist wenig sinnvoll.

Jedenfalls verstehe ich den Ansatz so. Ist aber zusätzlich noch etwas wirr beschrieben.

[mickym]

@thomas-braun Gebe ich Dir Recht - ich habe auch gerade damit etwas zu kämpfen - aber auch das sollte jedem bewusst sein.
Stelle nämlich fest, dass eine 16GB SD von Sandisk größer als von Verbatim ist. ;) - Aber wie gesagt man muss halt wissen, auf was man sich einlässt. ;)

Und klar macht das was Du sagst SD auf SSD keinen Sinn. Volle Zustimmung!!!!

[Homoran]

@mickym sagte in SSD Karte als Backup Image Clonen:

Aber lasst das doch die Leute entscheiden. Wenn ich im Supermarkt nach Nudeln frage, brauche ich auch keinen Angestellten der mir erklärt das Reis gesünder ist.

es geht nicht um den gesünderen Reis, sondern das Mitschleppen von Problemen und wenn es nur (oder gerade) versteckt im Untergrund passiert.
Wenn es dann nämlich nach der Rückspülung beim nächsten mal knallt ist sich der User garantiert nicht dessen mehr bewusst. Im Gegenteil. Dann heisst es; Ich ab aber doch neu aufgesetzt und ein Backup eingespielt

[Homoran]

@mickym sagte in SSD Karte als Backup Image Clonen:

Stelle nämlich fest, dass eine 16GB SD von Sandisk größer als von Verbatim ist.

da reicht ein Bit unterschied, damit das Image nicht mehr passt. Und die Reale Größe variiert, selbst bei "ein und derselben" Karte.

[Thomas Braun]

@mickym sagte in SSD Karte als Backup Image Clonen:

Stelle nämlich fest, dass eine 16GB SD von Sandisk größer als von Verbatim ist. - Aber wie gesagt man muss halt wissen, auf was man sich einlässt.

Bei den meisten hab ich aber nicht den Eindruck, das da immer gewusst wird auf was man sich da einlässt.
Beim clon ist die boot.confi logischerweise die gleiche, muss aber ggf. auf einem anderen System anders lauten. Die blkid ist eine andere. Usw...

Deswegen macht in clon oder imaga nur bei gleicher Hardware Sinn.

[mickym]

Wie gesagt - ich will doch nicht gegen Euch argumentieren. :anguished:

Ich will doch nur Hilfestellung geben für alle die sich auf gleicher Hardware mit dem Mitschleppen von allem was bislang installiert wurde, sich zum Klonen entschlossen haben.

Deshalb für alle die, die wissen was sie tun.

Wie gesagt kann es passieren, dass wenn man von einem SD-Karten Hersteller zum anderen feststellt, dass trotz nominal gleicher Größe sich die Größen tatsächlich unterscheiden.

Bislang hat ich immer SanDisc SD Karten und da sind die 16GB Karten anscheinend größer als die von SD Karten von Verbatim. Ich habe das nun erfolgreich migriert - hier deshalb trotz allem ein kurzer Erfahrungsbericht.

Getestet und gemacht habe ich das auf einem Raspberry SD Karte mit den 2 Partitionen - der FAT Boot Partition und der ext4 Linux Partition.

1. Mit einem Partition-Manager kann man die Linux Partition verkleinern (auf originaler SanDisc SD Karte - also die größere), sofern noch freier Speicherplatz auf der Partition. Ich habe ca. 512 MB kleiner gemacht (tatsächlich habe ich nach der Aktion festgestellt, dass die Verbatim Karten ca. 120 MB geringeren Platz haben).

2. Wenn man mit dem Win32 Disk Imager - seine Images der SD Karten erstellt, dann nun unbedingt die Option Read Only Allocated Partitions - anhaken. Es wird dann kein Image der ganzen Karte sondern nur der definierten Partitionen gemacht.

Beim Erstellen sollte dann das neue Image mit der verkleinerten Partition auch kleiner sein. Hier mal meine 16 GB Images - das größere Image ist das physisch Image, das kleinere nur mit den "Allocated Partitions".

3. Das passte dann auch auf die kleinere Verbatim Karte.

4. Nach erfolgreichem Boot habe ich mir dann angeschaut, wie die Plattenplatzverteilung war:

Bei der Verbatim Karte war der freie Platz hinter der Linux Partition 512 MB - also ca. 120 MB weniger. Ist schon krass!!!

Also nur für die, die wissen, was sie tun.

[Snowboarder2611]

Ich habe jetzt ein sauberes System auf meiner SSD.
Den Clon davon möchte ich als eine Art Komplettbackup halten. Also wenn ich mal wieder mit dem Broker nicht weiter komme oder den kaputtgefrickelt habe, kann ich das Image nehmen und es wieder auf die gleiche Platte ziehen. Da es die gleiche Platte ist, sollte auch alles gut gehen.
Ich versuche morgen meider boot Partition einen Laufwerksbuchstaben zu geben, damit ich ein Image anlegen kann.
Danke schon mal für die Hilfe bis hier her.

[sonnenschein]

@snowboarder2611 sagte in SSD Karte als Backup Image Clonen:

Zur Sicherheit wollte ich jetzt einen weiteren Clone von meider SSD erstellen mit allen so weit laufenden Aktualisierungen.

Also vor kurzer Zeit stand ich auch vor dem Problem. PI 4 hatte mir immer wieder die sd Card zerschossen. Habe dann auf SSD installiert und direkt mit dem PI geklont. Im der Grafischen Oberfläche des PI gibt es ein Menü dafür. Kann grade aber nicht schauen wie es genau heißt.
Windows, so wie Du es such tun wolltest, hat bei mir nicht gedüngt.

[Homoran]

@sonnenschein sagte in SSD Karte als Backup Image Clonen:

Im der Grafischen Oberfläche des PI gibt es ein Menü dafür

Bitte nicht zu einer grafischen Oberfläche auf einem Server animieren!
Server laufen eigentlich immer headless

[Dreamboy74de]

@homoran sagte in SSD Karte als Backup Image Clonen:

@sonnenschein sagte in SSD Karte als Backup Image Clonen:

Im der Grafischen Oberfläche des PI gibt es ein Menü dafür

Bitte nicht zu einer grafischen Oberfläche auf einem Server animieren!
Server laufen eigentlich immer headless

Guten Abend,
um nicht diese PÖSE grafische Oberfläche zu benutzen ( Das Programm das es dort gibt nennt sich PiClone), geht der Weg auch übers Terminal. Auf Github gibt es dazu ein Programm RPI-Clone das sehr einfach Klone vom laufenden System erstellt.Dort ist alles sehr gut beschrieben. Ein kleiner Abriss wie vorgegangen werden müsste...Wie gesagt es wird kein Image vom System erzeugt, sondern ne lauffähige Version auf einen anderen Datenträger. In meinem Fall zum Test habe ich meinen "Sandisk Ultra Fit USB Stick 3.1 Flash 64GB" auf einen baugleichen USB-Stick transferiert.(Anmerkung: das/den Laufwerk/Stick vorher blank FAT32 formatieren, ich hatte ein fremdes Betriebssystem auf den Stick und da gab es eine Fehlermeldung mit Abbruch beim anlegen der neuen Partionen.

Und Los gehts.Terminal auf dem Raspi starten.Das rpi-clone Programm installieren mit.

$ git clone https://github.com/billw2/rpi-clone.git 
$ cd rpi-clone
$ sudo cp rpi-clone rpi-clone-setup /usr/local/sbin

Dann das Laufwerk USB-Stick oder was auch immer, an den Raspi einstecken, und mit

$ lsblk

schauen welchen Laufwerksname er bekommen hat. In meinem Fall ist sda der Stick von dem gebootet wurde, und sdb wo die Kopie dann drauf soll.
Mit der Anweisung..

$ sudo rpi-clone sdb

gehts auch schon fast los. Ich habe die Frage übersprungen bei Optional ...file system label, da ich keine Labelnamen verwende. Nach 13:44 Minuten war er dann für das Erstellen das neuen Klone fertig.Raspi runterfahren...Alten USB-Stick raus... Raspi wieder an Strom und durchstarten.
Anbei noch der komplette Terminalauszug zum nachvollziehen der Schritte.

pi@rasppione:~ $ git clone https://github.com/billw2/rpi-clone.git
Klone nach 'rpi-clone' ...
remote: Enumerating objects: 180, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 180 (delta 0), reused 1 (delta 0), pack-reused 176
Empfange Objekte: 100% (180/180), 98.77 KiB | 455.00 KiB/s, Fertig.
Löse Unterschiede auf: 100% (68/68), Fertig.
pi@rasppione:~ $ cd rpi-clone
pi@rasppione:~/rpi-clone $ sudo cp rpi-clone rpi-clone-setup /usr/local/sbin
pi@rasppione:~/rpi-clone $ rpi-clone
rpi-clone needs to be run as root.

pi@rasppione:~/rpi-clone $ sudo rpi-clone
No destination disk given.

usage: rpi-clone sdN {-v|--verbose} {-f|--force-initialize} {-f2}
         {-p|--p1-size size} {-u|--unattended} {-U|--Unattended} {-q|--quiet}
         {-s|--setup host} {-e|--edit-fstab sdX } {-m|--mountdir dir }
         {-L|--label-partitions label} {-l|--leave-sd-usb-boot}
         {-a|--all-sync} {-F|--Force-sync} {-x} {-V|--version}
         {--convert-fstab-to-partuuid}
         {--exclude=PATTERN} {--exclude-from=FILE}

    -v	    - verbose rsync, list all files as they are copied.
    -f	    - force initialize the destination disk by imaging the booted disk
                partition structure.  File systems are then synced or imaged.
    -f2	    - force initialize only the first 2 partitions to the destination.
                So a multi partition USB boot can initialize clone back to
                a 2 partition SD card.
    -p size - resize destination partition 1 to 'size' bytes. For two partition
                initialize (when first clone to blank disk or using -f2 or -f).
                Use 'sizeM' for MiB size units. eg -p 256M equals -p 268435456
    -u	    - unattended clone if not initializing.  No confirmations asked,
                but abort if disk needs initializing or on error.
    -U      - unattended even if initializing. No confirmations asked,
                but abort only on errors.
    -q      - quiet mode, no output unless errors or initializing. Implies -u.
    -s host - add 'host' to args passed to script rpi-clone-setup and run it
                after cloning but before unmounting partitions. For setting
                clone disk hostname, but args can be what the script expects.
                You can give multiple '-s arg' options.
    -e sdX  - edit destination fstab to change booted device names to new
      	        device 'sdX'.  This is Only for fstabs that use device names.
                Used for setting up a USB bootable disk.
    -m dir  - Add dir to a custom list of mounted directories to sync.  Then
                the custom list will be synced instead of the default of all
                mounted directories.  The root directory is always synced.
                Not for when initializing.
    -L lbl  - label for ext type partitions.  If 'lbl' ends with '#', replace
                '#' with a partition number and label all ext partitions.
                Otherwise, apply label to root partition only.
    -l      - leave SD card to USB boot alone when cloning to SD card mmcblk0
                from a USB boot.  This preserves a SD card to USB boot setup
                by leaving the SD card cmdline.txt using the USB root.	When
                cloning to USB from SD card this option sets up the SD card
                cmdline.txt to boot to the USB disk.
    -a      - Sync all partitions if types compatible, not just mounted ones.
    -F      - force file system sync or image for some errors. eg:
                If source used > destination space error, do the sync anyway.
                If a source partition mount error, skip it and do other syncs.
    -x      - use set -x for very verbose bash shell script debugging
    -V      - print rpi-clone version.

  Clone a booted file system to a destination disk which is bootable.

  The destination disk is a SD card (USB card reader) or USB disk 'sdN' plugged
  into a USB port.  The 'sdN' name should be a full disk name like sda and not
  a partition name like sda1.  rpi-clone works on a Raspberry Pi and can work on
  other systems.  For a destination disk that shows up as sda, run:

    $ sudo rpi-clone sda

  Clones can be from a booted SD card or USB disk.  For a description, example
  clone runs and example usage of above options, see the README.md at:

      https://github.com/billw2/rpi-clone

  A line logging a rpi-clone run is written to /var/log/rpi-clone.log.

  Download:
    git clone https://github.com/billw2/rpi-clone

pi@rasppione:~/rpi-clone $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    1 57,3G  0 disk 
├─sda1   8:1    1  256M  0 part /boot
└─sda2   8:2    1 57,1G  0 part /
pi@rasppione:~/rpi-clone $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    1 57,3G  0 disk 
├─sda1   8:1    1  256M  0 part /boot
└─sda2   8:2    1 57,1G  0 part /
sdb      8:16   1 57,3G  0 disk 
├─sdb1   8:17   1  3,9G  0 part /media/pi/CAINE 12
└─sdb2   8:18   1  2,3M  0 part 
pi@rasppione:~/rpi-clone $ sudo rpi-clone sdb

Booted disk: sda 61.5GB                    Destination disk: sdb 61.5GB
---------------------------------------------------------------------------
Part      Size    FS     Label           Part   Size    FS  Label
1 /boot   256.0M  fat32  --                                   
2 root     57.1G  ext4   rootfs          2        2.0M  --  --
---------------------------------------------------------------------------
== Initialize: IMAGE partition table - FS types conflict ==
1 /boot               (49.0M used)   : MKFS  SYNC to sdb1
2 root                (8.1G used)    : RESIZE  MKFS  SYNC to sdb2
---------------------------------------------------------------------------
Run setup script       : no.
Verbose mode           : no.
-----------------------:
** WARNING **          : All destination disk sdb data will be overwritten!
-----------------------:

Initialize and clone to the destination disk sdb?  (yes/no): y
Optional destination ext type file system label (16 chars max): 

Initializing
  Imaging past partition 1 start.
  => dd if=/dev/sda of=/dev/sdb bs=1M count=8 ...
  Resizing destination disk last partition ...
    Resize success.
  Changing destination Disk ID ...Error: Partition(s) 1, 2 on /dev/sdb have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

  => mkfs -t vfat -F 32  /dev/sdb1 ...
  => mkfs -t ext4  /dev/sdb2 ...

Syncing file systems (can take a long time)
Syncing mounted partitions:
  Mounting /dev/sdb2 on /mnt/clone
mount: /mnt/clone: special device /dev/sdb2 does not exist.
    Mount failure of /dev/sdb2 on /mnt/clone.
Aborting!
pi@rasppione:~/rpi-clone $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    1 57,3G  0 disk 
├─sda1   8:1    1  256M  0 part /boot
└─sda2   8:2    1 57,1G  0 part /
sdb      8:16   1 57,3G  0 disk 
└─sdb1   8:17   1  3,9G  0 part /media/pi/CAINE 12
pi@rasppione:~/rpi-clone $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    1 57,3G  0 disk 
├─sda1   8:1    1  256M  0 part /boot
└─sda2   8:2    1 57,1G  0 part /
sdb      8:16   1 57,3G  0 disk 
└─sdb1   8:17   1  256M  0 part /media/pi/FAT32
pi@rasppione:~/rpi-clone $ sudo rpi-clone sdb

  Destination disk partition /dev/sdb1 is mounted on /media/pi/FAT32.
  The clone cannot proceed unless it is unmounted.
Do you want to unmount /media/pi/FAT32?  (yes/no): yes

Booted disk: sda 61.5GB                    Destination disk: sdb 61.5GB
---------------------------------------------------------------------------
Part      Size    FS     Label           Part   Size    FS     Label
1 /boot   256.0M  fat32  --              1      256.0M  fat32  --
2 root     57.1G  ext4   rootfs                                  
---------------------------------------------------------------------------
== Initialize: IMAGE partition table - partition number mismatch: 2 -> 1 ==
1 /boot               (49.0M used)   : MKFS  SYNC to sdb1
2 root                (8.1G used)    : RESIZE  MKFS  SYNC to sdb2
---------------------------------------------------------------------------
Run setup script       : no.
Verbose mode           : no.
-----------------------:
** WARNING **          : All destination disk sdb data will be overwritten!
-----------------------:

Initialize and clone to the destination disk sdb?  (yes/no): yes
Optional destination ext type file system label (16 chars max): 

Initializing
  Imaging past partition 1 start.
  => dd if=/dev/sda of=/dev/sdb bs=1M count=8 ...
  Resizing destination disk last partition ...
    Resize success.
  Changing destination Disk ID ...
  => mkfs -t vfat -F 32  /dev/sdb1 ...
  => mkfs -t ext4  /dev/sdb2 ...

Syncing file systems (can take a long time)
Syncing mounted partitions:
  Mounting /dev/sdb2 on /mnt/clone
  => rsync // /mnt/clone with-root-excludes ...
  Mounting /dev/sdb1 on /mnt/clone/boot
  => rsync /boot/ /mnt/clone/boot  ...

Editing /mnt/clone/boot/cmdline.txt PARTUUID to use a9928495
Editing /mnt/clone/etc/fstab PARTUUID to use a9928495
===============================
Done with clone to /dev/sdb
   Start - 19:49:18    End - 20:03:02    Elapsed Time - 13:44

Cloned partitions are mounted on /mnt/clone for inspection or customizing. 

Hit Enter when ready to unmount the /dev/sdb partitions ...
  unmounting /mnt/clone/boot
  unmounting /mnt/clone
===============================

pi@rasppione:~/rpi-clone $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    1 57,3G  0 disk 
├─sda1   8:1    1  256M  0 part /boot
└─sda2   8:2    1 57,1G  0 part /
sdb      8:16   1 57,3G  0 disk 
├─sdb1   8:17   1  256M  0 part 
└─sdb2   8:18   1 57,1G  0 part 
pi@rasppione:~/rpi-clone $ 

Hoffe das der eine oder andere diese kleine Anleitung als hilfreich sieht. ;-)

[Tobi68]

Hallo,

ich muss in diesen Beitrag auch einsteigen da ich am Sonntag auch eine nicht mehr funktionierende IOBroker Installation hatte und mir eigentlich genau die gleiche Frage wie @Snowboarder2611 gestellt habe.
Hatte nen guten support bekommen, der hatte aber leider auch nichts mehr viel retten können, meine SSD war irgendwie schreibgeschützt..
Leider ist mein letztes Backitup auch erst vom 28.12, habe bis jetzt noch nicht verstanden warum, normaler Weise wurden alle 3 Tage Backups gemacht.. aber egal.
Habe jetzt ne neue RPI4 Installation, 64 bit System, 8GB Ram auch verfügbar.

Ich habe auch feststellen müssen das ich leider auch nicht alles im Backit up angehakt hatte, wurde halt vor nem Jahr als erstes eingerichtet.. Danach habe ich doch nicht mehr daran gedacht was alles ins Backup gehört.
Redis und Telegram, Influx Grafana.. hatte ich doch in den ersten 2 Monaten keine Ahnung von.
Aber selbst wenn ich mit den Experten abklären kann was hier alles wichtig fürs Backup ist, werden wohl alle Konsolenbefehle (die ich mangels Linux Kennnissen gar nicht kenne) die für die ein oder anderen Adapter, oder einfach für das Setup notwendig sind nicht in das Backitup Backup fließen..
Sehe ich das richtig?

Ich habe leider auf SSD umgestellt, bei SD Karte hätte ich einfach ne zweite SD die einmal im Monat geklont wird und parallel die Backups vom Backit up..

Ich denke deswegen echt darüber nach mir ne zweite SSD anzuschaffen und mittels einem USB Adapter genau das auch mit der SSD zu machen.
Ich habe das Argon one M2 Gehäuse, das bringt die SSD ja über USB3 Brücke zum RPI, kann ich dort nicht auch irgendeine USB3 Festplatte zum clonen einrichten? ZB einmal im Monat per Script manuell ausgelösst?

Ist das eine Variante für Leute wie mich die nicht jeden Linux Befehl erst mal nachschlagen müssen..
Oder habe ich da einen Denkfehler oder gibt es eine einfachere Variante?
Nächste Frage:
Was gehört alles ins Backitup?
Homematik MySql, PostgreeSQL, Zigbee, Jarvis und Yakka nutze ich nicht..

Redis bin ich mir unsicher (glaube mein KNX Adapter arbeitet damit)

Bei Grafana und InfluxDB komme ich schon ins schwimmen..
Der Adapter InfluxDB war in der Datensicherung vom 28.12, ich bekomme den aber nicht grün Grafana ist auch nicht mehr da..
Eigentlich hatte ich das alles an einem Tag installiert.
Ist das solch ein Fall das Sachen die über die Konsole installiert werden per BackitUp nicht gesichert werden?
Oder hatte damals einfach der Haken gefehlt?

Im Moment verstehe ich nicht warum Blockly Sripte die KNX Objekte steuern sollen nichts steuern obwohl sie laufen..
Das ist auch so ein Fall, aber da werde ich @chefkoch009 drauf ansprechen.

[da_Woody]

@snowboarder2611 sagte in SSD Karte als Backup Image Clonen:

Aber jetzt bekomme ich die Platte ja unter Windows nicht angezeigt. Erst dann könnte ich die Platte wieder Clonen.

jedes, noch so mickrige, partitions tool zeigt dir das ding an. da kannst auch clonen.

[Thomas Braun]

@tobi68

Eigentlich relativ einfach. Das Backup nimmt nur die Nutzlast mit, also die reine Datenbank z.B. bei influx.
Den 'Rahmen' installiert man nach. Hilfreich sind da z.B. Notizen oder in das LogFile schauen. Wenn da was fehlt wird das in der Regel irgendwie kenntlich gemacht.

[Tobi68]

@thomas-braun sagte in SSD Karte als Backup Image Clonen:

@tobi68

Eigentlich relativ einfach. Das Backup nimmt nur die Nutzlast mit, also die reine Datenbank z.B. bei influx.
Den 'Rahmen' installiert man nach. Hilfreich sind da z.B. Notizen oder in das LogFile schauen. Wenn da was fehlt wird das in der Regel irgendwie kenntlich gemacht.

Thomas, es ist für Einsteiger (ich bin jetzt auch schon ein Jahr dabei) diesen "Rahmen" einzuschätzen.
zb. bin ich derzeit dabei mit mittels dem gekauften Kurs von Verdahtet über Grafana und Influx wieder alles einzurichten.
Ja diesmal schreibe ich alles im Notepad mit um im Fall der Fälle es nochmal schneller hinzubekommen, es soll ja auch schon mal vorkommen das auch solche Inhalte einfach nicht mehr online sind.
Und die ganze Arbeit im Putty, die für euch ein Kinderspiel ist ist für viele einfach eine sehr Mühselige unangenehme Sache.
Wer tippt schon gerne Befehle ein, deren Bedeutung einem nicht klar ist..

Deswegen die Frage die auch @Snowboarder2611 hatte, nach einer Lösung für ein Backup von dem kpl. System.
Ist mein Ansatz SSD monatlich Clonen und den Rest per BackitUp zu regeln praktikabel?
Für die Profis mit Sicherheit nicht, aber für unsereins machbar, ist ca. ne Stunde Arbeit, kostet max 80 euro und ich habe 100% ige Ausfallsicherheit, zumindest ist das mein Gedanke.
Wäre schön wenn mir das wer bestätigen könnte..
So, werde ich jetzt wieder 3 Wochen brauchen um die Kiste wieder auf dem Stand vom Samstag zu haben..
Sowas möchte ich einfach vermeiden, die Tage werden schon wieder länger und das Smarthome rückt für viele wieder nach hinten von der Prioritätenliste..