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.

Sollte die Information zu einer Meldung nicht ausreichen hilft es oft wenn man die Meldungsnummer (RBK....) in einer Suchmaschine eingibt.

 

Liste der meisten Fehlermeldungen

 

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.

RBK0178E: Erzeugung von %s Datei endet fehlerhaft mit RC %s.

RBK0196W: %s unterstützt keine Hardlinks.

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

RBK0203E: 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.

RBK0268E: Es werden nur Raspberries mit Raspberry PI OS unterstützt.

RBK0273E: %s ungültige Backupverzeichnis(se) in %s gefunden.

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

Beschreibung der meisten Fehlermeldungen

 

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.

RC23 bei rsync kann auch ein Zugriffsproblem sein.

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. Es kann auch sein dass Berechtigungen auf dam Backupgeraet fehlen. Die entsprechenden Fehlermeldungen vom Backuptool findet man wenn im die auf executeCmd Command folgenden Zeilen im Debuglog untersucht.

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.

Falls Berechtigungsprobleme existieren muss sichergestellt sein dass der Benutzer root sämtliche Rechte auf dem Backupgerät hat.

 

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.

 

RBK0178E: Erzeugung von %s Datei endet fehlerhaft mit RC %s."

Ursache:

dd Backup der Bootpartition schlägt mit einem Fehlercode fehl. Fehlercode RC1 ist ein Eingabe-/Ausgabefehler.

Weitere Aktionen:

Sieh nach was der Fehlercode von dd bedeutet. Wenn es RC1 ist prüfe die Bootpartition und/oder die Backuppartition.

 

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 beim Aufsetzen der benachrichtigung meist 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. In jedem Falle sollte man nachsehen was der RC des Mailclients bedeutet und kann daraus Hinweise finden wo die Ursache liegt. Z.B. kann es auch sein dass der Mailempfänger Probleme hat die eMail zu empfangen.
 

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.

 

RBK0268E: Es werden nur Raspberries mit Raspberry PI OS unterstützt.

Ursache:

raspiBackup wird nur für Raspberries und Raspbian unterstützt. Man kann mit der Option --unsupportedEnvironment trotzdem versuchen raspiBackup zu nutzen denn es läuft auch unter vielen anderen Linux Distributionen und raspberrykompatibler Hardware. Bei Fehlern wird aber wegen fehlender Testhard- und Software und -zeit kein Support geliefert. Siehe dazu auch hier

 

Weitere Aktionen:

Nutzung der Option --unsupportedEnvironment und hoffen dass raspiBackup mit der vorhandenen Software und Hardware umgehen kann.

 

RBK0273E: %s ungültige Backupverzeichnis(se) in %s gefunden."

Ursache:

Es dürfen im Backupverzeichnis eines Systems nur von raspiBackup erstellte Backupverzeichnisse existieren. Jegliche anderen Verzeichnisse oder Dateien erzeugen diese Fehlermeldung.

 

Weitere Aktionen:

Löschen oder Verschieben der nicht von raspiBackup erstellten Verzeichnisse oder Dateien an andere Plätze.

 

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.

Exitcodes

Im Normalfall terminiert raspiBackup mit einem Fehlercode 0. Im Falle eines Fehlers terminiert raspiBackup mit einem der folgenden Fehlercodes. Eine Fehlermeldung gibt noch genauere Informationen zu der Fehlerursache aus.

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

RC_UNSUPPORTED_ENVIRONMENT=132
RC_RESTORE_EXTENSION_FAILS=133
RC_BACKUP_EXTENSION_FAILS=134
RC_DOWNLOAD_FAILED=135
RC_BACKUP_DIRNAME_ERROR=136
RC_RESTORE_IMPOSSIBLE=137

 

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   
    #135 framp 2022-03-20 15:50
    Dachte ich es mir doch :-) Manchmal fixed sich ein Problem auch selbst :lol:
    Zitieren
    #134 JK 2022-03-20 15:24
    zitiere framp:
    Moin JK,

    ich wuerde an Deiner Stelle den naechsten Backuplauf abwarten und erst wenn es das Problem immer noch gibt detailierter reinsehen.

    Cu framp


    framp funktioniert wieder!

    Schönen Sonntag!
    Zitieren
    #133 framp 2022-03-13 10:45
    Moin JK,

    eben habe ich die Beschreibung zu 197W noch ein wenig erweitert. Du musst den RC Deines eMailClients nachsehen. Der wird Dir weitere Infos ueber die Ursache geben.

    Mir scheint das das ein temporaerer Fehler in der Nacht waehrend des Backups war denn sonst wuerdest Du das Problem heute morgen auch im Fakemodus haben. Hinweise ueber die Ursache findest Du u.U. auch in eMail Client Logs.

    ich wuerde an Deiner Stelle den naechsten Backuplauf abwarten und erst wenn es das Problem immer noch gibt detailierter reinsehen.

    Cu framp
    Zitieren
    #132 JK 2022-03-13 09:12
    Guten Morgen,

    die Benarichtigungmail des wöchentlichen Backups wurde heute nicht versendet. Bisher hatte es immer funktioniert. Im Log findet sich dazu folgender Eintrag:

    RBK0197W: eMail mit mail versenden endet fehlerhaft mit RC 36

    Ein Änderung der Maileinstellungen habe ich nicht vorgenommen. Beim Simulationsaufruf ist der Mailversand allerdings erfolgreich.

    Eine Internetsuche hat leider nichts ergeben. Raspian Buster und raspiBackup sind aktuell. Hast Du eine Idee woran es liegen kann?

    Besten Gruß
    JK
    Zitieren
    #131 Bernd 2022-03-06 23:46
    ja, außer das andere image habe ich nichts anderes gemacht.
    Zitieren
    #130 framp 2022-03-06 22:16
    Hm ... funktioniert es jetzt? Eigentlich kann ich mir nicht vorstellen dass es daran liegt.
    Zitieren
    #129 Bernd 2022-03-06 22:15
    so, jetzt weiß ich, wo das Problem lag: Ich verwendete die 64bit-Version von RaspiOs. Wer weiß, vielleicht hat die ja einen Fehler.
    Zitieren
    #128 framp 2022-03-06 18:53
    Das ist wirklich merkwuerdig. Beachte dass raspiBackup nur fuer Raspberries und RaspberryPiOS unterstuetzt wird ;-)
    Zitieren
    #127 Bernd 2022-03-06 18:51
    seltsam. Ich bekomme immer noch die gleiche Fehlermeldung. Dann will ich mal morgen das ganze neu aufsetzen. Danke für deine Hilfe.
    Zitieren
    #126 framp 2022-03-06 17:33
    Hm ... merkwuerdig. bernd:bernd - was ich erwarte - passt nicht zu root:UNKNOWN.

    Aber wie das kommt kann ich mir nicht erklaeren.

    Mein Vorschlag: Fuehre folgendende Befehle aus um den Installer manuell zu installieren:

    1) Loesche das # in dem Script wieder was Du vorhin eingefuegt hast

    2) sudo chown root:root /usr/local/bin/raspiBackupInstallUI.sh

    3) sudo chmod +x /usr/local/bin/raspiBackupInstallUI.sh

    Danach solltest Du den Installer mit

    sudo raspiBackupInstallUI.sh

    aufrufen koennen.

    Cu framp
    Zitieren
    #125 Bernd 2022-03-06 17:23
    ok, hier die Ausgaben:
    1. bernd:bernd
    2. -rwxr-xr-x 1 bernd bernd 163322 6. Mär 17:17 /usr/local/bin/raspiBackupInstallUI.sh
    Zitieren
    #124 framp 2022-03-06 17:10
    Ok. Dann mache mal bitte folgendes:

    1) Lade das Installationsscript runter mit

    wget HTTPS://raw.githubusercontent.com/framps/raspiBackup/master/installation/raspiBackupInstallUI.sh

    2) Aendere folgende Zeile darin

    trapWithArg cleanup SIGINT SIGTERM EXIT

    in

    #trapWithArg cleanup SIGINT SIGTERM EXIT

    3) Dann rufe den Installer auf mit

    sudo bash ./raspiBackupInstallUI.sh

    4) und zeige die Ausgabe von

    stat -c "%U:%G" /usr/local/bin/raspiBackupInstallUI.sh

    wie auch

    ls -la /usr/local/bin/raspiBackupInstallUI.sh

    Cu framp
    Zitieren
    #123 Bernd 2022-03-06 16:52
    Hier das Log. Der Anfang ist unauffällig, schicke ich dir aber gerne komplett.
    20220306-163432: DBG: 1628 - -> code_download_execute
    MSG: RBI0002I: raspiBackup.sh wird aus dem Netz geladen...
    MSG: RBI0015I: /usr/local/bin/raspiBackup.sh wurde erstellt.
    MSG: RBI0015I: /usr/local/bin/raspiBackupInstallUI.sh wurde erstellt.
    chown: ungültige Gruppe: „root:UNKNOWN“
    20220306-163433: DBG: 2297 - -> unrecoverableError 17
    /usr/local/bin/raspiBackupInstallUI.sh: DBG: 0000 -
    20220306-163433: DBG: 2300 - Progressbar error occured 17
    /usr/local/bin/raspiBackupInstallUI.sh: DBG: 0000 -
    20220306-163433: DBG: 1704 -
    Zitieren
    #122 framp 2022-03-06 14:54
    Moin Bernd,

    mir scheint irgendwas an Deinem System nicht in Ordnung zu sein.

    Was steht denn im Debuglog raspiBackupInstallUI.log ?

    Cu framp
    Zitieren
    #121 Bernd 2022-03-06 14:44
    Hi Framp,

    heute wollte ich raspiBackup auf einem neuen Pi installieren, was schief ging. Im Log steht folgendes:
    MSG: RBI0015I: Created /usr/local/bin/raspiBackup.sh.
    MSG: RBI0015I: Created /usr/local/bin/raspiBackupInstallUI.sh.
    chown: ungültige Gruppe: „root:UNKNOWN“
    2297 - -> unrecoverableError 17

    Was läuft schief?

    Viele Grüße
    Bernd
    Zitieren
    #120 JK 2022-02-12 15:06
    zitiere framp:
    Moin JK,
    ich habe eben noch mal die Extensions per Installer unter Linux runtergeladen. RC 4 heisst bei wget "network error". Ich stimme Dir zu dass da eigentlich nicht sein kann ... aber irgendwo da liegt das Hase im Pfeffer :-)
    Cu framp


    Funktioniert wieder, ohne mein zutun!

    Beste Grüße
    Zitieren
    #119 framp 2022-02-09 00:23
    Moin JK,

    ich habe eben noch mal die Extensions per Installer unter Linux runtergeladen. RC 4 heisst bei wget "network error". Ich stimme Dir zu dass da eigentlich nicht sein kann ... aber irgendwo da liegt das Hase im Pfeffer :-)

    Cu framp
    Zitieren
    #118 JK 2022-02-08 23:15
    Hallo framp,

    beim Versuch die zusätzlichen Komnponenten herunterzuladen kommt folgende Meldung:

    "RBI0021E: Es kann nicht auf www.linux-tips-and-tricks.de zugegriffen werden. wget RC: 4"

    Kann mir zwar nicht vorstellen, dass das damit zusammenhängt, aber ich habe seit drei Wochen einen neuen Provider. Anpingen Deiner Seite funktioniert übrigens.

    Version ist 0.6.6.1

    Schönen Gruß
    Zitieren
    #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