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 muss diese einfach nur in einem Kommentar am Ende dieser Seite genau angeben 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.

RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

RBK0019E: Option -a und -o nicht angegeben.

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

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

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.

RBK0105I: Neues Backupverzeichnis %1 wird gelöscht.

RBK0142E: Bootgerät kann nicht erkannt werden.

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

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

RBK0193W: %1 unterstützt keine Hardlinks.

 

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.


RBK0019E: Option -a und -o nicht angegeben.

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. Mit den beiden Optionen wird definiert was gestoppt und gestartet werden soll.

Weitere Aktionen:

Die beiden Optionen mit entsprechenden Parametern müssen beim Aufruf mitgegeben werden. Details dazu finden sich auf der FAQ Seite.

 

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 und tar Backup melden eine Lese- oder Schreibfehler einer Datei. Bei rsync bedeutet RC 23 oder 24 dass sich eine Datei während der Sicherung verändert hat.

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

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

 

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

 

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.

 

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.

 

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.

 

RBK0193W: %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 ignoriere diese Meldung. Berücksichtige aber dass jeder Backup ein Vollbackup ist und entsprechend mehr Zeit und Platz benötigt.
 

Kommentar schreiben

Hinweis

Spam Kommentare werden gelöscht und nicht veröffentlicht. Die Überprüfung wird manuell vorgenommen und deshalb dauert es i.d.R. zwischen ein paar Stunden bis zu einem Tag bis ein Kommentar veröffentlicht wird.

Kommentare   
#16 framp 2018-11-07 23:46
Hm ... wie sieht denn Dein Aufruf von raspiBackup genau aus? Vielleicht ist da ja noch in der Beta ein kleines Problem :oops:
Zitieren
#15 Jochen 2018-11-07 23:42
Mit der Beta kam erst die Meldung "-T Parameter keine Zahl", obwohl ich den gar nicht angegeben hatte. Mit -T "1 2" läuft es jetzt erst mal, und es wurde tatsächlich ein Backup erzeugt. Ist natürlich erstmal alles Quatsch rein virtuell, aber ich kann jetzt die Modi und Email-Einstellungen in Ruhe probieren.
Riesensache, das Ganze. Nochmals ganz dicke Danke!
Zitieren
#14 framp 2018-11-07 23:28
Moin Jochen,

jupp, Benutze die Beta. Die sollte dann keinen RBK0142E mehr liefern. Wenn doch erstelle das Debuglog mit -l debug und schicke es mir per eMail (siehe Kontakt Seite) zwecks Analyse zu.

Cu framp
Zitieren
#13 Jochen 2018-11-07 23:24
Danke für die Superschnelle Reaktion. Tatsächlich gibt es (zu meiner Überraschung, keine Ahnung seit wann) unter https://www.raspberrypi.org/downloads/ ein "RaspbianDesktop" zum Download, das tatdellos in VM läuft. Natürlich auf der anderen Architektur und mit einigen Unterschieden. Aber fast alles klappt, was in Verbindung mit Snapshot perfekt zu Rumprobieren ist.

Tatsächlich liegt /boot auf der gleichen Partition wie der Rest. Ich kann ja mal die Beta probieren.
Zitieren
#12 framp 2018-11-07 23:12
Moin Jochen,

mir ist nicht klar wie Du raspbian in VB laufen lassen kannst denn VB kann keine ARM Instruktionen emulieren :-? Ich vermute Du hast das i386 Raspbian Image in die VB gebracht. Die Frage ist ob da das Partitionslayout genauso aussieht wie bei der ARM Version.

Es muss die Raspbian Partitionsstruktur vorhanden sein. /boot muss existieren. Die Version 0.6.4 verlangt dass /boot auf einer separaten Partition zu / liegt. In der aktuellen 0.6.4.1 Beta kann /boot auch auf derselben Partition wie / liegen.

Cu framp
Zitieren
#11 Jochen 2018-11-07 22:50
Ich habe Raspbian-Desktop in einer VirtualBox laufen um alles mögliche erstmal in Sicherheit auszuprobieren.
Im Prinzip ist das klasse, klappt aber nicht, wenn etwas bestimmte Dinge voraussetzt.
raspiBackup erkennt beispielsweise kein Bootgerät (RBK0142E), vermutlich weil die "Platten" anders heißen.
Kann ich da etwas machen, um es trotzdem laufen zu lassen, um beispielsweise Optionen gefahrlos zu testen?

Mein Layout ist in der VirtualBox (lsblk):

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 32G 0 disk
├─sda1 8:1 0 31G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 1022M 0 part [SWAP]
sdb 8:16 0 16G 0 disk
└─sdb1 8:17 0 16G 0 part /media/usb
sr0 11:0 1 1024M 0 rom

Auf meinem echten Raspi benutze ich das Script schon seit einiger Zeit und es hat mich auch schon einige Male gerettet, dafür meinen allerherzlichsten Dank!
Zitieren
#10 framp 2018-08-21 20:38
Moin Ric,

nein, da habe ich offensichtlich was uebersehen :oops: .

Starte das Backup bitte noch einmal mit der zusaetzlichen OptionCode:-l debug und schicke mir das Debuglog an meine eMailAdresse zwecks Fehleranalyse (eMail siehe Kontakt Seite).

Danach gehet wieder auf die vorherige Version mit Option -U zurueck bis ich das Problem gefixed habe.

Cu framp
Zitieren
#9 Ric 2018-08-21 10:02
Seit dem letzten Update V0.6.4 wird mir folgender Fehler angezeigt:

/boot und root befinden sich auf demselben Gerät mmcblk0p2.
/boot und root auf demselben Gerät sind nicht unterstützt bei dem Backuptyp rsync. Benutze dd

Das Backup hat jahrelang ohne Probleme funktioniert. Habe ich eine Änderung übersehen?
Zitieren
#8 framp 2018-08-20 19:18
Mir war die Konsequenz nicht bewusst. Das muss ich aendern. Du hast ja schon einen Vorschlag wie ich das verbessern koennte. Man koennte auch zur Laufzeit pruefen ob xattrs unterstuetzt sind und dann das X mit einer Warnmeldung rausnehmen. Mal sehen was ich finde :-)
Zitieren
#7 Marc 2018-08-20 13:21
zitiere framp:
Ich habe das X bei den rsync Optionen bei der Version 0.6.4 zugefuegt :oops:


Na dann ist die Erklärung wenigstens da :-)
Und beim nächsten Anflug von Langeweile kannst du ja beim Setup abfragen, ob NFS genutzt wird... und dann... usw :-)
Bei mir läuft nun zumindest wieder alles wie am Schnürchen! Kein NFS hätte Verzicht auf Hardlinks bei meiner QNAP bedeutet, das wäre blöder gewesen...
Zitieren
#6 framp 2018-08-19 17:15
Moin Marc,

ich habe noch mal im git Repo genauer nachgesehen und Du hast Recht: Ich habe das X bei den rsync Optionen bei der Version 0.6.4 zugefuegt :oops: . Ich muss gestehen dass mir das nicht mehr bewusst war. Letztendlich sollten ja xattrs gesichert werden und sofern Du kein nfs benutzt funktioniert das auch. D.h. aber auch dass zukuenftig jeder mit nfs diese Meldung bekommt.
Die Loesung das X in der Konfigurationsoption DEFAULT_RSYNC_BACKUP_OPTIONS rauszunehmen wie Du es getan hast ist die beste Loesung. Somit ist sich jeder bewusst dass keine xattrs gesichert werden.

Ich habe noch nie gehoert dass das ein Problem war. Aber ein Benutzer von raspiBackup sollte sich bewusst sein dass sein Backup nicht ganz dem Original entspricht :-)

Cu framp
Zitieren
#5 Marc 2018-08-19 12:44
zitiere framp:
Ursache ist dass nfs keine xattrs unterstuetzt. Ich vermute mal Du hast einen Update Deines OS gemacht oder eine neue SW installiert die xattrs benutzt.


Danke... habe gestern Abend schon getestet und in den rsync Options dann das "X" weg gelassen, damit ging es dann einwandfrei. Habe auch schon überlegt ob ich ein dickes OS Upgrade gemacht habe, aber komme nicht mehr drauf. Ist wirklich seltsam... auf dem einen Pi sind es nur zwei Dateien, auf dem anderen aber locker 10. Muss ja durch irgendwas kommen!
Zitieren
#4 framp 2018-08-18 20:27
Moin Marc,

das ist ein bekanntes Problem.

Siehe dazu hier.

Auf den FAQ habe ich beschrieben wie man es fuer acl verhindern kann. Das sollte auch fuer xaatr funktionieren.

Ursache ist dass nfs keine xattrs unterstuetzt. Ich vermute mal Du hast einen Update Deines OS gemacht oder eine neue SW installiert die xattrs benutzt.

Wie ich rauslese benutzt Du eine neuere Version von raspiBackup (Vermutlich 0.6.4). Du kannst auf die vorherige Version mit Option -U zurueckgehen und noch mal testen. Du wirst aber denselben Fehler bekommen.

Cu framp
Zitieren
#3 Marc 2018-08-18 13:40
Hallo,

seit heute laufen auf zwei Rai meine Backup Jobs nicht mehr... Ziel ist ein QNAP via NFS

Fehler ist jeweils sowas

rsync: rsync_xal_set: lsetxattr(""/backup/GProxy/GProxy-rsync-backup-20180818-132050/usr/bin/systemd-detect-virt"","security.capability") failed: Operation not supported (95)

Irgendeine Idee dazu? Google meint das es irgendwas mit den erweiterten Rechten zu tun hat (der X Switch von rsync??)... hat sich da mit der letzten Version was geändert? Hatte zuerst meine QNAP / dortiges FW Update im Verdacht... aber nach einem Downgrade dort besteht der Fehler weiterhin!
Zitieren
#2 framp 2018-08-16 19:11
Moin Markus,

das ist hier genau der richtige Platz um die Frage zu stellen. Ich habe die Fehlermeldungen oben in der Liste aufgenommen. Sollte das nicht zur Loesung des Problems ausreichen lass mich wissen und ich erweitere die Erklaerungen.

Cu framp
Zitieren
#1 Markus Berg 2018-08-16 17:10
Hallo,

ich bekommen beim Versuch einen Prozess vor dem Backup zu stoppen die folgende Fehlermeldung:

08-16-2018 17:06:04 ??? RBK0048E: Ein Fehler trat beim Beenden von Services auf. RC 1.

Beim Versuch den Service wieder zu starten, kommt dann die korrespondierende Meldung:
08-16-2018 17:06:09 ??? RBK0047E: Ein Fehler trat beim Starten von Services auf. RC 1.

Leider habe ich hier keine Lösung gefunden?
Danke für eine kurze Info.
VG
Markus
Zitieren