Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 
Click here to open this page in English 

 

raspiBackup ermöglicht eine Sicherung von Raspberries manuell oder automatisch in regelmäßigen Abständen von einem laufenden System zu erstellen. D.h. es wird die SD Karte im laufenden Betrieb gesichert. Eine ausgelagerte Rootpartition wird dabei mitgesichert. Dabei muss die Raspberry nicht angehalten und manuell eingegriffen werden sondern nur alle wichtigen Services vor dem Backup gestoppt und nach erfolgtem Backup wieder gestartet werden. Backups können auf alle Geräte, die an Linux gemounted werden können, gesichert werden (USB Stick, USB Platte, nfs, samba, sshfs, ...). Als Backupmethoden stehen dd, tar und rsync mit und ohne Hardlinks zur Verfügung. Die erstellten Backups können mit raspiBackup auf beliebigen SD Karten unter Windows oder Linux wiederhergestellt werden. Auf der Quelle können die Raspbian Partitionen entweder beide auf der SD Karte liegen oder die Bootpartition auf SD Karte und die Root Partition auf einem externen Gerät wie z.B. ein USB Stick oder eine per USB angeschlossene SSD. Auch können beide Partitionen ausschliesslich auf einem USB Gerät liegen und mit dem USB Boot Modus gestartet werden.

 

 

Auf Youtube existiert auch ein Video auf dem raspiBackup vorgestellt wird sowie am Ende eine Demo der Installation von raspiBackup gegeben wird.

Für Freunde von Facebook exisitiert eine Facebookgruppe zu raspiBackup wo aktuelle Neuigkeiten und Randinformationen zu raspiBackup publiziert werden. Wichtige Informationen werden auch auf Twitter #raspiBackup veröffentlicht.

Wem raspiBackup gefällt und wer die Arbeit und den Support honorieren möchte darf gerne ein Trinkgeld geben. Details sind auf dieser Seite aufgeführt.

Der Code von raspiBackup ist reiner bash Code und steht unter der GPL auf github zur Verfügung.

 

Hinweise

  • Klicke Github um auf Github Fragen oder Probleme zu raspiBackup als Issues zu erstellen. Die Issues können gerne auch in Deutsch erstellt werden. So kann ich Fragen und Problemberichte tracken und Du bekommst eine Benachrichtigung über meine Antworten.
  • Klicke Facebook 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 Twitter um raspiBackup auf Twitter zu folgen.
  • Klicke Kommentar um eine Frage zu raspiBackup in einem Kommentar zu erstellen. Probleme bitte nur im github melden.

 

Wo lese ich jetzt weiter?

Wer eben mal schnell raspiBackup ausprobieren möchte findet hier eine Schritt für Schritt Anleitung wie raspiBackup in 5 Minuten installiert ist und dann sofort ein Backup erstellt werden kann.

Wer sich einen schnellen Überblick über die Funktionalität von raspiBackup verschaffen will sollte die Zusammenfassung lesen. Im FAQ Teil finden sich häufig gestellte Fragen sowie deren Antworten, die man sich immer durchlesen sollte.

Alle Funktionen und Einsatzgebiete von raspiBackup sind tabellarisch in der Funktionsübersicht zusammengetragen. Wer raspiBackup installieren will findet die Beschreibung bei der Installation. Wie man raspiBackup aufruft steht hier.  Alle Aufrufparameter von raspiBackup sind einmal alphabetisch sowie thematisch sortiert beschrieben. Wie man ein Backup mit raspiBackup zurückspielt ist hier beschrieben.

Weiterhin gibt es detailierte Informationen zu Erweiterungsmöglichkeiten von raspiBackup, wie man sich bei Fehlermeldungen und Fehlern von raspiBackup verhalten soll und eine detailierte Beschreibung sowie eine Tabelle der Vor- und Nachteile der Backupmethoden und eine Beschreibung der Backupmodi. Eine Liste der Bugfixes und Erweiterungen in den alten und der zukünftigen Versionen von raspiBackup findet sich hier. Wer eine Synology für den Backup benutzen will findet hier nützliche Tipps. Die Entwicklung von raspiBackup wurde durch Feedback, Testen und andere Hilfe von vielen Leuten unterstützt.

Noch weitere Themen finden sich im folgenden Inhaltsverzeichnis.

 

Inhaltsverzeichnis

  1. Zusammenfassung
  2. Funktionsübersicht
  3. Übersichtsbild
  4. Installation
  5. Manuelle Aufrufsyntax
  6. Aufrufparameter (alphabetisch sortiert)
  7. Aufrufparameter (thematisch sortiert)
  8. Erweiterungsmöglichkeiten
  9. Restore
  10. Fehlermeldungen und -suche
  11. Backuptypen und Entscheidungsbaum
  12. Vergleich partitionsorientierter Backup und normaler Backup
  13. Backupverzeichnisstruktur
  14. Haftungsausschluss
  15. Updatestrategie
  16. Regressiontests
  17. Weitere Seiten zu raspiBackup
  18. Häufige Fragen (FAQ) 
  19. Versionshistorie
  20. Benutzung von Synology
  21. Hilfreiche Links zum Thema BackupDefault_
  22. Versionshistorie
  23. Danksagungen
  24. Spenden
  25. Weitere Backuptools fuer die Raspberry



 

 

Zusammenfassung

Eine regelmäßige Sicherung von Raspberry Pis ist wichtig um im Falle von einem SD Kartenausfall oder auch unbeabsichtigten Änderungen immer wieder das System auf einen vorherigen Zustand zurücksetzen zu können. raspiBackup ermöglicht es, dass die Raspberry regelmäßig von sich selbst ein Backup erstellt und auf einem extern angebundenen Speichermedium wie usb Stick und -platte, nfs Server, smbfs/cifs/Samba Laufwerk, sshfs, davfs/webdav (Cloud) usw. (Siehe dazu Wie kann man von der Raspberry Pi auf externe Daten zugreifen) ablegt. Die Benutzung einer Synology als Backupspace ist ebenfalls möglich.

Eine einfache Wiederherstellung des gesicherten Backups nimmt raspiBackup natürlich auch vor.

Vor der Sicherung sollten alle aktiven Services gestoppt und nach dem Backup wieder gestartet werden um einen konsistenten Backup zu erhalten. Die notwendigen Befehle dazu können entweder über Parameter definiert werden oder es kann ein Beispielwrapperscript benutzt werden, welches dann wesentlich mehr und programmatisch gesteuerter Aktionen vor und und nach dem Backup vornehmen kann. Das automatische Mounten und Unmounten des Backupspaces ist schon im Beispielwrapperscript enthalten. Weiterhin gibt es Erweiterungspunkte für Plugins in raspiBackup um eigene Scripts vor und nach dem Backupvorgang einzubinden.

Im normalen Backupmodus werden die beiden SD Kartenpartitionen mmcblk0p1und mmcblk0p2 gesichert. Sofern die Rootpartition mmcblk0p2 auf eine externe Partition (USB Stick, USB Platte, ...) ausgelagert wurde wird diese externe Partition anstatt mmcblk0p2 gesichert. Ein USB Boot System kann mit einer beliebigen Anzahl von externen Partitionen gesichert werden ab der release 0.6.6.

Als Backupmethoden stehen zur Auswahl: dd Backup, tar Backup, (beides auch gezipped) und ein rsync Backup. Die einzelnen Backupmethoden sind im Detail hier nachzulesen. Dort befindet sich auch ein Entscheidungsbaum um schneller die richtige Backupmethode zu finden. Die maximale Anzahl von vorzuhaltenen Backups ist konfigurierbar. Zur Aktivierung von raspiBackup muss man, nachdem man das Script entsprechend ausgetestet hat, den Scriptaufruf in die Crontab der Raspberry Pi aufnehmen. Danach bekommt man regelmäßig eine eMail zugeschickt, die einen über das Ergebnis des Backups informiert. Die Meldungen von raspiBackup erfolgen in Deutsch oder Englisch
 

Funktionsübersicht

  • Automatische regelmäßige Sicherung einer laufenden Raspberry Pi (Sie sichert sich selbst)
  • Raspberry3 und Folgende wenn sie ohne SD Karte im USB boot mode betrieben werden sind unterstützt
  • Ähnlich aufgebaute SoCs werden auch unterstützt (Banana Pi, Ondroid, Beagle Board, Cubieboard, ...) Weitere Details dazu hier
  • Raspbian, Arch, Ubuntu, Volumio ...
  • Sicherung und Wiederherstellung ist unabhängig davon welches Betriebssystem (Linux, Windows oder Mac) für den Zugriff auf die Raspberry Pi benutzt wird
  • Windows oder Mac Benutzer nutzen einfach zur Wiederherstellung des Backups die Raspberry
  • Windows Benutzer können dd Backups mit win32diskimager restoren
  • Linux Benutzer können das Backup auf ihrem Linux System wiederherstellen oder auch die Raspberry benutzen
  • Beliebige Backupziele möglich, z.B.
    • Externer USB Stick
    • Externe USB Platte
    • Synology
    • cifs/samba Netzwerklaufwerk
    • nfs Netzwerklaufwerk
    • sshfs Netzwerklaufwerk
    • webdav Netzwerklaufwerk
    • ftpfs Netzwerklaufwerk
    • Generell jedes Device welches unter Linux gemounted werden kann
  • Einfacher Restore der Sicherung
  • Ein externes Rootfilesystem auf einer Platte oder einem USB Stick wird automatisch beim normalen Backupmodus mitgesichert und restored bei tar oder rsync backup (raspiSD2USB.py hilft beim Umziehen)
  • Einsetzbar auch zum Klonen einer Raspberry Pi
  • Einfache Installation. Die wichtigsten Optionen werden abgefragt und in die Konfigurationsdatei geschrieben.
  • Meldungen in Deutsch und Englisch
  • Diverse Aufrufparameter um den Backup zu steuern
  • dd, tar und rsync Backup möglich (-t Option). rsync benutzt bei einer ext3/ext4 Partition Hardlinks um den benötigten Plattenplatz zu minimieren
  • dd und tar kann gezippt werden um die Sicherung noch zu verkleinern (-z Option)
  • pishrink kann zur Verkleinerung von dd Images über ein Wrapperscript benutzt werden
  • dd Backup sichert per Option einschaltbar nur den von den Partitionen belegten Platz und nicht die ganze SD Karte
  • Boot backup benutzt per Option einschaltbar Hardlinks für die sich selten ändernde Bootpartition und spart dadurch Backupspeicherplatz
  • 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 (-a und -o Option)
  • Automatisches Anpassen der zweiter Rootpartition wenn die Restore SD Karte kleiner oder größer als die Original SD Karte ist
  • Ein Beispielscript hilft um vor und nach der Backup weitere Aktionen vorzunehmen wie z.B. das Mounten und Unmounten des Backupspaces
  • Einfache Erweiterung der Scriptfunktion durch Plugins (Option -N)
  • Anzahl der vorzuhaltenden Backups ist konfigurierbar (-k Option)
  • Intelleigente Backupstrategie steht zur Verfügung (Backups der letzen 7 Tage, der letzten 4 Wochen, der letzten 12 Monate und der letzten n Jahre werden aufgehoben)
  • eMail Benachrichtigung über den Backuplauf und Backupverlaufsstatus (-e Option)
  • Telegram Benachrichtigung über den Backuplauf und Backupverlaufsstatus (--telegram Optionen)
  • Unterstützte eMailClients: mailx/mail, sendEmail, ssmtp und msmtp (-s Option)
  • Nicht unterstützte eMailClients können durch ein eMailPlugin eingebunden werden
  • rsync benutzt Hardlinks um die Backupgröße zu reduzieren sofern sie vom Backupfilesystem unterstützt sind
  • Automatische Benachrichtigung, wenn eine neue Scriptversion verfügbar ist (-n Option)
  • Einfacher Update von raspiBackup durch die aktuellste Version (-U Option)
  • Einfache Wiederherstellung einer älteren Scriptversion sofern sie mit der Updatefunktion installiert wurde (-V Option)
  • Einfache Verteilung von neuen Scriptversionen auf eine größere Menge von Hosts (-y Option)
  • Beliebige Verzeichnisse und Dateien können aus dem Backup ausgeschlossen werden (-u Option)
  • Sicherung von einer beliebigen Anzahl von Raspberries in einem Backupverzeichnis
  • Unterstuetzung von Volumio

 

Übersichtsbild

raspiBackupOverview

Installation

 

Der schnellste und Standardweg raspiBackup in ca. 5 Minuten zu installieren und dann sofort einen Backup zu erstellen ist auf raspiBackup Schnellstart beschrieben. Wer raspiBackup sehr schnell aus der Befehlszeile mit seiner Standardkonfiguration installieren will findet dort auch die notwendige Information. Wer raspiBackup manuell installieren sollte der Beschreibung auf dieser Seite folgen.


 

Aufrufsyntax und -optionen

raspiBackup muss als Benutzer root oder per sudo aufgerufen werden. Die Aufrufsyntax ist

raspiBackup.sh Option1 Option2 Option3 ... Backupverzeichnis
und ab der Release 0.6.6 geht es auch ohne .sh
 
raspiBackup Option1 Option2 Option3 ... Backupverzeichnis
 

Alle Optionen die etwas ein- oder ausschalten könne durch ein angehängtes + oder - 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. Egal 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.

Neben /usr/local/etc/raspiBackup.conf gibt es weitere Konfigurationsdateien die sofern vorhanden, gelesen werden. Sie werden in folgender Reihenfolge eingelesen und überschreiben die vorherig eingelesenen Optionen. Zuletzt überschreiben die Optionen, die beim Aufruf mitgegeben werden die Konfigurationsoptionen.

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

 

 


Thematische Sortierung

 

Alphabetische Sortierung

Option Funktion Standard Option in der Konfigdatei
-a

Befehle um Services nach dem Backup wieder zu starten. Z.B. bei Samba "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. Alternativ kann ein Wrapperscript benutzt werden (Beispiel siehe unten). Diese Befehle sollten die exakte umgekehrte Reihenfolge haben wie die Befehle beim Parameter -o.

Beispiel:

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

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

Siehe dazu auch FAQ #1 und FAQ #18

Achtung: 

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

Keiner

 DEFAULT_

STARTSERVICES

-b Blocksize die beim dd Backup benutzt wird 1MB

DEFAULT_

DD_

BLOCKSIZE

-B

Die Bootpartition wird nicht per dd sondern per tar gesichert.

Hinweis: Diese Option hat keine Funktion wenn der partitionsorientierte Modus benutzt wird, also Option -P benutzt wird oder DEFAULT_PARTITIONBASED_BACKUP=1 in der Konfiguration gesetzt ist.

Nein

DEFAULT_

TAR_

BOOT_

PARTITION_

ENABLED

--coloring  Ab der Version 0.6.5 können die Meldungen in der eMail sowie auf der Konsole koloriert werden. Mögliche Werte sind C für Konsole und/oder M für eMail. Falls postfix als emailClient genutzt wird siehe auch Option --eMailColoring. CM

DEFAULT_

COLORING

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

DEFAULT_

DD_

PARMS

--dynamicMount Ab Version 0.6.6 wird damit vor dem Backup die angegebene Partition bzw der Mointpoint gemounted und am Ende wieder umounted. Falls sie schon gemounted ist wird 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). Keiner

DEFAULT_

DYNAMIC_

MOUNT

 -e email Addresse, die eine Status-email des backups zugesendet bekommt bzw im Fehlerfalle das Fehlerprotokoll   Keiner

DEFAULT_

EMAIL

-E

Optionale weitere Parameter die im eMailProgrammaufruf 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.

Keiner

DEFAULT_

EMAIL_

PARMS

--eMailColoring Standardmaessig wird das eMailColoring über die Subject Zeile gesteuert da dieser Weg von den meißten 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. SUBJECT

DEFAULT_

EMAIL_

COLORING

-f Angabe einer Konfigurationsdatei die als letztes eingelesen wird. Siehe hier alle möglichen Konfigurationsdateien und ihre Einlesereihenfolge. Nein  
-F Fake backup. Diese Option ist hilfreich beim initialen Testen von raspiBackup. Der eigentliche lange Backup wird dadurch nicht angestossen - aber sämtliche Optionsprüfungen wie auch das Senden der BenachrichtigungseMail. Nein  
-g Mit dieser Option wird beim Backup und Restore eine Fortschrittsanzeige angezeigt    
-G Festlegung der Sprache der Meldungen. Mögliche Sprachen sind DE (Deutsch) und EN (English). Interessenten, die die Meldungen in andere Sprachen übersetzen wollen können sich gerne melden

Eingestellte Systemsprache auf der Raspi.

EN (Englisch) wird benutzt falls die Systemsprache nicht unterstützt wird

DEFAULT_

LANGUAGE 

 -h Ausgabe der Aufrufsyntax mit seinen Parametern  Nein  
--ignoreAdditionalPartitions Ab Version 0.6.5 erlaubt raspiBackup mit dieser Option Systeme mit mehr als zwei Partitionen auf der SD Karte zu haben wenn tar oder rsync Backup genutzt wird. Allerdings werden nur die ersten beiden Paritionen, /boot und / gesichert und wiederhergestellt. Achtung: Alle anderen Partitionen werden ignoriert. Nein

 DEFAULT_

IGNORE_

ADDITIONAL_

PARTITIONS

 -k

 Anzahl der Backups, die pro Backuptyp vorzuhalten sind sofern es nicht durch folgende Option überschrieben wird. D.h. es werden 3 dd, 3 tar und 3 rsync Backups vorgehalten.

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

 3

DEFAULT_

KEEPBACKUPS

--keep_<type>

 

Ab Version 0.6.4.3: 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.

Parameter für Option -k

DEFAULT_

KEEPBACKUPS_

{DD|DDZ|TAR|

TGZ|RSYNC}

 -l

Log level definiert ob ein Debuglog erstellt wird:

- off  -> Es wird kein Debuglog erstellt

- debug -> Es wird ein Debuglog erstellt

Achtung: Die Logausgabe kann in manchen Fällen sensitive Informationen enthalten (Z.B. externe statische IP Adressen, eMailAdressen, Kennwörter für mount Befehle oder email Server, ...) . 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 Homeverzeichnis des Aufrufers gesichert damit es analysiert werden kann.

 on

DEFAULT_

LOG_

LEVEL

-m

Meldungsdetails 

- minimal -> Nur wichtige Meldungen werden ausgegeben

- detailed -> Viele Meldungen über den Fortschrit werden ausgegeben

minimal

DEFAULT_

MSG_

LEVEL

-M

  Mit der Option kann der Name des Backupverzeignisses modifiziert werden. Das erlaubt einen kurzlebigen nicht permananten Backup mit einem sprechenden Namen zu erstellen.

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

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

   
-n Benachrichtigung wenn eine aktuellere Scriptversion zum download verfügbar ist. Ja

DEFAULT_

NOTIFY_

UPDATE 

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

DEFAULT_

EXTENSIONS 

--notifyStart Ab der Version 0.6.5 kann man mit dieser Option einschalten dass man eine eMail oder eine Telegram Benachrichtigung bekommt wenn der Backup startet. Normalerweise wird nur am Ender das Backups eine Benachrichtigung geschickt. Nein

DEFAULT_

NOTIFY_

START

-o

Befehle um Services vor dem Backup zu stoppen damit kein inkonsistentes Backup erzeugt wird. Z.B. bei Samba "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. Alternativ kann ein Wrapperscript benutzt werden (Beispiel siehe unten). Diese Befehle sollten die exakte umgekehrte Reihenfolge haben wie die Befehle beim Parameter -a.

Beispiel:

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

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

Siehe dazu auch FAQ #1 und FAQ #18

Achtung: 

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

Keiner

 DEFAULT_

STOPSERVICES

-P Partitionsorientierter Modus. Damit kann 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. aus

DEFAULT_

PARTITIONBASED_

BACKUP

-s

email Program welches benutzt wird {mail|sendEmail|ssmtp|msmtp}. Für postfix und nullmailer muss mail benutzt 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

mail

 DEFAULT_

MAILPROGRAM

-S 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 aktuellsten Codestand ersetzt wird. Primär ist sie dafür gedacht den Codestand einer existierenden lokalen Betaversion zu aktualisieren. aus  
--smartRecycle Ab Version 0.6.5 schaltet diese Option die intelligente Rotationsstrategie ein. Details dazu sind hier beschrieben. aus

DEFAULT_

SMART_RECYCLE

--smartRecycleDryrun Ab Version 0.6.5 schaltet diese Option den Testmodus der intelligenten Rotationsstrategie ein. Details dazu sind hier beschrieben. ja

DEFAULT_

SMART_

RECYCLE_

DRYRUN

--smarteRecycleOptions Ab Version 0.6.5 definiert diese Option Parameter der intelligenten Rotationsstrategie. Details dazu sind hier beschrieben. "7 4 12 1"

DEFAULT_

SMART_

RECYCLE_

OPTIONS

--systemstatus  Ab Version 0.6.3.4 wird eine Liste der der aktiven Services und offenen Dateien in der Debugdatei erstellt    
-t

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

Achtung: Bei rsync darf keine Backuppartition mit NTFS Filesystem benutzt werden da NTFS nicht die Rechte eines ext3/4 Filesystems übernehmen kann. Dadurch können bei einem Restore nicht mehr die korrekten Rechte gesetzt werden und der Restore ist nicht nutzbar. Weiterhin werden nur bei einem ext3/4 Filesystem Hardlinks genutzt um die Datenmenge der Backups zu reduzieren.

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 Backups zusätzlich noch gezippt bzw verkleinert.

Hinweis: Beim dd Backup kann durch den Konfigurationsparameter DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY Backup-zeit und -platz gespart werden. Details zu dem Parameter siehe am Ende der Tabelle.

Siehe dazu auch FAQ #16

dd

DEFAULT_

BACKUPTYPE

--telegramToken

--telegramChatID

--telegramNotifications

Ab Version 0.6.5 können Benachrichtigungen nicht nur per eMail sondern auch per oder Telegram verschickt werden. Dazu sind folgende Konfigurationen notwendig:

Das Telegramtoken sowie die ChatID. 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.. Mit "m" werden die raspiBackup Meldungen mitgeschickt.

aus

F

DEFAULT_

TELEGRAM_

TOKEN

DEFAULT_

TELEGRAM_

CHATID

DEFAULT_

TELEGRAM_

NOTIFICATIONS

--timestamps Durch diese Option wird vor jeder Meldung ein Zeitstempel ausgegeben. Keiner

DEFAULT_

TIMESTAMPS

-T

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.

* bis Release 0.6.5.1

"1 2" ab Release 0.6.6

DEFAULT_

PARTITIONS_

TO_

BACKUP

-u
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*/*"
Die Anfuehrungszeichen 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/*
Ausserdem 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 Mode:
 
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
 
Keiner

 DEFAULT_

EXCLUDE_

LIST

-U

Die lokale raspiBackup.sh 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 Versionsnumer 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.

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

DEFAULT_

VERBOSE

-V 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)  Nein  
--version

Die Version von raspiBackup wird im folgenden Format ausgegeben:

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

Das dient im Wesentlichen dazu programmatisch die Versionsinformationen von raspiBackup abzufragen.

Aus  
-y 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. Nein

DEFAULT_

DEPLOYMENT_

HOSTS

-z Backup verkleinern mit gzip bei dd oder tar Backup Nein

DEFAULT_

ZIP_

BACKUP

  Nur im Fehlerfalle wird eine eMailbenachrichtigung gesendet. Hinweis: Sollte raspiBackup wegen aussergewöhnlicher Umstände abstürzen kann es durchaus sein dass keine eMail gesendet wird. Nein

DEFAULT_

MAIL_

ON_

ERROR_

ONLY

 

Backupoptionen, die beim rsync Backup genutzt werden. 

Benutzung auf eigene Gefahr !

--delete -aHAx

DEFAULT_

RSYNC_

BACKUP_

OPTIONS

 

Backupoptionen, die beim tar Backup genutzt werden. 

Benutzung auf eigene Gefahr !

-cpi

DEFAULT_

TAR_

BACKUP_

OPTIONS

 

Backupoptionen, die beim rsync Backup zusätzlich genutzt werden. 

Benutzung auf eigene Gefahr !

Keine

DEFAULT_

RSYNC_

BACKUP_

ADDITIONAL_

OPTIONS

 

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

Benutzung auf eigene Gefahr !

Keine

DEFAULT_

TAR_

BACKUP_

ADDITIONAL_

OPTIONS

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

DEFAULT_

LINK_

BOOTPARTITIONFILES

 

dd Backups sichern nur den von definierten Partitionen belegten Platz. Dadurch benötigt eine 32GB SD Karte, die nur eine 8GB Partition definiert hat, für den Backup nur 8GB und nicht 32GB. Dazu muss aber vermittels 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 FAQ #16

Nein

DEFAULT_

DD_

BACKUP_

SAVE_

USED_

PARTITIONS_

ONLY

  Die eMailAdresse des Versenders kann angegeben werden. root@$(hostname)

DEFAULT_

SENDER_

EMAIL

 

Backup Restore Test Reminder Intervall (Einheit: Monate)

 

6

DEFAULT_

RESTORE_

REMINDER_

INTERVAL

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

DEFAULT_

RESTORE_

REMINDER_

REPEAT

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

DEFAULT_

BEFORE_

STOPSERVICES

DEFAULT_

AFTER_

STARTSERVICES

 

Hinweis: Optionen in der Konfigdatei, die ja oder nein als Parameter benötigen müssen 0 für nein und 1 für ja sein.

Die Optionen für den Restore eines Backups sind auf dieser Seite beschrieben.
 
 

Erweiterungsmöglichkeiten von raspiBackup

Es bestehen folgende Möglichkeiten die Funktionalität des Backupscripts durch eigenen Code zu erweitern.

1) Benutzung eines selbstgeschriebenen Scriptes welches das Backupscript aufruft und Aktionen vor und nach dem Aufruf vornimmt
 

Dazu gibt es das folgende Beispielscript welches individuelle Anpassungsmöglichkeiten bietet und muss nur geringfügig an den gekennzeichneten Stellen den lokalen Gegebenheiten angepasst werden. Es enthält schon Code, der automatisch Geräte mounted und unmounted. Das Script kann hier runtergeladen werden.

Voraussetzung ist dass der Mountpoint in der /etc/fstab bereits definiert wurde. Anschliessend muss das Script noch an ein paar Stellen den jeweiligen lokalen Gegebenheiten mit einem Editor angepasst werden und dann aktiviert werden mit

sudo mv raspiBackupWrapper.sh /usr/local/bin
sudo chmod +x /usr/local/bin/raspiBackupWrapper.sh

 und dann ist raspiBackupWrapper.sh anstelle von raspiBackup.sh in der Crontab aufzurufen. Der Quellcode vom Wrapperscript findet sich auch auf github und kann durch einen Pull Request erweitert werden.

2) Benutzung von Plugins in die eigene Scripts eingehängt werden

Vor und nach dem eigentlichen Backup können Scripte asl Plugins eingehängt werden. Details dazu finden sich in der Detailbeschreibung zu Plugins

 

Restore

Ein Restore benötigt ein Linuxsystem. Windowsbenutzer oder Macbenutzer können dafür einfach die Raspberry selbst benutzen. Dafür muss nur eine SD Karte mit einem Raspbian gestartet werden, ein SD Kartenleser mit der neuen SD Karte die das Restore erhalten soll angeschlossen werden, der Backup entweder per USB oder Netzwerk gemounted werden und raspiBackup zum Restore gestartet werden.

Das dd Backup kann man auch unter Windows zurückspielen. Weiterhin kann das Backupscript kann auch genutzt werden, um SD Karten zu kopieren: Es wird ein Backup erstellt und dann auf einer anderen SD Karte restored.

Die genaue Aufrufsyntax für den Restore ist hier zu finden.

  

Fehlermeldungen und -suche

 
Die Fehlermeldungen sind i.d.Regel selbsterklärend. Informationsmeldungen haben eine Nummer, die mit I endet. Warnungsmeldungen enden mit W und Fehlermeldungen enden mit E. Eine Liste der am häufigsten auftretenden Fehlermeldungen mit weiteren detailierten Informationen findet sich hier.

Es kann aber vorkommen dass raspiBackup.sh nicht korrekt läuft und Fehlernachrichten schreibt. Das liegt zu 90% Prozent an fehlerhaften Konfigurationen oder Parametrisierung. Die Fehlermeldungen sollten auf die konkrete Ursache hinweisen. Falls nicht helfen folgende Massnahmen den Fehler genauer zu lokalisieren:
 
1) Start von raspiBackup in der Befehlszeile und nicht in der crontab um Fehlkonfigurationen in der Crontab zu eliminieren
2) Es wird eine Logdatei raspiBackup.log bei jedem Lauf im Backupverzeichnis erzeugt mit einer Menge detailierte Informationen und man kann man in der Logdatei nach Fehlermeldungen und -ursachen suchen die helfen den Fehler zu lokalisieren. Falls der 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.
3) 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 wie Probleme berichtet werden können.

 

 

Backupmethoden

Es gibt verschiedene Backupmethoden und eine jede hat ihre Vor- und Nachteile. Anbei eine Auflistung eben dieser für die verschiedenen unterstützten Backuptypen. Es können auch unterschiedliche Backupmethoden kombiniert werden. Sämtliche Backupmethoden können mit raspiBackup vollständig wiederhergestellt werden.
 
Ein dd Backup erstellt ein in sich konsistentes binäres Abbild der SD Karte. Dabei wird immer die ganze SD Karte gelesen und gesichert. Das bedeutet dass auch Daten gesichert werden, die sich nicht geändert haben. Auch bedeutet es, dass zum Restore die SD Karte wieder wenigstens so gross sein muss wie die Original SD Karte. Es wird keine Parition irgendwie in der Größe angepasst. Diese Methode belastet die SD Karte sehr stark. Allerdings kann ein dd Backup unter Windows mit disk32imager wiederhergestellt werden.
 
Ein ddz Backup sichert die gesamte SD Karte, wie ein dd Backup. Diese Methode belastet die CPU stark da die Datenmenge reduziert wird. (Es ist ein dd Backup mit eingeschaltetem Zippen mit -z). Ein Restore mit dem win32diskimager ist nicht möglich.
 
Ein tar Backup sichert die gesamte SD Karte, wobei allerdings das Backup nicht so gross ist wie bei einem dd Backup da nur die Daten gesichert werden, die tatsächlich existieren. Deshalb kann auch ein tar Backup auf eine SD Karte restored werden, die kleiner ist als die original SD Karte - sofern die gesicherten Daten auf die neue SD Karte passen.
 
Ein tgz Backup sichert die gesamte SD Karte, 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 schon einmal ein initiales Backup erstellt wurde.
 
  Vollbackup Backupzeit Backupgröße  Datenkompression CPU belastet Karte belastet Selektiver Restore möglich
Dateisystem
dd  ja lang gross 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

mittel ohne Hardlinks

klein mit Hardlinks

mittel ohne Hardlinks

nein nein kaum ja ext3/ext4
 

 

decisiontree de.dia

Vergleich partitionsorientierter Backup und normaler Backup

Es existieren zwei Backupmodi:

1) Normaler Backup

In diesem Modus werden die ersten zwei Partitionen (die Bootpartition und die Rootpartition) der SD Karte gesichert. Ausserdem wird beim tar und rsync Backup auch eine externe Rootpartition, d.h. eine auf einen USB Stick oder USB Platte ausgelagerte Rootpartition, gesichert. Mit dem dd Backup kann auch die gesamte SD Karte gesichert werden. Dieses kann man benutzen um z.B. NOOBS Images zu sichern. Falls die Ziel SD Karte beim Restore größer ist als die Quell SD Karte wird automatisch die zweite Partition entsprechend erweitert.

2) Partitionsorientierter Backup

In diesem Modus wird jede auf der SD Karte befindliche oder eine bestimmte Anzahl von Partitionen als tar oder rsync gesichert. Dabei ist die Anzahl der Partitionen beliebig. Falls die Ziel SD Karte beim Restore größer ist als die Quell SD Karte wird der zusätzliche Platz nicht benutzt. 

 

Backupverzeichnisstruktur (Normaler Backup)

Jeder Backuplauf erstellt im Backupverzeichnis ein Unterverzeichnis welches folgendes Format hat: <hostname>. Darunter wird ein weiteres Verzeichnis <hostname>-<backuptyp>-<backupdatum> erstellt. Wenn man die Option -M benutzt sieht der Unterordner wie folgt aus: <hostname>-<-M parameter> und darunter wird dann das weitere Verzeichnis <hostname>-<backuptyp>-<backupdatum> erstellt.

Beispiele: Die Raspberry hat den Hostnamen raspberrypi und es wird ein dd Backup am 15.04.2016 um 22:29:00 erstellt. Dann wird ein Verzeichnis raspberrypi erstellt sowie ein Unterverzeichnis raspberrypi-dd-backup-20160415-222900. Gibt man als Parameter für die Option -M "Hello world" mit wird das Verzeichnis raspberrypi-Hello_world sowie das Unterverzeichnis raspberrypi-dd-backup-20160415-222900 erstellt.

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 drei bzw fünf weitere Dateien immer zum eigentlichen Backup erstellt und sind notwendig für den Restore wenn es kein dd Backup ist:

  1. .img - Bootpartition der SD Karte
  2. .mbr - Master Boot Record der SD Karte
  3. .sfdisk - Partitionslayout der SD Karte - Ausgabe des sfdisk Befehls
  4. .blkid - (Partitionsorientierter Modus) - Ausgabe des blkid Befehls
  5. .parted - (Partitionsorientierter Modus) - Ausgabe des parted Befehls

root@jessie:/mnt/backup/raspberrypi# tree -L 2
.
├── raspberrypi-dd-backup-20160415-222900
│   └── raspberrypi-dd-backup-20160415-222900.img
├── raspberrypi-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-tar-backup-20160415-204305
    ├── raspberrypi-backup.img
    ├── raspberrypi-backup.mbr
    ├── raspberrypi-backup.sfdisk
    ── raspberrypi-tar-backup-20160415-204305.tar
    ── raspiBackup.log
    ── raspiBackup.msg

 

Backupverzeichnisstruktur (Partitionsorientierter Backup)

 

root@buster:/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

 

Haftungsausschluss

Das Backup- und Restorescript 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.

 

Updatestrategie

Vor 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 runterladen und aktivieren. Die aktuelle Version wird dabei gesichert und mit dem Parameter -V kann jederzeit wieder die vorherige Version aktiviert werden. 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 regression getestet. Details zum Regressiontest finden sich hier.

 

Spenden

Details dazu siehe hier

 

Weitere Seiten zu raspiBackup

Häufig gestellte Fragen (FAQ)

Versionshistorie von raspiBackup.sh

Sicherung des Backups von raspiBackup.sh auf einer Synology

Alle Artikel zu raspiBackup auf dieser Webseite

 

Hilfreiche Links zum Thema Backup

Shrinking images on Linux

rpi-clone: A shell script to clone a running Raspberry Pi SD card to a USB mounted SD card

sysmatt: Backup, Restore, Customize and Clone your Raspberry Pi SD Cards

Automatic RPi Image Downsizer

 

Weitere Backuptools fuer die Raspberry

rpi-clone: Sicherung einer Raspberry per rsync (Englisch)

piclone: Klonen einer SD Karte per cp. shell Script und UI im Raspbian enthalten

Automating backups on a Raspberry Pi NAS: Erstellen und Vorhalten von 7 täglichen, 4 wöchentlichen, 12 monatlichen und 5 jaehrlichen Backups. Diese Funktion ist per Helperscript mit raspiBackup verfuegbar. (Englisch)

borg: Sehr mächtiges Backuptool (Englisch)

urbackup




 

 

 

 

Kommentar schreiben

*** Hinweis ***

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

    Kommentare   
    #1219 framp 2021-04-05 13:34
    Moin Oliver,

    systemd Umstellung ist schon laenger pending (HTTPS://github.com/framps/raspiBackup/issues/286). Ich habe das jetzt aus dem Backlog geholt und gehe es fuer die naechste Release an.

    Cu framp
    Zitieren
    #1218 Oliver 2021-04-05 12:40
    Moin,

    habe die aktuelle Version auf meinem neuesten PiHole+Unifi-RPi4 installiert. Funktioniert prima,

    jedoch verwende ich als Timer nicht mehr das "veraltete" Cron, sondern habe hierfür einen Timer unter "Systemd" eingerichtet. Da habe ich alles besser im Überblick,

    Justmy2cents

    Dennoch vielen lieben Dank für das tolle Script !
    Schöne Restostern

    Oliver
    Zitieren
    #1217 framp 2021-03-27 20:57
    zitiere Umzugsunternehmen:

    3) Log-Level: Ich nehme an "DEFAULT_VERBOSE=1" in der Config ist das äquivalent zu "-v"?

    Ja.

    Bzgl der Version bist Du nicht ganz auf dem Letzten. Aber der von mir erwaehnte Bug ist da nicht mehr drin :-)

    Vermutlich liegt es an -v ... aber dann hast Du irre viele Dateien. Anyhow - wie Du schreibst - das passiert nur beim ersten Backup. Danach nicht mehr.

    Cu framp
    Zitieren
    #1216 Umzugsunternehmen 2021-03-27 19:45
    Nachtrag/Feedback:
    Das Full-Backup von ca. 80 GB dauerte - aufgrund der neuen performanten Konstellation mit der SSD - gerade einmal 35 Minuten (auf eine wohl gemerkt langsame HDD).

    Das abschließende "Masquerading" allerdings... dauerte knapp 2 Tage (!). Log-Datei hat 63 MB und 807.000 Zeilen...

    Ich finde gut, dass das Masquerading erst ganz am Ende stattfindet und zu dem Zeitpunkt bereits wieder alles läuft (Dienste gestartet etc.), allerdings kann es schonmal zu Überschneidungen kommen (nächstes raspiBackup startet evtl. schon) und das Zeilenweise sed scheint offensichtlich nicht sonderlich effizient zu sein.

    Eine Lösung hierfür habe ich nicht (außer das Masquerading per Config komplett abzuschalten, aber das hat schon seinen Sinn und man weiß ja vorher nicht, ob man nicht mal Log-Daten für Support-Fälle raus geben muss), wollte nur mal mit blanken Zahlen darauf hinweisen :-) zitiere framp:
    Moin Umzugsunternehmen,

    vielen Dank fuer dein Feedback. Nur durch solches Nutzerfeedback war und bin ich nur inder Lage raspiBackup zu verbessern.

    Das dass Masquerading so extrem lange dauert hat mir bislang noch niemand gemeldet. Allerdings gab es mal einen Bug in dieser Ecke der aber in der aktuellen Version gefixed ist. Mit sudo raspiBackup.sh -U -S holst Du Dir den letzten Stand.

    Was natuerlich auch noch sein kann ... allerdings 2 Tage kann ich mir trotzdem nicht erklaeren. Wenn Du die Option -v benutzt schreibt das Debugtool jede Datei raus die gesichert wird und wenn es viele sind wird die Logdatei entsprechend gross. Beim Maskieren wird 13 mal die Logdatei von vorne bis hinten gelesen. Ich werde mal versuchen diese Anzahl zu reduzieren.

    Bei mir dauert das Maskieren 1 Sekunde und die Logdatei is 91k gross.

    Pruefe mal ob Du die letzte Version nutzt und update sie. Ausserdem lass -v weg. Das braucht man nur zum Debuggen.

    Das Masqkieren habe ich ziemlich spaet eingebaut aber da ich doch immer wieder sensitive Informationen in ihnen fand und die Logs oft im Netzt irgendwo abgelegt wurden. Auch sollten sie maskiert sein wenn das Log mir direkt zugeschickt wird.

    raspiBackup : Version: 0.6.6 Date: 2021-02-26 16:16:38 Sha: 83ecd03

    Ich hoffe dadurch verschwindet Dein Problem denn 2 Tage ist nicht OK. Falls es nicht verschwindet moechte ich Dich bitten mit die Logdatei gezipped an meine eMail (siehe Kontakt Seite) zu schicken damit ich sie mir ansehen kann.

    Cu framp


    Hi framp, in aller Kürze:

    1) Vorweg zur Einordnung: Allzu tragisch ist es für mich nicht, da das Full-Backup ja i. d. R. nur 1x erstellt wird, danach geht´s in meiner Config dank rsync mit dem klugen inode-Link-System-Dingens differentiell eh sehr schnell und es ist mir nie aufgefallen dass raspiBackup noch länger arbeitet nachdem der Abschluss längst gemeldet (mail/Post-Skript) und die Dienste wieder gestartet wurden.

    2) raspiBackup-Version: "Version: 0.6.6 CommitSHA: 7989828 CommitDate: 2020-12-16 CommitTime: 09:58:36". "03-27-2021 19:42:51 --- RBK0073I: /usr/local/bin/raspiBackup.sh bereits auf der aktuellen Version 0.6.6."

    3) Log-Level: Ich nehme an "DEFAULT_VERBOSE=1" in der Config ist das äquivalent zu "-v"? Das ist auf 1 gesetzt, wohl von früheren Debugging-Aktionen.
    Ja, ich habe jede Datei die rsync anpackt im Log-File bzw. zur raspiBackup-Ausführung auf der Konsole, ist manchmal ganz hilfreich. Habe es jetzt dennoch deaktiviert (=0).
    Zitieren
    #1215 framp 2021-03-27 17:40
    Moin Umzugsunternehmen,

    vielen Dank fuer dein Feedback. Nur durch solches Nutzerfeedback war und bin ich nur inder Lage raspiBackup zu verbessern.

    Das dass Masquerading so extrem lange dauert hat mir bislang noch niemand gemeldet. Allerdings gab es mal einen Bug in dieser Ecke der aber in der aktuellen Version gefixed ist. Mit sudo raspiBackup.sh -U -S holst Du Dir den letzten Stand.

    Was natuerlich auch noch sein kann ... allerdings 2 Tage kann ich mir trotzdem nicht erklaeren. Wenn Du die Option -v benutzt schreibt das Debugtool jede Datei raus die gesichert wird und wenn es viele sind wird die Logdatei entsprechend gross. Beim Maskieren wird 13 mal die Logdatei von vorne bis hinten gelesen. Ich werde mal versuchen diese Anzahl zu reduzieren.

    Bei mir dauert das Maskieren 1 Sekunde und die Logdatei is 91k gross.

    Pruefe mal ob Du die letzte Version nutzt und update sie. Ausserdem lass -v weg. Das braucht man nur zum Debuggen.

    Das Masqkieren habe ich ziemlich spaet eingebaut aber da ich doch immer wieder sensitive Informationen in ihnen fand und die Logs oft im Netzt irgendwo abgelegt wurden. Auch sollten sie maskiert sein wenn das Log mir direkt zugeschickt wird.

    raspiBackup : Version: 0.6.6 Date: 2021-02-26 16:16:38 Sha: 83ecd03

    Ich hoffe dadurch verschwindet Dein Problem denn 2 Tage ist nicht OK. Falls es nicht verschwindet moechte ich Dich bitten mit die Logdatei gezipped an meine eMail (siehe Kontakt Seite) zu schicken damit ich sie mir ansehen kann.

    Cu framp
    Zitieren
    #1214 Umzugsunternehmen 2021-03-27 15:07
    Nachtrag/Feedback:
    Das Full-Backup von ca. 80 GB dauerte - aufgrund der neuen performanten Konstellation mit der SSD - gerade einmal 35 Minuten (auf eine wohl gemerkt langsame HDD).

    Das abschließende "Masquerading" allerdings... dauerte knapp 2 Tage (!). Log-Datei hat 63 MB und 807.000 Zeilen...

    Ich finde gut, dass das Masquerading erst ganz am Ende stattfindet und zu dem Zeitpunkt bereits wieder alles läuft (Dienste gestartet etc.), allerdings kann es schonmal zu Überschneidungen kommen (nächstes raspiBackup startet evtl. schon) und das Zeilenweise sed scheint offensichtlich nicht sonderlich effizient zu sein.

    Eine Lösung hierfür habe ich nicht (außer das Masquerading per Config komplett abzuschalten, aber das hat schon seinen Sinn und man weiß ja vorher nicht, ob man nicht mal Log-Daten für Support-Fälle raus geben muss), wollte nur mal mit blanken Zahlen darauf hinweisen :-)
    Zitieren
    #1213 framp 2021-03-21 19:36
    So wuerde ich es auch machen ;-)
    Zitieren
    #1212 Umzugsunternehmen 2021-03-21 18:19
    zitiere framp:
    Das ist schwer fuer mich zu beantworten. Ich weiss nicht was Du genau - die Betonung liegt auf genau :-) - beim Clonen gemacht hast. Auch weiss ich nicht welche Backumethode Du benutzt hast.

    Auch wenn ich die Informationen von Dir bekomme - nach so einer grossen Umstellung solltest Du einen Restoretest vornehmen um zu verifizieren dass Dein Backup OK ist.

    Dein Usecase ist nicht von mir getestet.

    Cu framp


    Hi framp,

    wie gesagt: balenaEtcher, Cloning. 1:1. Genauer geht es nicht ;-)

    BU-Methode ist rsync.

    Ich denke FÜR´S ERSTE zur Sicherheit einfach eine neue Backup-Serie anzufangen könnte nicht schaden. Ich werde dazu den Ordner-Namen des Backup-Targets ändern ("Hostname_OLD") sodass raspiBackup im Ziel-Verzeichnis eine neue Backup-Serie ("Hostname") startet. Sicher ist sicher (und allemal schneller als ein Restore-Test, um den man natürlich so oder so nicht herum kommt) :-)
    Zitieren
    #1211 framp 2021-03-21 00:19
    zitiere Umzugsunternehmen:
    Hi,
    Frage: hat die geänderte Hardware der Backup-Quelle (SSD anstatt zuvor SD) keinerlei Auswirkungen auf raspiBackup und einen möglichen Restore?

    Das ist schwer fuer mich zu beantworten. Ich weiss nicht was Du genau - die Betonung liegt auf genau :-) - beim Clonen gemacht hast. Auch weiss ich nicht welche Backumethode Du benutzt hast.

    Auch wenn ich die Informationen von Dir bekomme - nach so einer grossen Umstellung solltest Du einen Restoretest vornehmen um zu verifizieren dass Dein Backup OK ist.

    Dein Usecase ist nicht von mir getestet.

    Cu framp
    Zitieren
    #1210 Umzugsunternehmen 2021-03-20 23:34
    Hi,

    die Migration ist abgeschlossen, wurde allerdings als KLON (SD-Karte auf SSD) via balenaEtcher durchgeführt mit anschliessendem
    1) Anpassen der /boot/cmdline.txt
    2) Anpassen der /etc/fstab im Root-Filesystem
    3) Expand des Root-Filesystems via raspi-config (SSD war größer als Quelle/SD-Karte)

    Soweit so gut. Durch das Klonen sind die UUIDs auch identisch geblieben. Nun habe ich ein raspiBackup durchgeführt und festgestellt, dass die bestehende Backup-Serie fortgesetzt wurde. Soweit so gut.

    Frage: hat die geänderte Hardware der Backup-Quelle (SSD anstatt zuvor SD) keinerlei Auswirkungen auf raspiBackup und einen möglichen Restore?

    Ich war einfach positiv überrascht dass raspiBackup die neue SSD gar nicht interessiert. Vermutlich weil sich aus Partitions- und Quell-Medium-Sicht auch nicht wirklich was verändert hat (mmc... wurde zu sd... und das Root-Filesystem/Partition ist größer, sonst alles beim alten).
    Zitieren
    #1209 framp 2021-03-13 10:58
    Moin Heinzelmann,

    nein, der Text ist fix. ich nutze den eMailSender um zu sehen von welchem Rechner die eMail kam. Standard ist root@$(hostname) aber den Namen kannst Du auch konfigurieren.(Option DEFAULT_SENDER_EMAIL)

    Cu framp
    Zitieren
    #1208 Heizelmann 2021-03-13 10:38
    Wie kann ich der E-Mail einen eigenen Subject- oder Messagetext hinzufügen? Ich möchte auf einen Blick unterscheiden können, von welchem Rechner das Backup beendet wurde.
    Zitieren
    #1207 framp 2021-03-05 10:42
    zitiere Musikliebhaber:


    sudo bash raspiBackup.sh -u "/--exclude=/home/pi/Music/*" /backup/

    sudo bash raspiBackup.sh -u "/-exclude=/home/pi/Music/*" /backup/


    Es muss
    sudo bash raspiBackup.sh -u "\--exclude=/home/pi/Music/*" /backup/
    heissen. Backslash - nicht Forwardslash :-)

    Ansonsten kannst Du die Excludes auch in die Konfig schreiben. Da brauchst Du keinen Backslash benutzen.

    Cu framp
    Zitieren
    #1206 Musikliebhaber 2021-03-05 10:37
    Mein ursächlicher Aufruf war
    sudo bash raspiBackup.sh -u "--exclude=/home/pi/Music/*" /backup/
    welcher genau wie der vorletzte Post mit dem ungelösten Fehler
    ??? RBK0090E: Option -u erwartet einen Parameter. Falls der Parameter mit '-' beginnt beginne stattdessen mit '\-'.
    abbricht.

    Die Versuche mit der im Fehlerkommentar angegebenen Lösung ergeben nur
    sudo bash raspiBackup.sh -u "/--exclude=/home/pi/Music/*" /backup/
    RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld.
    rsync: change_dir "/--exclude=/home/pi/Music" failed: No such file or directory (2)

    sudo bash raspiBackup.sh -u "/-exclude=/home/pi/Music/*" /backup/
    RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld.
    rsync: change_dir "/-exclude=/home/pi/Music" failed: No such file or directory (2)

    Schade irgendwie. Wer ich mich wohl in rsync einarbeiten müssen. Dacht eigentlich nicht das Rad nochmal erfinden zu müssen, sondern ein vorhandens benutzen zu können.
    Zitieren
    #1205 framp 2021-03-05 10:03
    Moin Musikliebhaber,

    es muss "--exclude" benutzt werden denn die Anwqeisungen werden dirket an tar bzw rsync weitergegeben und muessen deren Syntax und Semantik gehorchen. Welche Fehlermeldung bekommst Du denn?

    Ansonsten sieh mal hier HTTPS://forum-raspberrypi.de/forum/thread/30278-raspibackup-sh-dateipfad-ausschlie%C3%9Fen/ nach. Dort wurde das Thema schon mal behandelt. Ansonsten lies bitte FAQ48 denn abgesehen von der Fehlermeldung hat Dein Problem nur marginal mit raspiBackup zu tun sondern ist eine Frage zu rsync bzw tar Exclude Listen :-)

    Cu framp
    Zitieren
    #1204 Musikliebhaber 2021-03-05 06:45
    Guten Morgen, ich hoffe jemand kann mir helfen.
    Backups ohne weitere Optionen machen und Restoren kann ich. Jetzt klappt das mit dem Excluden aber nicht so ganz.
    Ich möchte den Ordern /home/pi/Music und all seine Unterordner vom Backup excluden. Es excluded Music auch, aber dafür werden dann alle Unterordner auf Root-Ebene gebackuped. Wenn ich die Unterordner exclude, gehen deren Unteroder auf die Root-Ebene.
    Mein Funktionsaufruf sieht wie folgt aus
    sudo bash raspiBackup.sh -u "/home/pi/Music/* /home/pi/Music/Musik/* /home/pi/Music/Hörbücher/* /home/pi/Music/Non-Fiktion/*" /backup/
    Da überall --exclude= reinzuschreiben wie in der Optionenliste bringt nur eine Fehlermeldung.
    Grüße
    Zitieren
    #1203 framp 2021-02-06 00:04
    zitiere Umzugsunternehmen:

    Ich weiß nicht ob der Pi 4 so „klug“ ist und automatisch wenn er keine SD-Karte findet die USB-Ports auf ein bootfähiges Medium abprüft.


    Doch. Mit der Pi4 braucht man auch nichts Spezielles mehr tun. Bei der Raspi3 was noch gewisse Vorarbeit notwendig.

    Cu framp
    Zitieren
    #1202 Umzugsunternehmen 2021-02-05 23:55
    zitiere framp:
    Nein. Es gibt zwei Backupmodi. Den normalen der der Default ist und den partitionsorientierte Modus der mit der Option -P eingeschaltet wird. dd ist der Backuptyp. Den wuerde ich aber bei einer SSD moeglichst nicht nutzen denn dabei wird immer die gesamte SSD (incl dem nicht verwnedeten Platz) gesichert - ausser man benutzt pishrink und ein Warapperscript. Bei einer SSD ist rsync der empfohlene Backuptyp.

    Cu framp


    OK Danke. Da ich schon ein Ryan’s-Backup habe werde ich einfach noch ein letztes inkrem. erstellen und davon restoren (Neuerstellung eines Full Backups dauert zu lange).

    Mit Anleitung meinte ich eher ob bzw. was noch bezüglich des USB-Boot im Bootloader ggf. ein- oder umzustellen ist. Ich weiß nicht ob der Pi 4 so „klug“ ist und automatisch wenn er keine SD-Karte findet die USB-Ports auf ein bootfähiges Medium abprüft.

    raspiBackup-seitig weiß ich soweit Bescheid. Danke.
    Zitieren
    #1201 framp 2021-02-04 14:04
    Nein. Es gibt zwei Backupmodi. Den normalen der der Default ist und den partitionsorientierte Modus der mit der Option -P eingeschaltet wird. dd ist der Backuptyp. Den wuerde ich aber bei einer SSD moeglichst nicht nutzen denn dabei wird immer die gesamte SSD (incl dem nicht verwnedeten Platz) gesichert - ausser man benutzt pishrink und ein Warapperscript. Bei einer SSD ist rsync der empfohlene Backuptyp.

    Cu framp
    Zitieren
    #1200 Umzugsunternehmen 2021-02-04 14:01
    zitiere framp:
    zu 1) Ja. Nimm dazu aber den normalen Backupmodus.


    Ist damit als Backup-Typ DD gemeint??
    Zitieren
    #1199 framp 2021-02-04 13:45
    Moin,

    zu 1) Ja. Nimm dazu aber den normalen Backupmodus. Alignment ist nicht notwendig. Nur solltest Du nach dem Restore auf die SSD die Partitionsdefinitionen fuer /root in /etc/fstab fuer SSD updaten.

    zu 2) Ja, es wird die gesamte SSD gesichert. Wenn Du den rsync oder tar Backuptyp nimmst werden nur die existierenden Daten gesichert bzw beim rsync nur die neuen bzw geaenderten. An der Bootkonfiguration ist nichts anzupassen.

    Eigentlich brauchst Du keine Anleitung. Einfach Backup von der SD Karte erstellen und restore auf SSD und anpassen an SSD in /etc/fstab.

    Falls Du noch weiter Tipps suchst oder auch allgemeine Fragen zu Linux empfehle ich FAQ38 zu lesen ;-) Dort gibt es auch ein Unterforum Backup wo Du sicherlich auch Tipps bekommst von raspiBackup Nutzern wenn Du danach fragst.

    Cu framp
    Zitieren
    #1198 Umzugsunternehmen 2021-02-04 00:54
    Hallo,

    ich möchte nach langer Zeit und einigen toten SD-Karten das System auf eine SSD (USB-Boot) umziehen, komplett ohne SD-Karte, geeigneter USB 3.0-zu-SATA-Adapter liegt vor. Fragen hierzu:

    1) Ließe sich der Umzug anhand eines raspiBackup-Restores auf die SSD problemlos realisieren? Gibt es bezüglich der Parameter etwas zu berücksichtigen? Partition Alignment (für Performance bei SSDs ja ein Thema) ein Problem oder etwas wo Hand angelegt werden müsste bei/nach dem Restore?

    2) Was gilt es bei künftigen regulären raspiBackups zu beachten? (Wird automatisch eine neue Backup-Serie angelegt, wird die komplette SSD gesichert wie zuvor die gesamte SD-Karte)?

    Ich hab noch keinen so rechten Plan wie ich den Umzug mache und was es am Pi (4) noch umzustellen gilt (vermutlich Boot-Konfiguration anpassen). Ich suche noch eine gute Anleitung hierfür, kann mir für die Migration aber gut raspiBackup als Tool vorstellen, wenn auch mit entsprechender Downtime verbunden.

    Ganz allgemein also: Was sollte ich bezüglich raspiBackup bedenken, was ändert sich ggf. noch?

    Danke für Start-/Migrationshilfe bzw. allgemein Tipps und Erfahrungen hierzu.
    Zitieren
    #1197 framp 2021-02-03 14:46
    Moin Martin,

    zu 1) jein. Im Prinzip kannst Du alle Methoden nehmen. Bei dd ist aber noch etwas Programmieraufwand erforderlich (Einbinden von pishrink). Es gibt im git dazu ein kleines Beispielscript.Verschluesselung wird nicht von raspiBackup unterstuetzt. Dazu muss man sich ein Wrapperscript schreiben welches nach dem Backup das Backup verschluesselt. Selektive Wiederherstellung geht auch mit allen Methoden. Am einfachsten geht es bei rsync.

    zu 2) Nein. Musst Du selbst programmieren. Ein Hinweis: Nur bei rsync wird incrementell gesichert. Bei allen anderen ist es immer ein Fullbackup - mit der entsprechenden Backupzeit- und Uploadverlaengerung.

    zu 3) dd und tar sind immer Fullbackups. rsync sind bei ext3/4 Nutzung inkrementelle Backups. Bei anderen Dateisystem ist es aber auch immer ein Fullbackup.
    Kombinieren kann man das indem man zwei verschiedene raspiBackupkonfigurationen nutzt und einmal pro Woche ein tar Backup erstellt und taeglich ein rsync Backup.

    Bislang kenne ich niemanden der einen Onlinespeicher fuer Backups nutzt. Ich denke es liegt primaer daran dass der Backup dadurch sehr lange dauert und i.d.R. moechte man ein Produktivsystem ja wieder sehr schnell aktiv haben.

    Cu framp
    Zitieren
    #1196 Martin 2021-02-03 13:37
    ich habe mir die Feature-Liste durchgelesen und werde mir das Tool heute Abend einmal anschauen.

    Ein paar grundsätzliche Dinge vorab:
    1) ich bin auf der Suche nach einem Sicherungssystem das a) kleine Backupgröße, b) Datenkompression, c) Verschlüsselung und d) selektive Wiederherstellung bietet.
    Da bleibt mir laut obiger Tabelle wohl nur tgz, oder?
    wie muss ich mir den Unterschied in der Backup-Größe zwischen dd = kleiner und tgz = mittel vorstellen?

    2) Kann ich das Backup direkt während der Erstellung verschlüsseln, also dass auf dem Backupspeicher nie die unverschlüsselten Daten abgelegt werden, auch nicht temporär?
    (Grund = Nutzung Onlinespeicher als Backupmedium)

    3) Da es aus der Beschreibung nicht richtig hervorgeht, kann ich inkrementelle Backups erstellen und Full-Backups erstellen?
    Also sowas wie alle 30 Tage ein Full-Backup, dazwischen nur inkrementelle Backups?

    Vielen Dank schonmal für die Hilfe.
    Zitieren
    #1195 framp 2021-01-04 21:01
    Moin Stefan,

    ich benutze davfs2 nicht fuer meinen Backup. Ich empfehle Dir mal FAQ42 zu lesen (HTTPS://www.linux-tips-and-tricks.de/de/faq/#a47). Ich denke dort wirst Du eher eine Antwort bekommen. Da es allerdings weniger eine spezielle Raspi Frage ist werden sicherlich auch Linux Foren helfen.

    Cu framp
    Zitieren
    #1194 Stefan 2021-01-04 19:04
    Es ist einfach zum Haare ausreißen.

    Ich möchte meinen Raspberry Pi via WebDav sichern. Dazu mounte ich mein Remote-Verzeichnis auf einem NextCloud mit davfs2. Soweit so gut.

    Bei einem manuellen Anlegen und Ändern von lokalen Dateien sehe ich die Änderungen mehr oder weniger sofort auch auf der Nextcloud-Instanz.

    Startet ich nun das Backup via raspiBackup bricht es nach einer Zeit mit "not enough disk space" ab. Anstatt dass hier nämlich Daten auf das WebDav-Laufwerk übertragen werden, cached davfs2 die Daten auf der SD-Karte bis es merkt, dass dort kein Platz mehr ist. Das Backup bricht im Anschluss ab.

    Auch das Setzen von cache_size auf 0 und 1 hat nichts gebacht. Was macht man nun? Es gibt doch Leute die das erfolgreich einsetzen.

    Ist davfs2 einfach ungeeignet? Wie kriege ich die Daten denn anders auf die Nextcloud-Instanz?
    Zitieren
    #1193 framp 2020-09-02 15:15
    Moin Carsten,

    vielen Dank fuer den Hinweis. Ich habe das gleich korrigiert :-)

    Cu framp
    Zitieren
    #1192 carsten 2020-09-02 13:14
    Ahoi

    Da ist ein Typo bei den Telegram-Einstellungen:
    Mit "M" werden die raspiBackup Meldungen mitgeschickt. Mit "m" werden die raspiBackup Meldungen als Datei geschickt.

    Das aktuelle backup raspiBackup.sh V0.6.5.1 (a056338) verhält sich genau anders herum:
    Mit "m" werden die raspiBackup Meldungen mitgeschickt. Mit "M" werden die raspiBackup Meldungen als Datei geschickt.

    Gruss
    Carsten
    Zitieren
    #1191 framp 2020-08-03 20:46
    Moin Markus,

    raspiBackup unterstuetzt leider keine rsync Server. Ich hatte mir das mal angesehen aber das erfordert sehr viele Aenderungen in raspiBackup und es gibt kaum Benutzer die einen rsync Server betreiben.

    Wenn Du willst kannst Du ja mal einen Feature request dazu im github aufmachen. Wenn sich da eine signifikante Anzahl von Interessenten am rsync Server zeigt gehe ich das aber an.

    Cu framp
    Zitieren
    #1190 Markus 2020-08-03 20:36
    Ist es eigentlich auch möglich ein Backup zu einem rsync-Server zu machen?
    Würden dort auch Hardlinks funktionieren?
    Zitieren
    #1189 framp 2020-06-30 22:05
    Moin Andreas,

    vielen Dank fuer den Hinweis. Da ich reiner Linuxer bin und kein NTFS benutze bin ich auf diese Problematik nie gestossen. Aber auch sonst macht es wenig Sinn NTFS fuer das Backup zu benutzen weil dann keine Hardlinks genutzt werden koennen um die Datenmenge signifikant zu reduzieren.

    Ich nehme Deinen Punkt mal mit und baue in der naechsten Version einen Test ein ob bei rsync auf ext3/4 gesichert wird.

    Weiterhin schreibe ich im benutzerhandbuch noch bei der Option -t und dem Parameter rsync rein dass man kein NTFS benutzen sollte.

    Cu framp
    Zitieren
    #1188 Andreas 2020-06-30 21:54
    Hallo zusammen.
    Auf der Suche nach einem zuverlässig automatisierbaren Backup für meinen Pi4 bin ich zu raspiBackup gekommen. Das Skript ist sehr vielseitig und man kann es einfach automatisieren. Klasse!
    Beim Testen des ersten Backups bin ich jedoch sogleich in eine Anfängerfalle getappt. Da ich mich nur bis etwa Seite 14 der Kommentare durchgearbeitet habe und keine Lösung fand, möchte ich meine Erfahrung hier teilen.

    Mein Problem war: Der Pi war nach restore nicht mehr nutzbar, die Benutzerrechte waren verloren gegangen.

    Zunächst habe ich ein rsync-Backup meiner USB-Festplatte (Pi4 bootet von USB und es ist keine SD-Karte eingelegt) auf eine zweite USB-Platte erstellt. Das Restore mittels einem neu aufgesetzten Pi4 auf eine leere USB-Platte klappte auch ohne Fehler.
    Der anschließende boot des wiederhergestellten Systems ging ohne Fehler (autologon zum Desktop war aktiv). Ich konnte jedoch anschließend keine sudo-Befehle mehr ausführen, weil der Benutzer sudo keine Rechte mehr hätte.

    Die Ursache war, dass meine Backup-Platte (welche das rsync-Backup beinhaltet und nun als Grundlage für den restore gedient hat) mit NTFS formatiert war --> da werden die Benutzerrechte des Ursprungsystems nicht übernommen und können somit beim restore auch nicht wieder zurück übertragen werden. Aber das merkte ich erst bein restore, also kann ich den deutlichen Hinweisen zum testen des backup und restores nur zustimmen.
    Vielleicht hilft dieser Eintrag, diesem Anfängerfehler schneller auf die Sprünge zu kommen.
    Danke nochmals für dieses tolle Skript und die genaue Dokumentation, da steckt eine Menge Arbeit drin.
    VG Andreas
    Zitieren
    #1187 framp 2020-06-30 12:53
    Moin Marcus,

    da das immer mal wieder gefragt wird habe ich gerade Letztens eine neue Seite zu dem Thema erstellt. Falls dann noch was unklar ist kamnst Du dort in einem Kommentar gezielt Dein Verständnisproblem beschreiben :-)

    Cu framp
    Zitieren
    #1186 Marcus 2020-06-30 11:17
    Hallo Framp,
    nachdem ich mir deine wunderbare Dokumentation durchgelesen habe und das Programm seit Wochen nutze, hab ich doch noch eine Frage zum rsync-Backup.
    Die Hardlinks die auf das erste größere Backup zeigen leuchten ein.
    Wenn ich nun aber ein "smartes"- 7 4 12 1 Backup fahre, löscht er am 8. Tag das erste große Backup.
    Wo zeigen die Hardlinks dann hin?
    Dies verunsichert mich.

    Danke für deine Mühe.

    Gruß
    Marcus
    Zitieren
    #1185 framp 2020-06-04 18:25
    Moin Marcus,

    mit Original beim Restore ist das Backup gemeint ;-)

    Cu framp
    Zitieren
    #1184 Marcus 2020-06-04 18:24
    Sorry framp,

    ich habe eine Frage (oder vielleicht sitz ich ja auf der Leitung):
    Bei der Option DEFAULT_UPDATE_UUIDS steht folgendes im HB:
    "Verfuegbar ab Release 0.6.5: Beim Restore werden immer die UUIDs bzw PARTUUIDs genommen die das Original hat. Mit dieser Option werden neue UUIDs und neue PARTUUIDs generiert."

    Ist das "Original" nun das Backup oder das neu zu beschreibende Medium.

    Vielen Dank

    Marcus
    Zitieren
    #1183 framp 2020-06-03 11:36
    Moin Carsten,

    vielen Dank fuer den Hinweis. Ich habe im github einen issue dazu aufgemacht HTTPS://github.com/framps/raspiBackup/issues/242

    Cu framp
    Zitieren
    #1182 Eckibrecki 2020-06-03 10:44
    Hallo framp,
    ich habe mir gestern auch mal Dein Tool zum testen runtergeladen. Sieht gut aus. Vielen Dank für Deine Mühe!

    Bei den start/stop Services ist mir eine kleine Benutzerunfreundlichkeit aufgefallen ;-)
    Ich habe u.a. 2 Services die ich stoppen und wieder starten möchte. "fhem" und "fhem.js". Wähle ich bei der Reihenfolge zuerst fhem aus, bekomme ich beim starten des Backups die Meldung ".js kann nicht gestoppt werden" (nicht die genaue Meldung aber sinngemäß; wenn Du die genaue Meldung brauchst, kann ich es nochmal nachstellen).
    Ändere ich die Reihenfolge auf "fhem.js" und dann "fhem" funktioniert es ohne Fehlermeldung.

    Evtl. ist das noch eine Kleinigkeit für das nächste Update.

    Viele Grüße
    Carsten
    Zitieren
    #1181 framp 2020-05-31 12:43
    Moin Rene,

    die Abfrage kannst Du mit der undokumentierten Option -Y deaktivieren. Das benutze ich um im Regressiontest den Restore automatisiert durchfuehren zu koennen. Im Code steht # WARNING: dangerous option !!! ... d.h. Du weisst hoffentlich was Du tust und solltest sicher sein dass der Parameter fuer -d richtig ist denn sonst loeschst Du Dir u.U. irgendeine Platte :-* Also sei bitte vorsichtig ...

    DEFAULT_YES_NO_RESTORE_DEVICE ist eine Sicherheitseinstellung fuer diese Option: Nur fuer diese Geraete greift die Option -Y. Da musst Du Dein Restoregeraet eingeben, also z.B. /dev/sda oder /dev/mmcblk1. Default ist loop da ich zum Test als Ausgabegeraet ein Loopdevice benutze und sicher sein moechte dass mir keine Platte meines Desktops by error ueberschrieben wird :-)

    Cu framp
    Zitieren
    #1180 Rene 2020-05-31 12:25
    Erstmals THX für das geniale Tool!
    Backups lassen sich erstellen und erfolgreich wiederherstellen.

    Jetzt wollte ich den Restore auch automatisieren.
    Den Restore muss man immer bestätigen.
    Ich habe in der Config-Datei den Eintrag DEFAULT_YES_NO_RESTORE_DEVICE gefunden.

    Nach meinem Verständnis kann ich damit die Sicherheitsfrage deaktivieren.

    Dieser Wert, egal ob 0 oder 1 scheint aber nicht zu greifen.
    Ich erhalte immer wieder die Sicherheitsabfrage bzgl. dem Überschreiben der Partitionen.

    Wie kann ich die Sicherheitsfrage deaktivieren?
    Zitieren
    #1179 framp 2020-05-26 20:51
    Moin Alex,

    das ist natuerlich die Alternative: Einfach wieder auf die vorherige Version mit Option -V zurueckgehen.

    Cu framp
    Zitieren
    #1178 Alex 2020-05-26 20:45
    Hallo framp,

    top,vielen Dank! :-)
    Glücklicherweise hast Du den temporären Downgrade ja sehr leicht gemacht ;-)
    Viele Grüße
    Alex
    Zitieren