Neueste Seiten

Häufigste besuchte Seiten

raspiBackup - Fehlermeldungen, Ursachen und Aktionen

Details
Kategorie: raspiBackup
Zugriffe: 10119

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

Es gibt drei Typen von Meldungen:

1) Informationen. Die Meldungsnummer endet mit dem Buchstaben I

2) Warnungen. Die Meldungsnummer endet mit dem Buchstaben W

3) Fehler. Die Meldungsnummer endet mit dem Buchstaben E

Die meisten Fehlermeldungen von raspiBackup weisen genau auf die Fehlerursache hin. In machen Fällen sind weitergehende Erklärungen notwendig die im Folgenden zu finden sind. raspiBackup hat ca 200 Fehlermeldungen und diese hier alle aufzuführen und im Detail zu erklären ist sehr viel Aufwand. Wer also eine Erklärung für eine Fehlermeldung sucht und hier nicht findet sollte erst einmal seine Suchmaschine benutzen und nach der Fehlermeldungsnummer suchen. Falls das nicht zum Erfolg fuehrt muss diese in einem Kommentar am Ende dieser Seite genau angeben werden und dann wird sie hier aufgenommen. So werden dann nach und nach alle häufigen und wichtigen Fehlermeldungen von raspiBackup hier gesammelt und erläutert.

Meldungen im Nummernbereich von 0-999 werden von raspiBackup geschrieben. Meldungen von 1000-1999 werden von den Beispielplugins geschrieben. Alle anderen Nummernbereiche werden von eigene Plugin Meldungen genutzt.

Ausserdem beendet sich raspiBackup mit einem Fehlercode der auf die Ursache hinweist. Eine Liste der Fehlercodes findet sich am Ende der Seite.

RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

RBK0013E: Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ oder der Option -P gesichert werden können

RBK0015E: Es ist schon eine Instanz von raspiBackup aktiv.

RBK0019E: Option -a und -o nicht angegeben.

RBK0020E: Dateisystem des rsync Backupverzeichnisses %s unterstützt keine softlinks.

RBK0021E: Backupprogramm des Typs %s beendete sich mit RC %s.

RBK0027E: Kein externes Gerät an %1 verbunden. Die SD Karte würde für das Backup benutzt werden.

RBK0028E: %s ist kein Wiederherstellungsverzeichnis von raspiBackup.

RBK0030E: %s Datei Erzeugung mit dd endet fehlerhaft mit RC %s.

RBK0047E: Ein Fehler trat beim Starten von Services auf. RC %s.

RBK0048E: Ein Fehler trat beim Beenden von Services auf. RC %s.

RBK0051W: Ziel %s mit %s ist größer als 2TB und erfordert gpt statt mbr. Ansonsten werden nur 2TB genutzt.

RBK0061E: Keine Bootpartitionsdateien in %s gefunden die mit %s beginnen.

RBK0077E: Restore wurde fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

RBK0086E: Wiederherstellungsgerät darf keine Partition sein.

RBK0087E: Restore directory %s was not created by raspiBackup.

RBK0105I: Neues Backupverzeichnis %s wird gelöscht.

RBK0142E: Bootgerät kann nicht erkannt werden.

RBK0147E: Sicherung der Partition %s schlug fehl mit RC %s.

RBK0150W: Maximale Dateigröße im Backupverzeichnis %s ist auf 4GB begrenzt.

RBK0154E: Ein Restore ist nicht möglich wenn eine Partition von %s gemounted ist.

RBK0160E: Ziel %s mit %s ist kleiner als die Backupquelle mit %s.

RBK0196W: %s unterstützt keine Hardlinks.

RBK0197W: eMail mit %s versenden endet fehlerhaft mit RC %s.

BK0203E: Boot device kann nicht erkannt werden. Bitte das Problem mit einem Debuglog welches mit Option '-l debug' erstellt wird berichten."

RBK0211E: Externe Partition %s die an %s gemounted ist wird mit Option -P nicht gesichert.

RBK0263E: Dateisystem auf %s unterstützt keine Linux Dateiattribute.

RBK1005E: bc nicht gefunden. bc muss installiert werden mit 'sudo apt-get install bc'.

 

RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

Ursache:

raspiBackup endete mit einem Fehler und hat kein Backup erstellt.

Weitere Aktionen:

Eine vorangehende Fehlermeldung beschreibt die genau Ursache des Abbruchs. Diese suchen und deren Ursache beheben.

 

RBK0013E: Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ oder der Option -P gesichert werden können

Ursache:

raspiBackup sichert nur die ersten beiden Partitionen. Wenn mehr Partitionen existieren wird diese Meldung ausgegeben.

Weitere Aktionen:

Entweder löscht man die weiteren Partitionen oder man benutzt die Option --ignoreAdditionalPartitions.Damit wird explizit gesagt dass weitere Partitionen existieren dürfen aber NICHT gesichert werden. Alternativ kann man alles sichern mit dem backup Typ DD oder dem partitionsorientierten Modus.

 

RBK0015E: Es ist schon eine Instanz von raspiBackup aktiv.

Ursache:

raspiBackup verhindert dass es mehrere Male parallel gestartet wird. Entweder läuft raspiBackup noch oder der vorherige raspiBackup Lauf terminierte mit einem Fehler und der Lock wurde nicht entfernt.

Weitere Aktionen:

Mit ps -ef | grep raspiBackup kann man überprüfen ob raspiBackup gerade läuft. Wenn ja muss man warten bis sich raspiBackup beendet hat. Wenn nein muss die Datei /var/lock/raspiBackup gelöscht werden mit sudo rm /var/lock/raspiBackup


RBK0019E: Option -a und -o nicht angegeben.

Ursache:

raspiBackup erlaubt ein laufendes System zu sichern. Vor dem Backup sollten alle wichtigen laufenden Services gestoppt und am Ende wieder gestartet werden um kein inkonsistentes Backup zu erstellen. Wenn man keine zu stoppenden und zu startenden Services per Installer definiert hat müssen die Services mit den beiden Optionen im Aufruf angegeben werden.

Weitere Aktionen:

Die beiden Optionen mit entsprechenden Parametern müssen beim Aufruf mitgegeben werden oder die Services müssen mit dem Installer in der Konfigurationsdatei definiert sein. Details dazu finden sich auf der FAQ Seite.

 

RBK0020E: Dateisystem des rsync Backupverzeichnisses %s unterstützt keine softlinks.

Ursache:

Ein Backupdateisystem welches ein rsync Backup aufnehmen soll muss Softlinks unterstützen. Das wird nur von EXT2, EXT3 und EXT4 unterstützt. FAT32 oder NTFS unterstützen die nicht. Details dazu finden sich in FAQ19

Weitere Aktionen:

Entwerder muss die Backuppartition mit EXT2, 3 oder 4 formatiert werden oder es muss ein anderer Backuptyp wie dd oder tar benutzt werden.

 

RBK0021E: Backupprogramm des Typs %1 beendete sich mit RC %2.

Ursache:

Ein Backupprogramm (dd, tar oder rsync) welches von raspiBackup benutzt wird hat einen Fehler bekommen. Der RC gibt den Fehlercode an.

Weitere Aktionen:

RC 1 bei dd Backup meldet eine Lese- oder Schreibfehler einer Datei. Ein RC 1 bei tar sowie RC 23 oder RC 24 bei rsync bedeutet dass sich eine Datei während der Sicherung verändert hat. RC 2 bei tar bedeutet irgendein schlimmer Fehler trat auf.

Vorhergehende Meldungen zeigen die genaue Fehlermeldung des Backupprogramms. Falls diese nicht helfen die Ursache zu finden kann die Option -v bei tar und rsync benutzt werden um detailierte Meldungen von den Backupprogrammen im Debuglog zu erhalten die weiterhelfen. Danach hilft es sehr häufig die Fehlermeldung in eine Suchmaschine einzugeben um die Ursache zu finden. Auf der FAQ Seite sind viele Fehlermeldungen, deren Ursache und Fehlerbehebungsmassnahmen beschrieben. Bei rsync besteht die Möglichkeit die unnötig lange Liste der kopierten Dateien die bei der Option ausgegeben wird zu unterdrücken und damit nur noch Fehlermeldungen ausgeben zu lassen. Dazu muss in /usr/local/etc/raspiBackup.conf folgende Zeile geändert werden:  DEFAULT_RSYNC_BACKUP_ADDITIONAL_OPTIONS="--info=NAME0" (Achtung: Auf die Gross- und Kleinschreibung achten!)

Alternativ kann man Fehler von tar und rsync ignorieren lassen. Siehe dazu FAQ32.

Häufig ist aber auch die Backuppartition - speziell wenn es eine über das Netz angebundene Partition (nfs, samba) ist - das Problem. Meist sind es Netzwerkprobleme oder -fehlkonfigurationen. Auch kam es schon vor dass die Partition auf einem Gerät lag, welches Schreibfehler hatte.

Sollte ein Lesefehler vorliegen ist das ein Hinweis darauf dass die SD Karte ersetzt werden sollte. Dazu dann das letzte Backup auf eine neue SD Karte restoren.

Falls die Backuppartition per nfs gemounted ist diesen Artikel lesen.

 

RBK0027E: Kein externes Gerät an %1 verbunden. Die SD Karte würde für das Backup benutzt werden.

Ursache:

raspiBackup prüft ob eine externe Partition am Backuppfad gemounted ist, denn wenn nicht würde das Backup auf der SD Karte gespeichert werden was keinen Sinn macht und wenn die SD Karte klein ist wird sie überlaufen.

Weitere Aktionen:

Sei nun %1 /backup welches der Standardpfad ist. Die lokale Backuppartition von einerm USB Stick oder USB Platte muss an /backup gemounted werden. Benutze einen entsprechenden Eintrag in der /etc/fstab um den Mountpunkt /backup mit einer externen Partition zu verbinden. Man kann das prüfen mit

findmnt /backup

 

Wenn man weiss was man tut kann man die Fehlermeldung mit der Option -c ausschalten.

 

RBK0028E: %s ist kein Wiederherstellungsverzeichnis von $MYNAME."

Ursache:

Es darf keine Datei angegeben werden wie z.B. die tar Datei. Es muss das Backupverzeichnis sein.

Weitere Aktionen:

Den Dateinamen weglassen und nur das Backupverzeichnis angeben.

 

RBK0030E: %s Datei Erzeugung mit dd endet fehlerhaft mit RC %s.

Ursache:

Beim Erstellen einer Datei mit dd trat ein Fehler auf. RC 1 bedeutet ein Lese- oder Schreibfehler.

Weitere Aktionen:

Beim Restore ist ziemlich sicher die SD Karte korrupt und eine andere SD Karte sollte benutzt werden. Beim Backup gibt es Schreibprobleme auf das Backupmedium welche gelöst werden müssen. Vorhergehende Meldungen vom Backuptool geben weitere Hinweis auf die Fehlerursache.

 

RBK0047E: Ein Fehler trat beim Starten von Services auf. RC %s.

RBK0048E: Ein Fehler trat beim Beenden von Services auf. RC %s.

Ursache:

Die Befehle der Option -a/-o bzw des Konfigurationsparameters DEFAULT_STARTSERVICES/DEFAULT_STOPSERVICES die Services starten/stoppen sollen erzeugen einen Fehler.

Weitere Aktionen:

Man muss herausfinden welcher der Startbefehle/Stopbefehle einen Fehler hat. Deshalb gibt man jeden Startbefehl/Stopbefehl einmal per sudo ein und achtet auf Fehlermeldungen. Danach ist die Ursache der Fehlermeldung zu beseitigen.

 

RBK0051W: Ziel %s mit %s ist größer als 2TB und erfordert gpt statt mbr. Ansonsten werden nur 2TB genutzt.

Ursache:

Die Zielpartition ist größer als 2TB und deshalb ist darauf ein gpt notwendig. Wenn das Backup nur ein mbr hat kann die Zielpartition nur bis 2TB erweitert werden.

Weitere Aktionen:

Sofern im Backup schon ein gpt genutzt wird kann die Meldung ignoriert werden. Ansonsten muss die Zielpartition manuell mit einem gpt versehen werden und die Partitionen entsprechend manuell angelegt werden. Danach kann dann das Backup mit der Option -0 restoren und die Zielpartition wird auf die maximale Kapazität erweitert.
 

RBK0061E: Keine Bootpartitionsdateien in %s gefunden die mit %s beginnen.

Ursache:

raspiBackup sucht in dem Backupverzeichnis nach dem Bootpartitionsbackup und findet es nicht.

Weitere Aktionen:

Es wurde ein Verzeichnis als Backupverzeichnis angegeben welche keine oder unvollständige Backupdaten enthält. Siehe hier welche Dateien sich im Backupverzeichnis befinden müssen. Ein Backupverzeichnis beginnt immer mit dem Hostnamen der Raspberry gefolgt von dem Backuptyp und dem Erstellungsdatum des Backups. Beispiele: raspberrypi-dd-backup-20160415-222900 oder raspberrypi-rsync-backup-20160416-094106

 

RBK0077E: Restore wurde fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

Ursache:

Es gab beim Restore Fehler. Das kann entweder beim Anlegen der Partitionen sein oder beim eigentlichen Restoren der Backupdaten.

Weitere Aktionen:

Zuerst eventuelle vorhergehende Fehlermledungen prüfen. Danach das Debuglog prüfen ob es beim Anlegen der Partitionen Probleme gab.  Dazu nach Checking that no-one is using this disk right now suchen und Fehlermeldungen. Es existiert ein bekanntes Problem mit einer neuen sfdisk Version in Bullseye wenn ein Backup von einem solchen System auf einem Linux mit einer älteren sfdisk version restored wird. Die Fehlermeldung ist

>>> line 5: unsupported command

Die Lösung dazu ist entweder ein Linux mit der sfdisk Version von Bullseye zu nehmen

sfdisk --version
sfdisk from util-linux 2.36.1

oder manuell die 5te Zeile in der Datei mit der Extension .sfdisk im Backupverzeichnis zu loeschen.
 

RBK0086E: Wiederherstellungsgerät darf keine Partition sein.

Ursache:

raspiBackup will beim Wiederherstellen des Backups auf der SD Karte Partitionen anlegen. Dazu muss die ganze SD Karte als Zielgerät angegeben werde. Eine einzelne Partition ist nicht erlaubt.

Weitere Aktionen:

Anstelle von z.B. /dev/sdb1, was eine einzelne Partition ist, muss z.B. /dev/sdb angegeben werden. Aber ACHTUNG: Sämtliche Daten auf der SD Karte werden dann überschrieben. Also vorher sicherstellen, dass keine anderen Daten auf anderen Partitionen noch benötigt werden. Siehe auch diese Seite zur Wiederherstellung.

 

RBK0087E: Restore directory %s was not created by raspiBackup.

Ursache:

raspiBackup generiert ein Backupverzeichnis welches einem bestimmten Format gehorcht. Sein Format muss wie folgt aussehen: <hostname>-<backuptyp>-backup-<datum>-<zeit>. Siehe dazu auch hier.

Weitere Aktionen:

Das Backupverzeichnis muss gemäß der o.g. Form umbenannt werden.

 

RBK0105I: Neues Backupverzeichnis %1 wird gelöscht.

Ursache:

Es trat ein Fehler auf und raspiBackup löscht das leere oder inkonsistente neue Backupverzeichnis.

Weitere Aktionen:

Eine vorhergehende Meldung weist auf einen Fehler hin der beseitigt werden muss.

 

RBK0142E: Bootgerät kann nicht erkannt werden.

Ursache:

raspiBackup kann das Bootgerät erkennen. Das pasiert normalerweise wenn eine andere Hardware als eine Raspberry benutzt wird oder ein anderes Operatingsystem als Raspbian benutzt wird.

Weitere Aktionen:

Das Problem auf github oder in einem Kommentar am Ende dieser Seite berichten.

 

RBK0147E: Sicherung der Partition %1 schlug fehl mit RC %2.

Ursache:

raspiBackup hat einen Fehler vom benutzten Backupprogramm bekommen beim Sichern einer Parition im partitioneorientierten Modus.

Weitere Aktionen:

Siehe RBK0021E

 

RBK0150W: Maximale Dateigröße im Backupverzeichnis %s ist auf 4GB begrenzt.

Ursache:

Das Filesystem der Backuppartition erlaubt nur Dateigrößen von 4GB und ist so gut wie nicht nutzbar für Backups.

 

Weitere Aktionen:

Es muss ein anderes Filesystem auf dem Backupspace angelegt werden. Welches das sein muss hängt von der Backupmethode ab. Auf dieser Seite findet man in einer Tabelle aus der das richtige Filesystem entnommen werden kann.
 

RBK0154E: Ein Restore ist nicht möglich wenn eine Partition von %1 gemounted ist.

Ursache:

Wenn eine Partition neu beschrieben wird darf sie nicht gemounted sein.

Weitere Aktionen:

Mit dem Befehl sudo mount | grep <device> (<device> ist in der Meldung genannt) rausfinden welche Partition gemounted ist und mit sudo umount <partition> wobei <partition> die gemountete Partition sein muss, die Partition (z.B. /dev/sda1) freigeben.

 

RBK0160E: Ziel %1 mit %2 ist kleiner als die Backupquelle mit %3.

Ursache:

Das Backup ist größer als die SD Karte auf die es zurückgespielt werden soll und kann deshalb nicht zurückgespielt werden. Die Meldung kommt nur beim dd Backup. Bei tar oder rsync Backup wird automatisch die Größe angepasst.

Weitere Aktionen:

Es muss eine größere SD Karte benutzt werden. Alternativ kann man mit dem Tool pishrink das dd Image verkleinern und dann mit raspiBackup zurückspielen. Siehe auch FAQ26.

 

RBK0196W: %1 unterstützt keine Hardlinks.

Ursache:

rsync benutzt Hardlinks um Backup Zeit und Space zu reduzieren. Hardlinks werden vom ext3/ext4 Filesystems welche lokal oder via nfs gemounted sind unterstützt. Samba und sshfs unterstützen keine Hardlinks.

Weitere Aktionen:

Benutze entweder eine Backuppartition welche Hardlinks unterstützt oder nutze den tar oder dd backup. Berücksichtige aber dass jeder Backup ein Vollbackup ist und entsprechend mehr Zeit und Platz benötigt.

 

RBK0197W: eMail mit %s versenden endet fehlerhaft mit RC %s.

Ursache:

Eine eMail kann nicht gesendet werden.

Weitere Aktionen:

Fast immer liegt die Ursache in einer Fehlkonfiguration des genutzten MTAs. Häufig bekommt raspiBackup auch keinen Fehler beim Sensden der eMail aber sie kommt trotzdem nicht an. Die Konfiguration eines MTAs ist sehr oft kompliziert und ist kein Problem von raspiBackup. Im Log des verwendeten MTAs findet man Fehlermeldungen die helfen die Ursache zu finden. Es wird hier in dem Kontext auf FAQ47 verwiesen.
 

RBK0203E: Boot device kann nicht erkannt werden. Bitte das Problem mit einem Debuglog welches mit Option '-l debug' erstellt wird berichten."

Ursache:

raspiBackup versucht das Bootdevice zu erkennen und kann das aus irgendwelchen Gründen nicht.

Weitere Aktionen:

Es sollte in github Issue erstellt werden in dem das Debuglog angehängt ist um die Ursache zu finden.

Hinweis: NVMe Speicher ist nicht unterstützt. Für die Entwicklung des NVME Supports sowie einen sorgfältigen Test fehlt NVMe Speicher sowie ein Adapter. Wer will kann für den NVMe Support in raspiBackup spenden. Details dazu finden sich hier.

 

RBK0211E: Externe Partition %s die an %s gemounted ist wird mit Option -P nicht gesichert.

Ursache:

Mit der Option -P kann mit raspiBackup nur eine SD Karte gesichert werden.

Weitere Aktionen:

Mit der Benutzung des normalen Backup Modus kann auch ein Backup bei einem USB Boot vorgenommen werden. Sollten mehr als 2 Partitionen vorhanden sein kann mit der Option --ignoreAdditionalPartitionsdie Sicherung der weiteren Partitionen ausgeschlossen werden.

 

RBK0263E: Dateisystem auf %s unterstützt keine Linux Dateiattribute.

Ursache:

Die rsync Backupmethode erfordert dass die Backupparition in der Lage ist Linux Dateiattribute zu speichern. Das aktuelle Dateisystem unterstützt dieses nicht. I.d.R. ist es ein NTFS Filesystem. Falls die Backuppartition per nfs eingebunden ist ist diese Fehlermeldung ein Zeichen dafür dass die nfs Partition nicht mit no_root_squash exportiert wird.

 

Weitere Aktionen:

Entweder muss die Backupmethode dd oder tar gewählt werden oder es muss eine Backuppartition genutzt werden werden die Linux Dateiattribute unterstützt. Details dazu finden sich auf dieser Seite.
 

 RBK1005E: bc nicht gefunden. bc muss installiert werden mit 'sudo apt-get install bc'.

Ursache:

Die Diskbeispielsextension benoetigt bc zum berechnen. 

Weitere Aktionen:

Installiere bc mit 'sudo apt-get install bc' damit die Diskbeispielextension gueltige Werte ausgibt.

Fehlercodes

Der Name des Fehlercodes weist auf die Ursache hin.

Beispiel: RC_EMAILPROG_ERROR=124 weist darauf hin dass in der eMailkonfiguration etwas nicht OK ist.

RC_ASSERTION=101
RC_MISC_ERROR=102
RC_CTRLC=103
RC_EXTENSION_ERROR=104
RC_STOP_SERVICES_ERROR=105
RC_START_SERVICES_ERROR=106
RC_PARAMETER_ERROR=107
RC_MISSING_FILES=108
RC_NATIVE_BACKUP_FAILED=109
RC_LINK_FILE_FAILED=110
RC_COLLECT_PARTITIONS_FAILED=111
RC_CREATE_PARTITIONS_FAILED=112
RC_DD_IMG_FAILED=114
RC_SDCARD_ERROR=115
RC_RESTORE_FAILED=116
RC_NATIVE_RESTORE_FAILED=117
RC_DEVICES_NOTFOUND=118
RC_CREATE_ERROR=119
RC_MISSING_COMMANDS=120
RC_NO_BOOT_FOUND=121
RC_BEFORE_START_SERVICES_ERROR=122
RC_BEFORE_STOP_SERVICES_ERROR=123
RC_EMAILPROG_ERROR=124
RC_MISSING_PARTITION=125
RC_UUIDS_NOT_UNIQUE=126
RC_INCOMPLETE_PARMS=127
RC_CONFIGVERSION_MISMATCH=128
RC_TELEGRAM_ERROR=129
RC_FILE_OPERATION_ERROR=130
RC_MOUNT_FAILED=131

Kommentar schreiben

*** Hinweis ***

 Kommentare sind erwünscht. Aber um lästige Spamposts abweisen zu können gibt es ein paar Dinge die zu beachten sind:
  1. Kommentare mit dem Text http werden sofort zurückgewiesen mit der Meldung Sie sind nicht berechtigt den Tag zu verwenden. zz
  2. Kommentare werden manuell überprüft und es dauert deshalb in der Regel einen Tag bis sie veröffentlicht werden.

    Kommentare   
    #117 Steinspiel 2021-12-27 18:15
    Moin framp,

    Nachdem raspiBackup, dank Deiner Hilfe, bei mir lief, wollte ich eine "saubere Installation" und habe noch einmal komplett von vorn begonnen... :sad:
    Nun "muss" ich Dich noch einmal um Hilfe bitten...
    Falls Du mir helfen willst, dachte ich es wäre in Deinem Sinne wenn ich gleich ein Issue eröffne, mit Logfiles, Screenshots usw.

    Danke fürs lesen, Steinspiel
    Zitieren
    #116 framp 2021-12-14 21:54
    Moin Steinspiel,

    vielen Dank fuer den Issue und die Logs. Ich sehe mir das an ;-)

    Cu framp
    Zitieren
    #115 Steinspiel 2021-12-14 21:45
    Ich noch mal...

    Ich glaube ich hatte vergessen zu erwähnen das ich das Restore heute mehrfach durchgeführt habe, allerdings auch immer wieder mit dem gleichen Ergebnis... :sad:

    bis dann,
    Zitieren
    #114 Steinspiel 2021-12-14 21:24
    Moin framp,

    Nachdem ich die USB Platte heute gegen eine neue ausgetauscht und alles mit einem aktiven USB Hub an den Raspberry angeschlossen habe, habe ich noch einmal problemlos ein neues Backup erstellt.
    Das Restore lief allerdings erneut nicht. :sad:

    Nun habe ich ein Issue erstellt, wie Du es anfangs geraten hast. Ich hoffe ich habe es richtig gemacht und alle relevanten Daten sind dort zu sehen.

    Aufgefallen ist mir die Meldung "no such file or directory" obwohl die Dateien existieren! Habe ich die falsche Aufrufsyntax verwendet?

    Danke und schönen Abend,
    Zitieren
    #113 framp 2021-12-13 21:50
    Moin Steinspiel,

    die DebugDateien werden immer wieder ueberschrieben und neu erzeugt. Also kein Loeschen notwendig.

    Cu framp
    Zitieren
    #112 Steinspiel 2021-12-13 21:37
    Moin,

    zitiere framp:
    Moin Steinspiel,
    [...]
    Vielleicht kannst Du noch mal ein anderes Geraet als Backuspace nehmen


    Das meinte ich ja: erst morgen die neue Platte fürs Backup, dann alles noch einmal durchgespielt und dann schauen...

    Noch mal kurz zu "raspiBackup.log", die vorhandenen *.log in /root bzw. /home/pi, werden die beim Backup und Restore ersetzt oder sollte ich die vorab von Hand löschen?

    schönen Abend noch,
    Zitieren
    #111 framp 2021-12-13 19:58
    Moin Steinspiel,

    ja, ich meine raspiBackup.log. Nach dem Backup findest Du das Log im Backupverzeichnis. Das vom restore den Du abbrichst befindet sich dann je nachdem welchen User Du zum Restore nutzt in /root oder /home/pi.

    Aber irgendwie hoert es sich fuer mich an (Du sprichst von einem zaehen Verhalten und ploetztlich anderer Fehlermeldungen) als wenn bei Dir ein Problem mit der USB Platte existiert. Sowas sehe ich natuerlich nicht im Debuglog. Vielleicht kannst Du noch mal ein anderes Geraet als Backuspace nehmen und den Restore testen bevor Du einen Issue erstellst mit den Logs ;-)

    Cu framp
    Zitieren
    #110 Steinspiel 2021-12-13 19:51
    Nabend framp

    Danke für die schnelle Antwort...
    Ich denke mit "debuglog" meinst Du "raspiBackup.log" und das jeweils von der Backup Platte *nach* dem erstellen des Backups und anschließend von der SSD auf der das restore gelandet ist ?

    Ich wollte das noch einmal alles neu erstellen damit Du die neuesten Logs bekommst, aber es gab beim Restore noch ganz andere Fehlermeldungen :-(

    Irgendwie kommt mir das Handling mit der Backup USB Platte "zäh" vor, z.B. dauert das mounten in /backup bestimmt 5 sek bevor der Prompt wieder erscheint...
    Ich hole morgen erst mal ein neues LW, bis dahin werde ich schauen wie man ein "Issue " erstellt... ;-)

    Danke, schönen Abend noch,
    Zitieren
    #109 framp 2021-12-12 20:35
    Moin Steinspiel,

    das sieht mir wirklich sehr merkwuerdig aus. Um die Ursache zu finden brauche ich das debuglog vom Backup wie auch vom Restore. Das sollte sich nach dem hard reset im home Verzeichnis der Aufrufers befinden.

    Am besten erstellst Du einen Issue im github (HTTPS://github.com/framps/raspiBackup/issues) und haengst die beiden Debuglogs dran. Aber vorsicht! Das debuglog vom Restore kann sensitive Informationen enthalten da die Maskierung eben dieser erst am Ende vom Restorelauf stattfindet. :sad:

    Gerne auch in Deutsch wenn Du willst. Anmeldung im github ist kostenlos.

    Cu framp
    Zitieren
    #108 Steinspiel 2021-12-12 17:51
    Moin,

    Bin vor kurzem auf raspiBackup aufmerksam gemacht worden und ganz begeistert, allerdings läuft das Restore noch nicht.

    Mein Setup:

    pi4, nur mit 120GB M2.SSD,
    diese hat eine 256 MB boot-Pratition sowie eine ca. 28 GB root-Partition, der Rest ist nicht zugeordnet
    der Pi bootet problemlos von SSD, openHABian 3.0 läuft.
    eine 2 TB USB 3.0 Toshiba Platte (eine einzige Partition, ext4) für`s Backup, diese ist am USB2.0 des Raspi angeschlossen
    eine zweite, baugleiche 120GB M2.SSD auf der das restore landen soll, diese hängt per Adapter am USB3.0 des Raspi.

    Ich habe schon einige Backups mit
    sudo raspiBackup -m detailed
    erstellt. alles lief Problemlod durch, mit Erfolgsmeldung am Ende.

    Meine Konfiguration von raspiBackuo:

    - Backup Typ -> Sichere mit rsync
    - Backup Modus -> Sichere die zwei Standartpartitionen
    - stoppende und startende Services -> nur openhabian und ZRAM

    Restore rufe ich so auf:
    sudo raspiBackup.sh --resizeRootFS- -d /dev/sdc /backup/openhabian/openhabian-rsync-backup-xxx

    Das ganze startet und läuft durch bis

    --- RBK0055I: Zweite Partition (Rootpartition) wird auf /dev/sdc2 zurückgespielt

    Dann "steht" das ganze mind. 30 min, die USB Platte macht hörbare "Klack" - Geräusche und irgendwann erscheit diese

    Read-only file system... Meldung.

    Anbei noch ein Screenshot, ich habe die ersten vier Buchstaben der URL ersetzt, damit der Link nicht abgewiesen wird...
    xxxxs://i.imgur.com/UqbRKhT.png

    Es hilft dann nur noch den Stecker am Raspi zu ziehen und neu zu booten.

    Hat jemand eine Idee an was kann es liegen könnte oder was kann ich noch machen?
    Ich muss dazu sagen das ich noch nicht viel Ahnung von Linux habe, ich musste mir ein paar Sachen anlesen um "soweit" zu kommen.

    Danke fürs lesen und schönen Rest Sonntag noch,
    Zitieren
    #107 framp 2021-11-20 09:06
    Moin GL,

    vielen Dank für den Hinweis. Ich werde das noch im FAQ aufnehmen.

    Zu 777 - das ist sicherlich eine Lösung aber eine ziemlich unsichere :-*

    Cu framp
    Zitieren
    #106 GL 2021-11-20 08:12
    Hi framp,
    ich musste nun doch kein Github-Issue aufmachen, konnte das Problem lösen.
    Es waren bei mir die Anpassung der Conf mit dem Eintrag bzgl. der ACL (FAQ24 - Lösung2).
    Ich bin darauf gekommen, da die Logfile irgendwann stehen blieb zu wachsen. Nachdem ich via STRG-C abgebrochen habe, sah ich darin einen Fehler "rsync Error Code-20" und auch viele Einträge bzgl. "ACL - operation not supported".
    Nachdem ich den Eintrag aus FAQ24 eingefügt habe wurde das 1. Backup nach knapp 2h fertig und ohne Fehlermeldung.
    Danke nochmals für die schnelle Hilfe.

    Achja: auch via NFS und Synology klappt ohne Probleme, was ich aber noch zusätzliche machen musste, war auf der Synology selbst den freigegebenen Ordner mit weiteren Rechten ausstatten (chmod 777 => evl. zuviel, da muss ich mich noch rantesten).
    Evtl. hilft es je jemand anderen :)
    Zitieren
    #105 framp 2021-11-18 17:32
    Klar. Nur zu. Im GitHub geht alles auch besser zu kommunizieren
    Zitieren
    #104 GL 2021-11-18 16:36
    Hi framp,

    okay, also via hopp sehe ich beim raspibackup keine Aktivität mehr, Screenshot gemacht, aber kann ich nicht anhängen.
    Swap wir auch nicht genutzt.
    ich beschreib das Thema mal als Issue in Guthub, falls das okay für dich ist.
    Danke dir
    Zitieren
    #103 framp 2021-11-18 16:10
    Moin GL,

    ich habe diesen Effekt bei mir noch nie gehabt. Aber es gibt immer mal wieder vereinzelt raspiBackup Nutzer die melden eine lange Backupzeit beim ersten Lauf mit rsync. Warum das so lange dauert konnte ich nie analysieren denn das geht nur wenn ich Zugriff auf die Raspi habe. Die gibt mir aber natuerlich keiner.

    Ich vermute mal dass Du rsync nutzt. Das ist je nach Menge der Dateien speicherhungrig. Ich koennte mir vorstellen dass Deine Raspi swapped. Sieh doch mal mit htop nach ob raspiBackup noch CPU verbraucht und wie es mit dem Speicher aussieht. Mit free siehst Du auch die Nutzung vom swap.

    Cu framp
    Zitieren
    #102 GL 2021-11-18 15:40
    Moin framp,

    Danke für die Rückinfo.

    zitiere framp:
    Moin GL,

    je nach Groesse des Images und dem Durchsatz auf die Backuppartition kann das beim ersten Mal bei rsync schon laenger dauern.

    ab wann müsste ich mir denn "Sorgen" machen, backup läuft jetzt set 2,5h.
    Was mich irritiert ist das ich auf der Synode weder einer Änderung im Backup-Umfang Anhang der Dateien, ByteAnzahl o.ä. seit 2h feststelle und auch auf der Syno im NFS-Monitoring keine Bewegung mehr sehe.

    zitiere framp:

    Du kannst noch die Option -v oder -g nutzen. Damit siehst Du dass noch was passiert. Oder Du siehst mit htop nach CPU Nutzung oder nload Netzwerknutzung wenn Du SMB oder nfs nutzt.

    Cu framp

    Danke, nload hab ich weder am RPI noch auf der Syno laufen. und die anderen Parameter müsste ich beim starten des Backups mit Anhänge, oder? ich wollte das backup aber jetzt nicht abbrechen...
    Zitieren
    #101 framp 2021-11-18 14:58
    Moin GL,

    je nach Groesse des Images und dem Durchsatz auf die Backuppartition kann das beim ersten Mal bei rsync schon laenger dauern. Bei dd und tarr dann aber jedes Mal :sad:

    Du kannst noch die Option -v oder -g nutzen. Damit siehst Du dass noch was passiert. Oder Du siehst mit htop nach CPU Nutzung oder nload Netzwerknutzung wenn Du SMB oder nfs nutzt.

    Cu framp
    Zitieren
    #100 GL 2021-11-18 12:33
    Hallo zusammen,

    ich habe das Setup Raspberry und NFS Mount auf Synology. Der Mount selbst und Zugriff klappt. Der Backupprozess wird auch ohne Fehler gestartet, jedoch scheint er sich nicht zu beenden. Die Daten auf dem NAS werden nach einer Weile nicht mehr bzw. verändern sich nicht, aber die Konsole bleibt bei
    "--- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld." stehen.

    Aktuell läuft das Backup meines Pi4 (iobroker, PivCCU, influxdb, grafane) schon 90min, wobei seit 60min keine Änderungen am Backup-Inhalt ersichtlich sind.
    was übersehe ich hier evtl. bzw. hat noch jemand einen Tipp?
    Zitieren
    #99 framp 2021-10-25 12:59
    Jupp. Es finden sich immer wieder Dinge die ich verbessern bzw fiixen kann :-)
    Zitieren
    #98 JK 2021-10-25 09:41
    Hi framp,

    läuft wieder perfekt nach einer Neuinstallation. Habe auch gesehen, dass du den Installer bzw die Einrichtung weiter verbessert hast. War in zwei Minuten erledigt. Voll gut!

    Danke und schöne Grüße
    JK
    Zitieren
    #97 JK 2021-10-24 23:22
    zitiere framp:
    Moin JK,

    es kann auch ein Fehler in raspiBackup bzgl des Loggings vorliegen. Das habe ich in 0.6.6.1 geanedert. Kannst Du mal das Debuglog vom Backup zur Verfuegung stellen? Am besten im github einen Issue erstellen und das Log anhaengen. Gerne auch in Deutsch :-)

    Cu framp


    Nabend framp,
    habe auch versucht auf Version 0.6.6. mit -V zurückzukehren, hat aber nicht funktioniert. Dann habe ich nochmal das Update auf 0.6.6.1 angestoßen, aber auch ohne Erfolg. Da kein Ordner angelegt wurde, habe ich leider auch keine Logdatei, die ich hochladen kann.

    Ich deinstalliere raspiBackup und installiere es wieder und gebe Bescheid wie es gelaufen ist :-)

    Beste Grüße
    JK
    Zitieren
    #96 framp 2021-10-24 20:26
    Moin JK,

    es kann auch ein Fehler in raspiBackup bzgl des Loggings vorliegen. Das habe ich in 0.6.6.1 geanedert. Kannst Du mal das Debuglog vom Backup zur Verfuegung stellen? Am besten im github einen Issue erstellen und das Log anhaengen. Gerne auch in Deutsch :-)

    Cu framp
    Zitieren
    #95 JK 2021-10-24 14:35
    Hi framp,

    danke zunächst für die Behebung des Problems mit den gleichen UUIDs beim restore!!

    Beim heutigen regelmäßigen Backup kam zunächst die Mail des erfolgreichen Durchlaufs, dann sofort hinterher eine Mail vom Cron Daemon mit folgendem Inhalt:

    /usr/local/bin/raspiBackup.sh: Zeile 1716, 1717, 1722, 1725 jeweils mit: /media/usbdrive/raspibackup/himberrypi/himberrypi-tar-backup-20211024-050001/raspiBackup.log: Datei oder Verzeichnis nicht gefunden

    Ein Backup wurde aber nicht gesichert, daher kam die Cron Mail.

    Einen Restore eines alten Backups mit anschließendem Backup wird von Cron mit:

    rm: das Entfernen von '/media/usbdrive/raspibackup/himberrypi/himberrypi-tar-backup-20211024-140301' ist nicht möglich: Das Verzeichnis ist nicht leer

    gemeldet, wobei nur log und msg sich im Ordner befinden und kein Tar und Boot backup

    Im Augenblick tendiere ich dazu raspibackup zu deinstallieren und neu aufzusetzen, da bestimmt die Fehlersuche länger dauern wird, es sei denn Du hast eine andere einfachere Lösung.

    Danke und schöne Grüße
    JK
    Zitieren
    #94 JK 2021-10-17 21:11
    zitiere framp:
    Moin JK,

    das ist natuerlich sehr unschoen :sad: . Um die Ursache rauszufinden brauche ich das Debuglog von den letzten Backuplauf wie auch das Debuglog vom Restorelauf. Kannst Du bitte einen Issue im github erstellen und die beiden Logs dort anhaengen? Gerne auch in Deustch. -> HTTPS://github.com/framps/raspiBackup/issues

    Cu framp


    Ja mache ich! Noch etwas ist mir aufgefallen: das vorhandene Tar Backup ist größer geworden ca. um die Menge der fehlenden Dateien.

    Dankeschön fürs kümmern!
    JK
    Zitieren
    #93 framp 2021-10-17 19:37
    Moin JK,

    das ist natuerlich sehr unschoen :sad: . Um die Ursache rauszufinden brauche ich das Debuglog von den letzten Backuplauf wie auch das Debuglog vom Restorelauf. Kannst Du bitte einen Issue im github erstellen und die beiden Logs dort anhaengen? Gerne auch in Deustch. -> HTTPS://github.com/framps/raspiBackup/issues

    Cu framp
    Zitieren
    #92 JK 2021-10-17 09:19
    Guten Morgen framp,

    einmal im Monat überspiele ich ein Restore auf einen Reserve USB Stick mit dem beschriebenen Aufruf, was bisher immer geklappt hat. Letzte Woche und auch heute wurde das Zurückspielen mit einer Fehlermeldung RBK0061E quittiert, dass keine Bootpartitionsdateien im Backupordner gefunden wurde. Mir ist dann im Backupordner aufgefallen, dass seit dem 10. Oktober die erfolgreich gemeldeten Backups ohne
    himberrypi-backup.img
    himberrypi-backup.mbr
    himberrypi-backup.sfdisk

    erstellt werden. An den Einstellungen habe ich nichts geändert. Ich fahre eine 0 4 12 0 Strategie. Alle Backups davor haben die fehlenden Dateien.

    Danke schonmal im Voraus und schöne Grüße
    JK
    Zitieren
    #91 framp 2021-09-12 15:53
    Moin Adocon,

    weiter oben auf dieser Seite ist die Fehlermledung 0021E beschrieben sowie moegliche Loesungsmoeglichkeiten. Meine Vermutung ist dass entweder eine Datei waehrend des Backupvorgangs geloescht wird oder sie geaendert wird. Dann liefert tar einen RC 1. Mit der zusaetzlichen Option -v bekommst Du raus welche Datei(en) das ist/sind.

    Cu framp
    Zitieren
    #90 Adocon 2021-09-12 15:27
    zitiere framp:
    Moin Adocon,

    da von Dir genutzte Backuptool (-t Parameter) hat einen Fehler bekommen. Du solltest aber weitere Fehlermeldungen von raspiBackup bekommen (Beginnen mit RBK) haben die den Fehler genauer eingrenzen.

    Cu framp


    Hallo framp,

    hier sind alle Zeilen in denen RBK vorkommt - so richtig habe ich aber trotzdem keine Idee woran es liegen könnte.

    more raspiBackup.log | grep RBK
    --- RBK0128I: Logdatei ist /media/nas-backup/@HOSTNAME@/@HOSTNAME@-tar-backup-20210911-220550/raspiBackup.log.
    --- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
    --- RBK0151I: Backuppfad /media/nas-backup mit Partitionstyp cifs wird benutzt.
    !!! RBK0157W: Keine Systemd Services sind zu stoppen.
    --- RBK0081I: Backup vom Typ tar wird in /media/nas-backup/@HOSTNAME@/@HOSTNAME@-tar-backup-20210911-220550 erstellt.
    --- RBK0036I: Partitionslayout wird gesichert.
    --- RBK0044I: Backup der Bootpartition wird in /media/nas-backup/@HOSTNAME@/@HOSTNAME@-tar-backup-20210911-220550/@HOSTNAME@-backup.img erstellt.
    --- RBK0044I: Backup des Partitionlayouts wird in /media/nas-backup/@HOSTNAME@/@HOSTNAME@-tar-backup-20210911-220550/@HOSTNAME@-backup.sfdisk erstellt.
    --- RBK0046I: Backup des Masterbootrecords wird in /media/nas-backup/@HOSTNAME@/@HOSTNAME@-tar-backup-20210911-220550/@HOSTNAME@-backup.mbr erstellt.
    --- RBK0158I: tar Backup "/media/nas-backup/@HOSTNAME@/@HOSTNAME@-tar-backup-20210911-220550/@HOSTNAME@-tar-backup-20210911-220550.tar" wird erstellt.
    --- RBK0085I: Backuperstellung vom Typ tar gestartet. Bitte Geduld.
    ??? RBK0021E: Backupprogramm des Typs tar beendete sich mit RC 1.
    --- RBK0033I: Bitte warten bis aufgeräumt wurde.
    --- RBK1001I: Speicherauslastung - Vor dem Backup - Belegt: 285 MB Frei: 143 MB - Nach dem Backup: Belegt: 162 MB Frei: 49 MB
    --- RBK1000I: CPU Temperatur vor und nach dem Backup: 47.8'C - 52.1'C
    --- RBK1002I: Partitionsauslastung vor dem Backup: Belegt: 6.37 TiB Frei: 4.09 TiB
    --- RBK1003I: Partitionsauslastung nach dem Backup: Belegt: 6.42 TiB Frei: 4.05 TiB
    --- RBK1004I: Änderung freier Platz: -50.38 GiB (-1.00 %)
    --- RBK0049I: Meldungen wurden in /home/@USER@/raspiBackup.msg gesichert.
    --- RBK0026I: Debug Logdatei wurde in /home/@USER@/raspiBackup.log gesichert.
    --- RBK0010I: @HOSTNAME@: raspiBackup.sh V0.6.6 (c8d3058) Sat 11 Sep 22:14:10 CEST 2021 beendet mit Returncode 109.
    ??? RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

    Cheers,
    Adocon
    Zitieren
    #89 framp 2021-09-11 23:02
    Moin Adocon,

    da von Dir genutzte Backuptool (-t Parameter) hat einen Fehler bekommen. Du solltest aber weitere Fehlermeldungen von raspiBackup bekommen (Beginnen mit RBK) haben die den Fehler genauer eingrenzen.

    Cu framp
    Zitieren
    #88 Adocon 2021-09-11 22:52
    Hallo,

    ich bekomme seit heute
    RBK0010I: sproxy: raspiBackup.sh V0.6.6 (c8d3058) Sat 11 Sep 22:14:10 CEST 2021 beendet mit Returncode 109

    cat /etc/os-release
    PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="10"
    VERSION="10 (buster)"
    VERSION_CODENAME=buster
    ID=raspbian
    ID_LIKE=debian

    sfdisk -v
    sfdisk from util-linux 2.33.1

    Das ganze trat hier schon einmal auf - leider finde ich die Lösung dazu nicht.

    Viele Grüße,
    Adocon
    Zitieren
    #87 framp 2021-09-10 09:53
    zitiere Klaus:
    weiß auch nicht, wo ich da was verbockt habe.

    Waere ja schon gut zu wissen warum es bei Dir dieses Problem gab. Dann koennte ich noch Code spendieren um das zukuenftig zu verhindern.

    Aber Hauptsache es funktioniert jetzt :-) Und nicht vergessen auch den Restore zu testen ;-)

    Cu framp
    Zitieren
    #86 Klaus 2021-09-10 07:18
    Hallo Framp,

    weiß auch nicht, wo ich da was verbockt habe.
    Die Neuinstallation hat es aber gebracht und der Backup wird erstellt.
    Vielen Dank für deine Unterstützung.

    MfG
    Klaus
    Zitieren
    #85 framp 2021-09-09 15:48
    Moin Klaus,

    ist schon merkwuerdig bei Dir :o . So ein Fall hatte ich noch nie. Bin gespannt ob es nach einer Neuinstallation klappt. jedenfalls keine eMail eingeben ;-)

    Bzgl Telegram: Das war fuer mich nicht ersichtlich. Aber es hat ja nicht geschadet den Link u maskieren. Sicher ist sicher :-)

    Cu framp
    Zitieren
    #84 Klaus 2021-09-09 14:46
    Hallo Framp,

    ich habe raspiBackup per angebotenem Install-Script aus "raspiBackup Schnellstart". Starte ich "raspiBackupInstallUI.sh" und rufe C8 auf, dann habe ich keinen Eintrag. Nach der Installation habe ich nur die /usr/local/etc/raspiBackup.conf geändert.
    Ich habe jetzt das Programm erneut installiert,
    dann sehen wir was passiert.

    Bezüglich Telegram: Ich war mir der Gefahr bewusst und hatte die Einträge geändert.

    MfG
    Klaus
    Zitieren
    #83 framp 2021-09-08 13:50
    Moin Klaus,

    im Log sehe ich immer noch dass eine eMail definiert wird. Hast Du die eMail vielleicht als Aufrufoption -e mitgegeben? Oder hast Du weitere Configdateien im EInsatz? Siehe dazu HTTPS://www.linux-tips-and-tricks.de/de/raspibackup/#parameter. Oder hast Du nicht /usr/local/etc/raspiBackup.conf geaendert?

    Ausserdem habe ich in Deiner vorherigen Antwort den Link zu der Config Datei vor dem publizieren maskiert da Du vergessen hast dass sich darin Deine Credentials fuer Telegram befinden und Du moechtest bestimmt nicht dass die jeder lesen kann :-)

    Cu framp
    Zitieren
    #82 Klaus 2021-09-08 12:40
    Hallo Framp,

    ich habe in der Conf-Date ab Zeile 65 das hier stehen:
    # emailadresse die das Backupergebnis erhält
    DEFAULT_EMAIL=""

    # Sender emailadresse die mit ssmtp benutzt wird
    DEFAULT_SENDER_EMAIL=""

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

    # mailprogram
    #DEFAULT_MAIL_PROGRAM="mail"
    DEFAULT_MAIL_PROGRAM=""

    Bekomme aber weiterhin:
    20210905-030018 DBG 3226: --- Parms:
    20210905-030018 DBG 3231: --- mail -s "@HOSTNAME@: Backup gestarted.
    20210905-030018 DBG 3231: --- MIME-Version: 1.0
    20210905-030018 DBG 3231: --- Content-Type: text/html; charset=utf-8" K@@@@e(18)
    /usr/local/bin/raspiBackup.sh: line 3232: mail: command not found
    20210905-030018 DBG 3234: --- mail: RC: 127

    Log und Conf unter: magentacloud.de/@@@@@@@@

    MfG
    Klaus
    Zitieren
    #81 Klaus 2021-09-05 20:44
    Hallo Framp,

    vielen Dank für die Recherche. Werde die Mailadresse löschen.

    MfG
    Klaus
    Zitieren
    #80 framp 2021-08-31 10:18
    Moin Klaus,

    vielen Dank fuer das Log. Darin finde ich

    20210829-030007 MSG 5289: ??? RBK0039E: Mail Program mail ist nicht installiert um eMail zu senden.

    und liege somit mit meiner vorherigen Annahme richtig :-)

    Die Loesung ist: Entweder installierst Du bei Dir einen MUA damit eine eMail gesendet werden kann oder Du loeschst Deine eingetragene eMail und disablest damit eMails.

    Cu framp
    Zitieren
    #79 Klaus 2021-08-31 09:46
    Hallo Framp.

    vielen Dank für die schnelle Antwort.
    Mail habe ich gar nicht installiert und habe dafür Telegram nutzen wollen. Log und conf findest du unter
    www.magentacloud.de/share/gul6os79rj

    Mfg
    Klaus
    Zitieren
    #78 framp 2021-08-29 17:56
    Moin Klaus,

    der RC 124 bedeutet dass ein Konfigurationsproblem mit dem benutzen Emailprogramm in der raspiBackup Config existiert. Was genau kann ich Dir nicht sagen da ich dazu das gesamte Debuglog benoetige.

    D.h. Du kontrollierst entweder noch mal die EMail Einstellungen bei raspiBackup oder Du stellst das gesamte Debuglog irgendwo ins Netz und gibst mir hier den Link darauf :-)

    Cu framp
    Zitieren
    #77 Klaus 2021-08-29 15:54
    Hallo,

    bin neuer Nutzer vom raspiBackup. Bekomme: Exit Coder 124:
    20210829-030007 DBG 5559: --> doitBackup 0
    20210829-030007 DBG 5312: --> getRootPartition
    20210829-030007 DBG 5317: *** cat /proc/cmdline
    20210829-030007 DBG 5317: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 smsc95xx.macaddr=DC:A6:32:DA:CB:F7 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 console=ttyS0,115200 console=tty1 root=PARTUUID=256f9dd5-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
    20210829-030007 DBG 5320: --- RootPartition: PARTUUID=256f9dd5-02
    20210829-030007 DBG 5324: inspect4Backup
    20210829-030007 DBG 5351: *** ls -1 /dev/mmcblk*
    20210829-030007 DBG 5351: ls: cannot access '/dev/mmcblk*': No such file or directory
    20210829-030007 DBG 5352: *** ls -1 /dev/sd*
    20210829-030007 DBG 5352: /dev/sda
    20210829-030007 DBG 5352: /dev/sda1
    20210829-030007 DBG 5352: /dev/sda2
    20210829-030007 DBG 5353: --- mountpoint /boot: 8:1 mountpoint /: 8:2
    20210829-030007 DBG 5368: --- Legacy boot discovery
    20210829-030007 DBG 5371: --- part: /dev/sda1
    20210829-030007 DBG 5374: --- bootDeviceNumber: 8:1
    20210829-030007 DBG 5375: --- rootDeviceNumber: 8:2
    20210829-030007 DBG 5440: --- BOOT_DEVICE: sda
    20210829-030007 DBG 5444: --- BOOT_DEVICENAME: /dev/sda
    20210829-030007 DBG 2013: --> getPartitionPrefix sda
    20210829-030007 DBG 2022: exitError
    .
    .
    .
    20210829-030008 DBG 3521: --- Terminate now with rc 124
    20210829-030008 MSG 3524: --- RBK0010I: @HOSTNAME@: raspiBackup.sh V0.6.6 (c8d3058) So 29. Aug 03:00:08 CEST 2021 beendet mit Returncode 124.
    20210829-030008 MSG 3546: ??? RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.
    124
    20210829-030007 DBG 1459:
    Zitieren
    #76 framp 2021-03-31 22:54
    Moin Wolfgang,

    in FAQ21 (HTTPS://www.linux-tips-and-tricks.de/de/fehlermeldungen/#M0021) wird beschrieben dass man mit der Option -v herausfinden kann welche Datei das Problem verursacht ;-)

    Cu framp
    Zitieren