Einführung

Eine regelmäßige Sicherung von Raspberry Pis ist wichtig, um im Falle eines Ausfalls des Systemspeichergerätes (SD-Karte, USB Disk, SSD, NVMe ...) oder auch von unbeabsichtigten Änderungen, durch die das System nicht mehr oder fehlerhaft bootet, das System wieder auf einen vorherigen Zustand zurücksetzen zu können.

raspiBackup erstellt eine Systemsicherung einer Raspberry Pi bei laufendem System. Das kann manuell oder automatisch in regelmäßigen Abständen geschehen. Ein Backup enthält immer das gesamte System, d.h. Systemdaten sowie Nutzerdaten. Deshalb bootet das System sofort wieder, wenn es zurückgespielt wurde.

Zur Installation und Konfiguration von raspiBackup gibt es einen Installer, mit dem menügesteuert einfach und schnell die wichtigsten Optionen von raspiBackup konfiguriert werden können, vergleichbar mit raspi-config. Speziellere Einstellungen lassen sich in einer Konfigurationsdatei vornehmen.

Alle Funktionen und Einsatzgebiete von raspiBackup sind gleich im ersten Kapitel Funktionsübersicht zusammengetragen.

Weitere Themen auf dieser Seite:

Einführungsvideo und Youtube-Channel

Es gibt ein Einführungsvideo zu raspiBackup auf Youtube.

Behandelte Themen sind

Vorstellung von raspiBackup mit seinen wichtigsten Fähigkeiten
Besuch der wichtigsten Webseiten zu raspiBackup
Vorstellung von GitHub als Fragen- und Probleminteraktionstool
Liveinstallation von raspiBackup mit dem menügesteuerten Installer

Die dort verwendeten Slides können zum Lesen hier heruntergeladen werden.

Viele weitere Videos zu allen möglichen Themen zu raspiBackup finden sich im raspiBackup-Channel.

Kontaktmöglichkeiten

Klicke , um auf GitHub Fragen oder Probleme zu raspiBackup als "Issues" zu erstellen. Die Issues können gerne auch in Deutsch erstellt werden. So lassen sich Fragen und Problemberichte tracken und man bekommt eine Benachrichtigung über Antworten. Das ist die präferierte Kontaktmethode.
Klicke , um auf Facebook aktuelle Aktivitäten und Randinformationen zu raspiBackup zu erfahren. Fragen zu raspiBackup sind auch möglich. Probleme bitte nur im GitHub melden.
Klicke , um raspiBackup auf Twitter zu folgen.
Klicke , um im deutschen RaspberryForum Fragen zu Raspberry Backups im Allgemeinen und raspiBackup im Speziellen zu stellen oder existierende Threads zu raspiBackup zu lesen.
Klicke , um raspiBackup auf Reddit zu folgen.

Hinweis

Jegliche anderen Kommunikationswege wie z.B. eMails, die leider gerne genutzt werden, werden ignoriert!

Trinkgeld

Eine Anerkennung des Entwicklungs- und Wartungsaufwands sowie Supports für raspiBackup ist gerne gesehen und wie folgt möglich:

Werde ein GitHub Sponsor für raspiBackup
Paypal: Die eMail framp att linux-tips-and-tricks dott de ist PayPal bekannt und ein jeder kann mit einem PayPal Konto an diese eMail ein Trinkgeld geben.
Keines von beidem: Einfach bei der o.g. eMail nachfragen. Es findet sich gewiss eine Alternative. Z.B. wurde Trinkgeld schon mehrmals auf die gute alte Art per Brief zugeschickt :-)

Das Trinkgeld wird primär dazu genutzt, Verbrauchsmaterialien wie SD-Karten, Adapter, Kabel etc., die für das Entwickeln und Testen benötigt werden, zu kaufen. Sofern das Trinkgeld ausreicht, wird damit auch neue Hardware gekauft, um in raspiBackup den notwendigen Hardwaresupport einzubauen und die korrekte Funktionalität auf der neuen Hardware zu verifizieren.

Danksagungen

Es haben im Laufe der Zeit sehr viele Leute aus der Community durch Kommentare, Erweiterungsvorschläge und Beta- und Fixtests zu raspiBackup beigetragen. In Anbetracht der großen Anzahl ist es leider nicht möglich, jeden einzelnen aufzuführen.

Daher einfach: Vielen Dank an alle Unterstützer!

Besonderer Dank geht an simonz für den Aufbau dieses raspiBackup Dokumentationsrepositories in GitHub, den Transfer aller raspiBackup Seiten von framps Homepage in dieses Repository und die intensive Unterstützung bei der Überarbeitung der Seiten mit Rat und Tat sowie mit sehr hilfreichen Tools.

Lizenz und GitHub-Link

Der Code von raspiBackup steht unter der GPL auf GitHub zur Verfügung.

Haftungsausschluss

raspiBackup wurde für den persönlichen Gebrauch erstellt und, da es sich als sehr nützlich erwies, der Allgemeinheit zur Verfügung gestellt.

Es wird im Rahmen des Möglichen die korrekte Funktionalität getestet aber es kann nicht ausgeschlossen werden, dass durch Fehler in raspiBackup die erwartete Funktionalität nicht gewährleistet ist. Jeder, der raspiBackup benutzt, tut das auf sein eigenes Risiko.

Der Ersteller von raspiBackup ist in keiner Weise haftbar für irgendwelche Fehlfunktionen des Scripts.

Nutzungshinweise

Oben auf den Seiten befinden sich zwei Icon-Gruppen zur Bedienung der Dokumentation:

Menü-links

Ein-/Ausblenden eines Inhaltsverzeichnisses
Auswahl eines Themes
Suchfunktion

Menü-rechts

Sprachauswahl (Deutsch/Englisch)
Drucken
GitHub-Seite des Dokumentationsprojektes
Änderungen an der aktuellen Seite im GitHub vorschlagen

Tippe ?, um eine kleine Tastatur-Navigationshilfe einzublenden.

Funktionsübersicht

Mit raspiBackup erhältst Du schnell und sicher regelmäßig ein vollständiges Systembackup Deiner Raspberries und eine konfigurierbare Backuphistorie und kannst somit Deine Raspberry vollständig wiederherstellen, so dass sie wieder mit einem alten Backupstand bootet.

Automatische regelmäßige Sicherung einer laufenden Raspberry Pi (sie sichert sich selbst) Siehe dazu auch Ist ein Backup eines laufenden Systems zuverlässig? Sollte nicht das gesamte System vor dem Backup gestoppt werden?
Vollständige und inkrementelle Sicherungen
- Der Backuptyp rsync erstellt vollständige und dann inkrementelle Sicherungen mittels Nutzung von Hardlinks.
- Die Backuptypen dd und tar erstellen immer vollständige Sicherungen (auch gezipped). Hinweis: Beim dd Backup ist per Option einschaltbar, dass nur der von den Partitionen belegte Platz und nicht die gesamte SD-Karte gesichert wird.
Die einzelnen Backuptypen sind im Detail hier beschrieben. Dort befindet sich auch ein Entscheidungsbaum, um schnell den richtigen Backuptyp zu finden.
Zwei Sicherungsstrategien
- Eine definierte Anzahl von Sicherungen wird vorgehalten
- Sicherungen werden nach der Großvater-Vater-Sohn Sicherungsstrategie (GVS) vorgehalten.
Zwei Backupmodi:
- der normale Backupmodus sichert nur die Boot- und Rootpartition
- der partitionsorientierte Modus sichert beliebig viele Partitionen
Eine beliebige Anzahl von Backups aus der Vergangenheit können vorgehalten werden

Es wird nicht nur ein einzelnes Backup erstellt, sondern eine Backuphistorie. Entweder definiert man eine Anzahl von Backups, die vorgehalten werden sollen, oder man nutzt das GVS-Prinzip (in raspiBackup "Intelligente Rotationsstrategie" genannt, siehe Großvater-Vater-Sohn Generationenprinzip
Eine intelligente Backupstrategie steht zur Verfügung Z. B. können Backups der letzten 7 Tage, der letzten 4 Wochen, der letzten 12 Monate und der letzten n Jahre aufgehoben werden.
Einfache Installation mit menügeführtem Installer (vergleichbar mit raspi-config)

Die wichtigsten Optionen von raspiBackup können in Deutsch, Englisch, Finnisch, Chinesisch und Französisch konfiguriert werden, so dass die erste Sicherung in 5 Minuten erstellt werden kann.
Open source

raspiBackup ist unter der GNU Lizenz als OpenSource und kostenlos verfügbar. Ein Trinkgeld ist aber trotzdem gern gesehen 😉
Alle weiteren z.T. sehr mächtigen Optionen sind ausführlich dokumentiert und können in einer Konfigurationsdatei definiert werden.
Beliebige Verzeichnisse und Dateien können aus dem Backup ausgeschlossen werden
Verschiedene Backuptypen können pro System gemischt werden (z.B. pro Tag ein rsync Backup, jeder Woche ein dd Backup)
Automatisches Stoppen und Starten von aktiven Services vor und nach dem Backup
Sicherung einer beliebigen Anzahl von Raspberries in einem Backupverzeichnis
Meldungen werden in Deutsch und Englisch, Französisch oder Finnisch unterstützt.
Benachrichtigungen

Die Sicherungslaufmeldungen können von raspiBackup per eMail oder Telegram, Slack oder PushOver verschickt werden. Smilies weisen auf Erfolg oder Misserfolg des Sicherungslaufes hin. Andere Smilies informieren über andere wichtige Ereignisse wie die Verfügbarkeit einer Beta oder eines neuen Releases oder die Erinnerung daran, mal wieder einen Restoretest durchzuführen, um die Sicherungsintegrität zu testen.
Unterstützte eMail-Clients: mailx/mail, sendEmail, ssmtp und msmtp. Nicht unterstützte eMail-Clients können durch ein eMail-Plugin eingebunden werden.
Einfaches Update von raspiBackup auf die aktuelle Version
Einfache Verteilung von neuen Scriptversionen auf eine größere Menge von Hosts
Alle Bootmodi werden unterstützt
1. Boot von einem USB Gerät oder SSD (USB boot Modus): Beide Partitionen liegen auf einem USB Gerät. Wird von den neueren Raspberries ab Modell 3B unterstützt
2. Boot von der SD-Karte: Beide Partitionen liegen auf der SD-Karte (jedes Modell)
3. Gemischter Modus: Boot von der SD-Karte und Nutzung der Rootpartition von einem USB Gerät. Das ist notwendig bei älteren Raspberries, die noch keinen USB Boot unterstützen
Beliebige Backupziele sind möglich, z.B.
- Externer USB Stick
- Externe USB Platte oder SSD
- SMB Netzwerklaufwerk
- NFS Netzwerklaufwerk
- SSHFS Netzwerklaufwerk
- WebDAV Netzwerklaufwerk
- FtpFS Netzwerklaufwerk
- Generell jedes Device, welches unter Linux gemounted werden kann
Ein externes Rootfilesystem auf einer Platte oder einem USB Stick wird automatisch im gemischten Modus beim normalen Backupmodus mitgesichert und restored bei tar oder rsync.
Snapshots

Es können manuell sogenannte raspiBackup Snapshots erstellt werden.

Das sind benannte Backups, die nicht automatisch gelöscht werden. Sie dienen zum Beispiel dazu, bei Systemupgrades wichtige Zwischenschritte zu sichern, um jederzeit bei Problemen wieder auf vorherige Stände zurückgehen zu können.
Einfache Wiederherstellung einer Sicherung

Eine Sicherung des Backuptyps dd kann auch auf einem Windows System wiederhergestellt werden. Win32Diskimager oder ähnliche Tools können genutzt werden. tar und rsync benötigen zur Wiederherstellung ein Linuxsystem. Es wird empfohlen, dazu eine vorkonfigurierte SD-Karte mit Raspberry Pi OS zu nutzen und auf einer Raspberry zu starten.
Anpassung von /etc/fstab und /boot/cmdline.txt an neue UUIDs, PARTUUIDs oder LABELs, damit das System sofort wieder startet.
Aktive Social Media Kanäle
Benachrichtigungen bei neuen Releases

Sobald ein Beta oder eine neue Release verfügbar ist, schreibt raspiBackup eine Meldung, die darauf hinweist. Ein Upgrade ist einfach vorzunehmen. Ebenso ein Downgrade zurück auf eine vorhergehende Release.
Regressionstestsuite

Die Basisfunktionalität von raspiBackup (Sicherung und Wiederherstellung) wird für alle Backuptypen und Modi automatisch getestet, um sicherzustellen, dass das neue raspiBackup Release genauso zuverlässig funktioniert wie vorher.
Dokumentation

Benutzerhandbuch mit z.B. FAQs, Konfigurationsbeispiele, NFS Konfiguration, Liste von Fehlermeldungen und wie man die Fehlermeldungen beseitigen kann und vieles mehr ist dokumentiert
Hilfs- und Beispielscripts

Verschiedene Hilfs- und Beispielscripts stehen zur Verfügung.

Sie können die Funktionalität von raspiBackup erweitern und entweder unverändert genutzt oder an eigene Anforderungen angepasst werden.

Zum Beispiel, wie pishrink genutzt werden kann, um eine dd Sicherung noch zu verkleinern oder wie parallel ein Clone erstellt werden kann, um ein aktuelles, jederzeit einsetzbares Bootmedium zu haben.

Ein Beispielscript hilft, um vor und nach dem Backup weitere Aktionen vorzunehmen, wie z.B. das Mounten und Unmounten des Backupspaces.

Und vieles, vieles mehr.
Erweiterungspunkte

Für Entwickler bietet raspiBackup verschiedene Erweiterungspunkte, um Vor- und Nachbereitungen bei der Sicherung wie auch dem Zurücksichern durch eigenen Code ausführen zu können.
Sicherung von NVMe Speicher

Wird für Raspberry 5 und Compute Model 4 (CM4) unterstützt
Unterstütze Betriebssysteme
- RaspbianOS / Raspberry Pi OS
- Ubuntu
Einfacher Systemumzug auf andere Speichermedien

Jede Sicherung kann auf eine SD-Karte, USB Platte oder SSD sowie NVMe SSD zurückgespielt werden. Schon ist das System auf ein anderes Gerät umgezogen.
Unterstützung von Volumio
Unterstützung von gpt Partitionen

Übersichtsbild

Unterstützte Hardware und Software

raspiBackup wird nur auf Raspberry Pi Hardware mit dem Raspberry Pi OS und Ubuntu unterstützt. Es läuft aber auch auf anderer Raspberry Pi kompatibler Hardware und anderen Linux Distributions erfolgreich. Dabei ist zu beachten, dass raspiBackup die beiden Partitionen /boot und /root benötigt, wie sie bei Raspberry Pi OS existieren.

D.h. man kann raspiBackup auf dem jeweiligen Environment ausprobieren und wenn es erfolgreich läuft, kann man sich freuen und es nutzen. Wenn es aber nicht läuft bzw. Fehlermeldungen bringt, wird kein Support gegeben. Man kann einen Issue in GitHub erstellen und das Debuglog beifügen. So kann framp prüfen, ob vielleicht mit ein paar kleinen Änderungen das Problem beseitigt werden kann. Sind größere Änderungen notwendig, werden diese nicht vorgenommen und somit kann raspiBackup in dem Environment nicht genutzt werden. Aber auch wenn ein Fix das Problem beseitigt, bleibt das Environment nicht unterstützt.

Insbesondere kann meist ein beliebiges Linux OS auf einer beliebigen Hardware genutzt werden, um ein Backup zu restoren. Auch hier ist dann die Option --unsupportedEnvironment notwendig. Sollte es doch Probleme geben, muss eine Raspberry zum Restore genutzt werden.

Unter der Tatsache, dass raspiBackup umsonst ist, ist es zu teuer/zu aufwändig für framp,

sich alle mögliche Hardware für die Tests anzuschaffen
alle mögliche Hardware- und Softwaretestkombinationen aufzubauen
jeweils alles bei einer neuen Release zu testen

Also kann framp raspiBackup nur unter den genannten Voraussetzungen unterstützen.

Es besteht die Möglichkeit der Donation und je nach Aufwand besteht die Chance, dass zukünftig weitere Environments von raspiBackup unterstützt werden.

raspiBackup prüft beim Aufruf, ob eine unterstützte Hard- und Software vorliegt und beendet sich ansonsten. Mit der Option --unsupportedEnvironment wird diese Prüfung nicht vorgenommen und führt u.U. zu Fehlern und Programmabbrüchen.

Raspberry Pi OS (RaspbianOS) Lite und Desktop

Sowohl Raspberry Pi OS (früher RaspbianOS) Lite als auch Desktop werden von raspiBackup unterstützt. Die Desktop Version sollte wenigstens auf einem RPi4/RPi5 mit 4GB Speicher genutzt werden.

Ubuntu

Sofern die offizielle Ubuntuversion für Raspberries genutzt wird, ist diese von raspiBackup unterstützt. Es sollte aber wenigstens eine Raspberry Pi 4 mit 4GB, besser noch mit 8GB Speicher, genutzt werden. Selbiges trifft für einen Raspberry Pi 5 zu. Vermutlich sind die Anforderungen an ein Ubuntu Server System geringer.

Raspberry Pi Compute Module (CM)

raspiBackup unterstützt Raspberry Pi Computemodule mit einer SD-Karte, eMMC Speicher und NVMe.

Wie man CM4 NVMe Devices auf Linux verfügbar macht, um ein NVMe Backup von raspiBackup zu restoren, ist der englischsprachigen Seite beschrieben.

Unterstützte Geräte

raspiBackup unterstützt folgende Geräte und Speicher

SD-Karten
Platten/HDDs
SSDs
USB Sticks
USB SD Adapter
eMMC Speicher
NVMe Speicher

Als Backupziel für die Backups kann prinzipiell alles genutzt werden, was unter Linux mountbar ist. Dazu gehören u.A.

SMB Netzwerklaufwerke
NFS Netzwerklaufwerke
SSHFS Netzwerklaufwerke
WebDAV Netzwerklaufwerke
FtpFS Netzwerklaufwerke

Auf Backupziele finden sich Beispiele für SMB, NFS und WebDAV Konfiguration.

Sprachunterstützung

raspiBackup nutzt standardmäßig die Systemsprache, um die entsprechende Sprache auszuwählen und zur Anzeige zu nutzen. Die Sprache kann aber auch per Option definiert werden. Wird die Sprache nicht von raspiBackup unterstützt, wird Englisch gewählt.

Unterstützte Sprachen sind

Chinesisch (CN)
Deutsch (DE)
Englisch (EN)
Finnisch (FI)
Französisch (FR)

Wer helfen möchte, raspiBackup eine weitere Sprache zu geben, ist herzlich eingeladen, dieses zu tun. Details dazu finden sich in dieser englischsprachigen Beschreibung.

Schnellstart - Installation in 5 Minuten

Die Dokumentation von raspiBackup ist Aufgrund der Fülle an Funktionen mittlerweile sehr umfangreich geworden.

Um den Einstieg zu erleichtern, wird auf dieser Seite deshalb kurzgefasst erklärt, wie raspiBackup in wenigen Minuten installiert und konfiguriert und dann Backups der Raspberry erstellt werden können.

Im Kapitel Konfigurationsbeispiele sind einige Inspirationen zum Einsatz von raspiBackup aufgeführt. Diese können zum Kennenlernen der Parameter dienen und damit bei der späteren Konfiguration während der Installation helfen.

Das Wiederherstellen eines Backups ist detailliert auf einer eigenen Seite beschrieben. Dort wird auch auf die primären Plattformen (Linux, Mac oder Windows) der Benutzer eingegangen.

Hinweis: Von raspiBackup-User Franjo_G gibt es eine weitere Anleitung zur Installation, Konfiguration und Nutzung von raspiBackup.im deutschen Raspberryforum.

Mit Installer oder ohne?

Es gibt verschiedene Möglichkeiten, raspiBackup zu starten.

Sogar eine "adhoc"-Nutzung von raspiBackup ganz ohne Installation ist möglich.

Hier wird aber nun auf die standardmäßige Installation mit dem Installer eingegangen.

Hinweis: Wer sich vor der Installation den Sourcecode von raspiBackup und/oder den Installer raspiBackupInstallUI ansehen möchte, kann dies über die folgende Links tun:

Der raspiBackup Installer

raspiBackup hat einen menügeführten UI Installer bzw. Konfigurator, raspiBackupInstallUI, mit dem es sich wie mit raspi-config einfach installieren und in Grundzügen konfigurieren lässt.

Ebenso vorhanden sind Update-Funktionen für den Installer selbst und für raspiBackup.

Die Installationsführung erfolgt über Menüs sowie über Auswahllisten. Als Menüsprachen stehen Deutsch, Englisch, Finnisch, Chinesisch und Französisch zur Verfügung.

In dem raspiBackup-Vorstellungsvideo auf Youtube wird eine Demo der Installation gezeigt.

Vorbereitung: Das Backup-Ziel/Backup-Verzeichnis

In der Standardkonfiguration geht raspiBackup davon aus, dass es einen Mountpoint /backup gibt, unter dem das Backupverzeichnis gemounted ist.

Dieser Mountpoint sollte schon vor der Installation erstellt und dann dort das externe Backupverzeichnis/Gerät (USB-Platte, USB-Stick, NFS-Laufwerk, ...) gemounted werden.

Im folgenden Beispiel wird eine externe USB-Platte bzw. USB-Stick gemountet:

sudo mkdir -p /backup
sudo mount /dev/sda1 /backup

raspiBackup setzt je nach gewünschtem Backuptyp für diese Partition ein gewisses Filesystem voraus. Dies wird in Kapitel "Welches Dateisystem kann auf der Backuppartition benutzt werden?" erklärt. Bitte beachten: Warum sollte man dd als Backuptyp besser nicht benutzen?.

Vor dem ersten Backup ist es sinnvoll, zu prüfen/sicherstellen, dass wirklich das richtige Backupziel bzw die richtige Backuppartition genutzt wird.

Hilfreich sind dabei folgende Befehle:

sudo blkid -o list
mount | grep backup

Download und Installation des Installers

Zum Download, der Installation und Start des raspiBackup Installers bitte folgendes in der Befehlszeile auf der Raspberry eingeben:

pushd /tmp
curl -o install -L https://raspibackup.linux-tips-and-tricks.de/install
sudo bash ./install
popd

Hinweis: Eine manuelle Installation ohne sudo Nutzung ist in einer extra Anleitung dokumentiert.

Nun kann man die Installation mit Standardkonfiguration wählen und die wesentlichen Einstellungen im Konfigurationsmenü zu ändern.

Screenshot Konfiguration (2019)

Alle weiterführenden Einstellungen werden in der Konfigurationsdatei /usr/local/etc/raspiBackup.conf mit einem Editor konfiguriert.

Zum Schluss kann die wöchentliche Sicherung mit raspiBackup eingeschaltet werden.

Der Installer kann jederzeit wieder in der Befehlszeile mit sudo raspiBackupInstallUI aufgerufen werden, um die Konfiguration zu ändern.

Installationsdemovideo

Systemd zum automatischen regelmäßigen Starten des Backups

Nachdem sowohl Backup als auch Restore erfolgreich getestet und die vor dem Backup zu stoppenden Services konfiguriert wurden, kann raspiBackup per Systemd timer für eine automatische Ausführung im gewünschten Intervall eingeplant werden.

Die Systemd-Konfiguration sollte immer mit dem Installer geändert werden.

Eventuelle manuelle Änderungen in der Systemd-Konfigurationsdatei /etc/systemd/system/raspiBackup.timer sollten "vorsichtig" vorgenommen werden. Sie könnten leicht dazu führen, dass der Installer die Konfigurationsdatei nicht mehr ändern kann.

Sollte es doch einmal ein Problem geben: Vom Installer wird immer ein Debuglog in der Datei /root/raspiBackupInstallUI.log angelegt, welches bei der Suche nach der Ursache hilft.

Die Benachrichtigung per eMail

Benachrichtigungen per eMail benötigen einen korrekt konfigurierten lokalen MTA wie Postfix, nullmailer, msmtp oder Exim4. Wird Pushover, Slack oder Telegram genutzt, muss die Konfigurationsdatei von raspiBackup vorher manuell entsprechend mit den benötigten Konfigurationsdaten versehen werden. Siehe Kapitel Allgemeine Konfiguration. Ein Benachrichtigungstest kann mit der Option -F durchgeführt werden.

Ein Backup erstellen ...

Nachdem die Backuppartition ja schon unter /backup gemountet ist (s.o.), kann das Backup gestartet werden. Beim ersten Mal vielleicht mit ausführlichen Meldungen:

sudo raspiBackup -m detailed

Je nach Größe der Installation kann das natürlich etwas länger dauern...

... und einen Restore testen!

Danach sollte unbedingt ein Restoretest durchgeführt werden (Link zur Restoredokumentation), um zu verifizieren, dass ein konsistentes Backup erstellt wird, und um sich mit der Restoreprozedur vertraut zu machen.

Denn: Ein Backup nützt nichts, wenn man in dem Moment, wo man es einspielen möchte, feststellt, dass es nicht zu gebrauchen ist.

Der ganze Restoreprozess sollte von Zeit zu Zeit durchexerziert und damit getestet werden, ob die erstellten Backups in Ordnung sind und sich damit ein System funktionsfähig restaurieren lässt. raspiBackup erinnert in regelmäßigen Abständen daran, einen Restoretest vorzunehmen. Das Erinnerungsintervall ist konfigurierbar. Der Standardwert ist 6 Monate.

Besonders wichtig ist das Testen auch, wenn ein neues System mit einem neuen Betriebssystem wieder mit raspiBackup gesichert wird. Es gibt immer wieder Änderungen bei neuen Betriebssystemversionen, die dazu führen können, dass der Restore nicht mehr funktioniert.

Weitere Schritte

Nachdem das erste Backup erfolgreich erstellt und wiederhergestellt wurde, sollte man sich in einer ruhigen Stunde über alle weiteren Optionen von raspiBackup informieren und je nach Bedarf einsetzen.

In jedem Falle ist es sinnvoll, sich die FAQs durchzulesen.

Jede Option kann in der Konfigurationsdatei /usr/local/etc/raspiBackup.conf definiert werden, so dass beim Aufruf keine weitere Optionen angegeben werden müssen.

Details dazu finden sich im Kapitel Aufruf und Optionen - Backup - Optionen und zu den Optionen, die sich nur über die Konfigurationsdatei einstellen lassen im Kapitel Aufruf und Optionen - Backup - Konfiguration.

Ebenfalls nützlich: raspiBackupDialog - ein komfortables Hilfsscript für raspiBackup, welches die Nutzung und den Aufruf von raspiBackup vereinfacht.

Deinstallation

Sollte sich tatsächlich herausstellen, dass raspiBackup nicht den Anforderungen genügt, steht eine Deinstallation per raspiBackup Installer zur Verfügung. Über einen der Kontaktwege ist es vorher aber sinnvoll, einmal nachzufragen, ob die vermisste Funktionalität nicht doch in raspiBackup verfügbar ist.

raspiBackup ohne Installation nutzen

Download von raspiBackup: curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackup.sh
Mount der Backuppartition unter /backup oder Angabe der Backuppartition als letzten Parameter im Aufruf, also z.B. sudo bash ./raspiBackup.sh /media/pi
Konfiguration von raspiBackup. Siehe dazu Aufruf und Optionen und die Konfiguration in der raspiBackup Konfigurationsdatei oder Nutzung der entsprechenden Aufrufoptionen beim Aufruf.
Start des Backups: sudo bash ./raspiBackup.sh

Falls kein rsync Backup gewünscht wird, muss der Backuptyp tar oder dd mit Option -t mitgegeben werden, also sudo bash ./raspiBackup.sh -t tar oder sudo bash ./raspiBackup.sh -t dd

Kurzinfos zu allen Aufrufoptionen von raspiBackup erhält man mit bash ./raspiBackup.sh -h

Installer - Aufruf und Optionen

Aufruf

sudo raspiBackupInstallUI {Optionen}

Es existieren zwei verschiedene Möglichkeiten den raspiBackup Installer raspiBackupInstallUI aufzurufen:

Aufruf ohne Optionen oder mit Option -t Der Installer startet mit einem Menu über welches raspiBackup konfiguriert werden kann. Option -t steuert ob crond oder systemd genutzt wird.
Aufruf mit Optionen Sofern eine andere Option als -tgenutzt wird führt der Installer die gewählte Funktion sofort ohne Menu aus.

Optionen

Mit folgenden Optionen kann der Installer bestimmte Funktionen direkt ohne Menüführung vornehmen:

-i: Re/Installation von raspiBackup
-e: Re/Installation von den raspiBackup Beispielerweiterungen
-h: Anzeige eines Hilfetextes
-U: Update vom Installer raspiBackupInstallUI
-u: Deinstallation von raspiBackup inklusive Installer
-t: Nutzung von entweder crond oder systemd als Backuptimer bei Option -i, Default ist systemd

Deinstallation

raspiBackup und der Installer können auch wieder deinstalliert werden:

sudo raspiBackupInstallUI -u

Hinweis: Dabei wird der Installer wie auch raspiBackup mit all seinen Dateien gelöscht!

Details zu einigen Menüpunkten

raspiBackup bietet zwei verschiedene Möglichkeiten an, Backupversionen vorzuhalten:

Eine maximale Anzahl von Backups, die für jeden Backuptyp behalten wird (Option -k). In der Konfigurationsdatei kann für jeden Backuptyp die Anzahl definiert werden (Option --keep<Type>). Wird die Anzahl überschritten, wird das älteste Backup gelöscht.
Nutzung der intelligenten Backupstrategie. Dabei werden nach einer bestimmten Regel Backups der letzten Tage, Wochen, Monate und Jahre vorgehalten. Ältere Backups werden jeweils gelöscht. Im Installer wird die Zahl der jeweils vorzuhaltenden Backups mit 4 Zahlen definiert. Der Standard ist 7 4 12 3.
1. tägliche Backups (7)
2. wöchentliche Backups (4)
3. monatliche Backups (12)
4. jährliche Backups (3)
Die intelligente Backupstrategie ist im Detail hier beschrieben.

Da raspiBackup keine Speicherinhalte sichert sollten alle Services, die wichtige Informationen im Speicher halten, vor dem Backup gestoppt werden.

raspiBackup bietet die Möglichkeit, vor dem Backup Services automatisch zu stoppen und anschließend wieder zu starten. Alle im Installer vorselektierten Services sollten immer gestoppt werden. Da nicht auszuschließen ist, dass auch weitere Services auf dem System wichtige Daten im Speicher halten und vor dem Backup gestoppt werden sollten, muss die Liste der nicht vorselektierten aber aktiven Services aufmerksam kontrolliert werden und im Bedarfsfall diese Services auch noch selektiert werden, damit sie vor dem Backup gestoppt werden.

Nach der Selektion der Services, die gestoppt werden sollen, muss noch die Reihenfolge definiert werden, in der sie gestoppt werden sollen. I.A. spielt die Reihenfolge keine Rolle, aber wenn ein Service Abhängigkeiten zu einem anderen Service hat, sollte der Service erst nach dem abhängigen Service gestoppt werden. Beispielsweise sollten alle Services, die mit einer Datenbank arbeiten, vor dem Stoppen der Datenbank gestoppt werden, damit sie noch offene Transaktionen beenden können.

raspiBackup bietet die Möglichkeit, regelmäßig automatisch Backups zu erstellen. Dieses erfolgt standardmäßig per Systemd, kann aber auch mit der Option -t beim Installieren des Installers auf Cron umgestellt werden.

Im Installer kann der Wochentag definiert werden, an dem ein Backup erstellt werden soll. Oder auch eine tägliche Sicherung. Außerdem wird die Zeit des Backups in Stunde und Minute definiert. Der Standard ist Sonntag um 05:00 Uhr.

Standardkonfiguration und Ort der Konfigurationsdatei

Der Installer erstellt folgende Dateien:

Konfigurationsdatei /usr/local/etc/raspiBackup.conf

In dieser werden folgende Standardwerte eingestellt und können mit dem Installer geändert werden. Alle anderen Optionen müssen mit einem Editor geändert werden oder mit einer Aufrufoption überschrieben werden.

Option	Einstellung
Backuppfad	/backup
Backupmode	normal
Backuptyp	rsync
Sprache	Sprache des Systems
Zip	nein
Meldungsdetail	normal
Backupanzahl	3
Services start	keine
Services stop	keine
Wöchentlicher Backup	nein
Backuptag	Sonntag
Backupzeit	05:00 Uhr

Aufruf und Optionen sind ausführlich beschrieben.

Systemd timer Konfiguration /etc/systemd/system/raspiBackup.timer

Diese Datei steuert den Aufruf von raspiBackup und im Standardfall ist der wöchentliche Backup ausgeschaltet. Er kann aber mit dem Installer eingeschaltet werden.
raspiBackup.sh /usr/local/bin
raspiBackupInstallUI.sh /usr/local/bin

Aufruf der Installation ohne Installer direkt von der Befehlszeile - online

Wer keine menügesteuerte Installation nutzen möchte, kann die Installation von raspiBackup und den Beispielextensions oder die Deinstallation direkt von der Befehlszeile aufrufen.

(Bei dieser Installation wird die Standardkonfiguration installiert.)

curl https://raspibackup.linux-tips-and-tricks.de/install | sudo bash -s -- -i

Statt -i kann jede andere Installeroption mitgegeben werden.

Änderungen an der Konfiguration können nun manuell mit einem Editor vorgenommen werden. Siehe dazu Aufruf und Optionen.

Man kann aber auch den Installer mit seinen Menüs benutzen, um die Konfiguration der primären Optionen anzupassen sowie den regulären Backup ein- oder auszuschalten.

Manuelle Installation und Konfiguration

Die Installation mit dem Installer ist die schnellste Methode. Man kann auch per Befehlszeile raspiBackup sehr schnell in einer Standardinstallation installieren. Wer raspiBackup aber aus verschiedenen Gründen manuell installieren möchte, findet im Folgenden die notwendigen Schritte:

Voraussetzungen: Login als Benutzer pi ins Home-Verzeichnis und eine aktive Netzwerkverbindung.

Der raspiBackup Installer wird in /usr/local/bin auf der Raspberry downloaded und aufgerufen. Dabei wird raspiBackup mit seinen Standardoptionen installiert. Anschließend kann man raspiBackup mit sudo raspiBackupInstallUI aufrufen und die Standardkonfiguration ändern.
```
 curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackupInstallUI.sh; sudo bash ./raspiBackupInstallUI.sh -i
```

raspiBackup kann man auch manuell downloaden und installieren.

Download der notwendigen Dateien:

curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackup.sh
curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackupInstallUI.sh
curl -sSL https://www.linux-tips-and-tricks.de/raspiBackup_de.conf > raspiBackup.conf

Jetzt müssen die Dateien in die entsprechenden Verzeichnisse kopiert und Ownership und Zugriffsrechte angepasst werden:

# Verschieben der Dateien in die richtigen Verzeichnisse
sudo mv raspiBackup.sh /usr/local/bin
sudo mv raspiBackupInstallUI.sh /usr/local/bin
sudo mv raspiBackup.conf /usr/local/etc

# Anpassen der Ownership und Zugriffsrechte
sudo chown root:root /usr/local/bin/raspiBackup.sh
sudo chmod 755 /usr/local/bin/raspiBackup.sh
sudo chown root:root /usr/local/etc/raspiBackup.conf
sudo chmod 600 /usr/local/etc/raspiBackup.conf

# Erstellen der Shortcuts ohne .sh am Ende
sudo ln -s /usr/local/bin/raspiBackup.sh /usr/local/bin/raspiBackup
sudo ln -s /usr/local/bin/raspiBackupInstallUI.sh /usr/local/bin/raspiBackupInstallUI

Nun kann der Installer mit sudo raspiBackupInstallUI aufgerufen werden und raspiBackup konfiguriert werden.

Anschließend sollte ein Restore eines Backups vorgenommen werden, um sich mit der Art, wie das Backup zu restoren ist, vertraut zu machen und das Backup zu testen. Es ist nichts ärgerlicher, wenn man zu dem Zeitpunkt, wenn man das Backup benötigt, feststellt, das das Backup nicht alles enthält oder sogar nicht brauchbar ist.

Will man raspiBackup auf einem System installieren, welches keinen Internetzugang hat, muss man 2.1 auf einem System ausführen, welches eine Internetverbindung hat. Danach sind die Dateien auf das Zielsystem zu kopieren und dort 2.2 und 2.3 auszuführen. Allerdings muss man berücksichtigen, dass dann keine Benachrichtigungen geschickt werden können wie auch keine Benachrichtigungen von raspiBackup bei neuen Versionen erhalten werden.

Statistiken

raspiBackup prüft bei jedem Start, maximal aber einmal pro Tag, ob es ein neues Release oder eine Beta gibt und weist dann mit einer Meldung darauf hin, so dass ein Upgrade geplant und durchgeführt werden kann. Bei dieser Prüfung werden auch ein paar Informationen übermittelt, die es ermöglichen, allgemeine Nutzungsdaten von raspiBackup zu ermitteln und sich einen Überblick über die jeweilige Nutzung zu verschaffen.

Die Informationen, die übertragen werden, sind

Release
Backuptyp
Backupmodus
Backup- oder Restoreaufruf
Keep
Parameter der intelligenten Rotationsstrategie, sofern sie genutzt wird
OS: Raspberry Pi OS oder Ubuntu

Das Senden dieser o.g. Informationen kann mit der Option

DEFAULT_SEND_STATS=0

in der Konfigurationsdatei /usr/local/etc/raspiBackup.conf ausgeschaltet werden.

Updates

Von Zeit zu Zeit wird eine neue Version von raspiBackup zum Download bereitgestellt, die neue Funktionen, Erweiterungen und kleine Fixes enthält.

Auf dieses wird von raspiBackup beim Aufruf und in der gesendeten eMail hingewiesen und man kann dann mit dem Parameter -U die neueste Version herunterladen und aktivieren. Die aktuelle Version wird dabei gesichert und mit dem Parameter -V kann jederzeit wieder die vorherige Version aktiviert werden.

Bei kleinen Änderungen wird kein neues Release zur Verfügung gestellt und man wird auch nicht auf die Änderung hingewiesen. Mit den Optionen -U -S wird immer der aktuelle Code heruntergeladen und aktiviert. So ein Update ist i.d.R. nicht notwendig und sollte nur vorgenommen werden, wenn dazu explizit aufgefordert wird.

Hinweis: Dabei wird kein Backup vom aktuell aktiven raspiBackup erstellt.

Vor dem Update sollte man nachlesen, welche Änderungen und Neuerungen in der neuen Version enthalten sind. Diese Information dazu findet sich in der Versionshistorie. Sollte einmal ein gravierender Fehler entdeckt werden, wird eine neue Version sofort bereitgestellt.

Jede neue Version wird vor der Veröffentlichung auf Regressions getestet.

Konfigurationsupdate

Sofern in einem neuen Release neue Optionen eingeführt wurden, wird die Konfigurationsdatei /usr/local/etc/raspiBackup.conf automatisch mit den neuen Optionen versehen. Die Details dazu sind hier beschrieben.

Funktionsdetails

Auf den folgenden Seiten werden verschiedene Themen zu raspiBackup genauer erklärt.

Dazu gehört ein Entscheidungsbaum, der hilft, den richtigen Backuptypen zu wählen. Weiterhin die Erklärung der Unterschiede vom normalen und partitionsorientierten Backupmodus, wie die intelligente Rotationsstrategie funktioniert, was raspiBackup Snapshots sind und welche Erweiterungsmöglichkeiten es gibt.

Außerdem finden sich Anleitungen, wie man bei den verschiedenen Backuptypen gezielt einzelne Dateien restoren kann.

Backup Einführung

raspiBackup erstellt im normalen Backupmodus immer ein vollständiges Backup des Systems. Beim partitionsorientierten Backupmodus können die zu sichernden Partitionen gewählt werden.

Wurde raspiBackup gerade frisch installiert und konfiguriert, wird empfohlen, die ersten Backups von der Befehlszeile zu erstellen und zu testen. Erst danach sollte der automatische Backup konfiguriert werden.

Bei der Konfiguration der Benachrichtigungen per eMail oder den anderen Pushdiensten hilft es sehr, die Option -F zu nutzen, denn dadurch wird kein Backup erzeugt, sondern es werden nur die Benachrichtigungen geschickt. So sind Fehlkonfigurationen schnell zu erkennen und können behoben werden, ohne immer auf die Beendigung eines längeren Backuplaufes warten zu müssen.

Entscheidungsbaum für Backuptypen

Es gibt verschiedene Backuptypen und eine jede hat ihre Vor- und Nachteile. Es können unterschiedliche Backuptypen kombiniert werden. Z.B. kann alle Monate ein Vollbackup mit tar erstellt werden und dazwischen wöchentlich ein rsync Delta Backup. Das erfordert aber eine manuelle Konfiguration von Systemd Timern und erfordert gute Systemd-Kenntnisse. Der raspiBackupInstaller konfiguriert nur genau einen Backuptypen.

Sämtliche Backuptypen können mit raspiBackup vollständig wiederhergestellt werden. Ein ddBackup kann auch unter Windows restored werden.

Ein dd Backup erstellt ein in sich konsistentes binäres Abbild des Systems. Dabei wird immer das ganze Gerät mit dem System gelesen und gesichert. Das bedeutet, dass auch Daten gesichert werden, die sich nicht geändert haben. Auch bedeutet es, dass zum Restore das Restoregerät wieder wenigstens so groß sein muss wie das Originalsystem. Es wird keine Partition in der Größe angepasst. Das bereitet besonders bei SD-Karten immer wieder Probleme, da die SD-Karten - obwohl z.B. 32GB groß - doch immer leichte Unterschiede haben und somit ein Restore eines 32GB Systems auf eine andere 32GB SD-Karte nicht erfolgreich sein kann, da die SD-Karte geringfügig kleiner ist.

Aber es wird nicht empfohlen, den Backuptyp dd zu nutzen. Erklärungen dazu sind in Warum sollte man dd als Backuptyp besser nicht benutzen? im Detail beschrieben.

Ein ddz Backup sichert wie ein dd Backup das gesamte System. Diese Methode belastet die CPU stark, da die Datenmenge reduziert wird. (Es ist ein dd Backup mit eingeschaltetem Zippen mit -z). Ein Restore mit Windowstools ist nicht möglich.

Ein tar Backup sichert alle auf dem Systemgerät gespeicherten Daten, wobei allerdings das Backup nicht so groß ist, wie bei einem dd Backup, da nur die Daten gesichert werden, die tatsächlich existieren. Deshalb kann auch ein tar Backup auf Geräten restored werden, die kleiner ist als das Originalgerät. Natürlich nur, sofern alle gesicherten Daten auf das neue Device passen.

Ein tgz Backup sichert das gesamte System, wie ein tar Backup. Diese Methode belastet die CPU stark, da die Datenmenge reduziert wird. (Es ist ein tar Backup mit eingeschaltetem Zippen mit -z)

Ein rsync Backup sichert außer beim ersten Mal nur die Daten, die sich zum letzten Backup geändert haben. Durch die Hardlinks des ext3/ext4 Dateisystems wird dafür gesorgt, dass trotzdem ein konsistenter Stand des Backups vorliegt. Allerdings werden die Daten nicht komprimiert. Das hat aber wiederum den Vorteil, dass man sehr gezielt einzelne Dateien ganz einfach per copy aus dem Backup zurückholen kann. Diese Methode ist sehr schnell, wenn bereits ein initiales Backup erstellt wurde.

Typ	Vollbackup	Backupzeit	Backupgröße	Datenkompression	CPU belastet	Karte belastet	Selektiver Restore möglich	Dateisystem
dd	ja	lang	groß	nein	mittel	hoch	nein	alle, fat32 nur bis 4GB
ddz	ja	lang	kleiner	ja	ja	hoch	nein	alle, fat32 nur bis 4GB
tar	ja	mittel	mittel	nein	nein	mittel	ja	alle, fat32 nur bis 4GB
tgz	ja	mittel	mittel	ja	ja	mittel	ja	alle, fat32 nur bis 4GB
rsync	ja	kurz mit Hardlinks	klein mit Hardlinks	nein	nein	kaum	ja	ext3/ext4

Entscheidungsbaum

Filesysteme

Die Vor- und Nachteile der möglichen Filesysteme sind zu beachten.

Vergleich partitionsorientierter Backup und normaler Backup

Es existieren zwei Backupmodi:

Normaler Backup

In diesem Modus werden die ersten zwei Partitionen (die Bootpartition und die Rootpartition) der SD-Karte gesichert. Außerdem wird beim tar und rsync Backup auch eine externe Rootpartition, d.h. eine auf einen USB Stick oder USB Platte ausgelagerte Rootpartition, gesichert. Falls das Zielgerät beim Restore größer ist als das Quellgerät, wird automatisch die zweite Partition entsprechend erweitert.

Mit dem dd Backup kann auch die gesamte SD-Karte gesichert werden. Es wird aber dringend davon abgeraten, ein dd Backup zu nutzen. Siehe: Warum sollte man dd als Backuptyp besser nicht benutzen?
Partitionsorientierter Backup

In diesem Modus wird jede auf dem System befindliche oder eine bestimmte ausgewählte Anzahl von Partitionen mit tar oder rsync gesichert. Dabei ist die Anzahl der Partitionen beliebig. Beim Restore kann ebenso ausgewählt werden, welche Partitionen zurückzuspielen sind. Wird auf das Originalsystem zurückgespielt, weil durch Änderungen am System es nicht mehr bootet, können bei einem rsync Backup nur die Änderungen zurückgespielt werden statt das ganze Backup und der Restore endet wesentlich schneller. Falls das Zielgerät beim Restore größer ist als das Quellgerät, wird die letzte Partition soweit erweitert, dass das gesamte Zielgerät genutzt wird.

Backupverzeichnisstruktur

Normaler Backup

Jeder Backuplauf erstellt im Backupverzeichnis ein Unterverzeichnis, welches folgendes Format hat: <hostname>.

Jeweils darunter wird ein weiteres Verzeichnis erstellt: <hostname>@<osversion>-<backuptyp>-<backupdatum>.

Bei Verwendung der Option -M (raspiBackup Snapshot) wird der Optionswert noch angehängt: <hostname>@<osversion>-<backuptyp>-<backupdatum><-M parameter>.

Beispiele:

Die Raspberry hat den Hostnamen "raspberrypi" und es wird ein rsync Backup von einem Bookworm OS am 15.04.2016 um 22:29:00 erstellt. Dann entstehen folgende Verzeichnisse:

 ├── raspberrypi
 │   └── raspberrypi@debian12-rsync-backup-20160415-222900

Gibt man als Parameter für die Option -M "Hello world" mit,

 ├── raspberrypi
 │   └── raspberrypi@debian12-rsync-backup-20160415-222900_Hello_world

Anbei die Verzeichnisstruktur meines Backupservers, der in diesem Falle auch eine Raspberry Pi ist. Verschiedene Backuptypen können pro Pi kombiniert werden. Jedes Backup wird in einem neuen Unterverzeichnis abgelegt.

Pro Raspberry System werden immer drei bzw. fünf weitere Dateien zusätzlich zum eigentlichen Backup erstellt und sind notwendig für den Restore, wenn es kein dd Backup ist. Damit ist es Linuxkundigen möglich, ein Backup auch manuell zu restoren. Dies ist im Kapitel Manueller Restore beschrieben.

.img - Bootpartition
.mbr - Master Boot Record des Systems
.sfdisk - Partitionslayout des Systems - Ausgabe des sfdisk Befehls
.blkid - (Partitionsorientierter Modus) - Ausgabe des blkid Befehls
.parted - (Partitionsorientierter Modus) - Ausgabe des parted Befehls

root@raspiBackup:/mnt/backup/raspberrypi# tree -L 2

 .
 ├── raspberrypi@debian12-dd-backup-20160415-222900
 │   └── raspberrypi@debian12-dd-backup-20160415-222900.img
 ├── raspberrypi@debian12-rsync-backup-20160416-094106
 │   ├── backup
 │   ├── bin
 │   ├── boot
 │   ├── boot.bak
 │   ├── dev
 │   ├── etc
 │   ├── home
 │   ├── lib
 │   ├── lost+found
 │   ├── media
 │   ├── mnt
 │   ├── opt
 │   ├── proc
 │   ├── raspberrypi-backup.img
 │   ├── raspberrypi-backup.mbr
 │   ├── raspberrypi-backup.sfdisk
 │   ├── raspiBackup.log
 │   ├── raspiBackup.msg
 │   ├── remote
 │   ├── root
 │   ├── run
 │   ├── sbin
 │   ├── selinux
 │   ├── srv
 │   ├── sys
 │   ├── tmp
 │   ├── usr
 │   └── var
 └── raspberrypi@debian12-tar-backup-20160415-204305
     ├── raspberrypi-backup.img
     ├── raspberrypi-backup.mbr
     ├── raspberrypi-backup.sfdisk
     ├── raspberrypi-tar-backup-20160415-204305.tar
     ├── raspiBackup.log
     └── raspiBackup.msg

Partitionsorientierter Backup

root@boockworm:/mnt/backup/raspberrypi# tree -L 2
.

├── raspberrypi-backup.blkid
├── raspberrypi-backup.fdisk
├── raspberrypi-backup.mbr
├── raspberrypi-backup.parted
├── raspberrypi-backup.sfdisk
├── mmcblk0p1
│   ├── bcm2708-rpi-b.dtb
│   ├── bcm2708-rpi-b-plus.dtb
│   ├── bcm2708-rpi-b-rev1.dtb
│   ├── bcm2708-rpi-cm.dtb
│   ├── bcm2708-rpi-zero.dtb
│   ├── bcm2708-rpi-zero-w.dtb
│   ├── bcm2709-rpi-2-b.dtb
│   ├── bcm2710-rpi-2-b.dtb
│   ├── bcm2710-rpi-3-b.dtb
│   ├── bcm2710-rpi-3-b-plus.dtb
│   ├── bcm2710-rpi-cm3.dtb
│   ├── bcm2711-rpi-400.dtb
│   ├── bcm2711-rpi-4-b.dtb
│   ├── bcm2711-rpi-cm4.dtb
│   ├── bootcode.bin
│   ├── cmdline.txt
│   ├── config.txt
│   ├── COPYING.linux
│   ├── fixup4cd.dat
│   ├── fixup4.dat
│   ├── fixup4db.dat
│   ├── fixup4x.dat
│   ├── fixup_cd.dat
│   ├── fixup.dat
│   ├── fixup_db.dat
│   ├── fixup_x.dat
│   ├── issue.txt
│   ├── kernel7.img
│   ├── kernel7l.img
│   ├── kernel8.img
│   ├── kernel.img
│   ├── LICENCE.broadcom
│   ├── overlays
│   ├── start4cd.elf
│   ├── start4db.elf
│   ├── start4.elf
│   ├── start4x.elf
│   ├── start_cd.elf
│   ├── start_db.elf
│   ├── start.elf
│   └── start_x.elf
├── mmcblk0p2
│   ├── backup
│   ├── bin
│   ├── boot
│   ├── dev
│   ├── etc
│   ├── home
│   ├── lib
│   ├── lost+found
│   ├── media
│   ├── mnt
│   ├── opt
│   ├── proc
│   ├── remote
│   ├── root
│   ├── run
│   ├── sbin
│   ├── srv
│   ├── sys
│   ├── tmp
│   ├── usr
│   └── var
├── raspiBackup.log
└── raspiBackup.msg

Intelligente Rotationsstrategie - Smart Recycle

raspiBackup kann entweder eine konfigurierbare Anzahl von Backups vorhalten oder eine intelligente Rotationsstrategie des Backups nutzen. Es wird auch "Generationenprinzip in der Datensicherung" genannt. Die Implementierung wurde von Manuel Dewalds Artikel "Automating backups on a Raspberry Pi NAS" inspiriert. Standardmäßig werden dann folgende Backups vorgehalten, wenn täglich Backups erstellt werden:

Backups des aktuellen Tages und der letzten 6 Tage
Backups der aktuellen Woche sowie der letzten 3 Wochen
Backups des aktuellen Monats sowie der letzten 11 Monate
Backup des aktuellen Jahres sowie der letzten 2 Jahre

Dieses lässt sich mit dem Installer den jeweiligen Bedürfnissen anpassen.

Werden wöchentliche Backups erstellt, entfallen natürlich die täglichen Backups. Die jeweilige Aufbewahrungsdauer für täglich, wöchentlich, monatlich und jährlich lassen sich mit Optionen konfigurieren.

Möchte man also nur wöchentliche, monatliche und jährliche Backups haben, kann das konfiguriert werden. Dabei ist zu beachten, dass dann der wöchentliche Backuptag den Backuptag des Monats definiert: Wird z.B. Montag als wöchentlicher Backuptag konfiguriert, ist das monatliche Backup immer am ersten Montag im Monat und das jährliche Backup am ersten Montag im Jahr.

Hinweis

Bei mehreren möglichen täglichen Backups wird immer das neueste tägliche Backup aufbewahrt. Bei den wöchentlichen, monatlichen und jährlichen Backups sind es dagegen die jeweils ältesten Backups.

Zum Beispiel wird bei zwei existierenden täglichen Backups von 10:00 und 13:00 Uhr der um 13:00 Uhr erstellte Backup gewählt.

Gibt es in der Woche Montag und Freitag Backups, wird der wöchentliche Backup von Montag gewählt.

Gibt es einen Backup am 1., 10. und 20. eines Monats, wird das Backup vom

für den monatlichen Backup gewählt.

Bei täglichen Backups sind somit wöchentliche Backups immer vom Montag, monatliche Backups immer vom Ersten des Monats und jährliche Backups immer vom 1.1. des Jahres.

Grafische Darstellung

smartStrategy

Beispiel - Backupverzeichnis (täglicher Backuplauf, Standardoptionen: 7/4/12/3)

    (Backuplauf am 17.11.2019)

    20191117 1. tägliches Backup
    20191116 2. tägliches Backup
    20191115 3. tägliches Backup
    20191114 4. tägliches Backup
    20191113 5. tägliches Backup
    20191112 6. tägliches Backup
    20191111 7. tägliches und 1. wöchentliches Backup

    20191101 1. monatliches Backup
    20191104 2. wöchentliches Backup
    20191001 2. monatliches Backup
    20191028 3. wöchentliches Backup
    20191021 4. wöchentliches Backup
    20190901 3. monatliches Backup
    20190801 4. monatliches Backup
    20190701 5. monatliches Backup
    20190601 6. monatliches Backup
    20190501 7. monatliches Backup
    20190401 8. monatliches Backup
    20190301 9. monatliches Backup
    20190201 10.monatliches Backup

    20190101 11. monatliches Backup und 1. jährliches Backup
    20181201 12. monatliches Backup
    20180101 2. jährliches Backup
    20170101 3. jährliches Backup

Optionen

Die intelligente Rotationsstrategie schaltet man mit der Option --smartRecycle ein. Mit der Option --smartRecycleOptions kann man die Aufbewahrungsmengen umdefinieren. Standardmäßig ist die Option --smartRecycleOptions "7 4 12 3" aktiv. Mit --smartRecycleOptions "0 4 12 0" werden z.B. die letzten 4 wöchentlichen und die letzten 12 monatlichen Backups vorgehalten.

Wichtiger Hinweis

Solange man nicht die Option --smarteRecycleDryrun ausgeschaltet hat, schreibt raspiBackup nur Meldungen, welche Backups gelöscht und welche aufgehoben würden.

Man kann somit erst einmal kontrollieren, ob das Ergebnis dem Gewünschten entspricht. Dadurch lässt sich verhindern, dass unbeabsichtigt existierende Backups gelöscht werden.

Das ist besonders wichtig, wenn man nach Umstellung auf die intelligente Rotationsstrategie das bisherige Backupverzeichnis weiterhin benutzen möchte und kein neues Verzeichnis benutzt.

Wurde sorgfältig geprüft, dass die intelligente Rotationstrategie die richtigen Backups löscht und die gewünschten Backups aufhebt, wird mit der Option --smartRecycleDryrun- (das - am Ende beachten!) in jedem Backuplauf die intelligente Rotationstrategie angewendet und nicht mehr benötigte Backups werden unwideruflich gelöscht.

Alternativ bewirkt die Konfigurationsoption

DEFAULT_SMART_RECYCLE_DRYRUN=0

dasselbe Ergebnis.

Auf Wikipedia - im Artikel Generationenprinzip - wird schön erklärt, wie das Rotationsprinzip funktioniert. Speziell die Grafik ist eine andere Möglichkeit, das Prinzip zu erklären.

Snapshots

raspiBackup bietet mit der Option -M die Möglichkeit, eine Art Snapshot zu erzeugen. Dieses sind normale Backups, die aber zwei Besonderheiten haben:

Snapshots werden nicht automatisch gelöscht durch die gewählte Backupstrategie
Snapshots muss man eine Beschreibung als Parameter zur Option -M mitgeben. Diese wird am Ende des Verzeichnisnamens angehängt und erlaubt den Grund des Snapshots zu speichern.

Somit kann man sehr leicht einen Snapshot außer der Reihe erstellen und durch die Beschreibung im Namen des Backupverzeichnisses kann der Grund des Snapshots erkannt werden. Das ist zum Beispiel sehr hilfreich, bevor man ein Softwareupdate vornimmt oder eine andere größere Änderung plant. Wenn das Update schief geht, hat man schnell wieder den vorherigen Stand hergestellt. Wenn er erfolgreich war, muss man den Snapshot im Backupverzeichnis manuell löschen.

Hinweis: raspiBackup Snapshots sind keine Snapshots im eigentlichen Sinne wie sie z.B. mit btrfs erstellt werden können. Es sind normale dd, tar oder rsync Backups. rsync Backups sind Deltabackups und dementsprechend auch bei Snapshots schneller fertig als dd oder tar Backups.

Es gibt ein Youtube Video, in dem die raspiBackup Snapshots erklärt werden sowie eine Demo gegeben wird.

Konfigurationsupdate bei einem Upgrade auf eine neue Version

Wann immer ein Upgrade einer raspiBackup Version vorgenommen wird, erfolgt sofort eine Prüfung, ob die neue Version eine neue Konfigurationsversion benötigt. Falls ja, erfolgt eine automatische Zusammenführung der lokalen Konfiguration mit der neuen Konfiguration in einer neuen Konfigurationsdatei von raspiBackup. Im Folgenden wird im Detail beschrieben, wie diese Zusammenführung vorgenommen wird.

Hinweis: Sollte aus irgendwelchen Gründen kein Konfigurationsdateiupdate bei einem Upgrade stattgefunden haben, kann mit folgendem Befehl der Update manuell angestoßen werden:

sudo raspiBackup.sh --updateConfig

Beim Zusammenführen der beiden Konfigurationen schreibt raspiBackup verschiedene Informationsmeldungen. Die folgenden Meldungen werden beispielsweise geschrieben, wenn von raspiBackup 0.6.4.3 auf raspiBackup 0.6.5 upgraded wird.

--- RBK0241I: Aktuelle Konfiguration v0.1.3 wird mit der neuen Konfiguration v0.1.4 in /usr/local/etc/raspiBackup.conf.merged zusammengefügt.
--- RBK0248I: Option DEFAULT_SMART_RECYCLE=0 wurde zugefügt.
--- RBK0248I: Option DEFAULT_SMART_RECYCLE_DRYRUN=1 wurde zugefügt.
--- RBK0248I: Option DEFAULT_SMART_RECYCLE_OPTIONS="7 4 12 1" wurde zugefügt.
--- RBK0248I: Option DEFAULT_TELEGRAM_TOKEN="" wurde zugefügt.
--- RBK0248I: Option DEFAULT_TELEGRAM_CHATID="" wurde zugefügt.
--- RBK0248I: Option DEFAULT_TELEGRAM_NOTIFICATIONS="F" wurde zugefügt.
--- RBK0248I: Option DEFAULT_NOTIFY_START=0 wurde zugefügt.
--- RBK0248I: Option DEFAULT_COLORING="CM" wurde zugefügt.
--- RBK0243I: Konfigurationszusammenfügung wurde erfolgreich beendet aber nicht aktiviert.
!!! RBK0245W: Soll die aktuelle Konfiguration in /usr/local/etc/raspiBackup.conf.bak gesichert werden und die aktualisierte Konfiguration aktiviert werden? j/N

Man sieht, dass eine neue Konfigurationsdatei /usr/local/etc/raspiBackup.conf.merged erstellt wird und in dieser die Zusammenfügung der aktuellen Konfigurationsdatei /usr/local/etc/raspiBackup.conf mit der neuen Konfigurationsdatei vorgenommen wird.

Welche Änderungen vorgenommen werden, kann in den Meldungen RBK0248I abgelesen werden. Zum Schluss wird man gefragt, ob die zusammengefügte Konfigurationsdatei aktiviert werden soll. Natürlich wird vorher ein Backup der existierenden Konfigurationsdatei in /usr/local/etc/raspiBackup.conf.bak vorgenommen. Antwortet man mit "ja", ist die Konfigurationszusammenfügung beendet und bekommt noch folgende Meldungen:

--- RBK0240I: Aktuelle Konfiguration /usr/local/etc/raspiBackup.conf wird in /usr/local/etc/raspiBackup.conf.bak gesichert.
--- RBK0244I: Zusammengefügte Konfiguration /usr/local/etc/raspiBackup.conf.merged nach /usr/local/etc/raspiBackup.conf kopiert und aktiviert.

Das ist die einfachste Methode, um die Konfigurationsdatei zu aktualisieren und ist schnell vorgenommen.

Man kann aber auch mit "nein" antworten und die zusammengefügte Konfigurationsdatei nicht sofort aktivieren. Man erhält dann folgende Meldung:

--- RBK0247I: Nun die zusammengefügte Konfigurationsdatei /usr/local/etc/raspiBackup.conf.merged überprüfen und nach /usr/local/etc/raspiBackup.conf kopieren um den Konfigurationsupdate zu beenden.

Innerhalb der zusammengefügten Konfigurationsdatei sind die neuen Optionen wie folgt gekennzeichnet und somit gut zu erkennen:

# Smart recycle
# >>>>> NEW OPTION added in config version "0.1.4" <<<<<
DEFAULT_SMART_RECYCLE=0
# Smart recycle dryrun
# >>>>> NEW OPTION added in config version "0.1.4" <<<<<
DEFAULT_SMART_RECYCLE_DRYRUN=1
# Smart recycle parameters (daily, weekly, monthly and yearly)
# >>>>> NEW OPTION added in config version "0.1.4" <<<<<
DEFAULT_SMART_RECYCLE_OPTIONS="7 4 12 1"`

Nun kann man sich manuell mit einem Editor die zusammengeführte Konfigurationsdatei /usr/local/etc/raspiBackup.conf.merged ansehen, kontrollieren und wenn nötig ändern. Zum Schluss wird die Datei zur Aktivierung nach /usr/local/etc/raspiBackup.conf kopiert.

Abschließend ist es sinnvoll, wie immer nach einem Upgrade, einen Backup/Restore Zyklus durchführen, um zu testen, ob noch alles wie vorher funktioniert.

raspiBackup unterstützt auch die Benutzung von unterschiedlichen Konfigurationsdateien. Der automatische Konfigurationsupgrade wird aber nur für die Standardkonfiguration /usr/local/etc/raspiBackup.conf vorgenommen. Alle anderen Konfigurationsdateien müssen manuell erweitert werden, indem die als neu gekennzeichneten Konfigurationszeilen genommen und in die anderen Konfigurationsdateien kopiert werden.

Anwendungs- und Konfigurationsbeispiele

Hier werden verschiedene Anwendungsbeispiele von raspiBackup sowie ihre Konfiguration vorgestellt und erklärt. Sie sollen helfen, aus der Vielzahl der Anwendungsmöglichkeiten die Richtige zu finden oder das Beispiel dann nach den eigenen Ansprüchen entsprechend anzupassen. Eine Übersicht aller Optionen findet sich in Aufruf und Optionen. Verschiedene Methoden, ein Backup zu restoren, sind im Kapitel Wiederherstellen/Restore beschrieben.

Weiterhin gibt es auf folgenden Seiten Konfigurationsbeispiele für verschiedene eMail Clients:

Anwendungsbeispiele

Ein Windowsbenutzer möchte seine Raspberry sichern und auf Windows restoren können.

Um ein Image unter Windows restoren zu können, muss ein dd Image von raspiBackup erstellt werden. Folgende Konfigurationsoptionen sind dazu wenigstens notwendig:

DEFAULT_BACKUPTYPE=dd
DEFAULT_KEEPBACKUPS=n

Ein Windowsbenutzer hat eine 32GB SD-Karte und benutzt nur 12GB davon, die er aber auch nur sichern möchte

Zusätzlich zu den genannten Optionen ist die folgende Option notwendig:

DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY=1

Allerdings ist dazu auch notwendig, die Rootpartition der Raspberry zu verkleinern, da standardmäßig der gesamte freien Platz der SD-Karte gesichert wird. Dieses geht aber nicht unter Windows sondern es muss ein Linux benutzt werden und mit den Tools gparted oder resize2fs die Rootpartition verkleinert werden.

Ein Windowsbenutzer möchte mit pishrink ein absolut minimales Image erstellen

Um ein minimales Backup zu erzeugen, kann man das Tool pishrink benutzen. Dazu gibt es das Script raspiBackupWrapper.sh, mit welchem man am Ende des Backups das dd Image per pishrink verkleinern kann. Die Option

DEFAULT_ZIP_BACKUP=1

verkleinert zwar auch noch einmal das Image, aber das kann nicht direkt unter Windows restored werden. Es muss vorher unzipped werden.

Eine Raspberry soll möglichst schnell gesichert werden. Die Backuppartition ist ein per NFS gemountetes EXT4 Dateisystem, welches von einer NAS zur Verfügung gestellt wird

Zuerst muss die Backuppartition der NAS gemounted werden. Dazu sollte in /etc/fstab die NFS Partition definiert und automatisch unter /backup gemounted sein.

DEFAULT_BACKUPTYPE=rsync
DEFAULT_KEEPBACKUPS=n

Da das Backupfilesystem mit EXT4 formatiert ist, kann raspiBackup Hardlinks benutzen und das beschleunigt den Backupprozess sehr, da nur die geänderten Dateien gesichert werden.

Ein Beispieleintrag in der /etc/fstab könnte wie folgt aussehen:

asterix:/backup    /backup    nfs    users,rw,sync,hard,intr,noauto,user    0    0

Dabei ist "asterix" der Hostname der NAS und "/backup" der exportierte NFS Mount. Weitere Hinweise zu Synology-spezifischen Einstellungen und Problemlösungen finden sich hier

Eine Raspberry soll auf ein per SMB gemountetes Dateisystem gesichert werden, welches von einem Windowssystem zur Verfügung gestellt wird

DEFAULT_BACKUPTYPE=tar
DEFAULT_KEEPBACKUPS=n

Das remote Windows Backupfilesystem sollte in der /etc/fstab definiert sein und automatisch gemounted werden. Es wird jedes Mal das gesamte System gesichert. Dabei ist darauf zu achten, dass das Filesystem auf dem SMB Laufwerk Dateien größer als 4GB unterstützen muss, denn die tar Dateien sind i.d.R. über 4GB groß. FAT32 reicht dazu nicht. Siehe dazu auch Welches Filesystem kann man auf der Backuppartition nutzen

Ein Beispieleintrag in der /etc/fstab könnte wie folgt aussehen:

//asterix/backup/ /backup    cifs noauto,noatime,user,utf8,umask=000,uid=1000,gid=1000,credentials=/etc/samba/auth.asterix.cifsuser 0 0

Es ist eine größere Änderung an der Raspberry beabsichtigt und verschiedene Zwischenstände sollen sicherheitshalber gesichert werden

Hierzu ist eine fertige Konfiguration von raspiBackup erforderlich (siehe vorhergehende Beispiele). Dann muss raspiBackup nur noch mit der Option

-M "Das ist ein sprechender Name des Backups"

aufgerufen werden und es wird ein Backup mit genau diesem sprechenden Namen im Backupverzeichnis /backup erstellt.

Hinweis: Dieses Backup ist ein sogenannter Snapshot und wird beim Backuprecycle ignoriert. Das Backup kann bei Bedarf manuell gelöscht werden.

Ein USB Boot System soll mit weiteren Partitionen gesichert werden

In diesem Falle wird der partitionsorientierte Backup gewählt sowie die zu sichernden Partitionen konfiguriert. Im Beispiel soll die Partition 5 mitgesichert werden.

DEFAULT_PARTITIONBASED_BACKUP=1
DEFAULT_BACKUPTYPE=rsync
DEFAULT_KEEPBACKUPS=n
DEFAULT_PARTITIONS_TO_BACKUP="1 2 5"

Eine Raspberry soll auf einen lokal angeschlossen USB Stick oder eine lokal angeschlossene USB Platte gesichert werden

DEFAULT_BACKUPTYPE=rsync
DEFAULT_KEEPBACKUPS=n
DEFAULT_BACKUPPATH="/USBStick"

Damit rsync Hardlinks benutzt und das Backup schnell ist, muss die Backuppartition mit ext3/4 formatiert sein. Will man Daten mit Windows austauschen und die Partition wurde mit Windows formatiert, ist tar als Backuptype zu benutzen. Dann dauert allerdings das Backup länger und benötigt deutlich mehr Platz.

Hinweis: Falls die USB Partition von Windows aus zugreifbar sein soll, muss sie mit NTFS formatiert sein. Dann ist aber kein Backuptyp rsync möglich. NTFS kann nur mit dem Backuptype dd und tar genutzt werden und der DEFAULT_BACKUPTYPE muss dann entsprechend gesetzt werden.

Ein Beispieleintrag in der /etc/fstab könnte wie folgt aussehen:

LABEL=usb    /USBStick    ext4     defaults,noatime,nofail        0    2

msmtp Konfiguration für einen web.de Account

Der Nutzer gNeadr von raspiBackup hatte Probleme, die eMail-Benachrichtigung für seinen web.de Account einzurichten. Nachdem es ihm erfolgreich gelungen war, alles richtig zu konfigurieren, bot er erfreulicherweise an, seine Installations- und Konfigurationsschritte hier zu veröffentlichen, damit andere raspiBackup Nutzer es leichter haben, die eMailKonfiguration für raspiBackup vorzunehmen.

In raspiBackup ist nicht viel zu konfigurieren. Die Schwierigkeit ist, den eMailClient richtig zu konfigurieren.

Anbei die Installations- und Konfigurationsschritte von gNeandr - noch einmal sehr herzlichen Dank für die Bereitstellung.

Raspberry Installation 2023-08-20
====================================================
SDCard 64GB microSDXC
 ext4 formatiert mit gparded auf LX
 Label: RXXXX

Install Raspberry Pi OS with Raspberry Pi Imager v.1.7.4

OS: Raspberry PI OS Lite (32-bit) Bullseye vom 2023-05-03

SD-Karte: Generic STORAGE_DEVICE (RXXXX) - 63.8GB

Erweiterte Einstellungen:

Hostname: rasp1
SSH aktiviert, Name: rasp1 PW: [siehe keypass]
Wifi: SSID: [ssid] PW: [siehe keypass]
Wifi Land: DE
Spracheinstellung: Berlin Tastatur: de

Speichern ==> SCHREIBEN

Setup for Static LAN with Fritzbox

(see also https://learn.sparkfun.com/tutorials/headless-raspberry-pi-setup/ethernet-with-static-ip-address)

Mit LX Terminal auf der SDCard (im CardLeser) die IF-Datei anpassen:

$ ls -lt /media/xxxxx/rootfs/etc/dhcpcd.conf

interface eth0
static ip_address=192.123.123.xx/24
static routers=192.123.123.1
static domain_name_servers=192.123.123.1

Erfordert Zugriff mit:

sudo nano /media/xxxxx/rootfs/etc/dhcpcd.conf

Danach im LX Dateimanager SDCard auswerfen.

Raspberry starten und konfigurieren

Danach SD-Karte in Raspberry installieren und diesen starten/Netzadapter anschliessen.

Mit Fritzbox kontrollieren, ggf. Namen des 'raspberry' ändern.

Raspberry per SSH starten mit:

ssh pi@192.123.123.7X (ip des Raspberry wie oben konfiguriert)

Raspberry/RASPIAN OS Konfigurieren & Update/Upgrade

Zur Sicherheit das Password ändern ... (see also https://www.raspberrypi.org/documentation/configuration/security.md) ... dies erfolgt mit dem Raspberry Config tool:

$ sudo raspi-config

Einstellung z.B.:

│ 1 Change User Password Change password for the 'pi' user │
│ 2 Network Options Configure network settings │
--> Name eingeben zB 'raspellX'
│ 3 Boot Options Configure options for start-up │
--> B2 Wait for network
│ 4 Localisation Options Set up language and regional settings to match your │
--> Locales: de_DE.UTF-8 UTF-8
--> default : en_GB.UTF-8
--> Timezone
--> Keyboard
│ 5 Interfacing Options Configure connections to peripherals │
--> P2 SSH
│ 6 Overclock Configure overclocking for your Pi │
│ 7 Advanced Options Configure advanced settings │
--> A1 Expand Filesystem
│ 8 Update Update this tool to the latest version │
--> update the tool
│ 9 About raspi-config Information about this configuration tool |

$ sudo apt-get update
$ sudo apt-get upgrade

mSMTP für Versand von EMail zB. aus raspiBackup

Diese Zusammenstellung basiert auf: https://goneuland.de/raspberry-pi-e-mails-versenden-mit-msmtp/

Installation

$ sudo apt-get install msmtp msmtp-mta mailutils

$ msmtp --version

msmtp version 1.8.11
Platform: arm-unknown-linux-gnueabihf
TLS/SSL library: GnuTLS
Authentication library: GNU SASL; oauthbearer: built-in
Supported authentication methods:
plain scram-sha-1 external gssapi cram-md5 digest-md5 login ntlm oauthbearer
IDN support: enabled
NLS: enabled, LOCALEDIR is /usr/share/locale
Keyring support: Gnome
System configuration file name: /etc/msmtprc <<===
User configuration file name: /home/pi/.msmtprc <<===
Copyright (C) 2020 Martin Lambers and others.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Die mit <<=== bezeichneten Zeilen sind wichtig für die weitere mSMTP Konfiguration!

Config Datei erstellen (bzw anpassen) für Versand mit WEB.de

$ sudo nano /etc/msmtprc

Das nachfolgende Listing von "/etc/msmtprc" zeigt die Einstellungen für den Versand über einen existierenden EMail Account bei WEB.de

Für den eigenen Einsatz müssen die Zeilen, die auf "# Anpassen" folgen mit den eigenen Werten geändert werden.

Im Abschnitt "# Authentifizierungs-Methoden." sind verschiedene Formate für die Passwort Angabe möglich. Die einfachste Art (wie im Beispiel) ist der direkte Eintrag des PW des Mail Account ... ABER das ist nicht die sicherste Methode! Siehe auch: # https://marlam.de/msmtp/msmtp.html#Authentication

$ sudo cat /etc/msmtprc

# Set default values for all following accounts.
defaults
# Use the mail submission port 587 instead of the SMTP port 25.
port 587
# Always use TLS.
tls on
# Mail account
# Hier wird jetzt alles für den E-Mail Account konfiguriert
# Einen beliebigen Namen verwenden
account raspi
# Host name of the SMTP server
# Anpassen
host smtp.web.de
# Envelope-from address
# Anpassen
from yyyyyy@web.de
# Authentifizierungs-Methoden. Mehr Informationen dazu findet man in der Dokumentation zu msmtp:
# https://marlam.de/msmtp/msmtp.html#Authentication
auth on
# Anpassen
user yyyyyy@web.de
# Anpassen
password PxxxxxxxxW
# Set a default account
# Name von oben hier wieder eintragen
account default: raspi

Rechte / Zugriff Anpassen

Die nächsten Schritte passen die Rechte der Datei an.

$ sudo chmod 600 /etc/msmtprc

Festlegen des E-Mail Programms mit "set sendmail":

$ sudo nano /etc/mail.rc

set sendmail="/usr/bin/msmtp -t"

$ sudo chown pi:pi /etc/msmtprc
$ ls -lt /etc/msmtprc

-rw------- 1 pi pi 566 Aug 19 19:55 /etc/msmtprc

Test von mSMTP für WEB.de

$ sudo echo "E-Mail Test" | mail -s "E-Mail Betreff" yyyyyy@web.de

Damit empfängt der WEB.de Mail Account diese Nachricht:

Betreff: E-Mail Betreff: mSMTP TEST
Datum: Sun, 20 Aug 2023 14:40:18 +0200
Von: yyyyyy@web.de
An: yyyyyy@web.de
E-Mail Test

raspiBackup Konfiguration für EMail Versand mit mSMTP

Anpassung

Die Konfigurationsdatei "raspiBackup.conf" wird an die vorstehende mSMTP Einrichtung angepasst für raspiBackup EMail Benachrichtigungen mit:

$ sudo nano /usr/local/etc/raspiBackup.conf

# email to send completion status
DEFAULT_EMAIL="yyyyyy@web.de"
# Sender emailadresse die mit ssmtp und msmtp benutzt wird
DEFAULT_SENDER_EMAIL="yyyyyy@web.de"
# Additional parameters for email program (optional)
DEFAULT_EMAIL_PARMS=""
# mailprogram
DEFAULT_MAIL_PROGRAM="mail"

Test EMail-Benachrichtung von raspiBackup mit mSMTP für WEB.de

$ sudo *raspiBackup* -m detailed -F

Console Ausgabe:

--- RBK0009I: rasp8: *raspiBackup*.sh V0.6.8 - 2023-08-18 (cbfe5e8) Sun 20 Aug 15:42:40 CEST 2023 gestartet.
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
!!! RBK0124W: Simulationsmodus an.
--- RBK0151I: Backuppfad /media/backup8 mit Partitionstyp ext4 wird benutzt.
!!! RBK0157W: Keine Systemd Services sind zu stoppen.
--- RBK0081I: Backup vom Typ rsync wird in /media/backup8/rasp8/rasp8-rsync-backup-20230820-154237 erstellt.
--- RBK0078I: Backupzeit: 00:00:01.
--- RBK0033I: Bitte warten bis aufgeräumt wurde.
--- RBK0159I: 5 Backups werden für den Backuptyp rsync aufbewahrt. Bitte Geduld.
--- RBK0017I: Backup erfolgreich beendet.
--- RBK0010I: rasp8: *raspiBackup*.sh V0.6.8 - 2023-08-18 (cbfe5e8) Sun 20 Aug 15:42:49 CEST 2023 beendet mit Returncode 0.
--- RBK0167I: Eine eMail wird versendet.
--- RBK0026I: Debug Logdatei wurde in /home/pi/raspiBackup.log gesichert.

Der WEB.de Mail Account empfängt diese Nachricht:

Betreff: rasp8: Backup erfolgreich beendet.
Datum: Sun, 20 Aug 2023 15:42:50 +0200
Von: yyyyyy@web.de
An: yyyyyy@web.de
--- RBK0009I: rasp8: *raspiBackup*.sh V0.6.8 - 2023-08-18 (cbfe5e8) Sun 20 Aug 15:42:40 CEST 2023 gestartet.
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
!!! RBK0124W: Simulationsmodus an.
--- RBK0151I: Backuppfad /media/backup8 mit Partitionstyp ext4 wird benutzt.
!!! RBK0157W: Keine Systemd Services sind zu stoppen.
--- RBK0081I: Backup vom Typ rsync wird in /media/backup8/rasp8/rasp8-rsync-backup-20230820-154237 erstellt.
--- RBK0078I: Backupzeit: 00:00:01.
--- RBK0033I: Bitte warten bis aufgeräumt wurde.
--- RBK0159I: 5 Backups werden für den Backuptyp rsync aufbewahrt. Bitte Geduld.
--- RBK0017I: Backup erfolgreich beendet.
--- RBK0010I: rasp8: *raspiBackup*.sh V0.6.8 - 2023-08-18 (cbfe5e8) Sun 20 Aug 15:42:49 CEST 2023 beendet mit Returncode 0.
--- RBK0167I: Eine eMail wird versendet.

Exim4 Konfiguration

Folgende Variablen werden in der Beschreibung genutzt:

eMail Domain: MYDOMAIN (z.B. dummy.de)
Hostname des Servers: HOSTNAME (z.B. myserver)
smtp Hostname, um eMails abzuliefern: SMTP_PROVIDER_HOST (z.B. mail.your-server.de)
Userid, um emails zu senden: SMTP_INPUT_USERNAME
Password, um emails zu senden: SMTP_INPUT_PASSWORD

Änderungen bzw. Einfügungen:

/etc/aliases: root: HOSTNAME@MYDOMAIN, dann sudo newaliases
/etc/mailname: MYDOMAIN
/etc/hostname: HOSTNAME.MYDOMAIN
/etc/email-addresses: root: HOSTNAME@MYDOMAIN
/etc/hosts: hosts:127.0.1.1 HOSTNAME HOSTNAME.MYDOMAIN

/etc/exim4/update-exim4.conf.conf

dc_eximconfig_configtype='internet'
dc_other_hostnames='localhost'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='HOSTNAME.MYDOMAIN'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='SMTP_PROVIDER_HOST'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
keep_environment=

/etc/exim4/passwd.client

SMTP_PROVIDER_HOST:SMTP_INPUT_USERNAME:SMTP_INPUT_PASSWORD

Um z.B. Statusmails von raspiBackup als root zu versenden, kann nullmailer eingesetzt werden.

nullmailer Konfiguration

Um z.B. Statusmails von raspiBackup als root zu versenden, kann nullmailer eingesetzt werden.

Folgende Variablen werden in der Beschreibung genutzt (Provider ist Hetzner):

eMail Domain: MYDOMAIN (z.B. dummy.de)
Hostname des Servers: HOSTNAME (z.B. myserver)
smtp Hostname, um eMails abzuliefern: SMTP_PROVIDER_HOST (z.B. mail.your-server.de)
Userid, um emails zu senden: SMTP_INPUT_USERNAME
Password, um emails zu senden: SMTP_INPUT_PASSWORD

Änderungen bzw. Einfügungen:

Installation von mail: sudo apt install mailutils -y

/etc/nullmailer/remotes:

SMTP_PROVIDER_HOST smtp --auth-login --user=SMTP_INPUT_USER --pass=SMTP_INPUT_PASSWORD --ssl

Falls der Hostname kein gültiger Hostname beim eMailProvider ist, sind noch folgende Schritte nötig:

Nullmailer Rewrite Wrapper installieren und konfigurieren. Dabei NULLMAILER_USER=SMTP_INPUT_USER und NULL_MAILER_HOST=MYDOMAIN in "sendmail" setzen.
sudo chown 700 /usr/sbin/sendmail

Restore Einführung

raspiBackup stellt komplette Wiederherstellungen zur Verfügung, d.h. alle Partitionen werden i.d.R. wiederhergestellt. Im Gegensatz dazu können beim partitionsorientierten Modus die zu restorenden Partitionen ausgewählt und somit nur Teile restored werden.

Bei einem Restore werden auf dem Ziel-Datenträger (SD-Karte, USB-Platte, ...) neue Partitionen angelegt und dann mit dem entsprechenden Tool (dd, tar oder rsync) die Daten dorthin restored.

Der Ziel-Datenträger darf also aktuell nicht vom Betriebssystem selbst benutzt werden. Es muss eine weitere, mit einem Kartenleser angeschlossene Karte, USB-Platte, SSD oder NVMe Gerät sein.

Ein Restore benötigt ein Linuxsystem. Dazu sollte man i.d.R. eine Raspberry nehmen. Andere Linuxsysteme funktionieren auch, es ist aber nicht 100% garantiert, dass es damit immer funktioniert.

Sollte ein externes Rootfilesystem gesichert worden sein, wird es auch wieder auf ein externes Gerät zurückgespielt (Nur bei normalem Backupmodus mit tar oder rsync Backup).

Ein manueller Restore der Daten mit den zuvor benutzten Backuptools dd, tar oder rsync ist natürlich auch möglich. Ebenso ist (manuell) auch die Wiederherstellung einzelner Dateien möglich, insbesondere beim rsync Backup sehr einfach.

Das Backupscript kann auch genutzt werden, um Systeme zu kopieren: Es wird ein Backup erstellt und dann auf einem anderen Gerät restored. Typische Anwendung ist, eine SD-Karte auf eine SSD oder NVMe zu kopieren und danach das System mit der SSD/NVMe und nicht mehr mit einer SD-Karte zu betreiben.

Eine vollständige Liste aller Restore Aufrufoptionen findet sich hier.

Weitere Themen auf dieser Seite:

Wiederherstellungsszenario mit einer Raspberry mit RaspbianOS

Jedes Backup kann mit der/einer Raspberry Pi wiederhergestellt werden.

Ein Raspberry Pi OS auf der Raspberry starten
raspiBackup installieren
Das Systemgerät auf welchem das Backup wiederhergestellt werden soll (z.B. eine SD-Karte imit einem SD-Kartelleser oder SSD), anschließen.
Das Medium, welches das Backup enthält (z.B. eine Platte), anschließen und mounten bzw. ein Netzwerklaufwerk mit den Backupdaten mounten.
Falls die Rootpartition ausgelagert wurde, ein weiteres Gerät mit einer vorformatierten Partition anschließen, die die ausgelagerte Rootpartition enthalten soll, welche wiederhergestellt werden wird
raspiBackup zum Restore starten, Aufruf siehe unten.

Dabei wird üblicherweise genutzt:

das Systemgerät /dev/sda
die Backuppartition /dev/sdbx
und eine eventuelle Rootpartition /dev/sdcx

Wird ein Netzlaufwerk benutzt, ist die Rootpartition üblicherweise /dev/sdbx.

Die aktuelle Gerätebelegung kann abweichen und sollte immer überprüft werden, um zu vermeiden, dass andere Partitionen irrtümlicherweise überschrieben werden.

Z.B. mit

sudo parted -l

Wiederherstellungsszenario für Windowsbenutzer auf einem Windowssystem

Nur ein dd Backup lässt sich (auch) direkt unter Windows, mit dem Win32DiskImager, restoren.

Wiederherstellungsszenario für Linuxnutzer

Hinweis

Im Prinzip kann zwar jedes Linux OS genutzt werden, um ein Backup zu restoren. Aber bei möglichen Inkompatibiliäten dessen Tools, im Vergleich zu den beim Backup verwendeten Linux-Tools, kann es Probleme geben. Ein gelegentlich auftauchender Kandidat dafür ist sfdisk, das sich sowohl zu Jessie als auch zu Bullseye inkompatibel geändert hatte.

Deshalb:

Ein Restore sollte immer mit demselben OS vorgenommen werden, mit dem auch das Backup erstellt wurde.

Es wird das Gerät, auf welches das Backup restored werden soll, an das Linuxsystem angeschlossen, die Backuppartition gemounted und eine Partition für ein eventuelles externes Rootfilesystem bereitgestellt.

Dann raspiBackup zum Restore starten, Aufruf siehe unten.

Wenn kein RaspbianOS und/oder keine Raspberry Pi genutzt werden, muss noch die Option --unsupportedEnvironment angegeben werden.

Siehe auch Unterstützte Hard- und Software.

Beispielaufrufe

Notwendige Hardware für den Restore:

Eine laufende Raspberry Pi mit einem laufenden Raspberry Pi OS oder einem anderen Linux Betriebssystem oder ein anderer Linux Rechner mit installiertem raspiBackup.
Ein angeschlossenes Zielgerät des Backups
Ein angeschlossenes Backupdevice (per USB oder Netz)
Falls eine externe Rootpartition wiederherzustellen ist oder der USB Boot Mode benutzt wird, wo keine SD-Karte mehr benutzt wird, muss noch per USB eine weitere Platte angeschlossen sein

Gemeinsamkeiten der Beispielaufrufe:

Das gesicherte System heißt im Beispielaufruf "raspberrypi".
Der Ziel-Datenträger, der den Restore der Boot-/bzw. Boot- und Root-Partition erhalten soll, ist im Beispiel als /dev/sdf verfügbar.
Weiter unten ist beschrieben, wie man den aktuellen Wert für -d herausfinden kann
Achtung: Alle bestehenden Daten der Ziel-Datenträger werden nach einer Sicherheitsabfrage von raspiBackup vor dem Restore gelöscht.
Das zu restorende Backup ist verfügbar unter /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/

Restore auf eine SD-Karte

sudo raspiBackup.sh -d /dev/sdf /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/

Restore auf ein USB Gerät ohne SD-Karte (USB boot mode)

sudo raspiBackup.sh -d /dev/sdf /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/

Restore auf eine SD-Karte und eine externe Partition

Um den Restore der externe Rootpartition aufzunehmen, wurde auf /dev/sda eine entsprechend große Partition /dev/sda1 angelegt. Eine Formatierung ist nicht notwendig.

sudo raspiBackup.sh -d /dev/sdf -R /dev/sda1 /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/

Wie kann man die Gerätenamen der externen SD-Karte und externen Platte herausfinden?

Auf der Raspberry ist folgender Befehl einzugeben:

fdisk -l | egrep "^Disk /|^/dev"

Die Ausgabe sieht dann z.B. wie folgt aus:

pi@raspberrypi:~# sudo fdisk -l | egrep "^Disk /|^/dev"
Disk /dev/mmcblk0: 8011 MB, 8011120640 bytes
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    15646719     7761920   83  Linux
Disk /dev/sda: 15.5 GB, 15548284928 bytes
Disk /dev/sdb: 300.1 GB, 300069052416 bytes
/dev/sdb1               1   586072367   293036183+  ee  GPT

Hier sieht man, dass

die interne SD-Karte /dev/mmcblk0 8GB groß ist
die neue externe SD-Karte /dev/sda 16GB groß ist
die externe Platte /dev/sdb, auf die die Rootpartition gebracht werden soll, 300GB groß ist und eine Partition /dev/sdb1 hat.

Somit ist der Parameter für -d /dev/sda (Externe SD-Karte).

Falls eine externe Rootpartition mitgesichert wurde, ist noch -R /dev/sdb1 (Externe Rootpartition) notwendig.

Die Parameter müssen natürlich den lokalen Gegebenheiten angepasst werden.

Hinweis:

Ein Backup sollte regelmäßig getestet werden: Ob der Restore immer noch funktioniert und auch immer noch alle Daten beinhaltet.

Nichts ist so frustrierend, wenn man in dem Moment, wo man das Backup benötigt, feststellt, dass das Backup korrupt ist oder nicht alle Daten enthält...

Ein Test ist bei der Raspberry recht einfach:

Eine neue SD-Karte einlegen, das Backup restoren und von der neuen SD-Karte booten. Wird keine SD-Karte genutzt, also z.B. eine SSD, kann der Restoretest auch mit einer Platte vorgenommen werden, sofern sie groß genug ist, alle Daten der SSD aufzunehmen.

Falls aus irgendwelchen Gründen der Restore mit dem Script fehlschlägt, kann man natürlich jederzeit die vom Script gesicherten Daten mit den Standard Linuxtools, die zum Backup genutzt wurden - dd, tar oder rsync - manuell restoren. Allerdings geht das dann nicht ganz so bequem wie mit dem Script und es sind entsprechende Linux Kenntnisse erforderlich ;-) Siehe dazu auch Manueller Restore eines Backups.

Restore einzelner Dateien/Verzeichnisse aus einem Backup

Manchmal ist nicht ein kompletter Restore des ganzen Systems, sondern nur einzelner Datei(en) oder Verzeichnisse gewünscht. Dies wird nicht direkt von raspiBackup unterstützt. Da raspiBackup zum Restore des Gesamtsystem nur Standard-Linux-Tools verwendet, ist das aber für alle Backuptypen manuell möglich.

Allerdings müssen diese Aktivitäten auf einem Linux-System durchgeführt werden.

Am einfachsten geht das bei rsync-Backups. dd und tar Backups erfordern einige zusätzliche Schritte auf der Kommandozeile.

dd backup

Zuerst muss die dd Image-Datei verfügbar gemacht werden.

Im folgenden Beispiel ist die USB-Platten-Partition /dev/sda1 und wird nach /mnt gemounted mit:

sudo mount -o ro /dev/sda1 /mnt

Dort nach der gewünschten Backup-Generation und der Image-Datei suchen.

Als nächstes ist der Sektor-Offset in der Image-Datei mit fdisk zu ermitteln.

sudo fdisk -l raspberrypi-dd-backup-20160415-222900.img

Disk raspberrypi-dd-backup-20160415-222900.img: 7.5 GiB, 8011120640 bytes, 15646720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000798a3

Device                                     Boot Start  End      Sectors  Size Id Type
raspberrypi-dd-backup-20160415-222900.img1      8192   122879   114688   56M   c W95 FAT32 (LBA)
raspberrypi-dd-backup-20160415-222900.img2      122880 15646719 15523840 7.4G 83 Linux

Es sind also 8192 für die erste und 122880 für die zweite Partition.

Nun wird die Partition nach /media gemounted, in dem Beispiel die zweite, die root-Partition. Hinweis: Der Offset ist mit der Sektorgröße, hier 512, zu multiplizieren.

sudo mount -o ro,norecovery,loop,offset=$((122880*512)) raspberrypi-dd-backup-20160415-222900.img /media

Nun ist im Verzeichnis /media der Zugriff auf alle Daten des Backups möglich.

ls /media/

backup boot dev home lost+found mnt proc root sbin srv tmp var
bin boot.bak etc lib media opt remote run selinux sys usr

Zum Beenden die Partition wieder unmounten:

sudo umount /media
sudo umount /mnt

tar backup

Zuerst muss die tar-Datei verfügbar gemacht werden.

Im folgenden Beispiel ist die USB-Platten-Partition /dev/sda1 und wird nach /mnt gemounted mit:

sudo mount -o ro /dev/sda1 /mnt

Angenommen, auf das gesamte Verzeichnis /etc in der tar-Datei soll zugegriffen werden. Das geht mit folgendem Kommando.

tar -xf raspberrypi-tar-backup-20171028-205746.tar -C /tmp etc

Aber dabei muss man etwas geduldig sein, denn je nach Größe der tar-Datei kann das etwas dauern.

Schließlich wurde das /etc-Verzeichnis aus der tar-Datei nach /tmp extrahiert. Dort ist nun der Zugriff möglich.

rsync backup

Zu Beginn muss Zugriff auf das rsync-Backup-Verzeichnis bestehen.

Im folgenden Beispiel ist die USB-Platten-Partition /dev/sda1 und wird nach /mnt gemounted mit:

sudo mount -o ro /dev/sda1 /mnt

Nun ist direkt Zugriff auf die Inhalte möglich:

cd /mnt/backups/raspberrypi/raspberrypi-rsync-backup-20160705-212724-8G

ls -la

total 57592
drwxr-xr-x 26  pi   pi       4096 Jul 5 2016 .
drwxr-xr-x 14  root root     4096 Apr 18 2018 ..
drwxr-xr-x 2   root root     4096 Nov 15 2015 backup
drwxr-xr-x 2   root root     4096 May 29 2016 bin
drwxr-xr-x 2   root root     4096 Jan 1 1970 boot
drwxr-xr-x 3   root root     4096 Apr 20 2014 boot.bak
drwxr-xr-x 2   root root     4096 Jul 4 2016 dev
drwxr-xr-x 125 root root    12288 Jul 5 2016 etc
drwxr-xr-x 3   root root     4096 Feb 1 2015 home
drwxr-xr-x 16  root root     4096 May 29 2016 lib
drwx------ 2   root root     4096 Dec 15 2012 lost+found
drwxr-xr-x 2   root root     4096 Jul 3 2016 media
drwxr-xr-x 2   root root     4096 Jan 8 2014 mnt
drwxr-xr-x 3   root root     4096 Mar 1 2015 opt
-rwxr-xr-x 1   pi   pi     126799 Jul 5 2016 pi
dr-xr-xr-x 2   root root     4096 Jan 1 1970 proc
drwx------ 2   root root     4096 Jul 10 2013 .pulse
-rw------- 2   root root      256 Dec 16 2012 .pulse-cookie
-rw-r--r-- 1   root root 58720256 Jul 5 2016 raspberrypi-backup.img
-rw-r--r-- 1   root root      512 Jul 5 2016 raspberrypi-backup.mbr
-rw-r--r-- 1   root root      273 Jul 5 2016 raspberrypi-backup.sfdisk
drwxr-xr-x 4   root root     4096 Aug 15 2013 remote
drwx------ 13  root root     4096 Jul 3 2016 root
drwxr-xr-x 2   root root     4096 Jul 5 2016 run
drwxr-xr-x 2   root root     4096 May 29 2016 sbin
drwxr-xr-x 2   root root     4096 Jun 20 2012 selinux
drwxr-xr-x 3   root root     4096 Mar 7 2014 srv
dr-xr-xr-x 2   root root     4096 Jul 4 2016 sys
drwxrwxrwx 2   root root     4096 Jul 5 2016 tmp
drwxr-xr-x 10  root root     4096 Dec 15 2012 usr
drwxr-xr-x 12  root root     4096 Jul 8 2014 var

Manueller Restore eines rsync Backups

Ein von raspiBackup erstelltes Backup enthält alle für einen Restore notwendigen Informationen und kann manuell restored werden.

Ein raspiBackup Nutzer wollte aus verschiedenen Gründen einen rsync Backup manuell restoren und hat das freundlicherweise detailliert beschrieben.

# Manuelles Anlegen der Partitionen:
sfdisk /dev/sdb < /backup/pi/pi-rsync-backup-20170812-134552/pi-backup.sfdisk

# MBR restoren:
dd of=/dev/sdb if=/backup/pi/pi-rsync-backup-20170812-134552/pi-backup.mbr count=1
sync

# Inform the operating system about partition table changes:
partprobe /dev/sdb

# Root-Partition formatieren & mounten:
mkfs -t vfat /dev/sdb1
mkfs -t vfat /dev/sdb6
mkfs.ext4 /dev/sdb5
mkfs.ext4 /dev/sdb7

mkdir -p /mnt/sdb1
mkdir -p /mnt/sdb5
mkdir -p /mnt/sdb6
mkdir -p /mnt/sdb7

mount /dev/sdb1 /mnt/sdb1
mount /dev/sdb5 /mnt/sdb5
mount /dev/sdb6 /mnt/sdb6
mount /dev/sdb7 /mnt/sdb7

# udevadm settle waits for udevd to process the device creation events for all hardware devices, thus ensuring that any device nodes have been created successfully before proceeding:
udevadm settle

# rsync-Restoren:
rsync --numeric-ids -aAHXv --exclude=/pi-backup.* /backup/pi/pi-rsync-backup-20170812-134552/mmcblk0p1/ /mnt/sdb1
rsync --numeric-ids -aAHXv --exclude=/pi-backup.* /backup/pi/pi-rsync-backup-20170812-134552/mmcblk0p5/ /mnt/sdb5
rsync --numeric-ids -aAHXv --exclude=/pi-backup.* /backup/pi/pi-rsync-backup-20170812-134552/mmcblk0p6/ /mnt/sdb6
rsync --numeric-ids -aAHXv --exclude=/pi-backup.* /backup/pi/pi-rsync-backup-20170812-134552/mmcblk0p7/ /mnt/sdb7

# Fake-HW-Clock patchen:
# logItem "Updating hw clock"
echo $(date -u +"%Y-%m-%d %T") > /mnt/sdb7/etc/fake-hwclock.data

# logItem "Syncing filesystems"
sync

# umount all recovery-folders:
umount /mnt/sdb*

# SD-Karte auswerfen:
eject /dev/sdb

# Mount-Verzeichnisse aufräumen:
rmdir /mnt/sdb*

# SD-Karte in Pi stecken und testen!!!
# Boing! geht :-)

Manual tgz restore

The backup directory created by raspiBackup contains all information required to restore this backup also manually with standard Linux tools. The following page describes how to restore a normal tgz backup.

Create the partitions on the SD card

First of all the SD card has to be plugged in in into a Raspberry which is used to restore the backup. It usually is detected as /dev/sda or /dev/sdb. Use lsblk to check what's the device used by the SD card. In the following description I use /dev/sdb now.

Next mount the backuppartition on a mountpoint. /mnt iis used in the following description for the backup partition and hostname raspberry and /media for the target SD card partitions.

Now create the partitions with

sudo sfdisk /dev/sdb < /mnt/raspberry/raspberry-tgz-backup-20170812-134552/raspberry-backup.sfdisk

This will create two partitions.

You can check whether everything is OK with

sudo fdisk -l /dev/sdb

Disk /dev/sdb: 7.43 GiB, 7969177600 bytes, 15564800 sectors
Disk model: MassStorageClass
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa02ea338Device Boot Start End Sectors Size Id Type
/dev/sdb1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sdb2 532480 15564799 15032320 7.2G 83 Linux

Restore first partition (boot partition)

sudo dd of=/dev/sdb1 if=/mnt/raspberry/raspberry-tgz-backup-20170812-134552/raspberry-backup.img
sync

You can check whether everything is OK with following commands:i

sudo mount /dev/sdb1 /media; ls /media; sudo umount /media

You should get a list of all boot files.

bcm2708-rpi-b.dtb bcm2708-rpi-zero-w.dtb bcm2710-rpi-3-b-plus.dtb bcm2711-rpi-4-b.dtb config.txt fixup4x.dat issue.txt LICENCE.broadcom start4x.elf
bcm2708-rpi-b-plus.dtb bcm2709-rpi-2-b.dtb bcm2710-rpi-cm3.dtb bcm2711-rpi-cm4.dtb COPYING.linux fixup_cd.dat kernel7.img overlays start_cd.elf
bcm2708-rpi-b-rev1.dtb bcm2709-rpi-cm2.dtb bcm2710-rpi-zero-2.dtb bcm2711-rpi-cm4s.dtb fixup4cd.dat fixup.dat kernel7l.img start4cd.elf start_db.elf
bcm2708-rpi-cm.dtb bcm2710-rpi-2-b.dtb bcm2710-rpi-zero-2-w.dtb bootcode.bin fixup4.dat fixup_db.dat kernel8.img start4db.elf start.elf
bcm2708-rpi-zero.dtb bcm2710-rpi-3-b.dtb bcm2711-rpi-400.dtb cmdline.txt fixup4db.dat fixup_x.dat kernel.img start4.elf start_x.elf

Restore second partition (root partition)

Now format the second partition with

sudo mkfs.ext4 /dev/sdb2

You can check whether everything is OK with following commands:

sudo mount /dev/sdb2 /media; df -h /media

You should get something like

Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 7.0G 24K 6.6G 1% /media

Now restore the tgz Backup on the partition created just now:

sudo tar --exclude /boot --same-owner --same-permissions --numeric-owner -x -v -z -f /mnt/raspberry/raspberry-tgz-backup-20170812-13455/raspberry-tgz-backup-20170812-134552.tgz -C /media
sudo umount /media
sudo umount /mnt

During the restore you should see the list of all files restored.

Boot the restored system

Now remove the target SD card, insert it in another Raspberry and boot the Raspberry with the restored backup.

Fragen und Antworten

Die folgenden Seiten beantworten Fragen zu raspiBackup und erklären einige Details.

Dazu gehört, welches Filesystem man auf den Backuppartitionen nutzen sollte und wie Hardlinks mit rsync funktionieren.

Welches Filesystem kann auf der Backuppartition benutzt werden?

Je nachdem, welche Backupmethode man bei raspiBackup benutzt, muss das richtige Filesystem auf dem Backupgerät vorhanden sein. In der folgenden Tabelle sind die verschiedenen Filesysteme pro Backupmethode gekennzeichnet sowie ihre Restriktionen.

Lokal angeschlossene Backuppartitionen

Filesystem	dd	tar	rsync
fat16	4GB Limit	4G Limit	nein
fat32	ja	ja	nein
exFat	ja	ja	nein
ntfs	ja	ja	nein
ext2/3/4	empfohlen	empfohlen	empfohlen

Remote angeschlossene Backuppartitionen

Filesystem	dd	tar	rsync
SMB	ja	ja	eingeschränkt Geht über den Umweg mit der Nutzung eines Loopdevices. Siehe dazu auch FAQ24.
NFS	ja	ja	empfohlen Die Sicherung von ACLs geht auch, aber nur über den Umweg der Nutzung eines Loopdevices. Oder man schaltet die Sicherung von ACLs aus. Siehe dazu auch FAQ24.

Wie funktionieren Hardlinks zusammen mit rsync

Immer wieder wird gefragt, wie der rsync Backup funktioniert und wie Hardlinks dazu eingesetzt werden. Der folgende Artikel beschreibt, wann Dateien im Dateisystem erstellt und gelöscht und wann Hardlinks erstellt und entfernt werden.

Hardlinks sind eine Filesystemfähigkeit, die von den Linux Filesystemen ext3 und ext4 unterstützt werden. Es sind Zeiger, die einen Dateinamen mit seinem Inhalt auf dem Filesystem verbinden. D.h. mit Hardlinks kann auf Dateien mit unterschiedlichen Namen aus unterschiedlichen Positionen im Dateibaum verwiesen werden. Der Linux Befehl ln kann z.B. dazu benutzt werden.

Bei einem ersten rsync Backup werden alle Dateien kopiert und im Backupverzeichnis gesichert. Bei dem zweiten und jedem folgenden Backup werden nur die Dateien erneut kopiert, die neu sind oder sich geändert haben, sowie gelöschte Dateien gelöscht.

Dadurch sind i.d.R. alle rsync Backups bis auf den ersten relativ schnell, sofern sich die geänderte Datenmenge in Grenzen hält.

Für alle Dateien, die sich nicht geändert haben, werden im Backupverzeichnis Hardlinks auf die Dateien erstellt, die in vorherigen Backups gesichert wurden.

Werden Dateien gelöscht, wird der Hardlink auf die vorher gesicherte Datei, die im vorherigen Backup existiert, im neuen Backup nicht mehr angelegt und somit die Datei im neuen Backup entfernt.

Dadurch hat man jederzeit immer vollen Zugriff auf einen Backupstand und unveränderte Dateien werden nicht immer wieder gesichert und belegen Plattenplatz. Dadurch spart man Backupzeit und -platz.

Eine Datei wird erst dann gelöscht, wenn sie keine Hardlinks mehr auf sich hat. Das bedeutet, solange es noch mindestens ein Backup gibt, welche auf die Datei per Hardlink verweist, wird die Datei nicht gelöscht und steht für ein Restore zur Verfügung.

Das folgende Bild zeigt einmal graphisch, wann Hardlinks und Dateien erstellt bzw. gelöscht werden. Es gibt auch ein zugehöriges Youtube Video, inklusive einer Demo am System.

In der nachfolgenden Graphik wird gezeigt, wann F2 in BD6 im Filesystem gelöscht wird. Das stimmt aber nur, wenn vorher alle Backups, die F2 beinhalteten, gelöscht wurden - also BD1 - BD5.

raspiBackup rsync

Viele Dateimanager zeigen den genutzten Speicherplatz ohne Berücksichtigung der Platzeinsparung durch Hardlinks an und somit als viel zu hoch. Das gilt besonders für Windows Dateimanager.

In der raspiBackup FAQ17 ist beschrieben, wie der wirklich belegte Speicherplatz bei der Nutzung von Hardlinks ermittelt werden kann.

Weblinks

du counting harldinks towards filesize - Ein Artikel, der erklärt, warum der Befehl du über mehrere Verzeichnisses ausgeführt werden muss, um die Einsparungen durch Hardlinks zu sehen

Warum sollte man dd als Backuptyp besser nicht benutzen?

Viele Benutzer von raspiBackup nutzen dd als Backuptyp. Insbesondere Nutzer, die mehr mit Windows als mit Linux arbeiten, da sie einen dd Backup unter Windows mit win32imager oder ähnlichen Tools restoren können.

dd kann natürlich als Backuptool benutzt werden, aber es gibt ein gewisses Risiko dabei, welches es bei den Backupmethoden tar und rsync nicht gibt. Deshalb wird jedem Nutzer von raspiBackup empfohlen, besser tar oder rsync zu nutzen.

Warum?

dd sichert eine ganze Partition 1 zu 1 auf Bitebene. Dabei werden Fehler gemeldet, wenn die Bits nicht gelesen werden können. Es kommt aber auch immer mal wieder vor, dass es Filesystemfehler gibt. Diese entstehen i.d.R. durch plötzlichen Stromausfall. Diese Fehler bemerkt dd nicht. D.h. dd sichert eine Parition inklusive der Filesystemfehler, die dann beim Restore auch wiederhergestellt werden. Somit hat man eine exakte Kopie des Systems mit Filesystemfehlern. Man legt immer weiter Backups an, im Glauben das alles OK ist und löscht dann irgendwann auch alte Backups. Somit werden nach und nach unbemerkt Backups ohne Filesystemfehler durch Backups mit Filesystemfehlern ersetzt. Wenn dann ein Restore benötigt wird, hat man kein Backup mehr ohne Filesystemfehler und kann nur hoffen, dass die Filesystemfehler keine wichtigen Daten des Systems beschädigt haben. Ansonsten ist das Backup unbrauchbar.
Beim Restore eines dd Backups wird das Backup 1 zu 1 auf Bitebene zurückgespielt. Wenn die SD-Karte nicht OK ist, wird oftmals kein Fehler von dd gemeldet. Bootet man dann das System, startet es nicht oder es gibt Fehlermeldungen von Systemservices. Dann melden sich die Benutzer und erstellen einen Problembericht, weil raspiBackup nicht korrekt funktioniert. Nachdem sie dann gebeten werden, doch mal einen Restore auf eine neue SD-Karte vorzunehmen, ist das Problem verschwunden. Diese Problemberichte sind unnötiger Aufwand, der vermieden werden sollte.

Was nun?

Eine Umstellung auf tar ist schnell gemacht. Es kann dasselbe Filesystem auf der Backuppartition genutzt werden wie für dd.

Der Restore kann allerdings nicht mehr mit Windowsprogrammen wie Win32DiskImager oder Etcher vorgenommen werden.

Stattdessen kann man aber raspiBackup auf einer Raspberry starten. Hat man nur eine Raspberry zur Verfügung, sollte man sich einmalig eine "Not-SD-Karte" mit Raspbian und raspiBackup erstellen und beiseite legen, bis man sie braucht...

Für rsync benötigt man ein ext2/3/4 Filesystem auf der Backuppartition. Dieses kann unter Linux erstellt werden. Den Restore wird auch wieder mit raspiBackup auf einer Raspberry vorgenommen.

Weitere Nachteile von dd Backups

Bei einem dd Backup wird immer die gesamte Partition gesichert - selbst wenn nur ein Bruchteil der Partition (z.B. 33%) genutzt wird. Dass heisst bei einer 64GB Partition werden immer 42GB umsonst gesichert, der Sicherungsprozess dauert unnötigerweise 66% länger und die Sicherung belegt 66% mehr Speicherplatz. Es gibt die Option DD_BACKUP_SAVE_USED_PARTITIONS_ONLY mit der man nur die existierende Rootpartition sichert und nicht das gesamte Gerät.

Welchen Backuptyp ist der Beste?

Die effizienteste Backuptyp ist rsync. Durch die Benutzung von Hardlinks werden nur Dateien kopiert, die sich geändert haben und somit ist jeder ausser dem ersten Backupvorgang relativ schnell beendet. Ausserdem liegen die Backupdateien entpackt vor und auf sie kann direkt zugegriffen werden, wenn nur ein paar Dateien aus dem Backup benötigt werden. Bei tar und dd muss man die Backups erst umständlich entpacken.

Weiterführende Informationen

Wie kann man mit raspiBackup einen Clone erstellen?

raspiBackup erstellt regelmäßig beliebige Backupversionen, die man im Bedarfsfall zurückspielen kann. Häufig möchte man aber einfach den letzten Backup auf einem Medium fertig greifbar haben, um ihn im Fehlerfalle sofort einsetzen zu können, also einen Clone.

raspiBackup bietet keine direkte Möglichkeit, einen Clone zu erzeugen.

Mit Hilfe eines kleinen Hilfstools ist dieses aber möglich: Mit diesem wird ein Backup erstellt und anschließend dieser Backup auf ein Medium zurückgespielt. Wird der Backuptyp rsync genutzt, ist der Restore nur eine Synchronisation der Änderungen von dem letzten Backup zum aktuellen Backup und ist i.d.R. schnell erledigt.

Das Hilfstool heißt raspiBackupAndClone.sh und steht auf GitHub zur Verfügung.

Folgende Schritte sind notwendig, um es einzusetzen:

Hinweis: ist im Folgenden das Device, welches den Clone erhalten soll, also z.B. /dev/mmcblk0 oder /dev/sda.

raspiBackupAndClone.sh installieren

Download von raspiBackupAndClone.sh

curl -s -O https://raw.githubusercontent.com/framps/raspiBackup/refs/heads/master/helper/raspiBackupAndClone.sh

Verschieben des Scripts nach /usr/local/bin

sudo mv raspiBackupAndClone.sh /usr/local/bin

raspiBackupAndClone.sh ausführbar machen

sudo chmod +x /usr/local/bin/raspiBackupAndClone.sh

Einmaliges Initialisierung des Clonedevices
1. Erstellen eines partitionsorientierten Backups durch den Aufruf von
```
sudo raspiBackup -P -t rsync <BackupVerzeichnis>
```
2. Zurückspielen des gerade erstellten Backup auf das Clonedevice mit
```
sudo raspiBackup -d <clonedevice> <Backupverzeichnis>
```
Regelmäßigen Aufruf von raspiBackupAndClone.sh statt raspiBackup.sh einstellen
1. In der Datei /etc/systemd/system/raspiBackup.service
```
ExecStart=/usr/local/bin/raspiBackup.sh
```
  ändern in
```
ExecStart=/usr/local/bin/raspiBackupAndClone.sh <clonedevice>
```

Falls manuell ein Backup erstellt werden soll, muss raspiBackupAndClone.sh statt raspiBackup.sh aufgerufen werden.

Hinweis: Falls kein rsync Backup möglich ist, muss in raspiBackupAndClone.sh die Zeile USE_RSYNC=1 in USE_RSYNC=0 geändert werden. Dann dauert der Restore allerdings wesentlich länger, da keine Synchronisation sondern ein Vollrestore vorgenommen wird.

Umziehen des Raspberry Betriebssystems von SD-Karte auf SSD, USB Platte oder USB Stick

raspiBackup ist dafür gedacht, ein Backup wieder auf die originale Gerätekonfiguration zurückzuspielen. Es gibt 3 mögliche Szenarien:

/boot und / auf SD-Karte
/boot auf SD-Karte und / extern auf einer SSD, USB Platte oder USB Stick (Ältere Rasperry, welche keinen USB Boot Mode kann)
/boot und / auf einer SSD, USB Platte oder USB Stick (USB Boot Mode auf neueren Raspberries)

raspiBackup kann aber auch dafür benutzt werden, sehr einfach von (1) nach (2) oder (3) zu migrieren.

Dazu wird ein Backup mit raspiBackup erstellt und anschließend auf die neue Gerätekonfiguration zurückgespielt.

Für (2) als Migrationsziel ist folgender Befehl zum Restore notwendig:

sudo raspiBackup.sh -d <SD-Karte> -R <USB Gerät> <Backup>

Für (3) ist folgender Befehl zum Restore notwendig:

sudo raspiBackup.sh -d <USB Gerät> <Backup>

Dabei kann <USB Gerät> eine SSD, eine USB Platte oder ein USB Stick sein

Wenn auf ein grosses USB Gerät umgezogen werden soll, ist die Option --resizeRootFS- sinnvoll, die die Rootpartition nicht expandiert, denn dann kann der Rest des USB Gerätes für weitere Partitionen genutzt werden.

Details zum Restore können bei "Wiederherstellen/Restore" nachgelesen werden.

Wie kann ich eine Betaversion von raspiBackup installieren und ausprobieren?

Von Zeit zu Zeit gibt es eine neue Version von raspiBackup, die neue Funktionen, Erweiterungen und auch Fehlerkorrekturen enthält.

Jede neue Version durchläuft einen automatisierten Regressiontest, der die eigentliche Backup- und Restorefunktionialität testet. Dann werden die neuen Funktionen, Erweiterungen und Bug Fixes, die während der Entwicklung schon getestet wurden, noch einmal manuell verifiziert.

Danach wird die neue Version als Beta allgemein zur Verfügung gestellt. Dieses ist erkennbar daran, dass dem eMail Subject das Smiley :-D vorangestellt wird. Nun hat jeder Benutzer von raspiBackup die Möglichkeit, die zukünftige neue Version vorneweg mit den neuen Funktionen, Erweiterungen und Fehlerkorrekturen zu testen, und im Fehlerfalle ein Problemrecord zu erstellen, so dass das Problem gefixed werden kann.

Da es nicht möglich ist, alle möglichen Systemumgebungsbedingungen zu testen, hilft das Testen der Betaversion auch, für die Community sicherzustellen, dass sich möglichst keine Fehler in der neuen Version eingeschlichen haben.

Nun folgend wird beschrieben, wie man eine Beta installieren kann, sie wieder deinstallieren und Problemberichte erstellen kann.

Die Installation der Beta ist relativ einfach. Man benutzt

sudo raspiBackup -U

Dabei wird die aktuelle raspiBackup Version gesichert, so dass jederzeit wieder auf die vorhergehende Version zurückgewechselt werden kann. Dies geschieht mit

sudo raspiBackup.sh -V

wobei aus einer Liste der vorherigen Versionen diejenige auswählbar ist, die dann wieder aktiviert wird.

Sollte wider Erwarten ein Problem entdeckt werden, sollte auf GitHub ein Problemrecord bzw. Issue erstellt werden. Sehr wichtig dabei ist es, die Ausgabe von sudo *raspiBackup*.sh --version anzugeben, damit genau klar ist, welcher Codestand benutzt wird.

Da auch von internationalen raspiBackup Nutzern die Records gelesen werden, wäre es gut, sie in Englisch zu erstellen. Es ist aber auch kein Problem, nur Deutsch zu schreiben. Die Records werden dann bearbeitet und gefixed. Wenn eine neue Version bereitsteht, wird der Ersteller über GitHub informiert werden und sie kann mit sudo *raspiBackup*.sh -U -S erneut runtergeladen und der Fix verifiziert werden.

Wird eine externe Rootpartition unterstützt?

Ältere Raspberries, die noch keinen USB Boot Modus unterstützen, können so konfiguriert werden, dass nur die Bootpartition auf der SD-Karte abgelegt wird und das Rootfilesystem auf einer externen USB Platte.

raspiBackup unterstützt externe Rootpartitionen und eine ausgelagerte Rootpartition wird mitgesichert.

Im normalen Backupmodus werden normalerwesie die beiden RaspbianOS-Partitionen /boot und /root vom Systemgerät gesichert. Wenn die Rootpartition aber auf eine externe Partition (USB Stick, USB Platte, ...) ausgelagert wurde, wird diese externe Partition gesichert sowie die Bootpartition von der SD-Karte. Wird dieser Backup zurückgespielt, muss die Option -R genutzt werden, um das Zielgerät für die externe Rootpartition anzugeben.

Aufruf und Optionen

raspiBackup muss als Benutzer root oder per sudo aufgerufen werden.

raspiBackup Option1 Option2 Option3 ... Backupverzeichnis

Alle Optionen, die etwas ein- oder ausschalten, können durch ein angehängtes + oder - beim Aufruf von raspiBackup gezielt ein- oder ausgeschaltet werden.

Beispiel: Die Option -z sowie die Option -z+ schaltet die Backupcompression ein. Mit der Option -z- wird dagegen die Backupcompression ausgeschaltet, und zwar unabhängig davon, was in der Konfigurationsdatei in dem Parameter DEFAULT_ZIP_BACKUP steht. Damit kann eine Option in der Befehlszeile ausgeschaltet werden, obwohl sie in der Konfigurationsdatei eingeschaltet ist.

Zu den meisten Aufrufoptionen gibt es zugehörige Optionen in der Konfigurationsdatei /usr/local/etc/raspiBackup.conf. Außerdem können weitere Konfigurationsdateien genutzt werden, um selektiv bestimmte Optionen zu setzen oder zu überschreiben.

Konfigurationsdateien

Neben /usr/local/etc/raspiBackup.conf gibt es weitere Konfigurationsdateien, die, sofern vorhanden, gelesen werden. Die höchste Priorität haben die Optionen, die bei dem Aufruf mitgegeben werden.

Die Priorität der Optionsquellen ist aus folgender Tabelle ersichtlich:

Priorität	Quelle
1	Aufrufoptionen
2	-f <configFile>
3	$(pwd)/.raspiBackup.conf
4	~/.raspiBackup.conf
5	/usr/local/etc/raspiBackup.conf

Hinweis: Optionen in der Konfigurationsdatei, die ja/an oder nein/aus als Parameter benötigen, müssen 0 für nein und 1 für ja sein. Kein Eintrag in der Standardspalte bedeutet, der Standard ist ""

Hinweis: Bei einem Versionsupgrade wird nur die Standardkonfigurationsdatei /usr/local/etc/raspiBackup.conf mit neuen Konfigurationsoptionen aktualisiert. Alle anderen Konfigurationsdateien müssen gegebenenfalls manuell aktualisiert werden.

Es existieren für den Backup- und Restore-Aufruf verschiedene Optionen:

Aufrufoptionen sowie deren Konfigurationsoption (Backup / Restore). Die Konfigurationsoptionen können durch die entsprechenden Aufrufoptionen temporär überschrieben werden
Reine Konfigurationsoptionen, die nicht per Aufrufoption überschrieben werden können (Backup / Restore)
Allgemeine Aufruf- und Konfigurationsoptionen sowohl für den Backup als auch den Restore (Aufrufoptionen)

Hilfetext auf der Konsole

Sofern man sich auf der Konsole bewegt, kann eine Liste der verfügbaren Aufrufoptionen sowie deren aktuellen Status mit den Optionen -h oder --help ausgegeben werden.

Thematische Liste von Aufruf-Optionen

Eine Liste der Aufruf-Optionen ist auch thematisch sortiert vorhanden.

Backup Optionen und Konfigurationen

Die Aufrufoptionen und die dazugehörigen Konfigurationsoptionen für raspiBackup sind in Optionen erklärt.

Optionen, die nur in der Konfigurationsdatei für den Backup angegeben werden können, sind in Konfiguration beschrieben.

Siehe auch Allgemeine Aufrufoptionen und Allgemeine Konfigurationsoptionen.

Backup Optionen

Diese Liste enthält alle Aufrufoptionen von raspiBackup sowie die entsprechenden Konfigurationsoptionen.

-a: Befehle, die Services nach dem Backup starten

Befehle, um Services nach dem Backup wieder zu starten. Z.B. bei SMB "service smbd start" (Achtung: Anführungszeichen an Anfang und Ende). Diese Option ist zusammen mit der Option -o obligatorisch.

Mehrere Befehle müssen durch && getrennt werden. Diese Befehle sollten die exakte umgekehrte Reihenfolge haben wie die Befehle beim Parameter -o.

Beispiel:

-a "service nfs-kernel-server start && service smbd start"

Soll wirklich kein Service gestartet werden, muss ein Doppelpunkt ":" als Argument mitgegeben werden.

Siehe dazu auch FAQ1 und FAQ18

Hinweis: Die Parameter können mit dem Installer gesetzt werden. Werden sie manuell geändert kann der Installer nicht mehr zur Änderung genutzt werden.

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

Optionsname	Standard	Im Installer	Konfigurationsname
-a	keine	konfigurierbar	DEFAULT_STARTSERVICES

-b: Definition der Blocksize, die beim dd Backup genutzt wird

Blocksize, die beim dd Backup benutzt wird

Optionsname	Standard	Im Installer	Konfigurationsname
-b	1 MB	nein	DEFAULT_DD_BLOCKSIZE

-B: Bootpartition wird als tar gesichert statt per dd

Die Bootpartition wird nicht per dd sondern per tar gesichert.

Hinweis: Diese Option hat keine Funktion, wenn der partitionsorientierte Modus benutzt wird.

Optionsname	Standard	Im Installer	Konfigurationsname
-B	aus	nein	DEFAULT_TAR_BOOT_PARTITION_ENABLED

-c: Erlaube lokale Backupspeicherung

Es kann kein Backup auf der Rootpartition erstellt werden, um vor unbeabsichtigtem Vollschreiben der Rootpartition durch das Backup zu schützen. Es macht normalerweise keinen Sinn, ein Backup auf der Systempartition abzulegen.

Mit dieser Option wird der Test ausgeschaltet und es kann ein Backup auf der Rootpartition erstellt werden.

ACHTUNG: Es wird nicht geprüft, ob das Backup noch auf die Rootpartition passt.

Optionsname	Standard	Im Installer	Konfigurationsname
-c	aus	nein	DEFAULT_SKIPLOCALCHECK

-D: Weitere Optionen für den dd Backup

Weitere Aufrufoptionen für das dd Backup (z.B. "conv=notrunc,noerror,sync")

Optionsname	Standard	Im Installer	Konfigurationsname
-D	automatisch	nein	DEFAULT_DD_PARMS

--dynamicMount: Dynamisches Mounten der Backuppartition

Damit wird vor dem Backup die angegebene Partition bzw. der Mointpoint gemounted und am Ende wieder umounted. Falls sie schon gemounted war, wird sie am Ende die Partition nicht umounted. Der Mountpoint muss in /etc/fstab definiert sein und kann dann entweder der Mountpoint selbst sein (z.B. /backup) oder die Backuppartition (z.B. /dev/sdb1).

Optionsname	Standard	Im Installer	Konfigurationsname
--dynamicMount	aus	nein	DEFAULT_DYNAMIC_MOUNT

-F: Simuliert den Backuplauf und hilft, die eMail Benachrichtgung schnell zu testen

"Fake backup". Diese Option ist hilfreich beim initialen Testen von raspiBackup. Der eigentliche lange Backup wird dadurch nicht angestoßen - aber sämtliche Optionsprüfungen wie auch das Senden der Benachrichtigungs-eMail und Pushnachrichten.

Optionsname	Standard	Im Installer	Konfigurationsname
-F	keiner	nein

--ignoreAdditionalPartitions: Es werden mehr als zwei Partitionen toleriert, wobei aber nur die ersten beiden Partitionen gesichert werden.

Mit dieser Option sind Systeme mit mehr als zwei Partitionen unterstützt; im normalen Backupmodus, wenn tar oder rsync Backup genutzt wird. Allerdings werden nur die ersten beiden Partitionen, /boot und / gesichert und wiederhergestellt.

Optionsname	Standard	Im Installer	Konfigurationsname
--ignoreAdditionalPartitions	nein	nein	DEFAULT_IGNORE_ADDITIONAL_PARTITIONS

--ignoreMissingPartitions: Test, ob alle Partitionen gesichert werden

Es wird im partitionsorientierten Backupmodus geprüft, ob alle Partitionen, die im letzten Backup gesichert wurden, auch wieder gesichert werden. Mit dieser Option wird der Test ausgeschaltet.

Optionsname	Standard	Im Installer	Konfigurationsname
--ignoreMissingPartitions	nein	nein	DEFAULT_IGNORE_MISSING_PARTITIONS

-k: Anzahl der Backups die vorgehalten werden sollen

Anzahl der Backups, die pro Backuptyp vorzuhalten sind, sofern es nicht durch die keep Option der jeweiligen Backuptypen überschrieben wird. D.h., es werden standardmäßig 3 dd, 3 tar und 3 rsync Backups vorgehalten.

Hinweis: Diese Option ist wirkungslos, wenn die intelligente Rotationsstrategie benutzt wird.

Optionsname	Standard	Im Installer	Konfigurationsname
-k	3	konfigurierbar	DEFAULT_KEEPBACKUPS

--keep_{type}: Anzahl der Backups pro Typ, die vorgehalten werden sollen

Anzahl der Backups, die für den jeweiligen Backuptypen vorgehalten werden.

{type} kann jeder Backuptyp sein, also dd, ddz, tar, tgz oder rsync.

Hinweis: Diese Optionen sind wirkungslos, wenn die intelligente Rotationsstrategie benutzt wird.

Optionsname	Standard	Im Installer	Konfigurationsname
--keep_dd	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_DD
--keep_ddz	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_DDZ
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC
--keep_tar	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_TAR
--keep_tgz	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_TGZ

-M: Erstellen eines raspiBackup Snapshots

Mit der Option wird ein raspiBackup Snapshot erstellt, welcher nicht im Backup-Recycleprozess berücksichtigt und somit nicht automatisch gelöscht wird. Der Snapshot erhält am Ende des Verzeichnisnamens den angegebenen Text. Siehe auch diese Seite zu Snapshots.

Beispiel: Der Hostname ist "idefix" und der Parameter für -M ist "Initial boot from SD". Dann wird folgendes Verzeichnis angelegt:

idefix/idefix-rsync-backup-20170103-170717_idefix-Initial_boot_from_SD

Hinweis: raspiBackup Snapshots sind normale Backups und keine "richtigen" Snapshots wie die bei LVM oder btrfs. Es werden aber beim rsync Backup Hardlinks genutzt, um die Snapshotzeit zu reduzieren.

Hinweis: Da die Snapshotverzeichnisse nicht im Backup-Recycleprozess berücksichtigt werden, müssen sie manuell gelöscht werden.

Optionsname	Standard	Im Installer	Konfigurationsname
-M	keiner	nein

-N: Erweiterungen, die vor und nach dem Backup aufgerufen werden sollen

Aktivierung von eigenen Scripterweiterungen (Plugins). Siehe dazu diese Seite, die auch zwei Beispielerweiterungen anbietet, die die CPU Temperatur und die Speicherbelegung vor und nach dem Backuplauf ausgeben.

Optionsname	Standard	Im Installer	Konfigurationsname
-N	keine	nein	DEFAULT_EXTENSIONS

--notifyStart: Benachrichtigung beim Backupstart

Mit dieser Option wird eingeschalten, dass eine eMail oder eine Push-Benachrichtigung gesendet wird, wenn der Backup startet. Normalerweise wird nur am Ende des Backups eine Benachrichtigung geschickt.

Optionsname	Standard	Im Installer	Konfigurationsname
--notifyStart	nein	nein	DEFAULT_NOTIFY_START

-o: Befehle, die Services vor dem Backup stoppen

Befehle, um Services vor dem Backup zu stoppen, damit kein inkonsistentes Backup erzeugt wird. Z.B. bei SMB "service smbd stop" (Achtung: Anführungszeichen an Anfang und Ende). Diese Option ist zusammen mit der Option -a obligatorisch.

Mehrere Befehle müssen durch && getrennt werden. Diese Befehle sollten die exakte umgekehrte Reihenfolge haben wie die Befehle beim Parameter -a.

Beispiel:

-o "service smbd stop && service nfs-kernel-server stop"

Soll wirklich kein Service gestoppt werden, muss der Doppelpunkt ":" als Argument mitgegeben werden.

Siehe dazu auch FAQ1 und FAQ18

Hinweis: Die Parameter können mit dem Installer gesetzt werden. Werden sie manuell geändert kann der Installer nicht mehr zur Änderung genutzt werden.

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

Optionsname	Standard	Im Installer	Konfigurationsname
-o	keine	konfigurierbar	DEFAULT_STOPSERVICES

-p: Backupverzeichnis

Angabe des Backupverzeichnisses, in welchem das erstellte Backup gespeichert werden soll.

Optionsname	Standard	Im Installer	Konfigurationsname
--p	aus	konfigurierbar	DEFAULT_BACKUPPATH

--rebootSystem: Reboot des Systems nach dem Backup

Durch diese Option wird ein Reboot des Systems am Ende des Backuplaufes vorgenommen und somit werden alle Services wieder gestartet. Deshalb werden Argumente der Option -a auch ignoriert.

Hinweis: Wird die Option -F benutzt, wird kein reboot durchgeführt.

Optionsname	Standard	Im Installer	Konfigurationsname
--rebootSystem	aus	nein	DEFAULT_REBOOT_SYSTEM

--smartRecycle: Nutzung von SmartRecycle

Diese Option schaltet die intelligente Rotationsstrategie - Smart Recycle ein. Damit werden die --keep Optionen ignoriert und müssen nicht auf 0 gesetzt werden.

Optionsname	Standard	Im Installer	Konfigurationsname
--smartRecycle	aus	konfigurierbar	DEFAULT_SMART_RECYCLE

--smartRecycleDryrun: Testmodus von SmartRecycle

Diese Option schaltet den Testmodus der intelligenten Rotationsstrategie - Smart Recycle ein.

Optionsname	Standard	Im Installer	Konfigurationsname
--smartRecycleDryrun	ja	nein	DEFAULT_SMART_RECYCLE_DRYRUN

--smartRecycleOptions: Smartrecycle-Optionen

Diese Option definiert Parameter der intelligenten Rotationsstrategie - Smart Recycle.

Optionsname	Standard	Im Installer	Konfigurationsname
--smartRecycleOptions	"7 4 12 1"	konfigurierbar	DEFAULT_SMART_RECYCLE_OPTIONS

--systemstatus: Aktive Services beim Backupstart anzeigen

Es wird eine Liste der aktiven Services und offenen Dateien in der Debugdatei erstellt.

Optionsname	Standard	Im Installer	Konfigurationsname
--systemstatus	aus	nein

--unsupportedEnvironment: Nutzung auf nicht unterstützter HW und OS

Wird raspiBackup auf nicht unterstützten Umgebungen gestartet, muss diese Option angegeben werden.

Optionsname	Standard	Im Installer	Konfigurationsname
--unsupportedEnvironment	aus	nein

-P: Partitionsorientierter Backupmodus

Partitionsorientierter Modus. Damit wird im Gegensatz zum normalen Modus, wo nur die ersten beiden Partitionen gesichert werden, eine beliebige Anzahl von Partitionen gesichert. Mit der Option -T wird definiert, welche Partitionen zu sichern sind.

Optionsname	Standard	Im Installer	Konfigurationsname
-P	aus	konfigurierbar	DEFAULT_PARTITIONBASED_BACKUP

-T: Angabe der Partitionen, die beim partitionsorientierten Backup gesichert werden sollen

Falls der partitionsorientierte Backupmodus mit der Option -P gewählt wurde, kann mit dieser Option definiert werden, welche Partitionen gesichert werden sollen. Beispiel: -T "1 2 5" sichert die ersten beiden und die fünfte Partition. Mit * werden alle Partitionen gesichert.

Optionsname	Standard	Im Installer	Konfigurationsname
-T	"1 2"	nein	DEFAULT_PARTITIONS_TO_BACKUP

-t: Typ des Backups (dd, tar, rsync)

Typ des Backups, der entweder dd, tar oder rsync sein kann. rsync benutzt bei einer ext3/ext4 Partition Hardlinks, um den benötigten Speicherplatz zu minimieren.

Detailinformationen zu den Backuptypen Ein externes Rootfilesystem wird automatisch bei tar oder rsync Backup mitgesichert, sofern nicht die Option -P benutzt wird. Mit der Option -z werden die dd und tar Backups zusätzlich noch gezippt bzw. verkleinert.

Hinweis: Beim dd Backup kann durch den Konfigurationsparameter DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY Backupzeit und -platz gespart werden.

Siehe dazu auch FAQ16.

Optionsname	Standard	Im Installer	Konfigurationsname
-t	rsync	konfigurierbar	DEFAULT_BACKUPTYPE

-u: Weitere Verzeichnisse aus dem Backuprozess auszuschließen

Erweiterung der Excludeliste beim Backup, um bestimmte Verzeichnisse beim Backup zu ignorieren.

Achtung: Die Parameter müssen der jeweiligen Syntax des Backuptools gehorchen und führen sonst zum Abbruch des Backups. Für rsync oder tar könnte die Liste wie folgt aussehen:

"--exclude=/backup/* --exclude=/rsnapshot/* --exclude=/www-data*/* --exclude=/home/pi/.local/share/Trash"

Die Anführungszeichen sind wichtig! Weitere Informationen zu der Syntax finden sich auf der man Page der jeweiligen Backuptools.

Folgende Verzeichnisse werden niemals gesichert:

Der Backupfad, der im Aufruf angegeben wurde
/proc/*
/lost+found/*
/sys/*
/dev/*
/tmp/*
/boot/*
/run/*
/proc/*
/lost+found/*
/sys/*
/dev/*
/tmp/*
/boot/*
/run/*

Außerdem werden alle gemounteten Verzeichnisse von externen Geräten, die nicht auf / gemounted sind, nicht gesichert. Es wird nur die Boot Partition /dev/mmcblk0p1 und die Root Partition /dev/mmcblk0p2 bzw. das ausgelagerte Rootverzeichnis auf z.B. /dev/sda1 gesichert.

Hinweis für den partitionsorientierten Modus: Wenn die Option -P benutzt wird, werden in allen Partitionsbackups die o.g. Verzeichnisse ausgenommen.

rsync:

/verzeichnis/ - Excluded Verzeichnis auf allen Partitionen
mmcblk0p2/verzeichnis/* - Excluded Verzeichnis auf Partition mmcblk0p2

tar:

verzeichnis/* - Excluded Verzeichnis auf allen Partitionen

Optionsname	Standard	Im Installer	Konfigurationsname
-u	keine	nein	DEFAULT_EXCLUDE_LIST

-v: Alle Meldungen des verwendeten Backuptools werden protokolliert

Die verwendeten Backuptools tar und rsync zeigen detaillierte Informationen an (Verbose mode). Die Option ist besonders nützliche bei initialen manuellen Backuptests, um den Backupfortschritt verfolgen zu können.

Optionsname	Standard	Im Installer	Konfigurationsname
-v	aus	nein	DEFAULT_VERBOSE

-z: Kompression des Backups bei dd oder tar

Backup verkleinern mit gzip bei dd oder tar Backup

Optionsname	Standard	Im Installer	Konfigurationsname
-z	aus	konfigurierbar	DEFAULT_ZIP_BACKUP

Backup Konfigurationsoptionen

Die meisten Aufrufoptionen können auch in der Konfigurationsdatei definiert werden. Siehe dazu Backup-Optionen.

DEFAULT_BEFORE_STOPSERVICES / DEFAULT_AFTER_STARTSERVICES

Die hier definierten Befehle werden vor bzw. nach dem Backup vor bzw. nach dem Stoppen von Systemservices (Option -a und -o) ausgeführt.

Config-Option	Standard
DEFAULT_BEFORE_STOPSERVICES	keiner
DEFAULT_AFTER_STARTSERVICES	keiner

DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY

dd Backups sichern durch diese Option nur den von definierten Partitionen belegten Platz. Dadurch benötigt z.B. eine 32GB SD-Karte, die nur eine 8GB Partition definiert hat, für den Backup nur 8GB und nicht 32GB. Dazu muss aber mittels gparted oder resize2fs die root Partition entsprechend verkleinert werden, denn üblicherweise füllt die root Partition den gesamten Rest der SD-Karte aus.

Siehe dazu auch FAQ16.

Config-Option	Standard
DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY	keiner

DEFAULT_LINK_BOOTPARTITIONFILES

Sich selten ändernde Bootparition Backups werden mit Hardlinks verknüpft, um Backupspace zu sparen. Voraussetzung: Der Backupspace unterstützt Hardlinks (ext3/ext4 Filesystem).

Config-Option	Standard
DEFAULT_LINK_BOOTPARTITIONFILES	keiner

DEFAULT_MAIL_ON_ERROR_ONLY

Nur im Fehlerfalle wird eine eMailbenachrichtigung gesendet. Hinweis: Sollte raspiBackup wegen außergewöhnlicher Umstände abstürzen, kann es passieren, dass keine eMail gesendet wird.

Config-Option	Standard
DEFAULT_MAIL_ON_ERROR_ONLY	keiner

DEFAULT_REBOOT_SYSTEM

Mit dieser Option kann ein Reboot des gesicherten Systems am Ende des Backups konfiguriert werden.

Hinweis: Die Services, die vor dem Backup gestoppt wurden, werden nicht wieder gestartet. Das ist unnötig, da sie sowieso beim Neustart gestartet werden.

Config-Option	Standard
DEFAULT_REBOOT_SYSTEM	0

DEFAULT_RSYNC_BACKUP_ADDITIONAL_OPTIONS

Backupoptionen, die beim rsync Backup zusätzlich zu den Standardoptionen von raspiBackup genutzt werden.

Benutzung auf eigene Gefahr!

Config-Option	Standard
DEFAULT_RSYNC_BACKUP_ADDITIONAL_OPTIONS	keiner

DEFAULT_RSYNC_BACKUP_OPTIONS

Damit können die rsync Standard-Backupoptionen überschrieben werden.

Benutzung auf eigene Gefahr!

Config-Option	Standard
DEFAULT_RSYNC_BACKUP_OPTIONS	--delete -aHAx

DEFAULT_TAR_BACKUP_OPTIONS

Damit können die tar Standard-Backupoptionen überschrieben werden.

Benutzung auf eigene Gefahr!

Config-Option	Standard
DEFAULT_TAR_BACKUP_OPTIONS	-cpi

DEFAULT_TAR_BACKUP_ADDITIONAL_OPTIONS

Backupoptionen, die beim tar Backup zusätzlich zu den Standardoptionen genutzt werden.

Benutzung auf eigene Gefahr!

Config-Option	Standard
DEFAULT_TAR_BACKUP_ADDITIONAL_OPTIONS	keiner

Restore Optionen und Konfigurationen

Die Aufrufoptionen und die dazugehörigen Konfigurationsoptionen für raspiBackup sind in Optionen erklärt.

Optionen, die nur in der Konfigurationsdatei für den Restore angegeben werden können, sind in Konfiguration beschrieben.

Siehe auch Allgemeine Aufrufoptionen und Allgemeine Konfigurationsoptionen.

Restore Optionen

raspiBackup restored standardmäßig beim normalen Backupmodus das gesamte System. Beim partitionsorientierten Modus kann dagegen beim Restore ausgewählt werden, welche Partitionen restored werden sollen. Wird beim partitionsorientierten Modus der rsync Backuptyp genutzt, kann bei einem Restore auch ein Deltarestore gewählt werden (Option -00). Das heißt, es werden mit rsync nur die geänderten Dateien und gelöschte Dateien aus dem Backup kopiert sowie nicht im Backup vorhandene Dateien - also neu erstellte Dateien - gelöscht. Damit ist ein sehr schneller Restore möglich.

Unabhängig von raspiBackup ist auch ein manueller Restore der Daten mit den zuvor benutzten Backuptools dd, tar oder rsync möglich. Dazu sind dann entsprechende Kenntnisse der Linux Backuptools notwendig.

Ebenso ist manuell auch die Wiederherstellung einzelner Dateien/Verzeichnisse möglich.

-C: Auf Badblocks prüfen

Beim Formatieren wird mittels mkfs.ext4 -c auf Bad Blocks geprüft. Hinweis: Die Restorezeit wird dadurch erhöht.

Option	Standard	Im Installer	Konfigurationsname
-c	aus	nein	DEFAULT_CHECK_FOR_BAD_BLOCKS

-d: Restoredevice

Device, auf dem das Backup wiederhergestellt wird.

Option	Standard	Im Installer	Konfigurationsname
-d	keiner	nein	DEFAULT_RESTORE_DEVICE

Beispiel: -/dev/sda

Hinweis: Der Parameter muss ein Device sein und keine Partition. Es darf keine Partitionsnummer wie z.B. bei /dev/sda1 vorhanden sein.

Achtung: Dieses Device wird i.d.R. vollständig gelöscht und neu angelegt! Beim tar und rsync Backup wird automatisch die Größe der root Partition entsprechend verkleinert oder vergrößert, wenn das Zielgerät eine andere Größe hat als das gesicherte System. Dabei muss natürlich auf dem Zielgerät noch genügend Platz für die Daten des Quellsystems vorhanden sein. Ist nicht genügend Platz, wird der Restore abbrechen.

-N: Erweiterungen, die vor und nach dem Restore aufgerufen werden sollen

Optionsname	Standard	Im Installer	Konfigurationsname
-N	keine	nein	DEFAULT_EXTENSIONS

-R: Externe Rootpartition

Durch diese Option kann man Backups von Systemen restoren, die eine externe Partition als Rootpartition benutzen, wie USB Sticks oder Festplatten. Dieses ist nur möglich, wenn ein tar oder rsync Backup vorliegt. Der Parameter definiert die Partition, auf welchem das root Verzeichnis restored werden soll. Beispiel: /dev/sdb1.

Option	Standard	Im Installer	Konfigurationsname
-R	nein	nein

Hinweis: Diese Option nur benutzen, wenn sowohl eine SD-Karte als auch ein externes Rootfilesystem auf einem Gerät benutzt wird. Sonst reicht die Option -d. Die Option ist nur sinnvoll bei älteren Raspberries, die noch keinen USB Boot unterstützen.

Achtung: Die Partition wird neu formatiert. Deshalb aufpassen, dass es die richtige Partition ist und dass die Partition groß genug ist, um die Partition des Backups aufzunehmen!

Hinweis: Diese Option steht nur zur Verfügung, wenn der normale Backupmodus benutzt wurde. Im partitionsorientierten Modus (Option -P) kann keine externe Rootpartition mitgesichert werden.

--resizeRootFS: Rootfilesystem anpassen

Während der Wiederherstellung kann die Rootpartition auf die maximal verfügbare Größe des Zielgerätes der externen Partition ausgedehnt werden. Wird die Option ausgeschaltet mit --resizeRootFS-, wird die Rootpartition so groß angelegt, wie sie auf dem Originalsystem war. Nutzt man die Option -P, so wird die letzte Partition auf dem Gerät erweitert. Liegen mehr als 2 Partitionen vor, ist es dann nicht die Rootpartition.

Option	Standard	Im Installer	Konfigurationsname
--resizeRootFS	ja	nein

-T: Zu restorende Partitionen

Beim partitionsorientierten rsync Backup können damit gezielt Partitionen ausgewählt werden, die zu restoren sind. Mit "*" werden alle Partitionen restored.

Option	Standard	Im Installer	Konfigurationsname
-T	"1,2"	nein	DEFAULT_PARTITIONS_TO_RESTORE

--updateUUIDs: Anpassen der UUIDs

Beim Restore werden immer die PARTUUIDs, UUIDs und LABELs des Originals restored. Dieses erzeugt i.d.R. Probleme, wenn man das restorte System am Originalsystem mounted. Mit dieser Option werden neue PARTUUIDs, UUIDs und LABEL beim Restore generiert.

Option	Standard	Im Installer	Konfigurationsname
--updateUUIDs	ja	nein

-Y: Automatisierter Restore

Standardmäßig wird vor dem Restore angezeigt, wie das Restoredevice gerade aussieht und abgefragt, ob man das Device wirklich überschreiben will. Soll der Restore automatisiert erfolgen, wird mit dieser Option die Abfrage unterdrückt.

Achtung: Dadurch kann man u.U. unbeabsichtigt das falsche Device überschreiben und wichtige Daten löschen.

Option	Standard	Im Installer	Konfigurationsname
-Y	aus	nein

Zusätzlich muss noch die Option DEFAULT_YES_NO_RESTOREin der Konfigurationsdatei entsprechend gesetzt sein für die Restoredevices.

-0: Keine Partitionierung

Es wird kein neues Partitionslayout auf dem Zielgerät erstellt, sondern das existierende benutzt. Somit kann man eine gewünschte Partitionierung vor dem Restore vornehmen und dann ein Backup restoren. Details dazu siehe FAQ #6

Option	Standard	Im Installer	Konfigurationsname
-0	aus	nein

-00: Keine Partitionierung und Formatierung

Hiermit wird keine Formatierung der mit der Option -T ausgewählten Partitionen bei einem rsync partitionsorientierten Backup vorgenommen. Dadurch wird der Restoreprozess extrem beschleunigt, da nur neue, geänderte oder gelöschte Dateien gesynced werden.

Option	Standard	Im Installer	Konfigurationsname
-00	aus	nein

-1: Partitionierungsfehler ignorieren

Das Partitionslayout wird auf der SD-Karte erstellt, so wie es auf dem Quellgerät existiert und dabei werden sämtliche Fehler, die entdeckt werden - inklusive des Fehlers, dass das Zielgerät zu klein ist - ignoriert. Siehe FAQ #6 für weitere Details.

Option	Standard	Im Installer	Konfigurationsname
-1	aus	nein

Hinweis: Diese Option kann unerwartete Ergebnisse haben. Benutze die Option nur, wenn Du weißt, was Du tust.

Restore Konfigurationsoptionen

Die meisten Aufrufoptionen können ebenso in der Konfigurationsdatei definiert werden. Siehe dazu Restoreoptionen.

DEFAULT_RESTORE_EXTENSIONS

raspiBackup bietet für den Restore wie beim Backup die Möglichkeit, auch pre und post Exits zu konfigurieren, um vor und nach dem Restore noch Aktionen vorzunehmen. Die Syntax ist genauso wie für die Backup Extensions.

Config-Option	Standard
DEFAULT_RESTORE_EXTENSIONS	keiner

DEFAULT_RESTORE_REMINDER_INTERVAL

Backup Restore Test Reminder Intervall (Einheit: Monate)

Config-Option	Standard
DEFAULT_RESTORE_REMINDER_INTERVAL	6

DEFAULT_RESTORE_REMINDER_REPEAT

Anzahl der Erinnerungen, einen Backup Restore Test durchzuführen.

Config-Option	Standard
DEFAULT_RESTORE_REMINDER_REPEAT	3

DEFAULT_YES_NO_DEVICES

Mit der Aufrufoption -Y können die Ja/Nein Abfragen beim Restore unterdrückt werden.

Da dieses aber unbeabsichtigtes Löschen von Devices bewirken kann muss mit dieser Option vermitteles eines regulären Ausdruckes definiert werden, welche Restoredevices ohne Abfrage überschrieben werden dürfen.

Config-Option	Standard
DEFAULT_YES_NO_DEVICES	loop

Allgemeine Optionen und Konfigurationen

Die Aufrufoptionen und die dazugehörigen Konfigurationsoptionen für raspiBackup sind hier erklärt.

Optionen, die nur in der Konfigurationsdatei für den Backup angegeben werden können, sind in Allgemeine Konfigurationsoptionen beschrieben.

Siehe auch Backup Optionen und Backup Konfigurationsoptionen sowie Restore Optionen und Restore Konfigurationsoptionen

Allgemeine Optionen

-A: Das Laufzeitlog wird bei der eMail Benachrichtigung mitgeschickt

Das Laufzeitlog wird bei der eMail Benachrichtigung mitgeschickt.

Optionsname	Standard	Im Installer	Konfigurationsname
-A	aus	nein	DEFAULT_APPEND_LOG

--coloring: Kolorierungseinstellungen bei eMails und Konsolmeldungen

Die Meldungen in der eMail sowie auf der Konsole können koloriert werden. Mögliche Werte sind C für Konsole und/oder M für eMail. Falls Postfix als eMail Client genutzt wird, siehe auch Option --eMailColoring.

Optionsname	Standard	Im Installer	Konfigurationsname
--coloring	automatisch	nein	DEFAULT_COLORING

-e: eMailAdresse, an die die Benachrichtigung geschickt wird

email Addresse, die eine Status-email sowie die Meldungen des Backuplaufs zugesendet bekommt

Achtung: Die Benachrichtigungsemail wird vom root Nutzer gesendet. D.h. der eMailClient auf dem System muss so konfiguriert werden, dass mit

echo "eMail-Text" | sudo mail -s "Betreff" "Empfänger eMail"

die eMail erfolgreich gesendet wird.

Mit der Konfigurationsoption DEFAULT_SENDER_EMAIL kann die Standardsenderadresse "root@$(hostname)" bei Bedarf geändert werden.

Hinweis: Die eMail Benachrichtigung funktioniert nur, wenn ein MTA wie z.B. nullmailer, msmtp, Postfix oder Exim4 entsprechend korrekt konfiguriert wurde. Für einige eMailClients gibt es Konfigurationsanleitungen. Ansonsten ist FAQ38 zu berücksichtigen. Die eMailfunktion kann relativ einfach mit der "Fake"-Option -F getestet werden. Außerdem sind weitere Benachrichtigungsmöglichkeiten wie Pushover, Slack oder Telegram unterstützt.

Optionsname	Standard	Im Installer	Konfigurationsname
-e	keine	konfigurierbar	DEFAULT_EMAIL

-E: Optionale Parameter für die eMailClientProgramme

Optionale weitere Parameter, die im eMail-Programmaufruf mitgegeben werden. Für sendEmail muss er z.B. wie folgt aussehen: "-f absender.mail@absenderdomain -s smtp-server:587 -xu Username -xp Password".

Achtung: Die Parameter für -E müssen in Anführungszeichen " eingeschlossen sein. Speziell zum Testen der eMail Benachrichtigungsfunktion ist der Parameter -F hilfreich.

Achtung: Wenn der Parameter -l 1 benutzt wird, steht das Password im Log und sollte vor Verschicken des Logs manuell maskiert werden.

Optionsname	Standard	Im Installer	Konfigurationsname
-E	keine	nein	DEFAULT_EMAIL_PARMS

--eMailColoring: Steuerung, wo der genutzte eMailClient Colorierungnsinformationen akzeptiert

Standardmäßig wird das eMailColoring über die "Subject" Zeile gesteuert, da dieser Weg von den meisten eMail Clients genutzt wird. Wenn man aber Postfix als eMail Client benutzt, muss man OPTION als Parameter mitgeben, da Postfix das Coloring mit einer separaten Option steuert.

Optionsname	Standard	Im Installer	Konfigurationsname
--eMailColoring	SUBJECT	nein	DEFAULT_EMAIL_COLORING

-f: Angabe einer Konfigurationsdatei

Angabe einer Konfigurationsdatei, die eingelesen wird. Siehe alle möglichen Konfigurationsdateien und ihre Einlesereihenfolge.

Optionsname	Standard	Im Installer	Konfigurationsname
-f	keiner	nein

-g: Fortschrittsanzeige

Mit dieser Option wird beim Backup und Restore eine Fortschrittsanzeige angezeigt. Beim tar Backup steht keine Fortschrittsanzeige zur Verfügung.

Optionsname	Standard	Im Installer	Konfigurationsname
-g	keiner	nein

-G: Sprache der Meldungen

Festlegung der Sprache der Meldungen. Standard ist die Systemsprache sofern sie unterstützt wird. Ansonsten sind alle Meldungen in Englisch.

Eine Liste der unterstützten Sprachen findet sich hier.

Wer helfen möchte, raspiBackup eine weitere Sprache zu geben, ist herzlich eingeladen, dieses zu tun. Details dazu finden sich in dieser englischsprachigen Beschreibung.

Optionsname	Standard	Im Installer	Konfigurationsname
-G	Systemsprache oder EN	konfigurierbar	DEFAULT_LANGUAGE

-h: Hilfe

Ausgabe der Aufrufsyntax mit seinen Parametern

Optionsname	Standard	Im Installer	Konfigurationsname
-h	keiner	nein

-l: Loglevel

Definiert, ob ein Debuglog erstellt wird:

off -> Es wird kein Debuglog erstellt
debug -> Es wird ein Debuglog erstellt

Achtung: Die Logausgabe kann sensitive Informationen enthalten. raspiBackup maskiert z.B. externe statische IP Adressen, eMailAdressen, Kennwörter für mount Befehle oder email Server, u.V.m. Es können aber immer noch sensitive Informationen im Debuglog enthalten sein, die noch manuell maskiert werden sollten. Das Debuglog wird immer im Backupverzeichnis abgelegt. Falls es Fehler gibt und das Backupverzeichnis wieder gelöscht werden wird, wird das Log vorher in das Home-Verzeichnis des Aufrufers gesichert.

Optionsname	Standard	Im Installer	Konfigurationsname
-l	an	nein	DEFAULT_LOG_LEVEL

-L: Verzeichnis wo das Debuglog sowie die Laufzeitmeldungen gespeichert werden

Definiert das Ziel der Logdatei raspiBackup.log.

varlog: Die Logdatei wird in /var/log/ geschrieben
backup: Die Logdatei wird in das erzeugte Backup geschrieben
current: Die Logdatei wird in das aktuelle Verzeichnis geschrieben.
<Dateiprefix>: Das Debuglog wird dort mit der Extension .log und die Messagedatei mit der Extension .msg abgelegt.

Beispiel: /home/pi/raspiBackup

Am Ende existieren /home/pi/raspiBackup.log sowie /home/pi/raspiBackup.msg

Im Backupverzeichnis werden keine Logs abgelegt.

Optionsname	Standard	Im Installer	Konfigurationsname
-L	backup	nein	DEFAULT_LOG_OUTPUT

-m: Meldungsdetails

Meldungsdetails

minimal: Nur wichtige Meldungen werden ausgegeben
detailed: Viele Meldungen über den Fortschritt werden ausgegeben

Optionsname	Standard	Im Installer	Konfigurationsname
-m	minimal	konfigurierbar	DEFAULT_MSG_LEVEL

-s: eMailClientProgramm welches benutzt wird, um die eMail zu verschicken

email Programm, welches benutzt wird {mail|sendEmail|ssmtp|msmtp}. Für Postfix und nullmailer muss mail benutzt werden und die mailtools installiert werden. Für sendEmail muss der Parameter -E zusätzlich genutzt werden für weitere obligatorische Parameter (Siehe Parameter -E Beschreibung für Details).

Es kann auch ein eMailPlugin benutzt werden, um eMails zu verschicken. Damit können beliebige weitere eMailClients in raspiBackup eingebunden werden. Der -s Parameter muss dann "mailext" sein. Details zum eMailPlugin siehe diese Seite.

Optionsname	Standard	Im Installer	Konfigurationsname
-s	mail	nein	DEFAULT_MAIL_PROGRAM

-S: Unbedingtes Update

Ein Update mit der Option -U wird auch vorgenommen, wenn die Versionen übereinstimmen. Sie bewirkt, dass sowohl eine lokale Betaversion wie auch eine lokale normale Version mit dem aktuellen Codestand ersetzt wird. Primär ist sie dafür gedacht, den Codestand einer existierenden lokalen Betaversion zu aktualisieren.

Optionsname	Standard	Im Installer	Konfigurationsname
-S	aus	nein

--timestamps: Alle Meldungen werden mit einem führenden Zeitstempel ausgegeben

Durch diese Option wird vor jeder Meldung ein Zeitstempel ausgegeben.

Optionsname	Standard	Im Installer	Konfigurationsname
--timestamps	aus	nein	DEFAULT_TIMESTAMPS

-U: Update von raspiBackup

Die lokale raspiBackup Version wird durch die letzte aktuelle Version ersetzt, sofern eine neue Version existiert. Die vorherige Version wird als raspiBackup.sh.n.m gesichert, wobei n und m die Versionsnummer von raspiBackup ist. Siehe Parameter -V, um eine vorhergehende Version wiederherzustellen.

Achtung: Vorher sollte man diese Seite lesen und sich über die Änderungen und Neuerungen informieren.

Zusätzlich gibt es noch die Option -S, mit der Betaversionen auf den letzten Stand gebracht werden können.

Mit der Option -V kann auf eine ältere Version zurückgegangen werden.

Optionsname	Standard	Im Installer	Konfigurationsname
-U	aus	nein

--updateConfig: Update der raspiBackup Konfiguration

Mit dieser Option kann man ein Update der Konfiguration erzwingen, falls sie nicht bei einem normalen Update mit der Option -U vorgenommen wurde.

Optionsname	Standard	Im Installer	Konfigurationsname
--updateConfig	aus	nein

--unsupportedEnvironment: Nicht unterstützte HW und SW wird akzeptiert

Wird raspiBackup auf nicht unterstützten Umgebungen gestartet, ist diese Option anzugeben.

Optionsname	Standard	Im Installer	Konfigurationsname
--unsupportedEnvironment	aus	nein

--version: Anzeige der Versionsinformation

Die Version von raspiBackup wird im folgenden Format ausgegeben:

Version: 0.6.3.2 CommitSHA: 8fbcd1a CommitDate: 2018-02-19 CommitTime: 19:18:31#

Optionsname	Standard	Im Installer	Konfigurationsname
--version	aus	nein

-v: Alle Meldungen des verwendeten Backuptools werden protokolliert

Die verwendeten Backuptools tar und rsync zeigen detaillierte Informationen an (Verbose mode). Die Option ist besonders nützliche bei initialen manuellen Backuptests, um den Backupfortschritt verfolgen zu können.

Optionsname	Standard	Im Installer	Konfigurationsname
-v	aus	nein	DEFAULT_VERBOSE

-V: Reaktivierung einer vorhergehenden raspiBackup Version

Es wird eine Liste aller existierenden Vorgängerversionen angezeigt und man kann die Version auswählen, die wiederhergestellt werden soll. Die aktuelle Version wird gesichert und kann dann auch mit dieser Option später wiederhergestellt werden (Siehe auch -U Parameter)

Optionsname	Standard	Im Installer	Konfigurationsname
-V	keiner	nein

-y: Kopie der aktuellen raspiBackup Version auf vordefinierte lokale Hosts per scp

Mit dieser Option wird das aktuelle Script auf alle Hosts kopiert, die in der Konfigurationsdatei definiert sind. Der Zugriff muss per authorized_keys ohne Kennwort möglich sein. Somit lässt sich raspiBackup schnell auf einer größeren Menge von Hosts nach einem Versionsupdate verteilen.

Optionsname	Standard	Im Installer	Konfigurationsname
-y	keiner	nein	DEFAULT_DEPLOYMENT_HOSTS

Allgemeine Konfigurationsoptionen

Hinweis: Optionen in der Konfigdatei, die ja/an oder nein/aus als Parameter benötigen, müssen 0 für nein und 1 für ja sein. Kein Eintrag in der Standardspalte bedeutet, der Standard ist ""

DEFAULT_BACKUPPATH

Diese Konfigurationsvariable definiert das Verzeichnis, in dem die Backups abgelegt werden.

Config-Option	Standard
DEFAULT_BACKUPATH	/backup

Diese Option kann beim Aufruf von raspiBackup überschrieben werden mit der Option -p oder indem am Ende ein Verzeichnis angegeben wird. (Siehe Aufruf und Optionen).

DEFAULT_COLOR_CODES

Hiermit können die html und VT100 Colorcodes definiert werden. Default ist gelb für Warnungen und Rot für Fehler. Das erste Pärchen der Definition legt die Codes für Warnung das zweite Pärchen die Definition für Fehler fest. Dabei ist die erste Definition der HTML Colorcode und die zweite Definition der VT100 Colorcode.

Config-Option	Standard
DEFAULT_COLOR_CODES	("#FF8000 33" "#FF0000 31")

Siehe ANSI Colorcodes

DEFAULT_PUSHOVER_*

raspiBackup kann Benachrichtigungen per Pushover schicken. Dazu ist es notwendig, sich auf https://pushover.net/ registriert zu haben und eine Application eingerichtet zu haben.

Mit den Notifications definiert man, ob man in Erfolgs- und/oder Fehlerfalle benachrichtigt werden will. Mögliche Optionen sind "S" für Erfolg (Success) und/oder "F" für den Fehlerfall (Failure). Mit "M" werden die raspiBackup Meldungen als Datei geschickt.. Es können die Optionen beliebig kombiniert werden. Beispiel: "SF" oder "SM".

Die Prioritäten entsprechen den verfügbaren Pushover Prioritäten.

Die Klänge entsprechen den verfügbaren Pushover Klängen.

Config-Option	Standard
DEFAULT_PUSHOVER_TOKEN	keiner
DEFAULT_PUSHOVER_USER	keiner
DEFAULT_PUSHOVER_NOTIFICATIONS	keiner
DEFAULT_PUSHOVER_SOUND_SUCCESS	keiner
DEFAULT_PUSHOVER_SOUND_FAILURE	keiner
DEFAULT_PUSHOVER_PRIORITY_SUCCESS	keiner
DEFAULT_PUSHOVER_PRIORITY_FAILURE	keiner
DEFAULT_PUSHOVER_ADDITIONAL_OPTIONS	keiner
DEFAULT_PUSHOVER_DEVICE	keiner

DEFAULT_SEND_STATS

Es werden beim Versionscheck ein paar raspiBackup Optionen übermittelt, die für Statistikzwecke genutzt werden.

Config-Option	Standard
DEFAULT_SEND_STATS	ja

DEFAULT_SENDER_EMAIL

Die eMailAdresse des Versenders kann bei ssmtp und msmtp angegeben werden.

Config-Option	Standard
DEFAULT_SENDER_EMAIL	root@$(hostname)

DEFAULT_SLACK_*

raspiBackup kann Benachrichtigungen per Slack schicken.

Mit den Notifications definiert man, ob man in Erfolgs- und/oder Fehlerfalle benachrichtigt werden will. Mögliche Optionen sind "S" für Erfolg (Success) und/oder "F" für den Fehlerfall (Failure). Mit "M" werden die raspiBackup Meldungen als Datei geschickt. Es können die Optionen beliebig kombiniert werden. Beispiel: "SF" oder "SM".

Config-Option	Standard
DEFAULT_SLACK_WEBHOOK_URL	keiner
DEFAULT_SLACK_NOTIFICATIONS	keiner

DEFAULT_TELEGRAM_*

raspiBackup kann Benachrichtigungen per Telegram schicken.

Mit den Notifications definiert man, ob man in Erfolgs- und/oder Fehlerfalle benachrichtigt werden will. Mögliche Optionen sind "S" für Erfolg (Success) und/oder "F" für den Fehlerfall (Failure). Mit "M" werden die raspiBackup Meldungen als Datei geschickt. Es können die Optionen beliebig kombiniert werden. Beispiel: "SF" oder "SM".

Config-Option	Standard
DEFAULT_TELEGRAM_TOKEN	keiner
DEFAULT_TELEGRAM_CHATID	keiner
DEFAULT_TELEGRAM_NOTIFICATIONS	keiner
DEFAULT_TELEGRAM_THREADID	keiner

Thematisch sortierte Aufruf-Optionen

Backup-Optionen

Restore-Optionen

Optionen, die die Meldungen und das Log betreffen

Optionen, die Benachrichtigungen steuern

Optionen, die Update, Restore und lokale Verteilung von raspiBackup steuern

Optionen, die Services vor dem Backup starten und stoppen sowie Erweiterungen

Weitere Optionen

Häufige Fragen (FAQ)

0) Wie entstand raspiBackup?

Bei framp liefen 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, wurde ein kleines Script 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 um durch die Hardlinks Backupzeit und -space zu sparen. Nachdem imer mal wieder eine Wiederherstellung notwendig war und alles gut klappte dachte framp dass das Script auch anderen Raspberryfreunden hilfreich sein könnte und publizierte raspiBackup. Siehe auch 10 Jahre 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. Bei einem Backup wird nur gesichert was sich auf dem Speichermedium und nicht was sich noch im Hauptspeicher befindet.

Ein Systemstopp ist leider nicht regelmäßig und automatisch vornehmbar. Wenn man alle aktiven Services wie MySQL, SMB, NFS, 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 Services nicht, besteht eine hohe Wahrscheinlichkeit, dass das Backup inkonsistent wird. Dazu gibt es die Parameter -a und -o, um die entsprechenden Stopp- und Startbefehle vor bzw. nach dem Backup auszuführen. Siehe auch FAQ18 dazu.

Mit dem Installer können Systemd Services ausgewählt werden, die gestoppt und nach dem Backup wieder gestartet werden sollen und die Parameter für Option -a und Option -o werden entsprechend gesetzt.

2) Wie kann ich ein Backup wiederherstellen?

raspiBackup kann jedes Backup wieder zurück gespielt werden. (Siehe dazu hier die Details). Als Windowsbenutzer kann man entsprechende Windowstools nutzen, 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 RaspbianOS und kopiert darauf raspiBackup. Dann schließt man das Gerät, auf welches das Backup zurückgespielt werden soll, sowie das Medium mit dem Backup an die Raspberry an. Danach ruft man raspiBackup auf und lässt ein gewünschtes Backup auf das Gerät zurückschreiben. Anschließend fährt man das System runter, legt das Gerät mit dem zurückgespielten Backup ein und startet die Raspberry wieder.

3) Was kann raspiBackup alles sichern und wiederherstellen?

Im normalen Modus sichert raspiBackup mit tar oder rsync zwei Partitionen: Die Boot und die Rootpartition die auf dem System. Wenn die Rootpartition auf ein externes Medium verlagert wurde wird auch die externe Rootpartition gesichert. Mit dem dd Backup wird die gesamte SD-Karte gesichert. Dann kann aber keine externe root Partition mitgesichert werden.

Im partitionsorientierten Modus werden beliebig viele Partitionen des Systems gesichert. Weitere externe Partitionen werden aber nicht gesichert.

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 entsprechenden Linux-Kenntnissen zu Fuß restoren zu können.

Die Sicherung legt Dateien an, die die lesbaren Ausgaben von den Linux Befehlen sfdisk, blkid und fdisk von dem System enthält. Damit lässt 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?

Beim dd Backuptyp muss man nach den Restore auf ein größeres Gerät mit Linux Repartitionierungstools nach der Wiederherstellung die Partitionsgröße anpassen, wenn man für die zweite Parition sämtlichen Platz nutzen will. Ein dd Restore auf ein kleineres Gerät geht nicht.

Ohne Probleme funktioniert es bei einem kleineren oder größeren Gerät, sofern tar oder rsync Backup. Beim normalen Backupmodus wird automatisch die Größe der root Partition entsprechend angepasst, d.h. entsprechend verkleinert oder vergrößert. Bei einer Vergrößerung wird der gesamte zur Verfügung stehende Platz benutzt. Wird von dem Backup des Systems mehr Platz benutzt als das Restore Gerät hat gibt es natürlich Fehler beim Restore. Beim partitionsorientierten Backupmodus wird die letzte Partition entsprechend angepasst.

Mit der Option -0 (Null) wird keine Partitionierung des neuen Gerätes vorgenommen sondern die existierende Partitionierung des gesicherten Systems 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 groß 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.

Einen partitionsorientierten Backup kann man auf kleinere Geräte restoren indem man es mit ihren gewünschten Partitionen vorformatiert und dann mit der Option -0 das Backup wiederherstellt.

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 Partitionierung vor und verwendet die existierende 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
SMB Netzwerklaufwerk
NFS Netzwerklaufwerk
SSHFS Netzwerklaufwerk
WebDAV Netzwerklaufwerk
FtpFS Netzwerklaufwerk

9) Wie kann ich die Funktion von raspiBackup noch erweitern und zusätzlich etwas vor oder nach dem Backup und/oder Restore ausführen lassen?

Da gibt es verschiedene Möglichkeiten:

Ein Wrapperscript wird benutzt und nimmt vor und nach dem Backuplauf weitere Aktionen vor wie z.B. weitere Dinge zu sichern.
Beliebige Erweiterungspunkte (Extensions) können vor und nach dem Backup und/oder restore 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 Exim4, Postfix und nullmailer, ssmtp, msmtp 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 verwendeten 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 oder ein Problem mit raspiBackup. Wie bekomme ich Hilfe?

Eines vorweg: Die Betonung liegt auf raspiBackup Fragen. Für Linuxfragen oder -probleme siehe FAQ38 und FAQ47.

Es gibt verschiedene Optionen:

In GitHub können Problemberichte (Issues) erstellt werden bei Fragen oder Problemen. Das ist meine präferierte Option. Dazu ist eine einmalige Registrierung notwendig. Diese sowie die Benutzung von GitHub ist kostenlos.
Im Raspberry Forum gibt es ein Unterforum zu Backups, wo Fragen zu raspiBackup gestellt und Probleme berichtet werden können. framp wird über alle neuen Threads informiert und kann sich dem Thread widmen.

Siehe auch diese Hinweise

Hinweis: Jegliche andere Kontaktwege werden ignoriert.

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 in FAQ12 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 erstellt 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.

Alternativ kann man per raspiBackupWrapper Script nach dem Backup mit raspiBackup pishrink aufrufen lassen und das dd Image auf das mögliche Minimum verkleinern.

17) Wie kann ich feststellen, dass der rsync Backup tatsächlich 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. SMB und SSHFS unterstützen keine Hardlinks.

Hinweis: Der Windows Explorer ignoriert Hardlinks und zeigt deshalb eine falsche effektive Belegung an. Es muss deshalb ein Linuxsystem genutzt werden um die Belegung zu prüfen. Die Raspberry bietet sich dafür an.

Der Befehl sudo du -sh * zeigt den tatsächlich benutzen Speicherplatz an und sudo du -shl * zeigt den Speicherplatz an, der belegt werden würde, wenn keine Hardlinks benutzt werden würden (Das, was Windows fälschlicherweise anzeigt) .

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

Hinweis: Wie funktionieren Hardlinks zusammen mit rsync?. Und dazu noch ein Youtube Video.

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

Systemd Services können mit dem Installer konfiguriert werden der in der Konfigurationsdatei DEFAULT_STARTSERVCIES und DEFAULT_STOPSERVCIES entsprechend setzt. Anwendungen die nicht als Systemservices laufen müssen manuell mit den beiden Optionen in der Konfigdatei hinzugefügt werden. Danach kann der Installer nicht mehr zur Konfiguration dieser beiden Optionen genutzt werden.

Folgende Services sollten auf alle Fälle gestoppt werden:

Service	Stopp Befehl
NFS	systemctl stop nfs-kernel-server
SMB/samba	systemctl stop samba
Pilight	systemctl stop pilight
Cups	systemctl stop cups
Minidlna	systemctl stop minidlna
Apache	systemctl stop apache2
Wordpress	systemctl stop wordpress
nginx	systemctl stop nginx
mysql	systemctl stop mysql
seafile	systemctl stop seafile
ownCloud	Siehe Apache
FHEM	systemctl stop fhem
iobroker	systemctl stop iobroker
cron	systemctl stop cron

Die Services sollten dann per Option DEFAULT_STARTSERVICES wieder gestartet werden. Die Reihenfolge sollte dann genau umgekehrt sein zu der Stoppreihenfolge.

Der Installer sorgt automatisch dafür dass die ausgewählten Systemd kontrollierten Services in der entsprechenden Reihenfolge gestoppt bzw. gestartet werden. Leider garantiert Systemd nicht dass die Abhängigkeiten der Services berücksichtigt werden. Zu ein paar Anwendungen gibt es auch weitere Tipps auf dieser Seite die man berücksichtigen sollte.

Beispiel für -a

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

Beispiel für -o

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

In der Konfigurationsdatei sieht es dann z.B. wie folgt aus:

DEFAULT_STOPSERVICES="systemctl stop nfs-kernel-server && systemctl stop pilight && systemctl stop samba"

bzw.

DEFAULT_STARTSERVICES="systemctl start samba&& systemctl start pilight && systemctl  start nfs-kernel-server"

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

Mit der Option --systemstatus wird in das Debuglog die Liste der gestarteten System Services sowie der offenen Dateien vor den Start des Backups ausgegeben.

Möchte man ausdrücklich keine Services stoppen und starten muss ein Doppelpunkt als Service angegeben werden, also -a : -o :

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 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 SMB freigegeben wird unterstützt keine Hardlinks. Eine Alternative ist NFS. Werden keine Hardlinks unterstützt kann rsync nicht genutzt werden.
FAT32 kann nur Dateien bis zu 4GB speichern. Ein dd Backup wird so groß wie die SD-Karte (Außer 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 SMB 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. Es gibt eine spezielle Seite wo ich und 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.

/usr/local/etc/raspiBackup.conf
./.raspiBackup.conf (aktuelles Verzeichnis)
~/.raspiBackup.conf (Home Verzeichnis)
Die optionale Konfigurationsdatei, die mit der Option -f angegeben wurde
Aufrufparameter

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

Es gibt dazu die Option -g für dd, tar und rsync. Die Option sollte nur genutzt werden wenn man raspiBackup manuell startet.

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 NFS4 mit rsync keine Posix 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.

Hinweis: Synology unterstützt keine ACLs mit NFS3 as of 13.5.2022.

Hinweis: Mit folgendem Befehl findet mal alle Dateien mit ACLs: sudo getfacl -Rs /Der Befehl braucht Zeit, bis er fertig ist.

Mögliche Lösungen:

Füge die folgende Zeile
```
DEFAULT_RSYNC_BACKUP_OPTIONS="-aHx --delete --force --sparse"
```
(kein großes A) in /usr/local/etc/raspiBackup.conf ein und damit sichert rsync keine ACLs mehr.
Nutze tar und nicht rsync
Benutze ein lokal angeschlossenes Gerät welches mit ext4 formatiert ist
Benutze NFS version2 oder version3. Lies dazu diesen Artikel. Diese Option funktioniert aber nicht mit einer Synology.
Benutze raspiBackupWrapper.sh, in dem sich Code befindet, der ein Loop Device welches ein mit ext4 formatiertes Image als Backuppartition benutzt und somit ACLs speichern kann. (Nur für erfahrene Benutzer).

In Bullseye hat Debian persistentes Journaling eingeführt und somit existiert /var/log/journal mit ACLs auf dem System. Wer raspiBackup Release 0.6.6 oder früher nutzt muss mindestens auf Release 0.6.6.1 upgraden oder den Workaround, der auf GitHub in Issue 393 beschrieben ist, anwenden.

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öße angegeben sind (z.B. 16GB) sind trotzdem unterschiedlich groß. 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

Man kann also das erste Image auf die zweite SD-Karte bringen aber nicht umgekehrt.

Lösung:

Eine größere SD-Karte nehmen
Das Quellimage verkleinern. Das Tool pishrink eignet sich dazu.
Das Backup mit dem Parameter DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY erstellen (Siehe dazu auch FAQ16)
Vor dem Erstellen des Backups die Rootpartition mit gparted etwas 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 raspiBackupRestore2Image.sh. 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 zurückgespielt 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 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

BastiFanta hat einen anderen Grund dafür gefunden:

Ich musste den NFS-Share mit der Option no_root_squash erstellen, siehe für weitere Details: https://www.selflinux.org/selflinux/html/nfs03.html

30) Mir gefällt raspiBackup und ich möchte die Entwicklung und den Support honorieren. Wie kann ich das tun?

Zum Beispiel ein Trinkgeld geben.

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.

Diese Fehler wurden in vorhergehenden Versionen ignoriert. Da dadurch aber inkonsistente Backups erstellt werden können werden sie nicht mehr ignoriert.

Folgende Optionen existieren, um das Problem zu beseitigen:

Stoppe den Service der die Datei während des Backups ändert. Das kann man entweder mit dem Installer vornehmen (M3->C6) sofern es ein System Service ist oder man muss manuell in der Konfigurationsdatei die beiden Optionen DEFAULT_STOPSERVICES und DEFAULT_STARTSERVICES um die Befehle erweitern, um den Service zu stoppen und zu starten. Tipp: Mit der Option --systemstatus erhält man im Debuglog eine Liste der aktiven Services und ihrer offenen Dateien. Damit kann man herausfinden welcher Service eine Datei während des Backups modifiziert.
Mit der option DEFAULT_EXCLUDE_LIST kann man die Dateien die sich während des Backups ändern vom Backup ausnehmen Achtung: Wenn diese Dateien wichtige Dateien einer Anwendung sind dann wird die restorte Anwendung nicht mehr starten. Also dringend vorher prüfen ob sich wichtig ist und gründlich testen ob die restorte Anwendung wieder startet wenn die Dateien fehlen..
inotifywait -m -e delete -e create -e move -e modify -e attrib

U.U. muss noch die Option -r zugefügt werden, damit auch alle Unterverzeichnisse überwacht werden.

Nutze die Configurationsoptionen RSYNC_IGNORE_ERRORS bzw TAR_IGNORE_ERRORS um den Fehler zu irgnorieren. Details dazu stehen hier

33) Ich habe einen Cubieboard, Banana Pi, Odroid, Hummingboard, oder Beagle Board. Kann raspiBackup diese auch sichern?

Prinzipiell sollte das gehen bzw. geht es schon für bestimmte nicht Raspberry Hardware. Einfach ausprobieren. raspiBackup wird aber nur für RaspbianOS und Raspberry HW unterstützt. D.h. wenn es funktioniert, sei glücklich. Wenn es nicht funktioniert, frage aber nicht nach Support. :-)

Beim Aufruf muss dann noch die Option --unsupportedEnvironment mitgegeben werden.

34) Ich möchte mein 16GB dd Backup zurückspielen und bekommen die Meldung dass die Ziel SDKarte zu klein ist. Wieso?

SD-Karten haben zwar eine bestimmte Größe wie z.B. 16GB aber sie SD-Karten haben nie genau diese Größe sondern es gibt kleine Abweichungen nach unten und oben. Da das dd Backup genauso groß ist wie die SD-Karte kann das dd Backup nicht zurückgeschrieben werden wenn man eine geringfügig kleinere SD-Karte erwischt. Deshalb sollte man bei einem DD Backup die letzte Partition immer etwas kleiner als maximal möglich erstellen. Siehe dazu auch FAQ16. Man kann aber mit pishrink das dd Image verkleinern und danach mit raspiBackup zurücksichern.

35) Ich möchte mein Rootfilesystem auf eine USB Platte verschieben. Kann ich das mit raspiBackup beim Restore machen?

Sofern es ein tar oder rsync Backup ist geht das. Einfach bei Restore die Option -R nutzen.

36) Was bedeuten die Returncodes (RC) mit denen raspiBackup im Fehlerfalle endet?

101 - Ein Programmfehler wurde festgestellt
102 - Ein Linux Befehl liefert einen Fehler
103 - raspiBackup wurde mit CTRLC beendet.
105 - Beim Stoppen von Services gab es Fehler
106 - Beim Starten von Services gab es Fehler
107 - Ein Parameter in einer Option ist fehlerhaft
108 - Es werden Dateien nicht gefunden
109 - Das verwendete Linux Backupprogramm dd, tar oder rsync hat einen Fehler beim Backup bekommen
110 - Ein Link zu einer Datei kann nicht erstellt werden
111 - Beim Sammeln der Partitionsinformationen gibt es Fehler
112 - Beim Restore gibt es Fehler beim Erstellen der Partitionen
114 - Ein dd Image kann nicht erstellt werden
115 - Benötigte Partitionen wurden nicht gefunden
116 - Der Restore wurde vom Benutzer abgebrochen
117 - Das verwendete Backupprogramm dd, tar oder rsync hat einen Fehler beim Wiederherstellen bekommen
118 - Angegebene Geräte wurden nicht gefunden
119 - Ein Verzeichnis kann nicht angelegt werden
120 - Linux Tools fehlen die von raspiBackup benötigt werden
121 - Es konnte keine gültige Bootpartition gefunden werden
122 - Die Extension BEFORE_START_SERVICES endete fehlerhaft
123 - Die Extension BEFORE_STOP_SERVICES endete fehlerhaft
124 - Die Emailextension endete fehlerhaft
130 - A file operation failed (chmod, mv, ...)
131 - A mount failed
132 - The environment (HW/SW) is unsupported
133 - Die RESTORE_EXTENSION endet fehlerhaft
134 - Die BACKUP_EXTENSIONa endet Fehlerhaft
135 - Ein Download einer Datei endet fehlerhaft
136 - Ein ungültiges nicht von raspiBackup erstelltes Backupverzeichnis wurde angegeben
137 - Ein ungültiges Restoregerät wurde angegeben
138 - Ein ungültiges Bootgerät wurde angegeben
138 - USBMOUNT detected
140 - An error occured during cleanup
143 - Overlayfilesystem entdeckt
144 - Erstellung des Backupordners auf der Backuppartition am Ende des Backup endet fehlerhaft
145 - Resize einer Partition endet fehlerhaft
147 - UUID Update endet fehlerhaft

37) Der eMail Betreff hat manchmal am Anfang einen Smiley. Was bedeutet er?

smiley	Bedeutung
;-)	Es gibt eine neuere Release von raspiBackup. Ein Upgrade sollte mit der Option -U vorgenommen werden. Zurückgehen kann man wieder mit der Option -V.
:-D	Es existiert eine Betaversion der nächsten raspiBackup Release. Beta Tester sind willkommen und können mit der Option -U die Beta installieren. Nach dem Test kann man auf die aktuelle Version wieder mit der Option -V zurückgehen.
O.o	Eine Warnmeldung wurde geschrieben.
:-(	Die raspiBackup Release ist veraltet und enthält einen schwerwiegenden Fehler. Sie sollte dringend durch die aktuelle Release mit der Option -U ersetzt werden.

38) Wo kann ich Fragen stellen und Hilfe bekommen zu Linuxfragen und -problemen die im eigentlichen Sinne nichts mit raspiBackup zu tun haben?

raspiBackup wurde entwickelt, um auch Linux Einsteigern das Sichern ihrer Raspberry schnell möglichst einfach zu ermöglichen. Allerdings sind dazu trotzdem gewisse Linux-Kenntnisse notwendig. Häufige Probleme mit raspiBackup sind bei Linux Einsteigern einfache Linux-Probleme. Solche Fragen werden nicht in den Kontaktkanälen beantwortet. Dazu gibt es Foren mit kompetenten Mitgliedern, die gerne helfen. Ein empfehlenswertes Forum ist das deutsche Raspberry Pi Forum. Ein anderes ist das englische Raspberryforum.

39) Wo finde ich das Debuglog von raspiBackup?

Siehe FAQ41

40) Wie kann ich meine Konfiguration nach einem Versionsupdate auf den neuesten Stand bringen?

Dieses wird von raspiBackup beim Upgrade automatisch erledigt. Siehe dazu Konfigurationsupdate bei einem Upgrade auf eine neue Version.

41) Wo finde ich das Debuglog von raspiBackup?

Das Debuglog heißt raspiBackup.log beim Backup und raspiBackup.logr beim Restore.

Wenn raspiBackup erfolgreich endet, steht das Logfile im Backupverzeichnis
Wenn raspiBackup nicht erfolgreich endet, steht das Logfile im Heimverzeichnis des Aufrufers
- Wenn raspiBackup über die Konsole gestartet wurde, steht das Logfile entweder in /home/<user> oder /root
- Wenn raspiBackup über Cron oder systemd im Hintergrund gestartet wurde, steht das Logfile in /root
Wenn raspiBackup unerwartet endet oder mit kill gestoppt wurde, findet sich das Logfile in /tmp
Das Logfile beim Restore steht entweder in /home/<user> oder /root

42) Wo können die /boot und /root Partition liegen ?

raspiBackup unterstützt folgende Konfigurationen im normalen Backupmodus, wobei immer nur die /boot und /root gesichert werden. Weitere Partitionen werden ignoriert.

/boot und /root auf SD-Karte oder einem anderen Gerät (Platte, SSD, ...)
/boot auf SD-Karte und /root auf eine anderen Gerät (Platte, SSD, ...) Dieses ist notwendig, wenn eine ältere Raspberry vorliegt, die noch keine USB Boot unterstützt, man aber trotzdem die Rootpartition nicht mehr auf der SD-Karte haben möchte.

43) Wie finde ich alle Dokumentationsseiten zu raspiBackup bzw. Seiten zu einem speziellen Thema?

Initial befand sich alle Doku zu raspiBackup auf dieser Seite.

Jetzt befindet sich alles auf dieser Webseite.

44) Warum startet das Image mit dem restorten Backup nicht?

Siehe FAQ49

45) Wie kann ich Optionen temporär im Aufruf an- und ausschalten?

Viele Optionen dienen dazu etwas ein- oder auszuschalten. Normalerweise wird die die Optionen einmal in der Konfigurationsdatei definiert und gut ist. Möchte man aber kurzzeitig Optionen der Konfigurationsdatei überschreiben kann man die Option mit einem + für einschalten und - für ausschalten benutzen. Beispiel: Hat man standardmäßig das Zippen von dd Backups eingeschaltet kann man das temporär mit der Option -z- ausschalten.

46) Warum ist es nicht zu empfehlen den Backuptyp dd zu benutzen?

Siehe dazu diesen Artikel.

47) Wo bekomme ich Hilfe bei reinen Linux-Fragen oder -Problemen, die nichts mit raspiBackup im eigentlichen Sinne zu tun haben?

Siehe FAQ38

48) Kann ich den Backup auf ein laufendes System zurückspielen?

Technisch geht das aber das Ergebnis ist alles andere als ein laufendes System. Deshalb bricht raspiBackup sofort ab wenn man das versucht. Ein Restore muss immer auf eine weitere SD-Karte oder ein weiteres Gerät, welches an die Raspberry angeschlossen ist, vorgenommen werden.

49) Mein Backup welches ich auf eine SD-Karte restored habe startet nicht. Warum nicht?

In 99.9% der Fälle ist die SD-Karte auf die restored wird defekt. Wenn man auf eine andere, möglichst neue, SD-Karte restored tritt das Problem üblicherweise nicht mehr auf. Es gibt auch die Option -C die man beim Restore nutzen kann um die SD-Karte auf Bad Blocks beim Formatieren zu prüfen. Dadurch dauert aber der Restoreprozess wesentlich länger. Siehe auch diese Seite zu Problemen eines dd Backups.

50) Mein Backup oder restore dauert ewig. Woran kann das liegen?

Die Backup- wie auch Restorezeit ist abhängig von der Größe der zu sichernden Daten wie auch der Performance der Backuppartition. Wird über das Netz per SMB oder NFS gesichert dauert es noch einmal länger. Beim rsync dauert der erste Backup länger da das erste Backup ein Vollbackup ist. Erst die folgenden Backups sind nur noch inkrementelle Backups und deshalb i.d.R. schneller.

Es kann vorkommen, dass der Backup- oder Restorelauf nicht endet bzw. extrem lange dauert. Das liegt i.d.R. daran, dass Fehler bei der Sicherung auftreten - Schreib- oder Lesefehler, die von den genutzten Linux Backuptools dd, tar oder rsync gemeldet werden.

Bei rsync kann es auch daran liegen, dass ACLs gesichert werden sollen, aber dazu die Berechtigung nicht existiert oder ACLs nicht von der Backuppartition unterstützt werden. Letzteres trifft zu für NFS und SMB gemountete Backuppartitionen. Siehe dazu FAQ24.

Falls die mount Option sync genutzt wird, sollte diese durch die Option async ersetzt werden.

Option --timestamps hilft den Schritt zu finden, wo raspiBackup so lange braucht. Danach hilft das Debuglog weiter.

51) Wie werden die Statistiken der Fortschrittsanzeige berechnet ?

raspiBackup berechnet nichts. Stattdessen werden die Optionen der angebotenen Fortschrittsanzeige genutzt. Bei dd ist es die Option status=progress und bei rsync die Option info=progress2. tar hat keine eigene Fortschrittsanzeige und es wird deshalb der Datenstrom durch pv gestreamt. Die Details der jeweiligen Fortschrittsanzeige sind in der Dokumentation den Optionen in den jeweiligen Tools und sowie dem Linux Tool pv erklärt.

52) Wie kann ich eine Testversion oder einen temporären Fix von aus dem GitHub downloaden und ausführen?

Dazu gibt es ein Script bei GitHub. Dieses muss man wie folgt aufrufen:

curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | sudo bash -s -- <Branchname>

Dabei muss der GitHub Branch sein, von dem man sich raspiBackup.sh downloaden möchte. Danach ruft man diese raspiBackup Version wie folgt auf (Achtung: Auf den führenden Punkt achten !)

sudo ./raspiBackup.sh <Optionen>

53) Was sind raspiBackup Snapshots?

raspiBackup Snapshots sind spezielle Backups mit zwei besonderen Eigenschaften:

Sie werden nicht beim Backuprecycle berücksichtigt und müssen somit manuell im Backupverzeichnis gelöscht werden
Sie haben eine Beschreibung im Backupverzeichnisnamen anhand derer ein raspiBackup Snapshot leicht zu erkennen ist und mit dem man eine sprechende Beschreibung dem Snapshot geben kann damit er leicht zu erkennen ist.

Ein Snapshot wird mit der Option -M erstellt und kann sehr gut dazu genutzt werden beim Neuaufsetzen oder Änderungen am System zu bestimmten Zeitpunkten einen Snapshot zu ziehen damit man im Fehlerfalle zurückgehen kann. Anhand der Beschreibung kann man erkennen welchen Stand man mit dem Snapshot gesichert hat.

54) Wie kann ich auf die boot Partitionsdateien im Backupverzeichnis zugreifen?

raspiBackup speichert die Bootpartitionsdaten in einem Imagefile. Mit den folgenden Befehlen kann man auf die Dateien in diesem Image zugreifen:

sudo losetup -f <hostname>-backup.img
sudo mount /dev/loop0 /mnt

55) Warum habe ich plötzlich PARTUUIDs doppelt auf meinem System?

Während des Restores eine Backups wird die PARTUUID der Originalsystems für die Partitionen wieder genutzt. Wenn dieses restorte System an dem Originalsystem gemounted wird tauchen die PARTUUIDs doppelt auf und es wird i.d.R. Probleme beim Booten des Originalsystems geben. Für diese Fälle gibt es die Option -updateUUIDs beim Restore wodurch nicht dieselbe PARTUUID beim restorten System genutzt wird. Ab der Release 0.6.9 wird immer eine neue PARTUUID generiert. Will man das nicht muss mit der Option -updateUUIDs- dieses ausgeschaltet werden.

56) Wie kann ich raspiBackup auf einem unsupporteten System automatisch starten lassen?

Dazu muss die Datei /etc/systemd/system/raspiBackup.service geändert werden:

Ändere die Zeile ExecStart=/usr/local/bin/raspiBackup.sh in

ExecStart=/usr/local/bin/raspiBackup.sh --unsupportedEnvironment.

57) Wie kann ich raspiBackup auf ein neues Release updaten?

raspiBackup meldet wenn eine neue Release oder eine Beta verfügbar ist. Ein Update wird mit der Option -U gestartet. Mit der Option -V kann man wieder auf eine vorhergehende Release zurückgehen. Beta-Versionen werden oft mehrere Male erneuert. Um dann den neuesten Stand zu installieren müssen die Optionen -U und -S genutzt werden.

58) Was muß ich beachten, wenn ich mit rsync auf eine NFS gemountete Backuppartition sichern will?

Die Partition muss vom NFS Server mit no_root_squash exportiert werden.

59) rsync meldet dass Dateien während des Backuprozesses am System verschwunden sind und bricht mit Returncode 24 ab. Wie kann ich das verhindern?

Es gibt folgende Möglichkeiten:

Der Service der die Datei löscht wird vor dem Backup gestoppt und wieder gestartet
Die Datei oder auch das Verzeichnis in der sich die Datei befindet wird vom Backup excluded
Wenn das alles nicht genutzt werden kann gibt es noch die Option DEFAULT_RSYNC_IGNORE_ERRORS="24" mit dem raspiBackup den RC24 ignoriert.

Achtung: Es gibt seltene Umstände, in denen ein rsync RC 24 ein nicht zu ignorierender Fehler ist. Siehe dazu hier bei bugzilla.samba.org. D.h. man sollte möglichst versuchen, den Fehler mit Möglichkeit 1 oder 2 zu beseitigen.

Fehlermeldungen und -suche

Es kann vorkommen, dass raspiBackup nicht erfolgreich läuft und Fehlernachrichten schreibt. Das liegt zu 90% Prozent an fehlerhaften Konfigurationen oder Parametrierung.

Es gibt drei Typen von raspiBackup-Meldungen:

Informationen. Die Meldungsnummer endet mit dem Buchstaben "I"
Warnungen. Die Meldungsnummer endet mit dem Buchstaben "W"
Fehler. Die Meldungsnummer endet mit dem Buchstaben "E"

Die Fehlermeldungen sind selbsterklärend und sollten auf die konkrete Ursache hinweisen. Falls nicht, helfen folgende Maßnahmen, den Fehler genauer zu lokalisieren:

Start von raspiBackup in der Befehlszeile und nicht automatisch per systemd, um systemd Fehlkonfigurationen auszuschließen
Es wird bei jedem erfolgreichen Lauf eine Logdatei raspiBackup.log im Backupverzeichnis erzeugt, die eine Menge detaillierte Informationen enthält und hilft, Fehlerursachen zu finden. Ein Suchen nach Fehlermeldungen und -ursachen in dieser Logdatei kann helfen, den Fehler zu lokalisieren.

Falls das Backup fehlerhaft abbricht, wird die Logdatei vor dem Aufräumen in das Homeverzeichnis des Aufrufers gesichert.

Weiterhin kann auch der Parameter -v weiterhelfen, wenn Fehler in den Linux Backuptools auftreten.
Falls die Informationen in der Logdatei nicht helfen, die Fehlerursache selbst zu finden, besteht die Möglichkeit, den Fehler zu berichten. Siehe dazu die Hinweise in FAQ12, wie Probleme berichtet werden können.

In machen Fällen sind zu den Fehlermeldungen weitergehende Erklärungen notwendig. Diese sind im Folgenden zu finden.

raspiBackup hat ca. 200 Fehlermeldungen und diese hier komplett 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 eine Suchmaschine benutzen und nach der Fehlermeldungsnummer suchen. Falls das nicht zum Erfolg führt, sollte ein Issue im GitHub erstellt 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 Beispielerweiterungen geschrieben. Alle anderen Nummernbereiche können von eigene Erweiterungsmeldungen genutzt werden.

Außerdem beendet sich raspiBackup mit einem Fehlercode, der auf die Ursache hinweist. Eine Liste der Fehlercodes findet sich am Ende dieser Seite.

raspiBackup - Fehlermeldungen, Ursachen und Aktionen

RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

Ursache:

raspiBackup endete mit einem Fehler und hat kein Backup erstellt. Ein Debuglog wurde im Homeverzeichnis des Aufrufers 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 im normalen Backupmodus. 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 Backuptyp dd oder den partitionsorientierten Modus nutzen.

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

Diese Optionen können mit dem raspiBackup Installer für Systemd Services konfiguriert 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 in FAQ18.

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:

Entweder 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. Üblicherweise schreibt das Backupprogramm noch eine detailliertere Meldung, die hilft, die Ursache zu finden.

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 dem Backupgerät fehlen oder kein freier Speicherplatz auf der Backuppartition vorhanden ist.

RC23 bei rsync kann auch ein Zugriffsproblem oder ein ACL Problem mit NFS sein. Siehe FAQ24 zum ACL Problem und NFS.

Die entsprechenden Fehlermeldungen vom Backuptool findet man, wenn im die auf executeCmd Command folgenden Zeilen im Debuglog untersucht und sie werden auch auf der Konsole bzw. in der eMail angezeigt.

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 detaillierte Meldungen von den Backupprogrammen im Debuglog zu erhalten, die hoffentlich weiterhelfen.

Oder man fügt

DEFAULT_RSYNC_BACKUP_ADDITIONAL_OPTIONS="--info=NAME0"

in der raspiBackup Configdatei hinzu bei rsync, um nur Fehlermeldungen zu loggen und ein detailliertes Log, welches man mit Option -v erhält, zu vermeiden.

Danach hilft es sehr häufig, die Fehlermeldung in eine Suchmaschine einzugeben, um die Ursache zu finden. Auf der FAQ Seite sind viele Fehlermeldungen, und deren Ursache und Fehlerbehebungsmaßnahmen beschrieben. Bei rsync findet man im Debuglog nach dem Aufruf des rsync alle Fehlermeldungen von rsync und kann daraus die Ursache des Abbruchs ersehen.

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, SMB) 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 das Systemgerät bzw. SD-Karte ersetzt werden sollte. Dazu dann das letzte Backup auf ein neues Systemgerät 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 /backup, welches der Standardpfad ist. In dieses Verzeichnis muss ein externes Backupgerät gemounted werden. Ein entsprechender Eintrag in der /etc/fstab kann genutzt werden, um den Mountpunkt /backup mit einer externen Partition zu verbinden. Man kann das prüfen mit

findmnt /backup

Wenn man weiß, was man tut, kann man die Fehlermeldung mit der Option -c ausschalten.

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

Ursache:

raspiBackup erstellt auf der Backupartition ein Verzeichnis mit dem Hostnamen des gesicherten Systems und darunter werden die jeweiligen Backups in Unterverzeichnissen abgelegt. So ein Backup Unterverzeichnis muss angegeben werden.

Das Format des Backupverzeichnisses hat folgendes Aussehen:

troubadix@raspbian12-rsync-backup-20250615-050123

Weitere Aktionen:

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

RBK0039E: Mail Program %s ist nicht installiert um eMail zu senden.

Ursache:

Es wurde das konfigurierte Mailprogramm zum Senden von eMails nicht gefunden. Üblicherweise tritt der Fehler auf, wenn man Postfix oder nullmailer als MTA aufgesetzt hat.

Weitere Aktionen:

Das konfigurierte eMailprogramm installieren oder bsd-mailx oder mailutils installieren.

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 eine GPT-Partitionierung notwendig. Wenn das Backup nur ein MBR hat, kann die Zielpartition nur bis 2TB erweitert werden.

Weitere Aktionen:

Das System welches restored werden soll, nutzt noch MBR und muss in GPT konvertiert werden. Danach muss noch einmal ein Backup - dieses mal mit GPT erstellt werden. Dieses kann kann dann auf Platten größer als 2TB restored werden.

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. Im Kapitel Backupverzeichnisstruktur ist dokumentiert, 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 Fehlermeldungen 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 5. Zeile in der Datei mit der Extension .sfdisk im Backupverzeichnis zu löschen.

RBK0086E: Wiederherstellungsgerät darf keine Partition sein.

Ursache:

raspiBackup will beim Wiederherstellen des Backups Partitionen anlegen. Dazu muss das ganze Gerät 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>. Weitere Infos dazu im Kapitel Backupverzeichnisstruktur.

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.

RBK0109E: Nicht unterstütztes Filesystem %s auf Partition %s.

Ursache:

raspiBackup unterstützt dieses Filesystemformat nicht

Weitere Aktionen:

Erstelle einen Issue in GitHub und es kann sein, dass dann der Filesystem Support in raspiBackup eingebaut wird.

RBK0142E: Bootgerät kann nicht erkannt werden.

Ursache:

raspiBackup kann das Bootgerät nicht erkennen. Das passiert normalerweise, wenn eine andere Hardware als eine Raspberry benutzt wird oder ein anderes Betriebssystem als Raspberry Pi OS oder Ubuntu benutzt wird.

Weitere Aktionen:

Das Problem auf GitHub berichten.

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

Ursache:

raspiBackup hat einen Fehler vom benutzten Backupprogramm bekommen beim Sichern einer Partition im partitionsorientierten 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 bis 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 eine 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> ( ist in der Meldung genannt) herausfinden, welche Partition gemounted ist und mit sudo umount <partition>, wobei 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 das Gerät, auf das es zurückgespielt werden soll und kann deshalb nicht zurückgespielt werden. Die Meldung kommt nur beim dd Backup. Bei tar oder rsync Backup ist je nach Belegung nicht die volle Größe des Gerätes notwendig.

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.

RBK0164E: Es können keine Hardlinks erstellt werden. RC %s.

Ursache:

Hardlinks, die von rsync benötigt werden, werden nur von einem ext3 oder ext4 Dateisystem unterstützt. Siehe dazu auch diese Seite.

Weitere Aktionen:

Entweder einen anderen Backuptyp wie tar oder dd wählen oder eine Backuppartition nutzen, die ext3 oder ext4 formatiert ist.

RBK0172E: Verzeichnis %s kann nicht erstellt werden.

Ursache:

Es fehlt die Berechtigung für den Nutzer root, das neue Backupverzeichnis zu erstellen.

Weitere Aktionen:

Ist das Backupverzeichnis per NFS gemounted, fehlt meist die Option NO_ROOT_SQUASH in der Datei /etc/exports des NFS Servers. Ansonsten ist das Backupverzeichnis mit nicht ausreichenden Rechten gemounted.

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:

Siehe 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. SMB 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 dann jedes 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:

Meist liegt die Ursache beim Aufsetzen der Benachrichtigung in einer Fehlkonfiguration des genutzten MTAs. Häufig bekommt raspiBackup auch keinen Fehler beim Senden der eMail, aber sie kommt trotzdem nicht an.

Die Konfiguration eines MTAs ist 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 ein GitHub Issue erstellt werden, in dem das Debuglog angehängt ist, um die Ursache zu finden.

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

Ursache:

Mit der Option -P können mit raspiBackup nur die Partitionen des Systemgerätes 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 --ignoreAdditionalPartitions die Sicherung der weiteren Partitionen ausgeschlossen werden.

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

Ursache:

Die rsync Backupmethode erfordert, dass die Backuppartition 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, die Linux Dateiattribute unterstützt. Details dazu finden sich auf dieser Seite.

RBK0266E: Es fehlt die Berechtigung um Linux Dateiattribute auf %s zu erstellen (Dateisystem: %s)

Ursache:

Einer per NFS eingebundene Backuppartition fehlt die notwendige Berechtigung für root, alle Dateiattributes zu setzen. I.d.R. exportiert der NFS Server die Backuppartition nicht mit no_root_squash. Diese Option muss in der Datei /etc/exports auf dem NFS Server für die exportierte Partition gesetzt werden. Auch muss ein Dateisystem exportiert werden, welches Linux-Dateiattribute unterstützt - also ext3 oder ext4. ntfs oder fat32 kann nicht genutzt werden.

Weitere Aktionen:

Mit no_root_squash die Backuppartition auf dem NFS Server exportieren.

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

Ursache:

raspiBackup wird nur für Raspberry Pis und RaspbianOS und Ubuntu 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. Unterstützte Hardware und Software

Weitere Aktionen:

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

RBK0273E: %s ungültige Backupverzeichnis(se) oder Dateien 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. Das passiert normalerweise, wenn man manuell Backupverzeichnisse umbenennt.

Weitere Aktionen:

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

RBK0274E: Das Restoregerät %s hat gemountete Partitionen. Hinweis: Ein Restore auf das aktive System ist nicht möglich.

Ursache:

Ein Restore darf nicht auf ein laufendes System vorgenommen werden. Auch darf das Restorgerät nicht gemounted sein. Dieser Check verhindert, dass aus Versehen ein aktives und anderweitig genutztes Gerät überschrieben wird. Falls usbmount aktiv ist, muss dieses erst deaktiviert werden.

Weitere Aktionen:

Das Restoregerät muss mit umount freigegeben werden oder usbmount deaktiviert werden.

RBK0277E: Restore ist nicht möglich wenn 'usbmount' installiert ist.

Ursache:

usbmount stört beim Restore eines Backups und darf nicht installiert sein.

Weitere Aktionen:

Deinstallation von usbmount mit dem Befehl sudo apt-get remove usbmount. Noch besser ist es, eine dedizierte SD-Karte mit einem kleinen Raspberry Pi OS (Raspberry Pi OS lite) vorzubereiten und diese SD-Karte zum Restore nutzen. Dort ist kein usbmount installiert.

RBK0343E: Dateisystemcheck auf %1 fehlerhaft beendet mit RC %2

Ursache:

Nach dem Restore wird das Filesystem geprüft. Dieses sollte keine Fehler haben Bei Fehlern wird der Restore abgebrochen.

Weitere Aktionen:

Der RC %2 gibt an welcher Fehler genau von fsck auf der Partition %1. Üblicherweise ist das Gerät auf welchem restored wurde nicht OK und sollte durch ein anderes Gerät (z.B. neue SD Karte) ersetzt werden.

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

Ursache:

Die Disk-Beispielsextension benötigt bc zum Berechnen.

Weitere Aktionen:

Installiere bc mit sudo apt-get install bc, damit die Disk-Beispielextension gültige 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 zur Fehlerursache aus.

RC_ASSERTION=101
RC_MISC_ERROR=102
RC_CTRLC=103
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_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
RC_INVALID_BOOTDEVICE=138
RC_ENVIRONMENT_ERROR=139
RC_CLEANUP_ERROR=140
RC_NOT_SUPPORTED=143
RC_TEMPMOVE_FAILED=144
RC_RESIZE_ERROR=145
RC_UUID_UPDATE_IMPOSSIBLE=147

Hilfsprogramme

Auf den folgenden Seiten werden verschiedene Hilfsprogramme vorgestellt:

raspiBackupDialog - ein komfortables Hilfsscript für raspiBackup

Ein agiler Nutzer von raspiBackup - Franjo-G - hat ein sehr nützliches kleines Hilfsscript mit dem Namen raspiBackupDialog geschrieben, welches in einem Dialog die wichtigsten Aufrufoptionen für den Backup und den Restore abfragt und mit denen dann raspiBackup anstößt. raspiBackup Snapshots werden unterstützt. Sehr einfach ist besonders der Restore durchzuführen: Vor dem Restore wird die Liste der vorhandenen Backups angezeigt und man kann auswählen, welches Backup wieder hergestellt werden soll.

Hinweis

Es ist empfehlenwert, raspiBackupDialog nach erfolgreicher Installation und Konfiguration von raspiBackup einfach mal downzuloaden und auszuprobieren.

Installation und Aufruf

raspiBackupDialog steht als Hilfsscript im GitHub Repository zur Verfügung.

Es kann wie folgt in das aktuelle Verzeichnis heruntergeladen werden:

curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | bash -s -- master helper/raspiBackupDialog.sh

Nun lässt es sich aufrufen mit:

sudo ./raspiBackupDialog.sh

Möchte man es nicht jedes Mal herunterladen, kann man es auf seiner Raspberry wie folgt dauerhaft verfügbar machen:

sudo mv ./raspiBackupDialog.sh /usr/local/bin
sudo chown root:root /usr/local/bin/raspiBackupDialog.sh

Danach kann es jederzeit wie folgt aufgerufen werden:

sudo raspiBackupDialog.sh

Aufrufoptionen

sudo raspiBackupDialog.sh --select            # Startet einen restore. Das Image kann aus einer Liste ausgefählt werden.
sudo raspiBackupDialog.sh --last              # Startet einen Restore vom letzten Backup.
sudo raspiBackupDialog.sh --backup            # Startet einen Backup.
sudo raspiBackupDialog.sh --delete            # Ein Backup kann zum Löschen ausgewählt werden.
sudo raspiBackupDialog.sh --mountfs "fstab"   # Das Backupverzeichnis wird gemäß fstab Eintrag gemountet.
sudo raspiBackupDialog.sh --mountfs "*.mount" # Das Backupverzeichnis wird per systemctl start *.mount gemountet.

Falls das Verzeichnis schon gemounted war, wird es nicht unmounted. Ansonsten wird es wieder umounted.

Dynamic mount funktioniert auch mit cron.

* * * /usr/local/bin/raspiBackupDialog.sh --mountfs "backup.unit" oder "fstab" --cron

Beispielaufrufdialog bei einem Backup

sudo raspiBackupDialog.sh

Please choose your preferred language
Bitte waehle deine bevorzugte Sprache
German = 1
English = 2
1
Soll ein Backup erstellt oder ein bestehendes Backup restored werden?
backup 1
restore 2
1
Befinden sich auf dem Systemlaufwerk mehr als die 2 Standard-Partitionen /boot und /root ? j/N
n
Soll ein Kommentar am Ende des Backup-Verzeichnisses eingefügt werden?
Dieses Backup wird dann nicht in die backup-Strategie übernommen und nicht automatisch recycled.
j/N
n
raspiBackup wird jetzt gestartet

Weitere nützliche Hilfsprogramme

Mittlerweile sind verschiedene Hilfsprogramme zu raspiBackup entstanden. Diese sind nicht offiziell unterstützt und als Beispiele für eigene Hilfsprogramme gedacht und für eigene Anforderungen angepasst werden können.

Sie stehen auf GitHub zum Download zur Verfügung:

raspiBackupWrapper.sh: Damit kann man vor und nach dem Aufruf von raspiBackup verschiedene Dinge erledigen lassen. Der Code mounted schon die Backuppartition und unmounted sie, falls sie vorher nicht gemounted war. Es ist etwas bash Script Kenntnis notwendig, um das Script dem eigenen Bedarf anzupassen.

Hinweis Dieses Script entstand, als raspiBackup noch keine Erweiterungspunkte hatte. Normalerweise reicht es, die vorhandenen Erweiterungspunkte zu nutzen, um die Funktionalität von raspiBackup für die eigenen Bedürfnisse zu erweitern.
raspiBackupNfsWrapper.sh: Es wird von dem Script geprüft, ob ein NFS Server verfügbar ist und nur dann raspiBackup gestartet. Außer ein paar Definitionen des NFS Servers ist nichts anzupassen.
raspiBackupRestore2Image.sh: Mit diesem Script kann ein tar oder rsync Backup, welches in normalen Backupmodus erstellt wurde, in ein dd Backup umgewandelt werden. Außerdem wird pishrink benutzt, um die Größe des dd Images soweit wie möglich zu minimieren. kmbach hat die Erstellung des Scripts angeregt. Das Script erfordert keine Änderungen.
raspiImageMail.sh: Dieses Script wurde von dem raspiBackup Benutzer kmbach erstellt, weil er am Ende vom Aufruf von raspiBackupRestore2Image.sh eine eMail erhalten wollte. Dazu werden die raspiBackup eMail Konfigurationsparameter benutzt. Das Script erfordert keine Änderungen.
raspiBackupAndClone.sh: Dieses Script erstellt eine Backupversion mit raspiBackup und restored anschließend das aktuelle Backup auf ein angeschlossenes Device. Somit hat man nach dem Backup immer ein aktuelles Backupsystem, von welchem man booten kann, wenn das Systemdevice korrupt wurde. Nimmt man den partitionsorientierten Backup mit rsync, ist der Restore nur eine Synchronisation der Änderungen zum vorherigen Stand und das geht wesentlich schneller als ein Vollrestore mit tar oder dd.

Hinweis: Falls das System durch irgendwelche Fehlkonfiguration nicht mehr bootet, hilft das geclonte Backup natürlich nicht, denn darin befindet sich dieselbe Fehlkonfiguration. In diesem Falle muss man ein älteres noch funktionierendes Backup manuell restoren.
raspiBackupAndJSON.sh: Wer die von raspiBackup erzeugten Meldungen nach dem Backup untersuchen will, kann mit diesem Script die Meldungen im JSON Format erzeugen lassen und sie dadurch wesentlich einfacher parsen, z.B. mit jq.
raspiBackupDialog.sh: Dieses von Franjo erstellte Script ist ein raspiBackup vorgeschaltetes Script, mit welchem einfacher Backups erstellt und auch restored werden können. Details dazu finden sich im Kapitel raspiBackupDialog - ein komfortables Hilfsscript für raspiBackup.

Nutzergeschriebene Extensions

Des weiteren gibt es Extensions, die von raspiBackup Nutzern geschrieben wurden und zur allgemeinen Verfügung in das raspiBackup Repository per PR eingestellt wurden. Weitere eigene Extensions werden gerne per PR aufgenommen.

Backupziele

raspiBackup mounted eine Backuppartition, um auf ihr die Backups abzulegen. Also kann jedes Gerät, von dem eine Partition unter Linux gemountet werden kann, als Backupziel genutzt werden.

Dazu gehören lokal angeschlossene SD-Karten, per USB angeschlossene Platten, SSDs, USB-Sticks und SD-USB-Adapter sowie NVMe-SSDs. Des weiteren kann SMB und NFS genutzt werden, um nicht lokal angeschlossene Backuppartitionen anzubinden. SSHFS, CurlFtpFS und WebDAV funktionieren ebenso zur Ablage der Backups auf entfernten Servern. Die AVM FRITZ!Box unterstützt ebenfalls SMB und kann somit auch als Backupziel genutzt werden.

Hinweis

Die jeweiligen Backupziele müssen eine formatierte Partition haben, in der die Backups abgelegt werden. Siehe Vor-und Nachteile der jeweiligen Filesysteme.

Neben den folgenden Kapiteln siehe dazu auch Wie kann man von der Raspberry Pi auf externe Daten zugreifen.

NFS als Backupziel

Es macht sehr viel Sinn, die Backups von raspiBackup auf einem NAS abzulegen und das NFS Protokoll dazu zu nutzen. Im Folgenden wird beschrieben, wie das bei einer Synology zu konfigurieren ist. Natürlich kann man auch jedes andere NAS nutzen, sofern es NFS unterstützt. Auch eine Raspberry kann als NFS Server konfiguriert und genutzt werden.

raspiBackup - Nutzung von NFS am Beispiel einer Synology

Wichtig: Die Partition auf dem NAS muss mit no_root_squash exportiert werden, damit rsync genutzt werden kann. Im UI muss dann bei Squash No-mapping eingetragen werden.

Synology Konfiguration

Es darf NICHT NFS4 aktiviert werden wie im Screenshot zu sehen ist! Es muss NFS3 genutzt werden. Mit NFS4 habe ich es nicht hinbekommen.

Synology NFS Konfiguration

Konfiguration einer Synology und der Raspberry, um ein rsync Backup per NFS auf einer Synology zu sichern

Im Wesentlichen sind folgende Schritte durchzuführen:

Gemeinsamen NFS Ordner auf der Synology erstellen
mount des gemeinsamen NFS Ordners auf der Raspi in der /etc/fstab
Installation und Konfiguration von raspiBackup per Installer (keinen automatischen Backup konfigurieren)
Test des Backups und Restores von der Commandline
Einrichten des regelmäßigen Backups in der Crontab per Installer

Es empfiehlt sich, vor dem Beginn die FAQ zu lesen, wo die wichtigsten Fragen und Antworten zu raspiBackup zusammengestellt sind.

Gemeinsamen NFS Ordner auf der Synology erstellen

Im DSM, Systemsteuerung -> Gemeinsamer Ordner -> Erstellen erstellt man einen gemeinsamen Ordner z.B. mit dem Namen raspiBackups. Eine Papierkorb braucht man nicht. Die NFS Berechtigungen müssen wie folgt eingestellt werden (Hinweis: raspiBackup läuft als root). Hostname oder IP: Hostname oder IP des NFS Clients, z.B. 192.168.0.10. Privileg: lesen/schreiben, Squash: keine Zuordnung, Sicherheit: sys.

Eintrag des gemeinsamen NFs Ordners auf der Raspi in der fstab

Folgender Eintrag in der /etc/fstab bewirkt das Mounten des Synology NFS Orders unter dem Mountpoint /backup unter der Annahme, dass 192.168.0.11 die Synology ist:

192.168.0.11:/volume1/raspiBackups /backup nfs rw,nfsvers=3 0 0

Es ist dringend zu empfehlen, den Mountpoint /backup zu nutzen und nicht z.B. /home/pi/backup oder andere Verzeichnisse.

Manueller mount des gemeinsamen NFS Ordners

Jetzt kann man prüfen, ob der Backupspace auf der Synology freigegeben ist mit showmount -e 192.168.0.11. Danach kann man mit sudo mount /backup den NFS Ordner manuell mounten. Durch den obigen Eintrag in der /etc/fstab wird der Mount nach jedem Neustart automatisch vorgenommen, und es ist kein manueller Mount mehr notwendig.

Test des Schreibzugriffs

Den Schreibzugriff kann man nun testen mit sudo bash -c 'echo "Raspberry war hier" > /backup/killroy.txt' und sudo cat /backup/killroy.txt. Falls es Probleme gibt, Hinweise von erfahrenen Synologybenutzern zu Synology und raspiBackup lesen.

Installation und Konfiguration von raspiBackup

Installation von raspiBackup gemäß dieser Anleitung. Dabei dann rsync als Backupmethode und /backup als Backuppfad angeben. Den regelmäßigen Backup noch nicht konfigurieren.

Test des Backups und Restores von der Commandline

Einrichten des regelmässigen Backups im Installer

Aufruf des Installers und Konfiguration des regelmäßigen Backupzeitpunktes.

Hinweis zu ACLs

Eigentlich kann man ACLs mit NFS3 sichern. Das klappt z.B., wenn man eine Raspberry als NFS Server aufsetzt (Siehe https://linux-tips-and-tricks.de). Allerdings funktioniert das nicht mit einer Synology - auch wenn sie NFS3 nutzt.

Eine Anfrage bei Synology am 13.5.2022 lieferte folgende Antwort:

Unfortunately, I have to inform you that both Linux ACL and setfacl are not supported by DSM. I would be pass this on as feedback to our development department as a function request.

Hinweise und Tipps von raspiBackup Benutzern, die eine Synology als Backupspace benutzen

Hinweis von Udo

Udo hat im Kommentar beschrieben, was man tun muss, damit der Automount der Synology beim Booten der Raspberry funktioniert.

Es wurde verschiedentlich berichtet, dass es mit Synologies Probleme mit Hardlinks geben kann, die von rsync benutzt werden, wenn NFS4 benutzt wird. Mit

192.168.0.42:/backup /backup nfs rw,nfsvers=3 0 0

wird das NFS3 Protokoll benutzt, so dass das Backupskript dann erfolgreich durchläuft. Weiterhin werden Softlinks mit SMB nicht unterstützt, wenn nicht wenigstens SMB Version 3 benutzt wird.

Hinweis von Markus

Bei mir läuft das Backup mit raspiBackup in folgender Konfiguration:

Raspberry mit Raspbian Wheezy
raspiBackup.sh, Version 0.5.7.10e
Synology NAS DS213, mit aktueller DSM Version

Synology NAS Share: /volume1/backup Synology NAS Share NFS Regeln: Hostname oder IP: *, Privileg: Lesen/Schreiben, Squash: Keine Zuordnung Synology NAS Share Berechtigungen (Konsole): d--------- 5 root root 4096 Dec 15 06:01 backup Raspberry Pi Mountpoint: /media/nas-backup

Raspberry Pi fstab Einträge für NFS3 und NFS4

# Entry for the NAS backup, mount with NFS version 3
192.168.X.XXX:/volume1/backup /media/nas-backup nfs rw,nfsvers=3 0 0
# Entry for the NAS backup, mount with NFS version 4
#192.168.X.XXX:/volume1/backup /media/nas-backup nfs rw 0 0

Auszug aus der raspiBackup.conf abgelegt unter /usr/local/etc/

cat /usr/local/etc/raspiBackup.conf
# path to store the backupfile
DEFAULT_BACKUPPATH="/media/nas-backup"
# how many backups to keep
DEFAULT_KEEPBACKUPS=4
# type of backup: dd, tar, xbmc or rsync
DEFAULT_BACKUPTYPE="rsync"

Hinweise von Alfred

Alfred bekam folgende Fehlermeldung von rsync

rsync: chown "/mnt/nas/arami nta/araminta-rs ync-backup-2016 1029-190948/mmc blk0p1/overlays /.w1-gpio-overl ay.dtb.ansSC4" failed: Operation not permitted (1)"

Dann benutze er den rsync Befehl, den er im raspiBackup.log fand, den raspiBackup ausführt, um das Backup zu erstellen, um das Problem zu reproduzieren und gezielt ohne raspiBackup zu debuggen. Da er den -P Modus benutzt, musste er vorher noch folgende Befehle ausführen:

sudo mkdir /tmp/mmcblk0p1
sudo mount /dev/mmcblk0p1 /tmp/mmcblk0p1

Er machte dann zufällig einen Fehler, der zur Lösung führte: Das ist der rsync Befehl, den er ausführte:

rsync --exclude="/mnt/nas" --exclude=/proc/* --exclude=/lost+found/* --exclude=/sys/* --exclude=/dev/* --exclude=/boot/* --exclude=/tmp/* --exclude=/run/* --exclude=mmcblk0p1/overlays/* --numeric-ids -aHAXx -v /tmp/mmcblk0p1 "/mnt/nas/test.backup"

Dieser Befehl funktionierte ohne Fehlermeldung. Es lag aber daran, dass vergessen wurde 'sudo' zu benutzen. Als der Befehl dann nochmal mit sudo ausführte kam die Fehlermeldung wieder. Das weist IMHO auf ein Zugriffsproblem auf dem Synology NAS hin. Nachdem dann auf dem NAS die NFS permissions von 'map all users to admin' auf 'no mapping' geändert wurde, bingo, funktionierte es auch mit sudo.

Hinweis von Chris

Wie folgt wurde erfolgreich ein TAR-Backup via NFS 4.1 auf einem QNAP-NAS erstellt.

Inhalt - /etc/fstab:

<NAS-IP/-Hostname>:/<Share name>  /backup   nfs4    defaults,_netdev,noatime    0    2

QNAP-NAS seitig (share):

Zugriffsrecht -> sync = "no wdelay"
Zugriffsrecht -> secure (Ja)
Host: IP vom Raspi
Sicherheit: sys,
Squash-Option: lesen/schreiben
Squash-Option: "Nur root-Benutzer zuordnen"
Anonymer GID: guest
Anonymer UID: guest

SMB als Backupziel

Eigentlich wird empfohlen, NFS statt SMB zu nutzen, um die Backups von raspiBackup abzulegen. Dann lässt sich Backuptyp rsync nutzen und immer nur ein Deltabackup erstellen statt eines Vollbackups, was bei SMB notwendig ist. Aber trotzdem mag es Gründe geben, warum man ein raspiBackup auf einem SMB Laufwerk ablegen möchte.

Im Folgenden wird beschrieben, wie das bei einer Synology zu konfigurieren ist. Dabei wird auch autoFS konfiguriert. Wird nicht bereits autoFS genutzt, erreicht man bei raspiBackup mit der Option DynamicMount dasselbe Verhalten.

Um automatisch die SMB Backuppartition zu mounten, wenn raspiBackup sie nutzt, ist auf der NAS ein shared Folder zu definieren und zu konfigurieren.

In der folgenden Anleitung wird der shared Folder Name "raspiBackup" angenommen.

Installation von autoFS

sudo apt install autofs

AutoFS konfiguration

/etc/auto.cifs

synoRaspiBackup -fstype=cifs,rw,credentials=/home/pi/scratch.conf,cache=none,iocharset=utf8,file_mode=0664,dir_mode=0775,vers=3.1.1,soft,iocharset=utf8 ://<synologyIP>/raspiBackup

Damit wird ein SMB shared folder mit dem Namen raspiBackup auf dem NAS definiert mit dem Mountpoint synoRaspiBackup.

/etc/auto.master

/mnt /etc/auto.cifs --timeout=600 --ghost

sorgt dafür, dass in /mnt/synoRaspiBackup die SMB Partition des NAS automatisch gemountet wird, sobald darauf zugegriffen wird.

Definition der SMB Zugangsdaten

/home/pi/raspiBackup.conf

user=<AdministratorName>
password=<AdministratorKennwort>

Zugangsdaten nur für den Nutzer pi lesbar machen

chmod 600 /home/pi/raspiBackup.conf

Definition der SMB Partition als Backuppartition in raspiBackup

Aufruf des raspiBackupInstallers mit sudo raspiBackupInstallUI und Definition von /mnt/synoRaspiBackup (M3 -> C2)

AVM FRITZ!Box als Backupziel

Wer kein NAS besitzt, aber seine Raspberries mit raspiBackup sichern möchte, kann natürlich auch den NAS Speicher einer Fritzbox nutzen. Allerdings muss dazu der Backuptyp tar genommen werden, da das genutzte SMB-Protokoll keine Hardlinks unterstützt und somit auch kein rsync Backuptyp genutzt werden kann, bei dem man inkrementelle Backups erhält.

Sehr hilfreich, um eine Fritzbox dazu zu nutzen, war ein Artikel von andwil.de. Dort wird sehr schön erklärt, was auf der Fritzboxseite und der Raspberryseite zu konfigurieren ist.

Anbei eine Beispielzeile in der /etc/fstab:

//192.168.0.1/FRITZ.NAS/USB-Sandisk3-2Gen1-01 /backup cifs noauto,user,vers=3.0,credentials=/home/pi/.smbcredentials,noserverino,uid=1000,gid=1000 0 0

Außerdem sollte mit

chmod 600 ~/.smbcredentials

dafür gesorgt werden, dass die Fritzbox-Zugangsdaten nur vom Nutzer gelesen werden können. Das ist zwar bei der Raspberry, wo normalerweise nur ein Nutzer drauf arbeitet, nicht unbedingt nötig. Aber es ist gute Praxis, Zugangsdaten immer nur für den jeweiligen Nutzer les- und änderbar zu machen.

Dann kann ein Backup mit

sudo raspiBackup -t tar

erstellt werden.

Nachdem der Restoretest erfolgreich war, ist dann noch im Installer der Backuptyp auf tar zu konfigurieren sowie der Zeitpunkt des regelmäßigen Backups festzulegen.

WebDAV als Backupziel

Für raspiBackup muss davfs genutzt werden, weil es das WebDAV Laufwerk genauso einbindet, wie es für alle anderen Laufwerke in Linux gemacht wird. Dann kann sowohl per Befehlszeile als auch mit einem Dateimanager darauf zugegriffen werden. Andere Tools, um auf WebDAV zuzugreifen, können nicht genutzt werden.

Installation von davfs2

sudo apt install davfs2

Anlegen des Mountpoints

sudo mkdir -p /remote/webdav

Definieren der Zugangsdaten

/etc/davfs2/secrets
```
/remote/webdav	<Userid> 	<Password>
```

Zugangsdaten nur für den Nutzer pi lesbar machen

sudo chmod 600 /etc/davfs2/secrets
sudo chown root:root /etc/davfs2/secrets

Einträge in der /etc/fstab erstellen

# t-online
https://webdav.mediencenter.t-online.de        /remote/webdav   davfs   rw,noauto,user  0       0 
# 1&1
https://sd2dav.1und1.de          /remote/webdav   davfs   rw,noauto,user  0       0
# ownCloud
https://cloud/owncloud/remote.php/webdav          /remote/webdav   davfs   rw,noauto,user  0       0
# seafile
https://seafile/seafdav       /remote/webdav  davfs   rw,noauto,user  0       0

Da davfs das Programm zum Mounten in /usr/sbin/mount.davfs ablegt, mount ihn aber in /sbin erwartet, muss man den folgenden Link einrichten:

sudo ln -s /usr/sbin/mount.davfs /sbin/mount.davfs

Durch einen Fehler in der WebDAV-Implementierung bei t-online können keine Dateien angelegt werden. Es kommt immer die Meldung, dass die Datei existiert - obwohl sie es nicht tut. Deshalb muss in der /etc/davfs2/davfs2.conf die folgende Zeile eingefügt werden, um die Locks auszuschalten.

use_locks       0

Wenn man den Speicherplatz automatisch beim Booten des Systems mounten möchte, ist noch das noauto in der /etc/fstab zu entfernen. Das ist für raspiBackup nicht notwendig, wenn die dynamicmount Option genutzt wird.

Tipps zur Homeautomation

Auf den folgenden Seiten werden Hinweise zu verschiedenen Anwendungen gegeben: Ob und welche Services zu stoppen und zu starten sind, welche Besonderheiten zu berücksichtigen sind, ob und welche Aktionen vor und nach dem Backup und/oder vor und nach dem Restore vorzunehmen sind.

Diese Seite lebt vom Feedback der raspiBackup Nutzer, die sich mit den jeweiligen Anwendungen auskennen und genau beschreiben können, worauf bei den jeweiligen Anwendungen zu achten ist. Deshalb ist Feedback auf der GitHub Diskussionsseite sehr erwünscht. Gerne auch in Deutsch.

raspiBackup Tipps für bestimmte Anwendungen

OpenHAB

Funktioniert ohne Probleme. Siehe hier auf der OpenHAB-Webseite.

ioBroker

ioBroker nutzt ACLs. Wer sein Backup auf eine per NFS angebundene Synology oder QNAP sichert, muss das Sichern von ACLs ausschalten, damit rsync nicht abbricht. Siehe dazu FAQ24, wie man das erreichen kann.

Wenn man ein Backup wiederherstellt, lassen sich mit ioBroker fix die fehlenden ACLs neu erstellen. Außerdem sollte man den ioBroker vor dem Backup mit systemctl stop iobroker stoppen und nach dem Backup mit systemctl start iobroker wieder starten. Das lässt sich entweder direkt in der raspiBackup Konfigurationsdatei bei DEFAULT_START_SERVICES und DEFAULT_STOP_SERVICES eingeben oder man nutzt den raspiBackup Installer und wählt dort den ioBroker als Service aus, der zu stoppen und zu starten ist. Der Installer generiert dann die entsprechenden Befehle in der Konfigurationsdatei.

FHEM

FHEM nutzt keine ACLs.

FHEM läuft als System Service und taucht somit im Installer als Service auf und kann dort einfach mit M3->C6 ausgewählt werden, so dass FHEM vor dem Backup gestoppt und am Ende wieder gestartet wird.

Zur manuellen Konfiguration in der Config dienen folgende Kommandos:

systemctl stop fhem

bei DEFAULT_STOPSERVICES

bzw.

systemctl start fhem

bei DEFAULT_STARTSERVICES

SmartHomeNG

SmartHomeNG läuft als System Service und taucht somit im Installer als Service auf und kann dort einfach mit M3->C6 ausgewählt werden, so dass SmartHomeNG vor dem Backup gestoppt und am Ende wieder gestartet wird.

Wer es manuell in der Config konfigurieren will, sollte folgende Befehle aufnehmen:

systemctl stop smarthome

bei DEFAULT_STOPSERVICES

bzw.

systemctl start smarthome

bei DEFAULT_STARTSERVICES

Hilfreiche Links zum Thema Backup

Weitere Backuptools

Anbei findet sich eine unvollständige Liste von anderen Backuptools, die genutzt werden können, um eine Raspberry zu sichern.

rpi-clone: Sicherung einer Raspberry per rsync. Cmdlinetool
piclone: Klonen einer SD-Karte per cp. Das UI ist im RaspbianOS Desktop enthalten. Keine Cmdlineversion.
image-backup: Von RonR im englischen Raspberryforum. Cmdlinetool.
borg: Sehr mächtiges Datenbackuptool, welches Deduplication unterstützt (Englisch) Nur für erfahrene Linux-User geeignet.
restic: Sehr mächtiges Datenbackuptool (Englisch). Nur für erfahrene Linux-User geeignet.
urbackup: Sehr mächtiges Backup (Englisch). Nur für erfahrene Linux-User geeignet.
rpi-backup: Script, um recht schnell direkt ein img Backup zu erstellen, ohne dd zu benutzen. Cmdlinetool
pibackup: Erstellt ein dd Backup, shrinked das dd Image und hält eine konfigurierbare Anzahl von Backups vor. Cmdlinetool.
shrink-backup: Ein weiteres Backuptool, was ähnlich wie rpi-clone und image-backup arbeitet. Cmdlinetool.

Verschiedenes

In den folgenden Kapiteln gibt es für interessierte raspiBackup Nutzer weitere Informationen über raspiBackup, seine Entstehung, wie das Logo entstand, wie die Entwicklungsumgebung von raspiBackup aussieht sowie eine Liste der Länder, in denen raspiBackup genutzt wird.

Versionshistorie

Die aktuelle Liste der raspiBackup Releases sowie deren Neuerungen und Bugfixe finden sich auf GitHub.

raspiBackup Logo

Freundliche Forenmitglieder vom deutschen Raspberry Forum haben mit Ihren Kenntnissen und großem Einsatz geholfen, ein Logo für raspiBackup zu erstellen.

Icon rot blau final 256

Es stellt die SD-Karte dar, die gesichert wird (jetzt ist es i.d.R. eine SSD - aber als raspiBackup entstand, war es immer eine SD-Karte). Der rote Ordner unten ist der Backupordner. Und die kleine Büroklammer unten rechts sorgt dafür, dass die Backups nicht aus dem auf dem Kopf stehenden Backupordner herausfallen laugh und die grünen Pfeile deuten den jeweiligen Backup und Restorevorgang an.

Anbei eine Auswahl von schönen Logos die in der Diskussion und beim Brainstorming entstanden sind:

10 Jahre raspiBackup (Retrospektive von framp)

Heute (07. August 2023) vor 10 Jahren wurde die erste Version von raspiBackup in meinem lokalen cvs abgelegt.

revision 1.1
date: 2013-08-07 21:28:14 +0200; author: framp; state: Exp; commitid: 10052029FC71A98602F;
Initial version
=============================================================================

Dieses cvs existiert leider nicht mehr, denn es wäre schon interessant zu sehen, wie sich das Script in den 10 Jahren verändert hat. Initial waren es um die 50 Codezeilen. Jetzt sind es 8000 Codezeilen.

In der wayback machine habe ich auf dieser Webseite 6/2013 eine initiale Version von raspiBackup gefunden. Ich habe sie auf meiner Webseite als raspiBackup_201306.sh abgelegt. Es waren nicht 50 sondern 314 lines of code.

Weihnachten 2013 schenkte mir mein Sohn eine Raspberry. Mit Begeisterung begann ich, mit ihr zu arbeiten und schnell kam eine zweite Raspberry dazu, die dann auch in Produktion eingesetzt wurde. Da SD-Karten leider nur eine beschränkte Haltbarkeit haben, entstand raspiBackup. Erst nur privat genutzt - aber nachdem es doch sehr gut seinen Dienst verrichtete, wurde es der Community zur Verfügung gestellt.

Was dadurch an Aufwand dazu kam, hatte ich unterschätzt: Es ist ein Unterschied, ob man ein kleines Script selbst schreibt und nutzt, oder es von anderen Usern genutzt wird. Es mussten sehr viele Tests auf falsche Eingaben und Systemumgebungen zugefügt werden. Dazu mussten dann auch entsprechende Fehlermeldungen geschrieben werden. Da die Fehlermeldungen nur kurz sind, entstanden parallel diverse Webseiten, auf denen die Funktionsweise von raspiBackup beschrieben wird, sowie detailliertere Beschreibungen der Fehlermeldungen und wie die Fehler beseitigt werden können.

Um die initiale Installation zu vereinfachen, entstand dann der Installer. Bald fanden sich auch Freunde von raspiBackup, die halfen, die Sprachunterstützung für Finnisch, Chinesisch und Französisch zusätzlich zu Deutsch und Englisch zuzufügen.

Es gab viel Feedback und Vorschläge von raspiBackup Nutzern, was noch nützliche Features in raspiBackup wären. Ohne diese Anregungen der raspiBackup Nutzer würde raspiBackup immer noch die initiale Funktion haben, die ich bei mir @home benötige. Es gab und gibt viele Helfer. Initial hatte ich mal eine Webseite gepflegt, auf der alle Helfer aufgeführt wurden. Irgendwann wurde es einfach zu viel und ich habe die Webseite vom Netz genommen.

Durch diese Hilfe entwickelte sich raspiBackup über die 10 Jahre fortwährend in seinem Funktionsumfang weiter. Zuerst kamen alle Feedbacks über die Kommentarfunktion auf meiner Webseite. Das erwies sich aber als sehr umständlich und schließlich wurde der cvs Code in GitHub abgelegt. Dadurch wurde das Erstellen von Featurerequests wesentlich vereinfacht. Zusätzlich ist seitdem das Berichten von Fehlern und Fragen zur raspiBackup Nutzung wesentlich einfacher.

Relativ schnell hatte ich mich dann in dem deutschen Raspberry Forum angemeldet. Die Mitglieder dort halfen mir sehr, meine Raspberry kennenzulernen und zu nutzen. Irgendwann fragte ich dann an, ob es nicht Sinn macht, ein Backup Subforum zu erstellen, was dann auch getan wurde. Seitdem helfe ich in dem Unterforum bei Fragen zu raspiBackup.

Ich halte eigentlich nicht viel von Videos, sondern präferiere textuelle Beschreibungen, denn darin kann man suchen. Aber im langweiligen Coronazeitraum erstellte ich dann doch verschiedene Videos zu raspiBackup und publizierte sie auf Youtube. Viel Aufwand habe ich dazu nicht getrieben - im Gegensatz zu anderen Leuten, die sehr fancy Videos auf Youtube publizieren: Ein paar Slides erstellt und die wurden dann im Präsentationsmodus erklärt. Später habe ich dann noch ein paar Videos mit praktischer Nutzung von raspiBackup auf der Befehlszeile erstellt. Aber die Zahl der Leute, die sich die Videos ansieht wächst. Der Aufwand war also nicht unnütz.

Franjo vom Raspberryforum schrieb ein kleines Tool namens raspiBackupDialog, mit welchem der Backup und Restore mit raspiBackup dialoggeführt vorgenommen werden kann.

Irgendwann erstellte ich auch eine Facebookgruppe zu raspiBackup. Initial konnten mich darüber raspiBackup Nutzer direkt kontaktieren. Das wurde mir dann aber irgendwann zu viel, da es letztendlich zu einem unbezahlten 7/24 Hotlinesupport für raspiBackup wurde.

Schließlich habe ich mal ein Paypalkonto eingerichtet, auf welches jeder dem raspiBackup gefällt, spenden kann. Außerdem kann jeder als Sponsor über GitHub spenden.

Reich werde ich dadurch natürlich nicht, aber es wird damit die Arbeit erkennbar gewürdigt, die ich in raspiBackup Entwicklung und Support reinstecke.

Auch kann ich damit Test-Hardware kaufen, denn ich kann und will nicht meine Produktivsysteme stilllegen, um raspiBackup zu testen und zu maintainen. Außerdem bin ich nicht mehr bereit, einen Cent in benötigte HW für raspiBackup zu stecken. raspiBackup ist kostenlos verfügbar und Nutzer sollen sich erkenntlich zeigen und die benötigte HW durch Spenden finanzieren.

Zum Beispiel spendete ein Nutzer ein CM4, damit ich NVMe Support in raspiBackup einbauen und testen konnte.

Aus den allgemeinen kleinen Spenden konnte ich einen RPi4 mit 8GB Memory erwerben und den Ubuntu Support in raspiBackup einbauen.

Schließlich hat jemand gespendet, damit ich mir einen RPi5 kaufen konnte. Die Spende gab es, da es ein auf einem RPi4 nicht reproduzierbares Problem mit rpi-clone gab. So konnte ich dann final das intermittierende Problem auf der RPi5 nachvollziehen und fixen. (rpi-clone ist ein nützliches Clonetool - kein Backuptool wie raspiBackup, aber oft nachgefragt, auf welches ich auch ein Auge habe.)

Im Mai 2025 hat simonz viel Einsatz und Energie in ein neues git Repository raspiBackupDoc gesteckt, um die bisherige Dokumentation von raspiBackup auf meiner Webseite in dieses Repository zu bringen und die Dokumentation dadurch wesentlich zu verbessern. Sämtliches Tooling wie auch der Transfer und Anpassung von meinen Webseiten ins Repository ist sein Verdienst. Dieses Repository und die daraus generierte raspiBackup Dokumentation wird zukünftig die Dokumentation auf meiner Webseite ablösen.

Zusätzlich entstanden viele kleine Scripte, die raspiBackup in seiner Nutzung unterstützen.

Hiermit gebe ich eine virtuelle Runde Freibier zur Feier des Tages aus.

Regressionstests die vor einem neuen Release ausgeführt werden

Jede neue Version von raspiBackup wird vor der Veröffentlichung einem Regressionstest unterzogen. Bedingt durch die vielen Optionen und möglichen Hardware- und Softwareumgebungen ist leider kein vollständiger Regressionstest möglich. Es wird aber dadurch sichergestellt, dass die Primärfunktionalität von raspiBackup, für die verschiedenen Backuptypen und -modi ein Backup zu erstellen, definitiv erfolgreich durchläuft. Auch werden alle neuen Features, obwohl sie natürlich schon beim Entwickeln getestet wurden, noch einmal getestet.

Der Regressionstest wird in einer virtualisierten Umgebung auf einem Linux Desktop, in der eine Raspi per Qemu simuliert wird, durchgeführt. (Siehe Entwicklungsumgebung.)

Als Basis wird ein RaspbianOS Lite genommen. Dieses wird mit den Standardoptionen von raspiBackup per dd, tar und rsync im normalen Modus gesichert, sowohl für ein reines SD Kartensystem als auch für ein reines USB Bootsystem. Außerdem wird ein tar und rsync Backup im partitionsorientierten Modus erstellt.

Danach werden alle jeweiligen Backups mit raspiBackup wieder restored, diese Images per Qemu gestartet und die folgenden Tests durchgeführt:

/boot/firmware/cmdline.txt wird aus der VM per scp auf den Host downloaded und geprüft
/etc/fstab wird aus der VM per scp auf den Host downloaded und geprüft
IP-Adresse 8.8.8.8 wird in der VM gepinged und getestet, ob der ping erfolgreich war
Die Anzahl der aktiven Services des Original Images wird mit verifiziert service --status-all

Jedem Benutzer von raspiBackup, der darüber hinausgehende Optionen benutzt, wird dringend nahegelegt, nach einem Versionsupgrade von raspiBackup Backup und Restore erneut sorgfältig zu testen. Es wird in diesem Kontext auf den Haftungsausschluss hingewiesen.

Entwicklungsumgebung

raspiBackup wird primär auf einem Linux Desktop entwickelt, aber natürlich auf einer richtigen Raspberry getestet. Dazu gibt es verschiedene vorab erstellte RaspbianOS Images, die zuerst mit raspiBackup restored und dann mit den neuen bzw. geänderten Code von raspiBackup manuell getestet werden. Nach erfolgreichen Test steht eine neue Version von raspiBackup an, allgemein verfügbar gemacht zu werden.

Zu Anfang wurden immer alle möglichen Testvarianten zu Fuß durchgetestet. Allerdings ist das ziemlich zeitaufwändig und es werden dabei viele SD-Karten verschlissen. Deshalb werden die Regressionstests nun in einer auf dem Desktop simulierten Raspberry vorgenommen. Das geht wesentlich schneller und seitdem geht auch nicht mehr so häufig eine SD kaputt.

Sämtlicher Sourcecode wird in einem git-Repository gewartet. Neue Releases entstehen in einem Development-Branch. Wenn ein neues Release fertig ist, um es allgemein verfügbar zu machen und alle Regressionstests erfolgreich durchgelaufen sind, wird die neue Version als Beta verfügbar gemacht. So können raspiBackup Benutzer die neue Version testen und Feedback geben. Außerdem wird die Beta auf meinen (framp) lokalen Raspberries eingesetzt. Nach ca. 4 Wochen wird der neue Code in den main Branch übernommen und die neue Version veröffentlicht.

raspiBackup ist Open Source und deshalb werden alle Releases im GitHub synchronisiert. Dazu gehört auch der Developmentzweig, der von Zeit zu Zeit synchronisiert wird.

raspiBackup schreibt seine git Codeversion (commit sha) in die folgenden Meldung RBK0009I

--- RBK0009I: raspifix: raspiBackup.sh V0.6.3.2 (5c98a16) started at Sun Jun  3 09:46:08 CEST 2018

Die hexadezimale Zahl in Klammern (5c98a16 in diesem Beispiel) erlaubt, den dazugehörigen Code anzusehen, wann immer ein Problem mit raspiBackup berichtet wird und die Problemursache kann leichter gefunden werden. Darum ist es wichtig, die Meldung RBK0009I in jedem Problembericht zu erwähnen. Außerdem ist es dadurch möglich, auf diesem Codestand einen Hotfix zu bauen. Das wird in der Regel getan und der Hotfix verifiziert, bevor er in das nächste Release einfließt.

Die meisten Probleme werden in GitHub verwaltet. Für jedes neue Release gibt es hier auf GitHub eine Zusammenfassung der Bugfixes und neuer Funktionalität.

Nutzer von raspiBackup weltweit

Im Januar 2024 hat raspiBackup Nutzer in 70 Ländern der Erde:

AD Andorra
AE United Arab Emirates
AL Albania
AM Armenia
AR Argentina
AT Austria
AU Australia
BE Belgium
BG Bulgaria
BN Brunei
BR Brasilia
CA Canada
CH Switzerland
CL Chile
CM Cameroon
CN China
CO Colombia
CY Cyprus
CZ Czech Republic
DE Germany
DK Denmark
EE Estonia
ES Spain
EU Europe
FI Finland
FR France
GB United Kingdom
GE Georgia
GH Ghana
GR Greece
HK Hong Kong
HR Croatia
HU Hungary
ID Indonesia
IE Ireland
IL Israel
IN India
IP
IR Iran
IT Italy
JE Jersey
JP Japan
KE Kenya
KR South Korea
KZ Kazakhstan
LI Liechtenstein
LT Lithuania
LU Luxembourg
LV Latvia
MD Moldova
MK North Macedonia
MT Malta
MX Mexico
MY Malaysia
NG Nigeria
NL Netherlands
NO Norway
NZ New Zealand
PA Panama
PH Philippines
PL Poland
PT Portugal
RO Romania
SC Seychelles
SE Sweden
SG Singapore
SI Slovenia
SK Slovakia
TH Thailand
TR Turkey
TW Taiwan
UA Ukraine
US United States of America
VN Vietnam
ZA Zaire

Version dieser Dokumentation

Last commit

commit 087c649094e57b28aa2b24d9f24344f1e7644512
Author: framp <framp@linux-tips-and-tricks.de>
Date:   Wed Oct 1 17:04:37 2025 +0200

    Xlated error message description

Build: 2025-10-01T15:05+00:00 (with: mdbook v0.4.52)

Testseite

Diese Seite ist gedacht zum Testen von Markdown-Features und -Syntax.

Unterschied zwischen Codeblock und Inline-Code

Inline-Code mit Single-Backticks stellt Code wie z.B. print("Good Morning") innerhalb normalen Textes dar.

Dies ist eine ganze Zeile mit Inline-Code

Sie wird anders dargestellt als ein Codeblock:

Und dies ein echter Codeblock.

Einrückungen

Text steht linksbündig.

Um zwei Zeichen eingerückt.

Um vier Zeichen eingerückt ergibt einen Codeblock!

print("Hello Markdown")

Codeblock mit Einrückung um 6 Leerzeichen:

  print("Hello Markdown")

Codeblock mit Einrückung um 8 Leerzeichen:

    print("Hello Markdown")

Tabellen

Tests bzgl. Wortumbruch

Verschiedene Längen des "Option" Titels mit Leerzeichen ändert nichts:

Option	Standard	Im Installer setzbar	Konfigurationsname
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC

Option	Standard	Im Installer setzbar	Konfigurationsname
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC

Option	Standard	Im Installer setzbar	Konfigurationsname
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC

Erst das Verlängern des Titels selber hilft:

Option zum Testen	Standard	Im Installer setzbar	Konfigurationsname
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC

Hier eine Spalte (Installer) zentriert:

Optionsname	Standard	Im Installer setzbar	Konfigurationsname
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC

... rechtsbündig:

Optionsname	Standard	Im Installer setzbar	Konfigurationsname
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC

... linksbündig:

Optionsname	Standard	Im Installer setzbar	Konfigurationsname
--keep_rsync	Parameter für Option -k	nein	DEFAULT_KEEPBACKUPS_RSYNC

Tests bzgl. Ausrichtung

Normal (Header zentriert, Spalten linksbündig):

Optionsname	Standard	Im Installer	Konfigurationsname
--ignoreMissingPartitions	nein		DEFAULT_...

Alles zentriert:

Optionsname	Standard	Im Installer	Konfigurationsname
--ignoreMissingPartitions	nein		DEFAULT_...

Alles linksbündig, inkl. Header:

Optionsname	Standard	Im Installer	Konfigurationsname
--ignoreMissingPartitions	nein		DEFAULT_...

Normal (Header zentriert, Spalten linksbündig):

Optionsname	Standard	Im Installer	Konfigurationsname
--keep_dd	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DD
--keep_ddz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DDZ
--keep_rsync	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_RSYNC
--keep_tar	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TAR
--keep_tgz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TGZ

Alles zentriert:

Optionsname	Standard	Im Installer	Konfigurationsname
--keep_dd	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DD
--keep_ddz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DDZ
--keep_rsync	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_RSYNC
--keep_tar	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TAR
--keep_tgz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TGZ

Alles linksbündig, inkl. Header:

Optionsname	Standard	Im Installer	Konfigurationsname
--keep_dd	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DD
--keep_ddz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DDZ
--keep_rsync	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_RSYNC
--keep_tar	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TAR
--keep_tgz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TGZ

Normal (Header zentriert, Spalten linksbündig):

Config-Option	Standard
DEFAULT_SEND_STATS	ja

Alles zentriert:

Config-Option	Standard
DEFAULT_SEND_STATS	ja

Alles linksbündig, inkl. Header:

Config-Option	Standard
DEFAULT_SEND_STATS	ja

formatiert per CSS und ohne Alignment-":" im Quelltext

100% Breite, linksbündige Header und Daten und Normal-Font im Header

Optionsname	Standard	Im Installer	Konfigurationsname
--keep_dd	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DD
--keep_ddz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_DDZ
--keep_rsync	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_RSYNC
--keep_tar	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TAR
--keep_tgz	Parameter für Option -k	konfigurierbar	DEFAULT_KEEPBACKUPS_TGZ

Config-Option	Standard
DEFAULT_SEND_STATS	ja

Fenced Codeblocks per Triple-Backticks

Besser/empfohlen:

Linksbündig:

print("Hello Markdown")

Um zwei Zeichen eingerückt:

print("Hello Markdown")

Um mindestens vier Zeichen eingerückt erzeugt aber einen Codeblock vom Codeblock:

```
print("Hello Markdown")
```

Um sechs Zeichen eingerückt:

  ```
  print("Hello Markdown")
  ```

Listen

Hier sieht man, warum Codeblocks durch Einrückung nicht mehr empfohlen werden: Es ist nicht immer eindeutig erkennbar oder sie werden beim Parsen evtl. nicht erkannt!

Linksbündig
dito
- sub 1 Text in sub 1 Text Um 4 Zeichen eingerückt ergibt hier nur Text
```
Um 4 Zeichen eingerückt und per Leerzeile abgesetzt
ergibt einen Codeblock
```
- zwei Zeichen eingerückt
- dito
  - sub 1 Text in Sub 1 Text Um 4 Zeichen eingerückt ergibt hier nur Text
```
Codeblock 1

Codeblock 2
```

Mit fenced Codeblocks (per Triple-Backticks) ist es eindeutig:

zwei Zeichen eingerückt
dito
- sub 1 Text in Sub 1 mit zwei Leerzeichen am Zeilenende
  ergibt eine neue Zeile und die Codeblocks dürfen auch direkt ohne Leerzeile folgen (eine Leerzeile schadet aber nicht und erhöht die Lesbarkeit des Quelltextes.)
```
print("")
```
```
print("")
```
```
```
  print("")
```
```

Erweiterungen/Plugins

Es besteht die Möglichkeit, eigene Codeerweiterungen vor und nach dem Backupprozess des Scripts einzubinden. Dieses ist sinnvoll, wenn eigentlich Änderungen im Backupscript notwendig sind, die aber dann nach jedem Update von raspiBackup auf eine neue Version wieder neu eingepflegt werden müssten. Die Extensions (Plugins) sind unabhängig vom jeweiligen Codestand von raspiBackup und deshalb in diesem Falle zu empfehlen.

Beispielerweiterungen stehen zur Verfügung und können als Vorlage für eigene Erweiterungen dienen. Durch die ersten wird die CPU Temperatur sowie die Hauptspeicher- und Backuppartitionsbelegung sowie die Partitionsbelegung vor und nach dem Backup ausgegeben. Die letzte Erweiterung wird nur am Ende des Backups aufgerufen und kann bei Erfolg bzw. Misserfolg des Backups unterschiedliche Aktionen auslösen.

Wer nützliche Erweiterungenfür die Community erstellt hat, kann sie gerne im deutschen Raspberry Pi Forum vorstellen und die Downloadlocation nennen. Sollten Fähigkeiten der Plugins fehlen, bitte einen Issue bei GitHub anlegen.

Außerdem existieren interessante, von raspiBackup Nutzern geschriebene, Plugins.

Plugin-Aufrufstellen beim Backup

Die verschiedenen Plugins werden an folgenden Stellen im Backupverlauf aufgerufen:

eMail Plugin (mem)
Notification (notify) Plugin, wenn eingeschaltet (DEFAULT_NOTIFY_START)
Slack, Pushover und Telegram Notifications, falls konfiguriert und wenn eingeschaltet (DEFAULT_NOTIFY_START)
BEFORE_STOPSERVICES (Definierte Befehle werden ausgeführt)
STOP_SERVICES (Definierte Befehle werden ausgeführt)
PRE_BACKUP_EXTENSION
READY_BACKUP_EXTENSION

... Erstellen des Backups ...

POST_BACKUP_EXTENSION
START_SERVICES (Definierte Befehle werden ausgeführt
AFTER_STARTSERVICES (Definierte Befehle werden ausgeführt)

... Aufräumarbeiten, wie das Löschen von obsoleten Backups (kann länger dauern) ...

FINAL_COMMANDS (ab Release 0.6.8) (Definierte Befehle werden ausgeführt)
eMail (mail) Plugin
Notification (notify) Plugin
Slack, Pushover und Telegram Notifications falls konfiguriert

... Final housekeeping ...

Exit

Plugin-Aufrufstellen beim Restore

Die verschiedenen Plugins werden an folgenden Stellen im Restoreverlauf aufgerufen:

PRE_RESTORE_EXTENSION

... restoren des Backups ...

POST_RESTORE_EXTENSION

Beispielerweiterungen

Der einfachste Weg ist, die Beispielerweiterungen mit dem Installer zu installieren und zu aktivieren. Entweder über die Menüfolge Installiere Komponenten->Installiere Beispielerweiterungen oder direkt über die Befehlszeile mit der Option -e.
```
raspiBackupInstallUI.sh
```
oder
```
raspiBackupInstallUI.sh -e
```
Wer die Beispielerweiterungen manuell installieren möchte, kann die tgz-Datei mit diesem Link mit einem Browser downloaden oder auch direkt wie folgt auf die Raspberry downloaden und nach /usr/local/bin auspacken:
```
wget http://www.linux-tips-and-tricks.de/raspiBackupSampleExtensions.tgz -O raspiBackupSampleExtensions.tgz
tar -xzf raspiBackupSampleExtensions.tgz -C /usr/local/bin
```

Dadurch werden die folgenden Scripts nach/usr/local/bin kopiert:

raspiBackup_mem_pre.sh und raspiBackup_mem_post.sh - Berichtet Memory Usage der Raspberry vor und nach dem Backup
raspiBackup_temp_pre.sh und raspiBackup_temp_post.sh - Berichtet die CPU Temperatur der Raspberry vor und nach dem Backup
raspiBackup_disk_pre.sh und raspiBackup_disk_post.sh - Berichtet die Plattennutzung vor und nach dem Backup
raspiBackup_execute_post.sh - Wird am Ende des Backups aufgerufen. Hilfreich, wenn eine eigene Erfolg/Fehler Benachrichtigungsfunktion genutzt werden soll.

Um die Plugins zu aktivieren, ist noch folgender zusätzlicher Aufrufparameter bei raspiBackup notwendig:

-N "temp mem disk execute"

bzw. in die Konfigurationsdatei ist folgende Zeile aufzunehmen

DEFAULT_EXTENSIONS="temp mem disk execute"

Notification Erweiterung

Für Notifications per Slack, Pushover und Telegram müssen keine Extensions geschrieben werden. Es genügt, die Notifications in raspiBackup zu konfigurieren. Wer andere Notificationziele versorgen möchte, kann das in einem Script mit dem Namen raspiBackup_notify.sh tun.

Beispielerweiterungen

Die folgenden Extensions können ein pre und/oder post Script haben und müssen raspiBackup_<extension>_pre.sh und/oder raspiBackup_<extension>_post.sh heißen.

temp
mem
disk

Alle anderen Extensions müssen kein _pre und _post am Ende haben.

Die Plugins erzeugen folgende Meldungen:

--- RBK1001I: Memory usage - Pre backup - Used: 97 MB Free: 130 MB - Post backup - Used: 98 MB Free: 121 MB
--- RBK1000I: CPU temperature pre and post backup: 53.2'C - 55.8'C
--- RBK1002I: Disk usage pre backup: Used: 1.30 TiB Free: 2.18 TiB
--- RBK1003I: Disk usage post backup: Used: 1.30 TiB Free: 2.18 TiB
--- RBK1004I: Free change: -256.00 KiB (0.00 %)

Meldungen

Die Beispielerweiterungen benutzen Meldungen, die ab dem Nummernbereich 1000 beginnen, wie z.B. RBK1000I. Wer eigene Erweiterungen erstellt, sollte, sofern sie Meldungen schreiben, diese bei 2000 beginnen lassen und nicht den Bereich unter 1999 benutzen.

Interface

Eine Erweiterungn bekommt im Aufruf den aktuellen Statuscode von raspiBackup mitgegeben. Ein Statuscode von 0 bedeutet in den Posterweiterungen: das Backup war erfolgreich. Jeder andere Statuscode bedeutet, dass das Backup abgebrochen wurde.

eMailErweiterung

Möchte man den Versand von eMails selbst programmieren, kann die emailErweiterung genutzt werden. Das ist dann besonders hilfreich, wenn die vom Script unterstützen eMailProgramme den eigenen eMailClient nicht unterstützen. Außerdem kann das Aussehen der eMail beliebig geändert werden. Eine Erweiterung, das mailx benutzt, befindet sich in den Beispielerweiterungen.

Die folgenden Parameter werden der eMailerweiterung übergeben:

email="$1"        # target email address
subject="$2"      # email subject
content="$3"      # email contents
parms="$4"        # addtl email parms passed with -E
append="$5"       # file to append

Hinweise

Achtung: Die Erweiterungen laufen mit root Rechten und können deshalb bei Fehlern das laufende System schädigen oder sogar zerstören!
Es sind nicht beide Scripts (pre und post) notwendig. Eines genügt.
Zum Testen von Erweiterungen ist der Parameter -F sehr hilfreich. Damit wird der eigentliche Backupprozess übersprungen und somit der Scriptdurchlauf sehr schnell.
Die Erweiterungen werden im Scope von raspiBackup aufgerufen. Daher besteht Zugriff auf dessen interne Scriptvariablen. Davon ist allerdings dringend abzuraten, da sich die Interna jederzeit ändern können. Aus diesem Grunde ist es auch ratsam, eigene Variablen mit einem erweiterungsspezifischen Prefix zu versehen, um mögliche Konflikte mit Variablennamen, die von raspiBackup benutzt werden, zu vermeiden.
Wer seinen Erweiterungscode teilen möchte, kann gerne einen Pullrequest auf GitHub anlegen. Dort sind alle Erweiterungen im Quellcode verfügbar, um sie zu erweitern und neue hinzuzufügen.

Erweiterungsscripte

Im raspiBackup Git Repository befinden sich verschiedene Scripte, die genutzt werden können, um darauf aufbauend die Funktionalität von raspiBackup den lokalen Anforderungen anzupassen.

Außerdem gibt es Erweiterungen, die von raspiBackup Nutzern geschrieben wurden und an Erweiterungspunkten genutzt werden können.

Beispielerweiterungen können mit dem Installer installiert werden und als Beispiele für eigene Erweiterungen genutzt werden.

Details zu den Erweiterungen sind hier beschrieben.

Language support for languages other than DE and EN (L10N)

raspiBackupInstallUI and raspiBackup initially printed messages in German and English only. But both are able to print messages in any language from a coding point of view (I18N). Anybody who is willing to help to add support for a yet unsupported language is welcome to translate raspiBackup messages.

Note

Don't hesitate if you're willing to add a new language to raspiBackup even you don't have any programming experience. You don't have to fiddle with the programming stuff. You have only to translate all messages into your native language. You even don't have to create a PR to get the new language into raspiBackup. All this programming stuff will be handled by raspiBackup developers for you.

Just add your interest in an issue on GitHub and you will immediate get individual support to add new messages in your native language to raspiBackupInstallUI and raspiBackup.

Right now following languages are supported:

ZH - Chinese
EN - English
FI - Finnish
FR - French
DE - German

Basic activities to add a new language to raspiBackup

There exist two files printing messages: raspiBackup and raspiBackupInstallUI.

Following steps have to be done to support a new language to them:

For every message a new line for the new language has to be added to the code. Example for FI:

MSG_RUNASROOT=2
MSG_EN[$MSG_RUNASROOT]="RBK0002E: $MYSELF has to be started as root. Try 'sudo %s%s'."
MSG_DE[$MSG_RUNASROOT]="RBK0002E: $MYSELF muss als root gestartet werden. Benutze 'sudo %s%s'."
MSG_FI[$MSG_RUNASROOT]="RBK0002E: $MYSELF tulee käynnistää root-oikeuksin. Suorita 'sudo %s%s'."

The line starting with MSG_FI was added in order to support Finnish. FI are the first two characters of the variable $LANG on a system which uses FI as system language.

Example for a German system:

echo $LANG
de_DE.UTF-8

and that's why MSG_DE is used.

The help text in raspiBackup may optionally also be translated. For every language a bash function usageLL() may be created which has to follow bash syntax. Just use the existing function usageEN as a template.
To enable the new language the following line in the code has to be updated:
```
SUPPORTED_LANGUAGES=("EN" "DE")
```
To enable Finnish the line has to be changed changed to
```
SUPPORTED_LANGUAGES=("EN" "DE" "FI")
```

Keyboard shortcuts

raspiBackup Dokumentation