Häufige Fragen zu raspiBackup. Jeder neue Benutzer von raspiBackup sollte sich einmal alle Fragen und Antworten durchlesen.

 

 

0) Wie entstand raspiBackup?

Bei mir laufen zu Hause drei Raspis. Zwei davon 7/24 - also rund um die Uhr. Ein jeder Server sollte regelmäßig gesichert werden denn es können immer mal unvorhergesehene Umstände eintreten, die eine Wiederherstellung eines vorherigen Standes erfordern. Speziell die SD Karte der Raspberry neigt dazu immer mal wieder auszufallen. Um dafür gewappnet zu sein habe ich mir ein kleines S

 

 

 

 

cript geschrieben, welches zuerst ein dd Backup, dann später, da ein dd Backup ja immer die gesamte SD Karte sichert obwohl nur Bruchteile davon benutzt werden, ein tar Backup automatisch erstellte. Zum Schluss wurde dann ein rsync Backup implementiert. Nachdem ich dann mehrere Male eine Wiederherstellung vornehmen musste und alles gut klappte dachte ich mir dass es vielleicht auch anderen Raspberryfreunden hilfreich sein könnte und publizierte raspiBackup.

1) Ist ein Backup eines laufenden Systems zuverlässig? Sollte nicht das gesamte System vor dem Backup gestoppt werden ?

Die sicherste Methode ist natürlich das System vollständig zu stoppen. Das kann man aber leider nicht regelmäßig und automatisch von cron gesteuert vornehmen. Wenn man alle aktiven Services wie mysql, samba, nfs, seafile, Owncloud, Webserver und alle anderen aktiven Services immer vor dem Backup stoppt um keine Dateninkonsistenzen zu erzeugen kann das Backup zum Wiederherstellen der Raspi genutzt werden. Stoppt man die Servies nicht besteht eine hohe Wahrscheinlichkeit dass das Backup inkonsistent werden wird. Dazu gibt es die Parameter -a und -o um die entsprechenden Stop- und Startbefehle vor bzw nach dem Backup auszuführen. Siehe auch FAQ 18 dazu. Alternativ kann ein Beispielwrapperscript erweitert werden (Siehe hier).

2) Wie kann ich ein Backup wiederherstellen?

Mit raspiBackup kann jedes Backup wieder zurückgespielt werden (Siehe hier die Details). Es wird aber ein Linux benötigt. Als Windowsbenutzer kann man win32diskimager benutzen um dd Backups wiederherzustellen. Für andere Backuptypen wie tar oder rsync ist ein Linux notwendig.

Allerdings kann man dazu die Raspberry benutzen: Man bespielt eine neue SD Karte mit raspbian und kopiert darauf raspiBackup. Dann schließt man einen externen SD Kartenleser, in die man eine SD Karte, die den Restore erhalten soll, einschiebt - sowie das Medium mit dem Backup an die Raspberry an. Danach ruft man raspiBackup auf und läßt ein gewünschtes Backup auf die externe SD Karte zurückschreiben. Anschliessend fährt man das System runter, legt die SD Karte mit dem zurückgespielten Backup ein und startet die Raspberry wieder.

3) Was kann raspiBackup alles sichern und wiederherstellen?

Im normalen Modus kann raspiBackup entweder zwei Partitionen sichern mit tar oder rsync: Die Boot und die Rootpartition die auf der SD Karte liegen. Wenn die Rootpartition auf ein externes Medium verlagert wurde wird auch die externe Rootpartition gesichert. (raspiSD2USB.py hilft bei der Verlagerung). Mit dem dd Backup wird die gesamte SD Karte gesichert. Dann wird aber keine externe root Partition mitgesichert.

Im partitionsorientierten Modus werden beliebig viele Partitionen der SD Karte gesichert. Weitere externe Partitionen werden aber nicht gesichert. Dieser Modus ist sinnvoll z.B. für NOOBS Installationen. Wer die NOOBS installation per windisk32imager restoren will muss den dd Backup im normalen Modus benutzen.

4) Welche Linux Sicherungsmethoden stehen zur Verfügung?

Es steht der dd Backup sowie der tar und rsync Backup zur Verfügung. dd und tar Backups können noch mit zip komprimiert werden. Auf dieser Seite können die Vor- und Nachteile der jeweiligen Backupmethoden nachgelesen werden.

5) Kann man die Sicherung auch ohne raspiBackup wiederherstellen?

Das ist eine Grundvoraussetzung für raspiBackup gewesen: Es muss möglich sein das Backup mit entprechenden Linuxkenntnissen zu Fuss restoren zu können.

Die Sicherung legt Dateien an, die die lesbaren Ausgaben von den Linux Befehlen sfdisk, blkid und fdisk von der SD Karte enhält. Damit läßt sich zuerst die Partitionsstruktur des Backups mit den entsprechenden Linuxtools wiederherstellen. Danach kann man die Partitionsbackups mit den entsprechenden Linuxtools wieder auf die Partitionen zurückspielen.

6) Kann man die Sicherungen mit raspiBackup auch auf kleiner und größere SD Karten wiederherstellen?

Auf größere Karten funktioniert das ohne Probleme. Allerdings benutzt das Image genau den Platz, den es im Original benutzt hat. Der restliche Speicherplatz wird nicht genutzt und muss mit Linux Repartitionierungstools nach der Wiederherstellung angepasst werden.

Das funktioniert sowohl für kleinere als auch größere SD Karten ohne Probleme sofern tar oder rsync Backup und der normale Backupmodus benutzt wird. Es wird automatisch die Größe der root Partition entsprechend angepasst, d.h. entsprechend verkleinert oder vergrößert. Bei einer Vergrößerung wird die gesamte SD Karte benutzt. Wird von der Backup SD Karte mehr Platz benutzt als die Restore SD Karte hat gibt es natürlich Fehler beim Restore. Beispiel: Backup SD Karte ist 32GB gross und 24GB werden benutzt. Die Restore SD Karte ist nur 16GB gross.

Mit der Option -0 (Null) wird keine Partitionierung der neuen SD Karte vorgenommen sondern die existierende Partitionierung der SD Karte genutzt. Man hat damit vollständige Kontrolle über die Größe der Wiederhergestellten Partitionen. D.h. man kann dadurch vor dem Restore genau festlegen, wie gross die Partitionen auf der neuen SD Karte sein sollen und somit auch auf kleiner SD Karten restoren. Das geht auch für partitionsorientierte Backups.

Ein dd Backup kann nicht auf eine kleiner Karte restored werden. Vorher muss es verkleinert werden. Das geht z.B. so. Oder man benutzt pishrink

7) Wie kann ich die Partitionierung der Ziel SD Karte beeinflussen?

Es gibt zwei Optionen die das Partitionierungsverhalten von raspiBackup beeinflussen: Option -1 (eins) zwingt raspiBackup die Partitionierung der Backup SD Karte auf die Ziel SD Karte zu erstellen auch wenn die Partitionen kleiner oder größer als die Ziel SD Karte sind. Mit der Option -0 (Null) nimmt raspiBackup keine Paritionierung vor und verwendet die existiernde Partition der Ziel SD Karte. Somit kann man vor dem Restore die Partitionen anlegen und formatieren wie man sie haben möchte und diese wird dann von raspiBackup benutzt.

8) Auf welchen Medien kann man mit raspiBackup die Backups ablegen?

Generell auf jedem Device welches unter Linux gemounted werden kann

  • Externer USB Stick
  • Externe USB Platte
  • Synology
  • cifs/samba Netzwerklaufwerk
  • nfs Netzwerklaufwerk
  • sshfs Netzwerklaufwerk
  • webdav Netzwerklaufwerk
  • ftpfs Netzwerklaufwerk

9) Die Funktion von raspiBackup reicht nicht aus und es muss noch zusätzlich etwas vor oder nach dem Backup getan werden

Da gibt es verschiedene Möglichkeiten:

a) Ein Wrapperscript (Siehe hier) wird benutzt und nimmt vor und nach dem Backuplauf weitere Aktionen vor wie z.B. weitere Dinge zu sichern.

b) Beliebige Erweiterungspunkte (Extensions) können vor und nach dem Backup von raspiBackup aufgerufen werden. Zwei Beispielerweiterungen (Siehe hier) melden zusätzlich die CPU Temperatur vor und nach dem Backuplauf sowie den belegten Hauptspeicher. Eine eMailExtension erlaubt es beliebige andere eMailClients anzusteuern.

10) Welche eMailClients werden von raspiBackup unterstützt?

raspiBackup unterstützt mailx, ssmtp und sendEmail. Andere eMailClients können über ein eMail Erweiterung (Extension) angesprochen werden (Details siehe hier).

11) Mein eMailClient wird leider nicht von raspiBackup unterstützt. Wie kann ich trotzdem eMails erhalten?

raspiBackup kann eine eMailErweiterung (extension plugpoint) zum Senden der eMail benutzen. Dazu muss ein kleines Script geschrieben werden, welches die eMailParameter entsprechende dem verwendeteten eMailClient aufbereitet und den eMailClient mit der korrekten Syntax aufruft. Eine Beispielerweiterung für mailx ist bei den Erweiterungsbeispielen enthalten.

12) Ich habe eine Frage zu raspiBackup. Wie bekomme ich eine Antwort?

Es gibt verschiedene Optionen:

1) In Github koennen Problemberichte (Issues) erstellt werden. Das ist meine präferierte Option. Dazu ist eine einmalige Registrierung notwendig. Diese sowie die Benutzung von github ist umsonst.

2) Am Ende jeder Webseite können Kommentare erstellt werden. Diese sind ideal um Fragen zu stellen. Um Spam zu vermeiden werden die Kommentare manuell kontrolliert und deshalb dauert es i.d.R. einen Tag bis der Kommentar veröffentlicht und beantwortet wird. Die eMailAdresse, die man dort optional angeben kann, wird nicht veröffentlicht. Sie ist notwendig wenn man über weitere Kommentare informiert werden will und sie wird auch im Bedarfsfalle genutzt um offline in Kontakt zu treten.

3) Auf Facebook können Kommentare erstellt werden. Eine Registrierung ist dafür notwendig.

Siehe auch diese Hinweise

13) Ich habe einen Fehler in raspiBackup gefunden. Wo kann ich den Fehler melden und wann bekomme ich einen Fix dafür?

Wie in jeder Software kann es vorkommen, dass auch raspiBackup Fehler hat. Die verschiedenen Kanäle über die Probleme berichtet werden können sind hier beschrieben.

14) Bekomme ich irgendwie automatisch mit dass es eine neue Version von raspiBackup gibt?

raspiBackup prüft bei jedem Aufruf ob es eine neuere Version gibt. Wenn ja wird eine entsprechende Meldung ausgegeben und die Benachrichtigungsemail weist im Titel mit einem Smiley ;-) darauf hin. Dann kann man auf dieser Seite nachlesen was die neue Version bringt und dann mit dem Parameter -U einen Versionsupdate vornehmen lassen.

15) Wie kann ich auf eine vorhergehende raspiBackup Version zurückgehen wenn ich nach einem Upgrade bemerke, dass die neue Version nicht so funktioniert wie ich es erwarte?

raspiBackup erstelt jedes mal wenn mit der Option -U eine neue Version aktiviert wird eine Sicherungskopie. Mit der Option -V kann man jederzeit auf eine vorhergehende Version zurückgehen. Es wird eine Liste von alle gesicherten raspiBackup Versionen angezeigt und man kann die Version, die zurückgespielt werden soll daraus auswählen.

16) Ich habe eine 32GB SD Karte wovon ich nur 8GB benötige. Ein dd Backup sichert aber immer 32GB, d.h 24GB zu viel.

Der dd Backup sichert immer die ganze SD Karte. Es gibt den Konfigurationsparameter DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY, der dafür sorgt, dass nur die definierten Partitionen gesichert werden. D.h. man muss mit gparted oder einem anderen Partitionierungstool nur eine kleinere Partition von 8GB erstellen. Die aktuellen Partitionsgrößen kann man mit dem Befehl lsblk kontrollieren.

17) Wie kann ich feststellen, dass der rsync tatsächlich Backup Hardlinks benutzt um Speicherplatz zu sparen?

Hardlinks werden erfolgreich von raspiBackup benutzt wenn ein lokaler USB Stick, eine lokale USB Platte oder auch eine per nfs gemountete Partition, die mit ext3/ext4 formatiert ist, benutzt wird. Samba sowie sshfs unterstützt keine Hardlinks.

Der Befehl du -sh * zeigt den tatsächlich benutzen Speicherplatz an und du -shl * zeigt den Speicherplatz an, der belegt werden würde, wenn keine Hardlinks benutzt werden würden.

Beispiel:

root@raspberrypi:/media/nas-backup/raspberrypi# du -sh *
4,5G raspberrypi-rsync-backup-20160822-184617
4,5M raspberrypi-rsync-backup-20160822-190436
5,2M raspberrypi-rsync-backup-20160822-195250
5,7M raspberrypi-rsync-backup-20160822-201610

root@raspberrypi:/media/nas-backup/raspberrypi# du -shl *
4,7G raspberrypi-rsync-backup-20160822-184617
4,7G raspberrypi-rsync-backup-20160822-190436
4,7G raspberrypi-rsync-backup-20160822-195250
4,7G raspberrypi-rsync-backup-20160822-20161

18) Welche Services muss man vor dem Backup stoppen und anschliessend wieder starten?

Alle Services die irgendwelche Systemzustände in Datenbanken oder im Speicher oder auf dem Dateisystem speichern müssen gestoppt werden damit nicht während des Backups inkonsistente Datenstände entstehen, die dann erst beim wiederhergestellten System bemerkt werden und das Backup unbrauchbar machen. raspiBackup bietet zum Stoppen von Services vor dem Backup den Parameter -o und zum Starten der Services nach dem Backup den Parameter -a an.

Folgende Services sollten auf alle Fälle mit der Option -o gestoppt werden:

Service Stop Befehl
nfs service nfs-kernel-server stop
Samba service samba stop
Pilight service pilight stop
Cups service cups stop
Minidlna service minidlna stop
Apache service apache2 stop
Wordpress service wordpress stop
nginx service nginx stop
mysql service mysql stop
seafile service seafile stop
Owncloud Siehe Apache
FHEM /etc/init.d/fhem stop
cron service cron stop

 

Die Services sollten dann per Option -a wieder gestartet werden. Die Reihenfolge sollte dann genau umgekehrt sein zu der Stopreihenfolge. Falls man sich wirklich sicher ist dass kein Service zu stoppen und zu starten ist kann man ":" als Parameter bei Option -a und -o mitgeben.

Beispiel für -a

-a "service pilight start && service samba start && service nfs-kernel-server start"

Beisplel für -o

-o "service nfs-kernel-server stop && service pilight stop && service samba stop"

Achtung: Die Befehle werden als root ausgeführt. Es ist kein sudo notwendig.

Mit dem folgenden Befehl kann erhält man eine Lists von offenen Dateien und welche Services sie geöffnet haben. Diese können zu einem inkonsistenten Backup führen und es ist empfehlenswer die Services vor dem Backup zu stoppen.

sudo lsof / | awk 'NR==1 || $4~/[0-9][uw]/'

19) Welche Formatierung muss eine Partition haben auf der ein Backup abgelegt wird?

Prinzipiell kann jedes Filesystem benutzt werden was an Linux gemounted werden kann. Allerdings gibt es ein paar Dinge zu beachten:

- Ein rsync Backup benutzt Hardlinks sofern möglich welche von ext3/4 unterstützt werden. Dann werden nur geänderte Dateien gesichert und gleiche Dateien per Hardlinks verknüpft. Ein ext4 Filesystem was über Samba freigegeben wird unterstützt keine Hardlinks. Eine Alternative ist NFS. Werden keine Hardlinks unterstützt werden vom rsync immer alle Dateien kopiert.

- FAT32 kann nur Dateien bis zu 4GB speichern. Ein dd Backup wird so gross wie die SD Karte (Ausser es wird die Konfigurationsoption DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY benutzt) und somit i.d.R. größer als 4GB. Selbiges trifft auf das tar Backup zu was auch sehr schnell größer als 4GB wird. Eine Alternative dazu ist NTFS.

Allgemeine Empfehlung: Benutze wenn möglich ext3/4. Auf Linux benutze NFS für Netzwerklaufwerke. Auf Windows benutze NTFS auf exportierten samba Netzwerklaufwerken. Benutze FAT32 nur wenn sichergestellt ist, dass die Backups nicht größer werden als 4GB.

20) Ich habe Probleme beim Sichern meiner Backups auf einer Synology. Wie kann ich die beseitigen?

Es gibt diverse Benutzer von raspiBackup die ihre Backups per nfs auf einer Synology erfolgreich sichern. Leider habe ich keine Synology und kann deshalb nicht kompetent helfen. Allerdings gibt es eine spezielle Seite wo Benutzer von raspiBackup beschrieben haben, was sie an der Synology konfiguriert haben, damit alles funktioniert.

21) Der Inhalt der Bootpartition ändert sich doch nicht. Warum wir trotzdem immer die Bootpartition bei jedem Backup neu gesichert?

Das stimmt in 98% der Fälle. Allerdings kann ein Firmwareupdate die Bootpartition ändern. Mit dem Konfigurationsparameter DEFAULT_LINK_BOOTPARTITIONFILES werden die Bootpartitionen im Backup mit Hardlinks verknüpft - sofern diese unterstützt werden. Damit kann man also pro Backup 60MB Backupspace sparen. Allerdings wird immer die Bootpartition erst einmal gesichert um dann zu testen ob sie sich zum vorhergehenden Backup geändert hat und dann durch einen Hardlink ersetzt. D.h. diese Option ist nur sinnvoll, wenn man einen sehr kleinen Backupspace hat.

22) Wie kann man  verschiedene Backupkonfigurationen in verschiedenen Backupläufen benutzen?

Die Konfigurationsparameter von raspiBackup werden in folgender Reihenfolge eingelesen und wirksam. Dabei können spätere Dateien bzw Optionen vorherige Optionen überschreiben.

1) /usr/local/etc/raspiBackup.conf

2) ./.raspiBackup.conf (aktuelles Verzeichnis)

3) ~/.raspiBackup.conf (Home Verzeichnis)

4) Die optionale Konfigurationdatei, die mit der Option -f angegeben wurde

5) Aufrufparameter

23) Ich möchte den Backupfortschritt verfolgen. Gibt es eine Option um einen Fortschrittsbalken zu erhalten?

Es gibt dazu die Option -g

24) raspiBackup meldet einen Fehler ACL_TYPE_ACCESS, Operation not supported bei der Benutzung des Backuptypen rsync

Die Fehlermeldung sieht in etwas wie folgt aus:

??? RBK0024E: Backupprogramm rsync hat einen Fehler bekommen. 
rsync: set_acl: sys_acl_set_file(media/pi, ACL_TYPE_ACCESS): Operation not supported (95)
 
Die Ursache liegt darin, dass rsync keine ACLs unterstützt. Diese sind aber auch in 99% der Fälle nicht notwendig. Die folgende Zeile in der /etc/mke2fs.conf
default_mntopts = acl,user_xattr
bewirkt dass jeder mount immer die acl für eine Partition einschaltet. Das trifft dann auch für die Backuppartition von raspiBackup zu, die standardmäßig auf /backup gemounted wird. Somit wird immer versucht acl Daten zu schreiben was von rsync nicht unterstützt wird.
 
Lösung:
Löschen von acl in default_mntopts in der Datei /etc/mke2fs.conf.
 
25) Fehlermeldung dev/... has unsupported feature(s): metadata_csum E2FSCK: Get a newer version of e2fsck

 

Lösung:
Vor dem Restore die /etc/mke2fs.conf editieren und bei beiden ext4 Optionen das metadata_csum entfernen. Dann den Restore mit raspiBackup durchführen.
 
26) Wieso bekommen ich die die Meldung ??? RBK0160E: Ziel /dev/sda mit xx GiB ist kleiner als die Backupquelle mit yy GiB obwohl beide SD Karten gleich gross sind?
SD Karten die mit einer bestimmten Grösse angegeben sind (z.B. 16GB) sind trotzdem unterschiedlich gross. Mit dem Befehl sudo fdisk -l /dev/mmcblk0
erhält man z.B. folgende Ausgabe die einem genau die Größe mitteilt:

sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 15.5 GB, 15548284928 bytes

Bei einer anderen ebenfalls 16GB grossen SD Karte erhält man z.B.
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
D.h. man kann zwar das erste Image auf die zweite SD Karte bringen aber nicht umgekehrt.
 
Lösung:
1) Eine grössere SD Karte nehmen
2) Das Quellimage verkleinern. Das Tool pishrink eignet sich dazu.
3) Das Backup mit dem Parameter DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY erstellen (Siehe dazu auch FAQ16)
4) Vor dem Erstellen des Backups die Rootpartition mit gpartedetwas verkleinern (Mehrere hundert MB oder gleich 1 GB). Dann passt der Backup auch auf SD Karten die etwas kleiner sind.
 
27) Ich habe ein tar oder rsync Backup und möchte das in ein dd Backup umwandeln. Geht das?
Es gibt ein Script mit dem Namen raspiBackupRestore2Image.sh welches hier zu finden ist. Damit kann man im Backupverzeichnis ein dd aus einem tar oder rsync Backup erzeugen.
 
28) Wieso verschwinden Dateiänderungen nach einem Reboot wieder von einem zurückgespieltem Backup?
Die SD Karte ist unglücklicherweise an der Stelle defekt, wo das Filesystem Änderungen ablegt (Superblock). Da dieser im Hauptspeicher gehalten wird bemerkt man den Fehler nur nach einem Reboot.
 
Lösung:
Das Backup muss noch einmal auf eine neue fehlerfreie SD Karte zurueckgespielt werden.
 
29) Ich bekomme die Meldung rsync: chown "(datei-fad)" failed: Operation not permitted (1). Wie kann ich das lösen?
Kurt hat dieses Problem bekommen, die Lösung gefunden und freundlicherweise mitgeteilt. DougieLawson hat hier die Lösung des Problems beschrieben.
 
Letztendlich musste der folgende Eintrag in der /etc/fstab
192.168.2.203:/data/raspi /media/nas nfs defaults 0 0
wie folgt geändert werden
192.168.2.203:/data/raspi /media/nas nfs defaults,noatime,noauto,x-systemd.automount 0 0
 
30) Mir gefällt raspiBackup und ich möchte die Entwicklung und den Support honorieren. Wie kann ich das tun?
Details zu einem Trinkgeld finden sich hier
 
31) Ich bekomme eine Fehlermeldung von raspiBackup. Was kann ich tun um sie zu beseitgen?
Es gibt eine Seite wo alle häufigsten Fehlermeldungen von raspiBackup genauer beschrieben sind inklusive Aktionen, mit denen man sie beseitigen kann. Besuche dazu diese Seite.
 
32) Nach dem Upgrade auf v0.6.3.2 bekomme ich Fehlermeldungen RBK0021E: Backupprogramm des Typs tar beendete sich mit RC 1 oder RBK0021E: Backupprogramm des Typs rsync beendete sich mit RC 23.
Bis v0.6.3.1 ignorierte raspiBackup gewisse Fehler von tar und rsync. Dieses kann dazu führen dass schwerwiegende Fehler nicht bemerkt werden. Deshalb wurde dieses in v0.6.3.2 deaktiviert. In der Version 0.6.3.2a kann man mit folgenden Definitionen in der Konfigurationsdatei dieses Verhalten wieder herstellen.
 

TAR_IGNORE_ERRORS="1"

RSYNC_IGNORE_ERRORS="23 24"

Es wird aber dringend geraten die Fehlerursache zu beseitigen und nicht die Fehler zu ignorieren.
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   
#94 Mar 2018-05-24 20:11
zitiere framp:
Kannst du noch etwas genauer erklären was pihole damit zu tun hat 8)


Klar :-)
die pihole DB liegt unter /etc... und der Rest darin ist verschwindend kleine, paar kb. Da die DB aber 2,5 GB hat, habe ich irrtümlicherweise gedacht /etc wird immer voll gesichert - ist aber natürlich nur dieses eine DB file!
Zitieren
#93 framp 2018-05-22 21:35
Danke für den Update. Kannst du noch etwas genauer erklären was pihole damit zu tun hat 8)

Cu framp
Zitieren
#92 Marc 2018-05-22 21:21
..hat sich erledigt: pihole-FTL.db ist die Antwort.

:-)
Zitieren
#91 Marc 2018-05-22 21:06
Moin zusammen,

gibt es irgendeine logische Erklärung, warum bei mir Hardlinks nicht bei /etc funktionieren?
Das Verzeichnis wird immer voll gesichert... bei allen anderen Verzeichnissen klappt die Hardlinkerei aber nachweislich hervorragend. Verwirrt mich dezent... :-)
Danke für Tipps & Ideen vorab!
Zitieren
#90 framp 2018-04-27 13:09
Moin Rob,

Dass weiss ich nicht. Habe mich noch nicht mir PXE Boot beschäftigt. Ich denke man muss aber noch was ändern.

Cu framp
Zitieren
#89 Rob 2018-04-27 11:58
Hallo,

könnte man ein Image was man mit raspiBackup erstellt auch direkt vom Netz per NFS booten?

Gruß
Rob
Zitieren
#88 Ingo 2018-04-26 20:34
Hi framp,

hätte ich auch dran denken können:
Version: 0.6.3.2a CommitSHA: c321366 CommitDate: 2018-04-07 CommitTime: 16:46:23

Gruß
Ingo
Zitieren
#87 framp 2018-04-26 19:43
Moin Ingo,

vielen Dank fuer Deine Hinweise. Eigentlich sollte tmp excluded werden. Auch sollte eigentlich immer ein Fehler im Log zu sehen sein - egal ob mit oder ohne TAR_IGNORE_ERRORS. Leider ist das ziemlich schlecht zu testen. Kannst Du mir bitte noch den git Stand von Deinem raspiBackup mitteilen damit ich das gezielt untersuchen und fixen kann?
Code:./raspiBackup.sh --version<br />Version: 0.6.3.2a CommitSHA: 9626c78 CommitDate: 2018-04-23 CommitTime: 22:42:30
oder bei aelteren Versionen Code:./raspiBackup.sh -h<br />--- RBK0009I: raspifix: raspiBackup.sh V0.6.3.2a (9626c78) started at Thu Apr 26 19:41:18 CEST 2018.<br />raspiBackup.sh 0.6.3.2a, 2018-04-23/22:42:30 - 9626c78
Ich brauche die 9626c78 :-)

Cu framp
Zitieren
#86 Ingo 2018-04-26 15:33
zitiere Simon:
Hallo framp,

wenn ich das Backup manuell mit -v Aufrufe, sehe ich zwar die Dateiliste, aber Backup läuft durch. Wenn ich nachts das tägliche Backup mit -v starte, bricht er trotzdem mit gleichem Fehler ab, hinterlässt mir aber keine Dateiliste o.ä. welche ich beim manuellen Backup über den Bildschirm laufen sehe.

Ich wüsste auch nicht, dass nachts um diese Uhrzeit andere spezielle Jobs laufen, welche ein stilllegen des Systems für Backup verhindern...

Grüße
Simon


Vielleicht kann ich etwas dazu beitragen: Ich hab' auch das Problem gehabt, dass bei der TAR-Sicherung das Backup ab und an nicht durchlief.

Die Option -v hat nicht viel zur Fehlerfindung beigetragen, sie hat zwar brav die gesicherten Dateien angezeigt, aber nicht, warum abgebrochen wurde.

Erst durch das Ignorieren der Tar-Fehler (TAR_IGNORE_ERRORS="1") hab' ich einen Hinweis bekommen: Da hat er einen Fehler bei einer Datei /tmp/devicename_####.log angezeigt (#### ist eine Zahl gewesen). Obwohl tmp ja eigentlich nicht mit gesichert werden soll, hab' ich als zusätzliche Option für Tar -u "--exclude='./tmp'" mit zum Aufruf angeben.

Seitdem läuft das Backup jetzt schon bestimmt ein dutzend mal ohne Probleme durch.

Gruß
Ingo
Zitieren
#85 framp 2018-04-07 23:06
Moin Bjoern,

Zitat:
Sonst läuft er auf nen Fehler, der nicht eingrenzbar ist...
Das stimmt nicht :-* . Der Fehler ist eingrenzbar. Siehe dazu FAQ18 und den lsof Befehl sowie die -v Option mit der Du die genaue Fehlermeldung vom rsync siehst.
Ich will das noch im Detail in den FAQ beschreiben wie man die Ursache fuer die RCs finden kann. Dazu brauche ich aber noch etwas Zeit :oops:

Cu framp
Zitieren
#84 Bjoern 2018-04-07 22:59
zitiere framp:
Moin Bjoern,

irgendwie verstehe ich Deine Frage nicht. :cry: Es wird ja RC 23 ignoriert und der Backup läuft durch. So soll es doch sein.

Cu framp


naja das Backup läuft erst mit dem Schalter IGNORE_ERRORS durch. Sonst läuft er auf nen Fehler, der nicht eingrenzbar ist...
Zitieren
#83 framp 2018-04-07 18:35
Moin Bjoern,

irgendwie verstehe ich Deine Frage nicht. :cry:
Zitat:
Dort steht aber nicht mehr unter "Fehlermeldungen"... Mit dem Schalter "-v" ist auch alles soweit in Ordnung.
Es wird ja RC 23 ignoriert und der Backup läuft durch. So soll es doch sein.

Cu framp
Zitieren
#82 Bjoern 2018-04-07 18:22
Hi,

seit der neuen Version hab auch ich das Problem mit dem Fehler RC 23. Mit RSYNC_IGNORE_ERRORS="23 24" läuft das dann aber komplett durch. Im Log steht:
--- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld.
--- RBK0174I: Backupprogramm rsync Fehler 23 wurde ignoriert. Fehlermeldungen:
--- RBK0007I: Services werden gestartet: 'sudo systemctl start dnsmasq %1%1 sudo systemctl start cron %1%1 sudo systemctl start mysql %1%1 sudo systemctl start apache2'.
--- RBK0010I: raspberrypi: raspiBackup.sh V0.6.3.2-hotfix (470b650) um Sat 7 Apr 18:15:55 CEST 2018 beendet.
--- RBK0017I: Backup erfolgreich beendet.

Dort steht aber nicht mehr unter "Fehlermeldungen"... Mit dem Schalter "-v" ist auch alles soweit in Ordnung.

Freu mich über Rückmeldung. Danke!
Zitieren
#81 framp 2018-03-31 17:09
Moin Simon,

perfekt. Ich melde mich dann per eMail bei Dir :-)

Cu framp
Zitieren
#80 Simon 2018-03-31 15:55
Ja klar, können wir tun.
Habe vergessen zu erwähnen, dass ich den Job nachts über einen cronjob laufen lasse (gestern mit Option -v). Das ist der einzige Unterschied, der mir einfällt.
Zitieren
#79 framp 2018-03-31 10:16
Moin Simon,

das ist merkwuerdig und muss genauer untersucht werden. :o Ich wuerde fuer Dich eine spezielle Version erstellen, die zusaetzliche Debuginformationen loggen wuerde um der Ursache auf die Spur zu kommen und Dir zusenden. Du muesstest dann aber den Hotfix bei Dir auch mit -v laufen lassen. Wuerdest Du das tun?

Cu framp
Zitieren
#78 Simon 2018-03-31 07:59
Hallo framp,

wenn ich das Backup manuell mit -v Aufrufe, sehe ich zwar die Dateiliste, aber Backup läuft durch. Wenn ich nachts das tägliche Backup mit -v starte, bricht er trotzdem mit gleichem Fehler ab, hinterlässt mir aber keine Dateiliste o.ä. welche ich beim manuellen Backup über den Bildschirm laufen sehe.

Ich wüsste auch nicht, dass nachts um diese Uhrzeit andere spezielle Jobs laufen, welche ein stilllegen des Systems für Backup verhindern...

Grüße
Simon
Zitieren
#77 framp 2018-03-30 10:22
Moin Simon,

in den vorherigen Versionen wurde der RC von tar ignoriert da der i.d.R. bedeutet das dass sich irgendwelche Dateien während des Backups geändert haben. Leider kann der RC 1 aber auch andere schlimme Dinge bedeuten die nicht ignoriert werden sollten. Deshalb führt jetzt jeder tar Fehler zu einem Abbruch und die Ursache muss behoben werden.

Was solltest Du jetzt tun?

Benutze zusaetzlich die Option -v. Dann wirst Du alle Fehlermeldungen von tar sehen. Wenn es irgendwelche Dateien sind die sich geändert haben stoppe die Services die die Dateien schreiben (Siehe dazu FAQ18). Wenn es andere Meldungen sind musst Du diese Fehler fixen.

Ich habe auch mittlerweile die Version 0.6.3.2 erweitert so dass man wieder das Ignorieren des RC 1 einschalten kann. Ich finde es gefährlich - aber wenn Du den Weg gehen willst kann ich Dir den Hotfix auf die V 0.6.3.2 zuschicken :-)

Cu framp
Zitieren
#76 Simon 2018-03-30 08:48
Hallo,

seit Update auf Version 0.6.3.2 wird das Backup auf allen meinen Raspis immer fehlerhaft beendet. Gehe ich auf die 0.6.3.1 zurück ist alles okay.

Fehler vom Log ist folgender:
??? RBK0021E: Backupprogramm des Typs tar beendete sich mit RC 1.

Was kann ich tun?

Danke und Gruß
Simon
Zitieren
#75 framp 2018-03-26 19:57
Moin DTrunsch,

das bedeutet dass während des Backups sich Dateien geändert haben und das ist nicht gut :-?

Mit der Option -v bekommst Du die exakte Fehlermeldung von rsync. Siehe FAQ18 wie Du rausfinden kannst wer die Datei schreibt bzw ändert und wie Du den Service stoppen kannst.

Cu framp
Zitieren
#74 DTrunsch 2018-03-26 19:18
Hallo zusammen,
könnt ihr mir sagen welcher fehler das ist?
"Backupprogramm des Typs rsync beendete sich mit RC 23". Dankeschön!
Zitieren
#73 framp 2018-03-21 12:38
Moin T. Schwarz,

Du meinst sicherlich ; und && :-)

Das haengt davon ab ob Du Fehler tolerieren willst oder nicht. Bei ; werden alle Services gestartet bzw gestoppt. Egal ob einer einen Fehler bekommt. Wenn der letzte Service keinen Fehler bekommt laeuft raspiBackup weiter., Bei && wird das Starten bzw Stoppen sowie raspiBackup beendet wenn ein Service einen Fehler bekommt.

Cu framp
Zitieren
#72 T. Schwarz 2018-03-21 11:11
Werden die zu stoppenden/startenden Dienste in der crontab-datei mit "," oder mit "&&" getrennt? Beides ist angegeben.
Zitieren
#71 framp 2018-02-11 10:54
Hm ... dann wäre der Log ganz hilfreich gewesen. Dann haette ich genau gesehen was ablaeuft und vielleicht hat ja raspiBackup bei der Erkennung ob was gemounted ist in diesem speziellen Fall ein Problem :oops: was ich dann haette fixen koennen. Falls Du es noch hast kannst Du es mir auch gerne an meine eMailAdresse schicken (Siehe Kontakt Seite) :-)

Cu framp
Zitieren
#70 genervt 2018-02-11 10:50
Ich hatte das Verzeichnis schon richtig angegeben (die Pfadangabe mit /mnt/usb hatte er auch irgendwie nicht gemocht). Hat man auch daran gesehen, dass der Backupordner erstellt wurde. Hat aber auch nicht geklappt. Die genaue Meldung weiß ich jetzt nicht mehr. Vielleicht ist es auch die Kombination aus Rasbperry PI 1 und dem ExFat Dateisystem auf dem Stick (den Exfat-Treiber hatte ich natürlich auch da schon installiert).
Zitieren
#69 framp 2018-02-11 10:43
Moin genervt,

freut mich dass es nun geklappt hat :-) .

usbmount mounted die USB Geräte unter /mnt/usb ... . Wenn Du beim Aufruf das richtige Verzeichnis wo der USB Stick von usbmount gemounted wurde (z.B. /mnt/usb oder /mnt/usb1) angegeben haettest haette der Backup auch funktioniert ;-) . Es ist aber besser explizit das USB Geraet zu mounten wie Du es jetzt tust.

Cu framp
Zitieren
#68 genervt 2018-02-10 23:43
Hi framp,

danke für deine schnelle Rückmeldung.
Ich habe usbmount wieder deinstalliert und mounte nun vorher via

"sudo mount /dev/sda /backup"

Jetzt läuft dein Script tadellos
Zitieren
#67 framp 2018-02-01 22:25
Moin genervt,

ich hoffe Du bist es nicht sehr :lol:

Es gibt eine undokumentierte Option mit dem man das ausschalten kann :-* Allerdings möchte ich gerne wissen warum Du diese Meldung offensichtlich faelschlicherweise bekommst um raspiBackup zu fixen.

Benutze bitte zusaetzlich die Optionen
-l debug
um eine Logdatei zu erstellen und stelle sie irgendwo ins Netz (no paste service) dass ich darauf zugreifen kann. Dann kann ich genau sehen warum Du diese Meldung bekommst und kann es fixen.

Cu framp
Zitieren
#66 genervt 2018-02-01 22:17
Kriege es leider nicht zum laufen.
Habe extra usbmount installiert, hat nichts gebracht
Anschließend habe ich sudo mount /dev/sda (ist mein USBStick) /backup durchgeführt
es wird darin auch ein Ordner raspberrypi erstellt, dennoch kommt immer

Zitat:
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.3.1 (590ae9c) um Do 1. Feb 22:14:15 CET 2018 gestartet.
--- RBK0128I: Logdatei ist /backup/raspberrypi/raspberrypi-ddz-backup-20180201-221414/raspberrypi-backup.log.
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
??? RBK0027E: Kein externes Gerät an /backup verbunden. Die SD Karte würde für das Backup benutzt werden.
--- RBK0026I: Logdatei wird in /home/pi/raspberrypi-raspiBackup.log gesichert.
--- RBK0105I: Neues Backupverzeichnis /backup/raspberrypi/raspberrypi-ddz-backup-20180201-221414 wird gelöscht.
??? RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.
Habe hier schon gelesen, dass das ein Schutz sein soll. Kann man diesen nicht mit einer Option umgehen? Ich weiß doch wohin ich sichere und dass dies nicht die SD-Karte ist.
Zitieren
#65 Christoph 2018-01-06 15:33
Hi framp,
werd ich tun, vielen Dank!
Zitieren
#64 framp 2018-01-06 15:09
Moin Christoph,

nein, das wird leider nicht unterstützt. Auf jeden Fall empfehle ich Dir diesen Beitrag einmal zu lesen. :-)

Cu framp
Zitieren
#63 Christoph 2018-01-06 14:52
Hallo,
ich habe eine frage,
ich habe eine NOOBs installation mit einer externen ROOT partition. Gibt es eine Möglichkeit auch in diesem System die bootpartition sowie die externe ROOT partition zu sichern?
Vielen Dank!
Zitieren
#62 framp 2017-12-15 21:01
Moin Apop85,

wenn irgendwo steht es muessen alle Services gestoppt werden sage mir bitte wo das steht. Das ist falsch. Es sollten die Services gestoppt werden die Daten im Speicher cachen und keine automatische Datenrecovery haben.

Es gibt Leute die stoppen nichts und der Backup ist konsistent.

So wie ich es sehe nutzt PiHole einen lighttpd-Webserver. Vermutlich muss der nicht gestoppt werden. Ich wuerde ihn zur Sicherheit aber trotzdem stoppen. In jedem Falle musst Du aber den Backup und Restore testen.

Cu framp
Zitieren
#61 Apop85 2017-12-15 03:30
Einmal wird erwähnt man muss die wichtigsten Services stoppen und ein anderes mal wird gesagt man müsse alle stoppen.

Was ist nun richtig? Was sind die wichtigen Services?

Nutze meinen Pi3 als PiHole kein Mediaserver/Apache o.ä. installiert.

OS ist Raspian Stretch
Zitieren
#60 framp 2017-11-22 18:53
Moin HMuser,

das klingt merkwuerdig :o . Kannst Du mal die Option -l debug beim Restore mitgeben und mir das Debuglog zuschicken? Meine eMail findest Du auf der Kontaktseite.

Cu framp
Zitieren
#59 HMuser 2017-11-22 06:43
Perfekt, hat funktioniert, Backup startet!
Jetzt kommt allerdings eine Menge Meldungen wie diese:

tar: ./System.map-4.9.29-10-osmc: Kann Datei-Eigentümer nicht zu uid 1000, gid 1000 ändern: Die Operation ist nicht erlaubt

Muss ich rechte auf der neuen SD ändern?

Danke für die schnelle Hilfe!
Zitieren
#58 framp 2017-11-21 22:30
Moin HMuser,

Du versuchst auf eine Partition, die sich auf /dev/sdb befindet, zu restoren und die noch gemounted ist. Mit Code:sudo umount <partition> musst Du vorher alle Partitionen unmounten.

Cu framp
Zitieren
#57 HMuser 2017-11-21 22:24
Hallo,
Versuche zum ersten Mal das neu angelegte Backup zu restoren. Bricht ab mit der Meldung
??? RBK0154E: Ein Restore ist nicht möglich wenn eine Partition von /dev/sdb gemounted ist.
??? RBK0077E: Restore wurde fehlerhaft mit RC 102 beendet. Siehe vorhergehende Fehlermeldungen.
Was mache ich falsch?
Zitieren
#56 framp 2017-10-30 19:41
zitiere Wilfried Bauer:
Müssen -a und -o jetzt zwingend gesetzt werden?

Ja. Wenn Du nichts zu stoppen/starten hast nimm
Code:-a : -o :
Zitieren
#55 framp 2017-10-30 19:39
Moin Wilfried,

dann habe ich Dich falsch verstanden.

Mit der Option wird in der eMail das Log der Konsole sowie das Debuglog mitgeschickt. Wenn Du auch das Debuglog haben willst musst Du es noch mit der Option -l einschalten.

Cu framp
Zitieren
#54 Wilfried Bauer 2017-10-30 19:38
Jetzt schlägt das Backup fehl. Auszug aus dem Log:

20171030-192428: MSG ??? RBK0019E: Option -a und -o nicht angegeben.
20171030-192428: DBG >> exitError 107
20171030-192428: DBG > cleanup
20171030-192428: DBG >> cleanupBackup
20171030-192428: DBG -- Got trap EXIT
20171030-192428: DBG -- rc: 107
Invocation parms: ''
20171030-192428: DBG -- emailTitle: raspi2: Backup nicht erfolgreich !!!.
20171030-192428: DBG >> sendEMail
20171030-192428: DBG -- Appendlog -a /home/pi/raspi2-raspiBackup.log
20171030-192428: DBG -- Sending eMail with program sendEmail and parms '-f SENDER@XXX.de -s securesmtp.t-online.de:587 -xu EMPFÄNGER@YYY.de -xp PASSWD'
20171030-192428: DBG -- Parm1:??? RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen. Parm2:raspi2: Backup nicht erfolgreich !!!.

Müssen -a und -o jetzt zwingend gesetzt werden?
Zitieren
#53 Wilfried Bauer 2017-10-30 19:32
Das ist schon klar. Die Optionen von DEFAULT_APPEND_LOG sind ja im Default conf File dokumentiert. Aber muss ich

DEFAULT_APPEND_LOG=0
oder DEFAULT_APPEND_LOG=1

verwenden?

Ziel ist, dass Backup-Logs immer im Fehlerfall (und nur dann) an die Email angehängt werden.
Zitieren