raspiBackup: sda1 auf sda2 sichern krieg ich nicht auf die Palette..

  • Hallo,
    mein rpi3 startet von SD, booted dann aber von sda1 (auf einer SSD). Also so wie man das mit den rpi1/2 gemacht hat, bevor es den neuen Bootloader für den rpi3 gab.
    Nun möchte ich mit dem raspiBackup die rootpartition (also sda1) per dd in ein Verzeichnis in sda2 sichern.
    Das bekomme ich nicht hin. Es wird immer die SD-Karte in das Backup geschrieben. Kann mir mal jemand die dafür benötigten Parameter mitteilen, bitte?
    Kiefer

  • raspiBackup: sda1 auf sda2 sichern krieg ich nicht auf die Palette..? Schau mal ob du hier fündig wirst!

  • Wie schaut denn dein /etc/fstab aus und was kommt raus wenn du 'df -h' machst? Wie siht dein /boot/cmdline.txt aus ?

    Ich boote von einem USB-Stick und habe auf /dev/sda1 das bootfverzeichnis /dev/boot (was eine Kopie von der SD ist) und auf /dev/sda2 ist das Betriebssystem.

    Wenn du die SSD mit sda1 als root verwenden willst muß das in fstab und in cmdline.txt richtig eingetragen sein.

    Frank

    Nach 35 Jahren im IT business hab ich mit Raspi mal selbst zum Programmieren begonnen...
    Habe auch einen 3D-Drucker, eine CNC-Fräse und etwas Elektronik-Bastelei als Hobby

  • Ich verwende die SSD ja bereits wie beschrieben:
    von sda1 wird gebootet, sda2 mounte ich bevor ich mit raspiBackup das Image ziehen will. Und ich kann dann auch in die gemountete Partition / den Ordner unter dem gemauntet ist schreiben. Und raspiBackup schreibt ja auch rein, halt nur die flasche Sourcepartition.

    Aber zu deinen Fragen
    df -h (alle unwichtige was mein netz betrifft entfernt):
    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
    /dev/root 9,9G 6,1G 3,3G 65% /
    devtmpfs 459M 0 459M 0% /dev
    tmpfs 463M 0 463M 0% /dev/shm
    tmpfs 463M 6,5M 457M 2% /run
    tmpfs 5,0M 4,0K 5,0M 1% /run/lock
    tmpfs 463M 0 463M 0% /sys/fs/cgroup
    tmpfs 10M 156K 9,9M 2% /var/log/openhab2
    /dev/mmcblk0p1 63M 21M 43M 34% /boot
    tmpfs 93M 0 93M 0% /run/user/1000


    fstab;
    tmpfs /var/log/openhab2 tmpfs defaults,noatime,nosuid,mode=0777,size=10m 0 0

    proc /proc proc defaults 0 0
    /dev/mmcblk0p1 /boot vfat defaults 0 2
    /dev/mmcblk0p2 / ext4 defaults,noatime 0 1


    cmdline.txt:
    dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

    Ich hoffe du hast ne Idee......
    Danke

  • Ok, ich kenn deine SD nicht aber dein Root-filesystem (/dev/root) hat nur 9,9GB was für eine SD etwas klein ist.

    Dein fstab enthält einen Fehler:
    /dev/mmcblk0p2 / ext4 defaults,noatime 0 1
    (also das root-verzeichnis) zeigt auf die SD und nicht auf /dev/sda1! Also eher so ausschauen:
    /dev/sda1 / ext4 defaults,noatime 0 1

    Bitte schreib das NICHT in den fstab bevor du sicher bist dass auf sda1 auch wirklich dein Betriebssystem ist! Denn wenn nicht dann wirst auf irgend eine alte Version booten die du mal installiert hast (oder eben nicht richtig).

    Wenn du im cmdline.txt root=xxx machst muss das mit dem fstab (auf xxx/etc/fstab) übereinstimmen.

    Also es könnte sein dass deine Konfig zwar den kernel von sda1 ladet aber dann das Betriebssystem wieder auf die SD hängt.

    p.s.: Wenn du ein Raspi-3 hast und wenn du Jessie diesem Jahr verwendest, warum bootest du dann überhaupt noch von der SD (mmcblk?)? Ich hab die alle rausgenommen...
    Bei mir schaut der boot von dem USB-stick so aus (auf dem stick ist sda1 dass boot und sda2 das root-verzeichnis):

    oh ja, ich mach das Backup nicht auf den Stick sondern auf das das NAS an der Fritz.Box.

    Und noch was, warum ich keine SSD verwend ist dass die Raspi's über USB (und Netzwerk) nur maximal ~30MB/s übertragen können da sie nur USB 2.0 haben. Damit sind meine USB 3.1 Sticks sicher nicht ausgelastet und die SSD noch weniger. Gegenüber der SD ist das System ca doppelt so schnell mit meinem USB-sticks aber egal ob ich eine SSD oder einen USB-stick einsetzte wird es nicht schneller. Nur die Kapazität würde einen Unterschied bedeuten aber da hab ich noch nie mehr als 8gb verbraten und die 32/64 GB sticks kommen damit gut durch.

    Frank

    Nach 35 Jahren im IT business hab ich mit Raspi mal selbst zum Programmieren begonnen...
    Habe auch einen 3D-Drucker, eine CNC-Fräse und etwas Elektronik-Bastelei als Hobby

    Einmal editiert, zuletzt von fjoke (25. Februar 2017 um 23:57)

  • Danke für den Hinweis mit der fstab. Hab ich geändert:

    proc /proc proc defaults 0 0
    /dev/mmcblk0p1 /boot vfat defaults 0 2
    /dev/mmcblk0p2 / ext4 defaults,noatime 0 1

    Neu gebootet, sieht alles gleich aus. Leider fällt auch das Backup gleich aus. Es ist eine Kopie der SD-Karte.
    Und ja, ich bin mir sicher, das ich auf der SSD (sda1) arbeite. Im moment ziehe ich Backups indem ich die SSD an eine VM mit Suse Leap hänge und da per gparted nachsehe was drauf ist und mit dd ein Backup ziehe.

    Warum SSD?
    Die SD-Karten gehen ja wohl häufiger kaputt. Also auf USB-Stick gewechselt. Da ich aber openhab und ne influxdb drauf laufen habe, wird viel auf den Stick geschrieben. Ausserdem läuft mir schonmal der Speicher voll, so das ins SWAP-file geschrieben wird. Und dann wirds langsam und es wird wieder jede Menge auf den Stick geschrieben, was dem halt auch nicht gut tut.
    Die SSD hat auch cache an Board, der für solche Schreibvorgänge ja genutzt wird. Also erstmal da sammeln (z.B. was so von der influxdb geschickt wird) und dann gesammelt in die Flashzellen schreiben. Sollte also besser für das Flash sein, ausserdem muss nicht alles was in die SWAP geht auch in die Flashzellen.
    Soweit meine Theorie, bin für andere Meinungen offen.
    Ausserdem hatte die SSD noch ein Kumpel rumliegen, sodas die mich noch weniger kostet als ein USB-Stick aud dem Laden ;)

    Aber zum raspiBackup. Woran kann das nun liegen. Haste / hat noch jemand ne Idee???

  • Zitat

    Und ja, ich bin mir sicher, das ich auf der SSD (sda1) arbeite.


    Sehe ich nicht so, oder meinst du drauf speichern, statt starten ?

    Code
    /dev/mmcblk0p2  /               ext4    defaults,noatime  0       1


    Wie lautet denn dein Befehl für dein Backup ?

  • ähhhhh ja, Kacke.
    Mir war aufgefallen, das Homegear (Fensterkontakte) heute nicht mehr funktionierte, laut den gespeicherten daten aus der influxdb seit meinen Versuchen Gestern. Deshalb habe ich ein Backup von gestern Vormittag zurückgespielt und dann auf dein posting geantwortet.
    ich habe jetzt kwasie die geänderte fstab nicht mehr :wallbash:
    Ich mache das dann gleich alles nochmal und melde mich wieder.
    :blush:

  • also nun mit dieser fstab:

    proc /proc proc defaults 0 0
    /dev/mmcblk0p1 /boot vfat defaults 0 2
    #/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
    /dev/sda1 / ext4 defaults,noatime 0 1


    das konfig vom raspi backup:

    # Pfad wo das Backupfile gespeichert wird
    DEFAULT_BACKUPPATH="/media/pi/rpi3backup"

    # Anzahl der zu vorhaltenden Backups
    DEFAULT_KEEPBACKUPS=5

    # Typ des Backups: dd, tar, xbmc or rsync
    DEFAULT_BACKUPTYPE="dd"

    # zip tar oder dd backup (0 = nein, 1 = ja)
    DEFAULT_ZIP_BACKUP=0

    # Durch & getrennte Befehle, die vor dem Starten des Backups auszuführen sind
    DEFAULT_STOPSERVICES="service openhab2 stop & service grafana-server stop & service telegraf stop & service influx$

    # Durch & getrennte Befehle, die nach dem Starten des Backups auszuführen sind
    DEFAULT_STARTSERVICES="service homegear start & service telegraf start & service influxdb start & service grafana-$

    # emailadresse die das Backupergebnis erhält
    DEFAULT_EMAIL=""

    # Weitere Parameter für das eMail programm (Optional)
    DEFAULT_EMAIL_PARMS=""

    # Log level (0 = keiner, 1 = debug)
    DEFAULT_LOG_LEVEL=1

    # log Ausgabe ( 0 = /var/log/syslog, 1 = /var/log/raspiBackup/<hostname>.log, 2 = <backupPath>/raspiBackup.log, 3 $
    DEFAULT_LOG_OUTPUT=2

    # Message level (0 = minimal, 1 = detailed)
    DEFAULT_MSG_LEVEL=1

    # mailprogram
    DEFAULT_MAIL_PROGRAM="mail"

    # Gerät wo das Backup restored wird
    DEFAULT_RESTORE_DEVICE=""

    # Log wird in eMail mitgeschickt (0 = nein, 1 = ja)
    DEFAULT_APPEND_LOG=0

    # Detailierte Logausgaben der Backupprogramme (0 = nein, 1 = ja)
    DEFAULT_VEBOSE=1

    # Check auf einen remoten Backupfad wird nicht vorgenommen (0 = nein, 1 = ja)
    DEFAULT_SKIPLOCALCHECK=0

    # Blocksize von dd
    DEFAULT_DD_BLOCKSIZE=1MB

    # Weitere Parameter für dd
    DEFAULT_DD_PARMS=""

    # Hardlinks werden für rsync benutzt (0 = nein, 1 = ja)
    DEFAULT_HARDLINKS=1

    # Excludeliste für das benutzte Backuprogramm
    DEFAULT_EXCLUDE_LIST=""

    # Notifizierung soll stattfinden wenn eine neue Scriptversion verfügbar ist (0 = nein, 1 = ja)
    DEFAULT_NOTIFY_UPDATE=1

    # Aufzurufende Erweiterungen
    DEFAULT_EXTENSIONS=""

    # partitionsbasierter backup modus (0 = nein, 1 = ja)
    DEFAULT_PARTITIONBASED_BACKUP=0

    # Partitionsnummern, die gesichert werden sollen beim partitionsbasierten Backup
    DEFAULT_PARTITIONS_TO_BACKUP="sda1"

    # Sprache der Meldungen (DE oder EN)
    DEFAULT_LANGUAGE="DE"
    # Systeme auf die raspiBackup mit dem Parameter -y übertragen wird
    # ssh Zugang muss in der authorized keys Datei definiert sein
    # Beispiel: "root@raspifix root@raspberrypi root@raspiap root@raspibmc pi@seafile"
    DEFAULT_DEPLOYMENT_HOSTS=""

    # Vorsichtig benutzen !
    DEFAULT_YES_NO_RESTORE_DEVICE="loop"

    # dd backup sichert nur den Platz der definierten Partitionen
    DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY=0

    # Es werden Hardlinks für Partitionsbootfiles benutzt
    DEFAULT_LINK_BOOTPARTITIONFILES=0

    # !!! Diese Optionen nur ändern wenn man weiss was man tut !!!
    # Sie definieren die Optionen die beim Aufruf von tar und rsync zum Sichern benutzt werden
    DEFAULT_RSYNC_BACKUP_OPTIONS="-aHAXx"
    DEFAULT_RSYNC_BACKUP_ADDITIONAL_OPTIONS=""
    DEFAULT_TAR_BACKUP_OPTIONS="-cpi"
    DEFAULT_TAR_BACKUP_ADDITIONAL_OPTIONS=""

    Es wird wieder nur eine Kopie der SD-Karte erstellt.
    Hast du / ihr Ideen dazu?

  • Hallo Kiefer!
    Verwende nicht das RaspieBackup sondern mach nur dd if=/dev/xxx | gzip --fast >/mnt/nas/backupdateiname.img.gz , aber nicht auf dem Rechner selbst. Man kann schon mit dd eine Partition sichern die online/gemountet ist aber das Ergebnis führt nicht immer zum Erfolg da sonst im Hintergrund kein Programm laufen soll das Dateien beschreibt, also auch keine logs u.s.w.

    Wenn ich deine config anschaue sehe ich allerdings dass du 'sda1' angibst aber ohne Pfad, ist das richtig? sollte da nicht /dev/sda1 stehen?

    Der Grund ist dass ich das Backup immer auf einem anderen rechner mache (ich fahre den Raspi runter, ziehe den USB stick ab und mach ein Backup von ihm auf einem anderen Raspi oder PC). Meine normalen Anwendungsdaten werden ohnehin online als Dateien auf's nas mit normalen copy gespielt.

    Frank

    Nach 35 Jahren im IT business hab ich mit Raspi mal selbst zum Programmieren begonnen...
    Habe auch einen 3D-Drucker, eine CNC-Fräse und etwas Elektronik-Bastelei als Hobby

    Einmal editiert, zuletzt von fjoke (26. Februar 2017 um 15:57)

  • Hallo Kiefer


    Das ist schon richtig, dass dd alleine aus der root-Konsole auch ein img einer gemounteten Partition erstellt. Dass das Abbild inkonsistent ist, merkt man erst nach der Rücksicherung, wenn das vermeintlich letzte funktionierende (und gesicherte) System auch nicht mehr richtig funktioniert.

    Auf
    https://www.linux-tips-and-tricks.de/de/raspberry/2…ckups-of-itself
    fand ich eine Beschreibung vom raspiBackup-Frontend mit den zwei Backupmodi:

    Im "normalen Modus" werden nur die ersten zwei Partitionen gesichert. Unter tar und rsync auch eine (externe) Rootpartition. Unter dd ist dann nur mehr ein Abbild der ganzen Karte (Platte) möglich.

    Im "partitionsorienrierten Modus" kann jede beliebige Anzahl von Partitionen gesichert werden; allerdings nur mit tar oder rsync.
    In den FAQs steht dort auch im Punkt 18., welche Programme/Services unbedingt angehalten werden müssen. FEHM, cron, nfs(kernel-server) ... gehören auch dazu.


    Servus!

    RTFM = Read The Factory Manual, oder so

  • Zum test habe ich nun eine Kopie der sda1 der SSD auf einen USB-Stick kopiert und mit einem weiteren raspi ein testsystem gestartet.
    Verstucht habe ich nun /dev/sda1 und * ausprobiert. Ausserdem das ganze mit der geändertn FSTAB. Keine Änderung, wir jeweils nur die SD-Karte gebackuped.

    @ RTFM: Das Anhalten der services ist klar, aber da bin ich ja noch nicht. Das das dd Backup evtl. nicht konsistent ist, ist auch klar. Kümmer ich mich drum, wenn mal eins da ist.

    "Im "normalen Modus" werden nur die ersten zwei Partitionen gesichert. Unter tar und rsync auch eine (externe) Rootpartition. Unter dd ist dann nur mehr ein Abbild der ganzen Karte (Platte) möglich."
    verstehst du das so, das man von der sda1 mittels dd kein Backup fahren kann? Wo genau siehst du das? Ich habe die Seite x-mal gelesen, aber so habe ich das nirgends in erinnerung.
    Es steht ja da, das man ein dd-image einfach mittels Win32Diskimager zurück spielen kann. Darauf kommst mir an.

    Ich versuch mal mit TAR/Rsync eins zu machen. Mal sehn wie das läuft.
    Automatisch zusammengefügt:
    Hab's mit TAR versucht. Auch hier wird nur die SD-Karte gesichert. Hier werden mehrere files zusätzlich angelegt:
    .parted, .mbr,.fdisk, .blkid
    Aus denen geht auch hervor, das nur die SD-Karte gesichert wird.
    Da ich bisher keine Ideen mehr hatte, gingen sie mir auch nicht aus.....

    Gefühlt gebe ich dem raspibackup einfach nciht den richtigen Parameter an, damit er weiss was er backupen soll.
    Für heute ist ende, muss morgen früh raus.
    Danke für die Hilfe.

    Einmal editiert, zuletzt von Kiefer (26. Februar 2017 um 20:35)

  • raspiBackup sichert eigentlich eine externe Rootpartition wenn von einer SD Karte gebootet wurde.

    Warum das bei Dir Probleme bereitet ist ohne ein Debuglog schwer herauszufinden :s

    Starte doch mal raspiBackup mit den zusätzlichen Optionen

    Code
    -m Detailed -l Debug -L Current

    . Dadurch wird das Debuglog im aktuellen Verzeichnis erzeugt und schicke die Datei raspiBackup.log an meine emailAdresse (Siehe hier). Ich sehe mir das dann mal an.

  • Hallo Kiefer!

    Wenn Du die Zusammenfassung aus meinem Link aufrufst und ca. 40 % runterscrollst, sind die beiden Backupmodi nach der Überschrift "Vergleich partitionsorientierter Backup und normaler Backup" beschrieben.

    Du kannst ein Linux-System von einem auf ein anderes Device nicht einfach kopieren-Systemdateien werden grossteils bei der Installation nur verlinkt. Auch werden devices nicht einheitlich angesprochen, sondern by-label, by-uuid, by-id oder by-path. Das kannst Du unter /dev/disk selbst nachschauen. Grub verwendet z.B. die UUID (und nicht z.B./dev/sda1) beim Systemstart. Und mit Solid State Disks hat(te) Linux seine Probleme, da würde ich mal im System Log nachschauen, ob die SSD überhaupt fehlerfrei eingebunden wird.

    Mach mal im Terminal ein

    sudo dd if=/dev/sda1 of=/dev/null
    sudo dd if=/dev/mmcblk0p1 of=/dev/null
    sudo dd if=/dev/sda of=/dev/null
    sudo dd if=/dev/mmcblk0 of=/dev/null

    An der Anzahl der (nirgendwohin) kopierten Blöcke lässt sich ableiten, ob dd alleine richtig funktioniert, oder das Frontend derzeit nicht das kann, was Du erwartest.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Last login: Sun Feb 26 16:39:57 2017
    ^[[Api@RPI3:~ $ sudo su
    root@RPI3:/home/pi# dd if=/dev/mmcblk0p1 of=/dev/null
    129024+0 Datensätze ein
    129024+0 Datensätze aus
    66060288 Bytes (66 MB) kopiert, 3,00915 s, 22,0 MB/s
    root@RPI3:/home/pi# dd if=/dev/sda1 of=/dev/null
    21098496+0 Datensätze ein
    21098496+0 Datensätze aus
    10802429952 Bytes (11 GB) kopiert, 332,068 s, 32,5 MB/s
    root@RPI3:/home/pi# dd if=/dev/mmcblk0 of=/dev/null
    7744512+0 Datensätze ein
    7744512+0 Datensätze aus
    3965190144 Bytes (4,0 GB) kopiert, 181,477 s, 21,8 MB/s
    root@RPI3:/home/pi# dd if=/dev/sda of=/dev/null
    234441648+0 Datensätze ein
    234441648+0 Datensätze aus
    120034123776 Bytes (120 GB) kopiert, 3752,06 s, 32,0 MB/s
    root@RPI3:/home/pi#


    Ich habe framp ein logfile geschickt. Mal sehn was er/sie sagt..

  • Hallo Kiefer!

    Gratulation !!

    dd alleine funktioniert offensichtlich richtig

    Du hast eine 4 GB SD und eine 120 GB SSD vollständig ins Nirwana gesichert.
    Dazu die Bootpartition, 66 MB und
    die "kopierte" Rootpartition, 11 GB
    Es konnten alle Sektoren fehlerfrei gelesen werden.

    Jetzt musst Du ergründenm warum das Front-End /dev/sda1 nicht übernimmt.
    Vllt findest Du mit man raspiBackup, oder apropos raspiBackup (aus der Konsole/Terminal aufgerufen) irgendwelche Einschränkungen.


    Servus !

    RTFM = Read The Factory Manual, oder so


  • Ich habe framp ein logfile geschickt. Mal sehn was er/sie sagt..


    Vielen Dank fuer das Log. Als ich es mir dann ansah war mir sehr schnell klar wo das Problem liegt. Ich habe zugegebenermassen Deinen ersten Beitrag nicht ganz richtig gelesen :wallbash: Sorry.

    1) Ein dd Backup sichert keine externe Partition. Bei der Beschreibung der Option -t ist das erwähnt
    2) Wenn man eine externe Parition zusaetzlich sichern will geht das nur mit tar oder rsync
    3) raspiBackup sichert immer die SD Karten beim dd Backup. Da mittlerweile die SD Karten riesig gross sind und man i.d.R. nur einen kleinen Teil benutzt kann man mit der KonfigurationsOption DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY nur die erstellte erste Partition sichern (i.d.R. 8GB) und nicht die ganzen 32 GB. Das spart BackupZeit und -platz.

    Wenn Du einen dd Backup haben willst der eine externe Partition beinhaltet weil Du ihn unter Windows per disk32imager restoren willst geht das nicht mit raspiBackup :no_sad: . Alternativ kannst Du den tar oder rsync Backup benutzen. Da wird die externe Rootpartition im normalen Modus gesichert und kann dann mit einer raspBerry unter Linux leicht wieder mit raspiBackup restored werden ;)

    PS: Es ist besser auf der Webseite Fragen und Probleme zu raspiBackup zu melden. Da bekomme ich direkt einen Hinweis per eMail. Hier im Forum lese ich nicht jeden Beitrag und bekomme dann auch nicht mit wenn es sich um einen um raspiBackup dreht.

  • Danke für deine Hilfe. Wenn ich jetzt TAR nehmen würde (habe ich schon probiert, hat auch nicht gemacht was ich wollte), wie genau müsse das konfig file aussehen:
    DEFAULT_BACKUPTYPE="tar"
    DEFAULT_RESTORE_DEVICE="" #für's anlegen des Backups ersmal egal???
    DEFAULT_PARTITIONBASED_BACKUP=1
    DEFAULT_PARTITIONS_TO_BACKUP="sda1" # oder /dev/sda1 ????
    Währe nett, wenn du dazu noch kurz was sagen könntest.

    Und so als Idee für mich: Ein kleines script welches die cmdline.txt auf die /dev/mmcblk0 verweisen lässt und einen reboot ausführt.
    Auf der SD-Karte ein weites Raspbian welches ein startscript ausführt:
    sda2 mounten, dd von sda1 in einen Ordner/file.img auf das gemountete sda2.

    Dann wieder ein kleines script welches die cmdline.txt auf die /dev/sda1 zurück biegt und einen reboot ausführt.
    Dann würde die sda1 auch gebackupt ohne irgendwelche laufenden prozesse.
    Ist das sinnvoll oder stell ich mit da jetzt quatsch vor?
    Danke schonmal,
    Ingo


  • Du benutzt hier den partitionsorientierten Modus. Da wird keine externe Partition gesichert.

    Zitat

    DEFAULT_BACKUPTYPE="tar"
    DEFAULT_PARTITIONBASED_BACKUP=0


    Zitat

    Und so als Idee für mich: Ein kleines script welches die cmdline.txt auf die /dev/mmcblk0 verweisen lässt und einen reboot ausführt.
    Auf der SD-Karte ein weites Raspbian welches ein startscript ausführt:
    sda2 mounten, dd von sda1 in einen Ordner/file.img auf das gemountete sda2.

    Dann wieder ein kleines script welches die cmdline.txt auf die /dev/sda1 zurück biegt und einen reboot ausführt.
    Dann würde die sda1 auch gebackupt ohne irgendwelche laufenden prozesse.

    Das geht natürlich auch. Dazu brauchst Du dann auch raspiBackup nicht. Dann solltest Du aber auch wenigstens die Bootpartition der SD Karte sichern, denn die muss zur Rootpartition passen. Dieses habe ich zu Anfang mal leidvoll erfahren müssen. Da hatte raspiBackup nicht jedes Mal die Bootpartition mitgesichert. Irgendwann gab es mal einen Firmware Update auf ihr und ich konnte das Backup zwar restoren - aber das System startete nicht mehr weil beides auseinandergelaufen war.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!