Bewertung: 4 / 5

Stern aktivStern aktivStern aktivStern aktivStern inaktiv
 
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. Raspberry 3 USB Boot Images werden auch unterstützt.

 

 

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.
  • Klicke Twitter um raspiBackup auf Twitter zu folgen.
  • Klicke Kommentar um einen Kommentar zu erstellen.

 

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. 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. Aufrufparameter (alphabetisch sortiert)
  6. Aufrufparameter (thematisch sortiert)
  7. Erweiterungsmöglichkeiten
  8. Restore
  9. Fehlermeldungen und -suche
  10. Backuptypen und Entscheidungsbaum
  11. Vergleich partitionsorientierter Backup und normaler Backup
  12. Backupverzeichnisstruktur
  13. Haftungsausschluss
  14. Updatestrategie
  15. Regressiontests
  16. Weitere Seiten zu raspiBackup
  17. Häufige Fragen (FAQ) 
  18. Versionshistorie
  19. Benutzung von Synology
  20. Hilfreiche Links zum Thema BackupDefault_
  21. Versionshistorie
  22. Danksagungen
  23. Spenden
  24. 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.

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 wenn sie ohne SD Karte im neuen USB boot mode betrieben wird ist 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
Es stehen viele Optionen zur Verfügung um das Verhalten von raspiBackup zu steuern. Die wichtigsten Optionen sind in rot gekennzeichnet. Verschiedene Optionen haben noch Parameter, wie z.B. -k 3 oder -m 1.Die Standardoptionen können in einer Konfigurationsdatei /usr/local/etc/raspiBackup.conf überschrieben werden. Eine Beispielkonfigurationsdatei die die Standardoptionen benutzt kann hier heruntergeladen werden. Anschliessend muss sie entsprechend umbenannt und in das richtige Verzeichnis kopiert werden.
 

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

 

 


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 CM

DEFAULT_

COLORING

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

DEFAULT_

DD_

PARMS

 -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

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

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

-s

email Program welches benutzt wird {mail|sendEmail|ssmtp|msmtp}. Für mailx muss auch mail angegeben 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. 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 mitgeschickt. Mit "m" werden die raspiBackup Meldungen als Datei geschickt.

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.

*

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

DEFAULT_

UPDATE_UUIDS

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

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

  Diese Option wird benutzt um an eMails das Log anzuhängen. -a

DEFAULT_

APPEND_

LOG_

OPTION

  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.
 

 



Thematische Sortierung

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 welche Möglichkeiten zur Kontaktaufnahme bestehen. In der Regel erfolgt dann die Bitte das erstellte ausführliche Logfile zwecks Analyse per eMail zuzuschicken.

 

 

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 und ermöglich damit auch die Sicherung von NOOBS Partitionen. Falls die Ziel SD Karte beim Restore größer ist als die Quell SD Karte wird der zusätzliche Platz nicht benutzt. Hinweis: Eine externe Rootpartition wird nicht unterstuetzt.

Hinweis: Der partitionsorientierte Modus wird nicht mehr weiterentwickelt.

 

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

 

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 automatisch abzuweisen gibt es ein paar Dinge die zu beachten sind:
  1. Kommentare werden manuell überprüft und deshalb dauert es in der Regel einen Tag bis sie veröffentlicht werden.
  2. Kommentare mit dem Text http werden zurückgewiesen mit der Meldung Sie sind nicht berechtigt den Tag zu verwenden.
  3. Es muss mindestens eine Stunde zwischen weiteren Kommentaren gewartet werden.

Kommentare   
#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
#1177 framp 2020-05-24 10:05
Moin Alex,

da bin ich wohl etwas ueber das Ziel hinausgeschossen mit meinen Verifikationen. :oops: In der naechsten Version 0.6.5.1, die bald kommen wird, wird dieser Check nicht mehr drin sein. Bis dahin kannst Du die folgenden Zeilen im Script ja schon mal bei Dir loeschen :-)
Code:
if ! [[ "$EMAIL" =~ ^[a-zA-Z0-9_.+-]+\@[a-zA-Z0-9-]+\.[a-zA-Z0-9.-]+$ ]]; then
writeToConsole $MSG_LEVEL_MINIMAL $MSG_INVALID_EMAIL "$EMAIL"
exitError $RC_PARAMETER_ERROR
fi


Cu framp
Zitieren
#1176 Alex 2020-05-24 08:16
Hi,

die neue Version 0.6.5 führt einen Precheck der angegebenen E-Mail-Adresse durch:

"$EMAIL" =~ ^[a-zA-Z0-9_.+-]+\@[a-zA-Z0-9-]+\.[a-zA-Z0-9.-]+$

Das mag teilweise hilfreich sein, hat jedoch bei mir letzte Nacht nach Update auf 0.6.5 zu einem Abbruch geführt, da ich keine E-Mail-Adressen von außerhalb verwende, sondern die Nachricht an lokale Benutzer zugestellt wird.

Wenn also bspw. "pi" angegeben wurde, dann bricht das Skript ab, obwohl "echo test | mail -s test pi" ein gültiger und funtionierender Prozess ist. In meinem Fall werden Nachrichten an lokale Benutzer via procmail etc. weiterverarbeitet. Geht jetzt nicht mehr :-(

Wäre nett, wenn Du das mal prüfen und überdenken könntest. Ansonsten bin ich nämlich sehr glücklich mit dem Tool.

Herzlichen Dank!
Zitieren
#1175 framp 2020-05-16 14:27
Moin Andi,

vielen Dank fuer den Hinweis. Das ist ein Bug :oops: . Ich habe es gefixed. Mit den Optionen -U -S kannst Du Deinen aktuellen Stand aktualisieren :-)

Cu framp
Zitieren
#1174 Andi 2020-05-16 13:26
Hallo framp,

habe erfolgreich ein Backup&Restore mit Version 0.6.5 durchgeführt. Mit dieser neuen Version erhalte ich nun im Log die Meldung "RBK0029E: Mail Program mpack is nicht installiert."
Dein Workaround dazu war "DEFAULT_APPEND_LOG=0 in der Konfig setzen" - stand bei mir bereits auf "0", trotzdem kam der Fehler. Muss ggf. noch ein anderer Parameter umgestellt werden?

Gruß,
Andi
Zitieren
#1173 framp 2020-05-12 16:14
Moin Mike,

vielen Dank fuer den Hinweis. In Deinem andren Beitrag habe ich Dir schon geantwortet. Ich kann das Problem leider nicht reproduzieren und brauche detailiertere Infos.

Cu framp
Zitieren
#1172 Mike 2020-05-12 12:59
Hi framp,

ist mit der finalen Version noch immer dasselbe Problem.
die MSG Datei:
--- RBK0009I: raspberrypiwatch: raspiBackup.sh V0.6.5 (7752af8) started at Tue 12 May 09:10:01 CEST 2020.
--- RBK0128I: Using logfile /mnt/nas/raspberrypiwatch/raspberrypiwatch-dd-backup-20200512-091000/raspiBackup.log.
--- RBK0116I: Using config file /usr/local/etc/raspiBackup.conf.
--- RBK0151I: Using backuppath /mnt/nas.
!!! RBK0157W: No services to stop.
--- RBK0081I: Creating backup of type dd in /mnt/nas/raspberrypiwatch/raspberrypiwatch-dd-backup-20200512-091000.
--- RBK0085I: Backup of type dd started. Please be patient.
--- RBK0078I: Backup time: 00:13:40.
!!! RBK0156W: No services to start.
--- RBK0159I: 7 backups kept for dd backup type.
--- RBK0205I: Deleting oldest backup in /mnt/nas/raspberrypiwatch. This may take some time. Please be patient.
--- RBK0033I: Please wait until cleanup has finished.
--- RBK0049I: Messages saved in /mnt/nas/raspberrypiwatch/raspberrypiwatch-dd-backup-20200512-091000/raspiBackup.msg.
--- RBK0026I: Debug logfile saved in /mnt/nas/raspberrypiwatch/raspberrypiwatch-dd-backup-20200512-091000/raspiBackup.log.
--- RBK0010I: raspberrypiwatch: raspiBackup.sh V0.6.5 (7752af8) stopped at Tue 12 May 09:23:52 CEST 2020 with rc 0.
--- RBK0017I: Backup finished successfully.


zitiere framp:
Moin Mike,

vielen Dank fuer den Hinweis. Offensichtlich wurde keine Logdatei erstellt. Am Ende werden im Logfile noch verschiedene sensitive Informationen maskiert. raspiBackup schreibt in einer Meldung wohin das Log geschrieben wird. D.h. Du findest den Dateinamen des Logs in der .msg Datei. Kannst Du die .msg Datei vielleicht mal hier zeigen damit ich eine idee bekomme was die Ursache ist?

BTW: Du benutzt eine 3 Wochen alte Beta. Mit Code:sudo raspiBackup.sh -U -S kannst Du Dir die aktuelle Beta holen.

Vielen Dank.

Cu framp

zitiere framp:
Moin Mike,

vielen Dank fuer den Hinweis. Offensichtlich wurde keine Logdatei erstellt. Am Ende werden im Logfile noch verschiedene sensitive Informationen maskiert. raspiBackup schreibt in einer Meldung wohin das Log geschrieben wird. D.h. Du findest den Dateinamen des Logs in der .msg Datei. Kannst Du die .msg Datei vielleicht mal hier zeigen damit ich eine idee bekomme was die Ursache ist?

BTW: Du benutzt eine 3 Wochen alte Beta. Mit Code:sudo raspiBackup.sh -U -S kannst Du Dir die aktuelle Beta holen.

Vielen Dank.

Cu framp

zitiere framp:
Moin Mike,

vielen Dank fuer den Hinweis. Offensichtlich wurde keine Logdatei erstellt. Am Ende werden im Logfile noch verschiedene sensitive Informationen maskiert. raspiBackup schreibt in einer Meldung wohin das Log geschrieben wird. D.h. Du findest den Dateinamen des Logs in der .msg Datei. Kannst Du die .msg Datei vielleicht mal hier zeigen damit ich eine idee bekomme was die Ursache ist?

BTW: Du benutzt eine 3 Wochen alte Beta. Mit Code:sudo raspiBackup.sh -U -S kannst Du Dir die aktuelle Beta holen.

Vielen Dank.

Cu framp
Zitieren
#1171 framp 2020-05-11 16:17
Jetzt habe ich Dich verstanden :-)

Ein dd Backup kann keine zwei Medien sichern. Dazu musst Du tar oder rsync benutzen.
Zitieren
#1170 marco 2020-05-11 16:14
zitiere framp:
Moin Marco,

ich verstehe nicht wo das Image von 16GB herkommt. Raspbian hat eine /boot von 256MB und eine /root beliebiger Groesse. Ob nun dir /root auf SD Karte ist oder SSD ist egal. Auch kann die /boot zusammen auf der SSD sein. Siehe dazu auch FAQ 42.

Cu framp

hi, beim dd backup kommt ein back up von 15.xxx GB größe bei raus. die SD karte ist insgesammt 16gb groß
und die ist nur zum booten. die ssd wird nach dem boot mit root initialisiert aber gefühlt gibt es davon kein backup... müsste ja auch 55gb haben bei dem dd backup
Zitieren
#1169 framp 2020-05-11 10:34
Moin Marco,

ich verstehe nicht wo das Image von 16GB herkommt. Raspbian hat eine /boot von 256MB und eine /root beliebiger Groesse. Ob nun dir /root auf SD Karte ist oder SSD ist egal. Auch kann die /boot zusammen auf der SSD sein. Siehe dazu auch FAQ 42.

Cu framp
Zitieren
#1168 marco 2020-05-11 06:07
zitiere framp:
Moin Marco,

ja, die externe Rootpartition wird zusammen mit de Bootpatrition der SD Karte auch gesichert und wiederhergestellt.

Cu framp


ich habe aber nur eine img datei die 16gb gros ist und nicht 256mb und eine 55gb ssd. auf der sd ist eine boot und root partition, auf der ssd ist die root partition die auch genutzt wird.
habe nach der installation von raspibackup auf ssd gewechselt.
Zitieren
#1167 framp 2020-05-09 17:31
Moin Andi,

wenn die Option auf 1 gesetzt ist (Default) dann wird die Rootpartition automatisch beim Restore auf die maximal moegliche Groesse der Parition vergroessert, d.h. die gesamte SD Karte wird benutzt. D.h. wenn Du ein Image einer 8GB Karte restorest auf eine 32Gb Karte werden alle 32Gb benutzt. Wenn Du es auf 0 setzt wird nur 8GB von der SD Karte beim Restore benutzt. Der Rest bleibt ungenutzt.

Die Option ist beim Restore beschrieben.

Cu framp
Zitieren
#1166 Andi 2020-05-09 17:21
Hallo framp,

vielen Dank für die vielen neuen Parametrisierungsmöglichkeiten in Version 0.6.5.
Konkrete Frage, da ich in der Web-Doku nichts dazu gefunden habe:
Was genau macht der Parameter "DEFAULT_RESIZE_ROOTFS" (steht bei mir standardmäßig auf "1")? Belegt das root Filesystem damit den kompletten Speicher, der nicht mit der Boot Partition belegt ist? Ich arbeite generell mit einem 32GB USB Stick und rsync.
Gruß Andi
Zitieren
#1165 framp 2020-05-08 09:57
Moin Marco,

ja, die externe Rootpartition wird zusammen mit de Bootpatrition der SD Karte auch gesichert und wiederhergestellt.

Cu framp
Zitieren
#1164 marco 2020-05-08 08:33
hi, kann ich auch neben der sdkarte auch die ssd sichern?
auf der sd ist nur noch die boot, die benutz wird und die ssd ist die root auf der alles läuft. ist sda2
danke
Zitieren
#1163 framp 2020-05-05 11:26
Moin Mike,

vielen Dank fuer den Hinweis. Offensichtlich wurde keine Logdatei erstellt. Am Ende werden im Logfile noch verschiedene sensitive Informationen maskiert. raspiBackup schreibt in einer Meldung wohin das Log geschrieben wird. D.h. Du findest den Dateinamen des Logs in der .msg Datei. Kannst Du die .msg Datei vielleicht mal hier zeigen damit ich eine idee bekomme was die Ursache ist?

BTW: Du benutzt eine 3 Wochen alte Beta. Mit Code:sudo raspiBackup.sh -U -S kannst Du Dir die aktuelle Beta holen.

Vielen Dank.

Cu framp
Zitieren
#1162 Mike 2020-05-05 08:47
Moin,

ich nutze "V0.6.5-beta (26e48d7)" und erhalte am Ende eines erfolgreichen backups folgende Fehlermeldung:
sed: can't read /mnt/nas/raspberrypiwatch/raspberrypiwatch-dd-backup-20200505-020001/raspiBackup.log: No such file or directory
sed: can't read /mnt/nas/raspberrypiwatch/raspberrypiwatch-dd-backup-20200505-020001/raspiBackup.log: No such file or directory
sed: can't read /mnt/nas/raspberrypiwatch/raspberrypiwatch-dd-backup-20200505-020001/raspiBackup.log: No such file or directory

Das Verzeichnis ist aber vorhanden_
mit der IMG Datei sowie raspiBackup.msg
Zitieren
#1161 framp 2020-04-07 18:32
Moin Markus,

mir ist nicht ganz klar was Du mit umsteigen meinst. Eine Beta ist nicht zum Umsteigen gedacht sondern zum Ausprobieren und Testen. Dann solltest Du lieber warten bis die v0.6.5 allgemein verfuegbar ist. Ich denke das wird in ein paar Wochen soweit sein.

Wenn Du die Beta mit der Option -U installiert hast wird weiterhin die alte Config Datei von der Beta benutzt. Deshalb verstehe ich nicht wieso Du irgendwelche 0.6.5-beta Dateien hast.

Ich empfehle aber die neue Konfig Datei v0.1.4 zu nehmen und die Optionen der aktuellen Config Datei einzupflegen. Dort findest Du dann auch die neuen Optionen zu SMART_RECYCLE. Natuerlich solltest vorher die alte Config sichern wenn Du wieder zureuckgehen willst auf 0.6.4.3.

Die neue Config wird nicht automatisch bei der Beta installiert. Die musst Du Dir von HTTPS://raw.githubusercontent.com/framps/raspiBackup/beta/config/raspiBackup_de.conf runterladen.

Ich hoffe ich habe jetzt alle Unklarheiten beseitigt :-)

Cu framp
Zitieren
#1160 Markus 2020-04-07 18:05
Hallo framp,
erst mal Danke für die Mühen und das tolle Programm!
Ich wollte auf die Version 0.6.5-beta umsteigen. Mit der Option -U hat auch alles geklappt.

Ich habe jetzt die verschiedene Dateien mit der Endung .0.6.5-beta.
Die raspiBackup.sh.0.6.5-beta.conf ist aber leer
(nur
# GENERATED - DO NOT DELETE
UUID=xxx)

Zwei Fragen zum Umstieg:
benenne ich alle Dateien um - ohne die Endungen 0.6.5-beta (und sichere die Originale vorher) oder lasse ich die Dateien wie sie sind? (speziell wenn ich es als cron laufen lassen möchte (ok ich kann in cron auch sagen welche conf Datei genutzt werden soll)

Die eigentliche Frage ist, da die raspiBackup.sh.0.6.5-beta.conf leer ist - ist es die richtige Vorgehensweise die alte conf zu kopieren und füge dort den Parameter für die DEFAULT_SMART_RECYCLE_DRYRUN=0 ein?

... ich möchte nur sicher gehen und mir nix zerschießen..
Danke!
Zitieren
#1159 framp 2020-03-05 11:18
Moin Ric,

vielen Dank fuer den Hinweis. Leider kann ich das nicht nachvollziehen. Weder bekomme ich akkumulierte Messages in der eMail auf meinen Systemen auf denen die Beta laeuft und eine der ersten Aktionen von raspiBackup ist das Loeschen der Messagedatei.

Kannst Du mir vielleicht das Debug log zur Verfuegung stellen? Irgendwo im Netz ablegen und mir den Link geben oder mir per eMail zuschicken (eMail siehe Kontakt Seite).

Vielen Dank

Cu framp
Zitieren
#1158 Ric 2020-03-05 09:43
Hallo framp

In Version 0.6.5-beta wird bei einem neuen Backup die backup.msg nicht mehr gelöscht. Das heisst, dass das Mail mit den Backup-Nachrichten immer grösser wird und eben auch alte Meldungen enthält.

Viele Grüsse, Ric.
Zitieren
#1157 john 2020-02-18 18:48
Hallo framp,

Ja direkt wo ich den Text weggeschickt habe, habe ich das auch gemerkt bzw. begriffen : )

Im Grunde ist es dann doch eigentlich so, es kann nur eine Datei unwiederbringlich verloren gehen, wenn ich, bevor ein neues Backup gezogen wird, ich 2 mal die Datei ändere und nach 1sten nicht wegsichere also kein neues Backup auslöse.Aber das ist ja bei jedem Backupvorgang so, ausser es gibt einen Trigger, der bei einer Änderung automatisch einen Backupvorgang auslöst, aber da müsste man ja die Verzeichnisse überwachen.

grüsse john
Zitieren
#1156 framp 2020-02-17 18:41
Moin john,
Zitat:
ist, den letzten Stand unwiederbringlich verlieren oder, da das nächste Backup dann ja wieder den alten Hardlink spiegelt.
Jein. Der letzte Backupstand ist verloren. Wenn jetzt aber ein neuer Backup gezogen wird werden alle nicht geaenderten Dateien wieder mit dem 12er Stand verlinked. Fuer alle neuen bzw geaenderten Dateien werden neue Dateien angelegt und nicht die Dateien aus dme 12er Backup verlinked.

Cu framp
Zitieren
#1155 john 2020-02-17 18:09
Hallo framp,

Ich hab nochmal ein bisschen mir das angeschaut, eigentlich ist ja auf jeder Datei ein Hardlink zum Inode vorhanden und das eigentlich auch wieder eine Referenz auf den tatsächlen pysikalischen Speicher hat, aber im Grunde ist das ja unwichtig was unter der Inode Overfläche passiert für das glaub ich.

Zu meiner neuen Frage:
Wenn ich aus meinem Beispiel festlege, dass sich eine Datei im Backup vom 13ten geändert hat (also erstellt wird mit einem anderen Inode Eintrag) dann würde ich ja, wenn ich dieses Backup lösche und noch kein weiteres Backup mit Hardlink Mirrors erstellt ist, den letzten Stand unwiederbringlich verlieren oder, da das nächste Backup dann ja wieder den alten Hardlink spiegelt.

Is das korrekt ? Btw. ich werde bei Gelegenheit mein Real Life Beispiel anpassen ( die inode ebene glaub ich muss mit einbezogen werden ) und hier posten

grüsse john
Zitieren
#1154 framp 2020-02-14 20:37
Moin john,

da kann nichts passieren. Du musst nur einfach immer daran denken dass eine Datei nur dann geloescht wird wenn ihr Benutzungszaehler, der bei jedem Loeschen um eins reduziert wird, auf null geht. Ansonsten bleiben die Dateien immer erhalten.

D.h. wenn eine Datei in Backup n+2 benutzt wird und der Backup n+1 geloescht wird (die Datei wurde in Backup n+1 erstellt) ist der Benutzungszaehler immer noch eins und somit existiert die Datei noch fuer Backup n+2

Cu framp
Zitieren
#1153 john 2020-02-14 17:39
Moin framp

Wir hatten doch vor geraumer Zeit mal die Diskussion mit den rsync Mechanismus und wenn man Dateien aus versehen löscht.

Kann das eigentlich auch passieren, wenn ich ein komplettes Backup lösche, das die Hardlinkkette kompromittiert ist. ?
Also Beispiel ich habe 3 Rsync Backups ( am 5ten 12 und 13ten) und ich lösche ein komplettes von den dreien aus Versehen.
Kann hierbei eine Inkonsitenz entstehen ?

grüsse john
Zitieren
#1152 framp 2020-01-10 16:01
Moin betonmoewe,

das eMail-Problem ist eigentlich kein eMailProblem. Ich hatte mir nur gedacht es macht keinen Sinn eine eMail zu senden wenn man raspiBackup von der Cmdline aus aufruft. Man sieht da ja gleich das Ergebnis. Ich habe es aber wieder rausgenommen. Ist besser so.
Der letzte Stand im git hat die Aenderung drin ;-)

Cu framp
Zitieren
#1151 framp 2020-01-10 12:34
zitiere betonmoewe:

2.) es wäre schön, beim install Prog auch auswählen zu können ob die aktuellste beta Version installiert werden soll (ggfalls nur als commandline Parameter, damit keine Verwirrung bei normalen usern aufkommt)


Kannst Du das etwas genauer beschreiben was Du genau getan hast um die Beta zu bekommen? Wie gesagt ist sie eigentlich noch nicht offiziell verfuegbar :roll:

Cu framp
Zitieren
#1150 framp 2020-01-10 12:09
Moin betonmoewe,

eben habe ich Dein Problem mit der Mail bei mir reproduzieren koennen. Im Regressionlauf wird nur die primaere Backup/Restore Funktionalitaet getestet und deshalb ist mir das entgangen :oops: (Waere aber spaetestens naechstes Wochendende bei meinem naechsten Backuplauf aufgefallen :-)

Ich sehe mir das an und fixed das.

Vielen Dank fuer Deinen Hinweis. Falls Du noch andere Dinge findest scheue Dich nicht Dich zu melden. Allerdings waere es dann fuer mich einfacher wenn Du Deine Findings im github reporten wuerdest (gerne auch in Deutsch) ;-) Kannst aber auch gerne weiterhin die Kommentarfunktion benutzen .

Cu framp
Zitieren
#1149 betonmoewe 2020-01-10 11:44
igendwie ist mein letzter kommentar etwas verstümmelt ...

wie geschrieben: im log sehe ich nichts

Ich habe DEFAULT_MAIL_PROGRAM= mail und auch mailext (natürlich mit installierter erweiterung) ausprobiert. DEFAULT_EMAIL ist auch gesetzt.
2.) es wäre schön, beim install Prog auch auswählen zu können ob die aktuellste beta Version installiert werden soll (ggfalls nur als commandline Parameter, damit keine Verwirrung bei normalen usern aufkommt)

Auf jeden Fall vielen Dank für das Skript. Ist schon einfacher als alles selbst in Skripte zu packen und diese immer wieder anzupassen

Die Betonmöwe
Zitieren
#1148 framp 2020-01-10 11:38
Moin betonmoewe,

die Beta ist zwar noch nicht offiziell freigegeben (Ich lasse sie vorher immer noch ein paar Wochen bei mir @home laufen). Aber ich finde es gut wenn Du sie schon mal testest.

An der sendMail Ecke hat sich nichts geaendert. Kannst Du mal die naechsten 20 Zeilen nach --> sendEMail aus dem Log zeigen?

Cu framp
Zitieren
#1147 betonmoewe 2020-01-10 11:29
Hallo Framp,

ich versuche grad das raspiBackup Skript zum laufen zu bekommen (Version 0.6.4.4-beta, da ich gerne die Funktion smart_backup ohne Wrapper nutzen möchte). Backup an sich funktioniert schon mal ... aber:
1.) ich bekomme es nicht hin, dass eine Mail versendet wird :( im log sehe ich nur
--> sendEMail
Zitieren
#1146 framp 2019-11-07 14:35
Moin aktivomat,

nein, das Problem ist noch nicht bekannt. Im naechsten Release wird es aber gefixed sein ;-)

Die Option -U ist eigentlich als einmalige Option gedacht, die man benutzt wenn raspiBackup eine neue verfuegbare Release meldet und man Zeit hat das neue Release mit Backup und Restore zu testen. Es kann leider immer mal passieren dass ein neues Release einen Bug hat :oops: und man sollte es immer noch mal testen.

Cu framp
Zitieren
#1145 aktivomat 2019-11-06 23:57
Hallo und guten Abend!

Irgendwas scheint bei der Update-Funktion nicht zu stimmen. Ich habe V0.6.4.3 drauf und starte mein Skript immer mit der -U Funktion. Jetzt wird immer gefragt ob ich auf V0.6.4.3 (welches ich ja schon drauf habe) aktualisieren möchte. Somit hänge ich quasi in einer Schleife. Oder ist das Problem bekannt?

Vielen Dank für die Hilfe und auch nochmals an das fantastische Skript, welches mir schon ein paar mal toll geholfen hat!
Zitieren
#1144 hardl 2019-08-13 18:35
Moin hardl,

raspiBackup ist dazu gedacht alles zu sichern und mit den exclude Statements gezielt ein paar Dateien oder Verzeichnisse auszunehmen. Wenn Du nur 4 Dateien sichern willst ist es besser das direkt mit einem rsync Befehl zu tun und den Aufruf in der Crontab aufzunehmen.

Cu framp
Zitieren
#1143 hardl 2019-08-13 12:56
Ich möchte nur diese Verzeichnisse vom Raspi regelmäßig mit rsync sichern:
/usr/share/openhab2/addons
/etc/openhab2
/var/lib/openhab2
/etc/default/openhab2

Gibt es einen anderen Weg, als sehr viele Verzeichnisse in EXCLUDE anzugeben?
Zitieren
#1142 framp 2019-08-06 09:51
Moin Christian,

Vielen Dank für dein Feedback. Das ist in der Tat merkwürdig. Ich sehe mir das mal genauer an und fixe das.

Cu framp
Zitieren
#1141 Christian 2019-08-05 23:04
Backup succeeded :-)
ERROR: parted is not installed.

Möglicherweise wird das pishrink nicht als root gestartet... aber hab schon alles kontrolliert - und finde den Fehler nicht?

lg
christian

Hallo framp,

danke für die schnelle Antwort. Habe ich jetzt alles kontrolliert/nachinstalliert.... Fehler kam aber trotzdem...

Was den Fehler behoben hat, ... ich habe in Zeile 148 den Aufruf von
pishrink.sh $BACKUP_TARGETFILE
geändert zu
sudo pishrink.sh $BACKUP_TARGETFILE

Jetzt läuft das Skript fehlerfrei durch :)
Keinen Plan warum beim Aufruf von pishrink die root Rechte nicht mitgegeben werden... das Skript wird über cron.d gestartet...genauso wie das originale raspiBackup. Wenn man das Wrapper Skript direkt manuell startet läuft es problemlos durch... nur als Cronjob nicht...

Danke
Christian
Zitieren
#1140 framp 2019-08-05 20:49
Moin Christian,

die Meldung kommt von pishrink.

pishrink erfordert dass ein paar Tools installiert sind die nicht von raspiBackup benoetigt werden und deren Verfuegbarkeit auch von raspiBackup geprueft wird.
Die Tools sind
Code:
parted losetup tune2fs md5sum e2fsck resize2fs


Du kannst die fehlenden Tools installieren mit
Code:
sudo apt-get install <toolname>


Dann sollte alles funktionieren ;-)

Cu framp
Zitieren