Click here to open this page in English 

 

raspiBackup ermöglicht Backups von Raspberries manuell oder automatisch in regelmäßigen Abständen von einem laufenden System zu erstellen. 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 wiederhergestellt werden. Eine ausgelagerte Rootpartition wird mitgesichert, Raspberry 3 USB Boot Images und NOOBS Images werden unterstützt.
 

 

 

Hinweis

  • Unter dem folgenden Link FB f Logo blue 29  werden aktuelle Aktivitäten und Randinformationen zu raspiBackup auf Facebook publiziert. Es ist dafür keine Facebook Anmeldung oder Registrierung notwendig.
  • Neuigkeiten zu raspiBackup werden auf Twitter Twitter f Logo blue 29 #raspiBackup publiziert.
  • Für Fragen Question 29 oder Problemmeldungen zu raspiBackup steht die Kommentarfunktion am Ende der Seite zur Verfügung.

 

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 Backup
  21. git Änderungslog
  22. Danksagungen
  23. Trinkgeld
  24. Benutzungsstatistiken

 



 

 

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.

Es stehen zwei Backupmodi zur Verfügung: 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. Im zweiter Backupmodus, dem partitionsorientierten Backupmodus, werden alle bzw eine definierte Anzahl von Partitionen der SD Karte gesichert. Damit kann somit eine NOOBS SD Karte sowie Images mit mehr als zwei Partitionen gesichert werden. 

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.

Für Freunde von Facebook exisitiert eine Facebookgruppe zu raspiBackup wo aktuelle Neuigkeiten und Randinformationen zu raspiBackup publiziert werden.

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

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, ...)
  • Raspbian, Arch, Ubuntu, Volumio, NOOBs ...
  • Der partitionsorientierte Backupmodus sichert eine beliebige Anzahl von Partitionen der SD Karte und kann somit NOOBs Images sichern
  • 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)
  • 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)
  • eMail Benachrichtigung über den Backuplauf und Backupverlaufsstatus (-e Option)
  • Unterstützte eMailClients: mailx/mail, sendEmail und ssmtp (-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

Die aktuelle Version von raspiBackup ist 0.6.3.2a. Eine schon existierende Konfigurationsdatei von raspiBackup (/usr/local/etc/raspiBackup.conf) sowie eine schon existierende Version vom Script raspiBackup (/usr/local/bin/raspiBackup.sh) werden automatisch in ihren Verzeichnissen vom Installationsscript gesichert. Das Installationsscript raspiBackupInstall.sh wird ebenso in /usr/local/bin kopiert.

Voraussetzung: Login als Benutzer pi ins Homeverzeichnis

  1. Zum Installieren können folgende alternativen Befehle auf der Raspberry ausgeführt werden. Ein Upgrade von Versionen auf eine neuere Version ist auch damit möglich denn das alte Script sowie die Config Datei werden vorher gesichert. Allerdings ist ein Upgrade mit der Option -U schneller vorgenommen. Nach der Installation sollte unbedingt die FAQ Seite gelesen werden.
    1. raspiBackup.sh wird in /usr/local/bin auf der Raspberry installiert und ausführbar gemacht. Danach werden die wichtigsten Optionen abgefragt und dann die Konfigurationsdatei /usr/local/etc/raspiBackup.conf entsprechend konfiguriert. Weiterhin wird eine Beispieldatei für Cron in /etc/crontab.d/raspiBackup erstellt. Anschliessend muss nur noch raspiBackup mit dem Backuppfad aufgerufen werden um ein Backup zu erstellen.
      curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackupInstall.sh && sudo bash raspiBackupInstall.sh 
    2. raspiBackup.sh wird in /usr/local/bin auf der Raspberry installiert und ausführbar gemacht. Ausserdem wird eine Standardkonfigurationsdatei auf /usr/local/etc/raspiBackup.conf installiert, wobei die Kommentare in der konfigurierten Systemsprache der Raspberry sind. Die Konfigurationsdatei muss manuell angepasst werden.
      curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackupInstall.sh && sudo bash raspiBackupInstall.sh -c
    3. raspiBackup.sh wird in /usr/local/bin auf der Raspberry installiert und ausführbar gemacht. Ausserdem wird eine Standardkonfigurationsdatei auf /usr/local/etc/raspiBackup.conf mit deutschen Kommentaren installiert . Die Konfigurationsdatei muss manuell angepasst werden.
      curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackupInstall.sh && sudo bash raspiBackupInstall.sh -c -l DE
  2. raspiBackup kann man auch manuell downloaden mit diesem Link in einem Browser oder auch direkt mit den folgenden Befehlen. raspiBackup muss man dann manuell in /usr/local/bin und die Konfigurationsdatei nach /usr/local/etc kopieren und anpassen.
    curl -sSLO https://www.linux-tips-and-tricks.de/raspiBackup.sh
    curl -sSL https://www.linux-tips-and-tricks.de/downloads/raspibackup-de-conf/download > raspiBackup.conf
  3. raspiBackup kann wie folgt regelmäßig aufgerufen werden:

    1. Ändern der Beispiel Cron Datei /etc/cron.d/raspiBackup. Der einfachste Weg ist das Zeichen # in der letzten Zeile zu entfernen. Dann wird automatisch immer am Sonntag morgen um 5 Uhr ein Backup erstellt.

    2. Aufnahme der folgenden Zeile in die /etc/crontab
    0 5  * * 0 /usr/local/bin/raspiBackup.sh -p /backup -t tar -k 4 -e Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!  
    mit dem Befehl
    sudo crontab -e
    Dann wird jeden Sonntag ebenso um 5 Uhr automatisch ein tar Backup in dem Verzeichnis /backup erzeugt und eine StatusEmail an Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! gesendet.

    Hinweis: Wer direkt die /etc/crontab mit einem Editor ändert muss die folgende Zeile einfügen:
    0 5  * * 0 root /usr/local/bin/raspiBackup.sh  -t tar -k 4 -e Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! /backup
  4. Anschließend sollte ein Restore auf eine weitere SD Karte vorgenommen werden um sich mit der Art, wie das Backup zu restoren ist, vertraut zu machen und das Backup zu testen. Es ist nichts ärgerlicher, wenn man zu dem Zeitpunkt, wenn man das Backup benötigt, feststellt, das das Backup nicht alles enthält oder sogar nicht brauchbar ist.

Die Deinstallation von raspiBackup sowie aller Konfigurationsdateien und dem Installationsscript startet man mit

sudo raspiBackupInstall.sh -u

Weitere Details zu den verschiedenen Funktionen des Installationsskriptes erfährt man durch den Aufruf der Hilfefunktion

raspiBackupInstall.sh -h

Achtung

Ein Backup nützt nichts wenn in dem Moment, wo man es einspielen möchte, feststellt, das das Backup nicht zu gebrauchen ist. Desshalb sollte man nach dem ersten erfolgreichen Backup auch sofort den Restore testen und immer wieder von Zeit zu Zeit den ganzen Restoreprozess durchexerzieren und damit testen ob die erstellten Backups OK sind und sich ein System damit funktionsfähig restaurieren läßt.

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

 

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.

 

Ab Version 0.6.3.2 können alle Optionen die etwas ein- oder ausschalten 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.


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

-A
Das Laufzeitlog wird in der email mitgeschickt Nein

DEFAULT_

APPEND_

LOG

-b Blocksize die beim dd Backup benutzt wird 1MB

DEFAULT_

DD_

BLOCKSIZE

-B Die Bootpartition wird nicht per dd sondern per tar gesichert. Nein

DEFAULT_

TAR_BOOT_

PARTITION_ENABLED

 -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 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  
 -k  Anzahl der Backups, die vorzuhalten sind  3

DEFAULT_

KEEPBACKUPS

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

 off

DEFAULT_

LOG_

LEVEL

-L

Ort wo der Laufzeitlog angelegt wird

- syslog -> /var/log/syslog

- varlog -> /var/log/raspiBackup/<hostname>.log

- backup -> <backupPath>

- current -> ./raspiBackup.log

Im Fehlerfalle findet sich die Logdatei für den Parameter backup im Homeverzeichnis des aufrufenden Benutzers. 

syslog für Backup

 currrent für Restore (nicht änderbar)

 DEFAULT_

LOG_

OUTPUT

-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 

-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

Einschalten des partitionsorientierten Backupmodus, der alle oder eine bestimmte Anzahl von Partitionen de SD Karte sichert. Dieser Modus sollte bei NOOBS Images für tar und rsync Backups gewählt werden und wenn mehr als zwei Partitionen auf der SD Karte sind. Soll das NOOBS Image per dd gesichert werden so dass es mit win32diskimager zu restoren ist muss dazu der normale Backupmodus mit dd Backup benutzt werden.

Siehe auch den Parameter -T.

Hinweis: In diesem Modus kann keine externe root Parition mitgesichert werden.

nein

DEFAULT_

PARTITIONBASED_

BACKUP 

-s

email Program welches benutzt wird {mail|sendEmail|ssmtp}. 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

-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

--timestamps  Ab der Version 0.6.3.2 wird durch diese Option 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*/*". 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.

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

Ab der Version 0.6.3.2 wird die Version von raspiBackup 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

 

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 aktuellen Verzeichnis erzeugt bei der zusätzlichen Benutzung des Parameters -l debug (kleines L) beim Aufruf von raspiBackup.sh mit einer Menge detailierte Informationen und man kann man in der Logdatei nach Fehlermeldungen und -ursachen suchen die helfen den Fehler zu lokalisieren. (Je nach Parameter -L befindet sich die Logdatei an anderer Stelle. Siehe die Details dazu oben bei der Parameterbeschreibung für -L. 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 sollte man den Fehler auf dieser Seite in einem Kommentar schildern. 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.

 

Backupverzeichnisstruktur (Normaler Backup)

Jeder Backplauf 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
│   ├── 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


Backupverzeichnisstruktur (Partitionsorientierter Backup) 

root@jessie:/mnt/backup/raspberrypi# tree -L 2
.
├── raspberrypi-dd-backup-20160415-222923
│   └── raspberrypi-dd-backup-20160415-222923.img
├── raspberrypi-rsync-backup-20160416-104548
│   ├── mmcblk0p1
│   ├── mmcblk0p2
│   ├── raspberrypi-backup.blkid
│   ├── raspberrypi-backup.fdisk
│   ├── raspberrypi-backup.mbr
│   ├── raspberrypi-backup.parted
│   └── raspberrypi-backup.sfdisk
└── raspberrypi-tar-backup-20160416-114748
    ├── mmcblk0p1.tar
    ├── mmcblk0p2.tar
    ├── raspberrypi-backup.blkid
    ├── raspberrypi-backup.fdisk
    ├── raspberrypi-backup.mbr
    ├── raspberrypi-backup.parted
    └── raspberrypi-backup.sfdisk

 

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.

 

Trinkgeld

Immer wieder wird gefragt ob und wie man den Entwicklungs- und Wartungsaufwand sowie Support für raspiBackup honorieren kann. Die auf der Kontaktseite genannte eMail ist PayPal bekannt und ein jeder kann mit einem PayPal Konto an diese eMail ein Trinkgeld geben.

 

Weitere Seiten zu raspiBackup

Häufig gestellte Fragen (FAQ)

Versionshistorie von raspiBackup.sh

Sicherung des Backups von raspiBackup.sh auf einer Synology

Verbesserungs- und Änderungsvorschläge

 

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

How to extend a NOOBS partition

Kommentare   
#1071 Axel 2018-06-04 16:18
Moin framp,

klar. Leider beides. Logs aus Securitygründen, OS für die Wiederherstellung. Natürlich ging das als vm charmanter, aber davon wollte ich weg. Ich denke, ich werde mit einem Logloch leben. LVMs -- ok; ich wollte aber KISS und den Pi möglichst wenig verändern.

Zur Not verteile ich die Logs weiter, nehme zwei PIs mit unterschiedlichen Backupzeiten oder sorge für andere Redundanz; -- das geht bei syslog mit den UDP-Paketen zum Glück noch einigermaßen gut.

LG
Axel
#1070 framp 2018-06-04 16:06
Moin Axel,

die Frage ist was Du Sichern willst:
1. Das OS oder
2. die Logs

Bei 1 kannst Du die Fehler von den Logs ignorieren. Bei 2 wird das mit raspiBackup nicht gehen. LVM snapshots denke ich koennten da helfen.

Cu framp
#1069 Axel 2018-06-04 15:40
Moin framp,

nun, der Logpfad war bereits genau so eingerichtet. Du hast mich aber in die richtige Richtung geschubst.

Mein Stopbefehl für den rsyslogd war:
"/etc/init.d/rsyslog stop"

Da aber über den syslog per socket die Protokollierung wieder anläuft und den Service damit startet, schrieben meine eingehenden logs natürlich einfach weiter. Mit 8 Meldungen pro Sekunde ging das recht schnell. Der richtige Stopbefehl lautet:
"systemctl stop syslog.socket rsyslog.service"
(vgl. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815862)

Eine andere Frage ist nun, ob diese Backupmethode richtig ist für einen syslogserver -- der damit während des ca. 15 Minuten dauernden backups nichts mehr logt. Da kannst Du mir aber vermutlich auch nicht helfen, es sei denn, es gibt künftig einen Weg, veränderte (geöffnete) Dateien zu sichern.

Danke für Deinen Support!

LG
Axel
#1068 framp 2018-06-04 14:44
Moin Axel,

ich vermute Du benutzt den Standard Logpfad fuer raspiBackup welcher /var/log/syslog ist und sich natuerlich ändert. Ist ein kleiner Bug in raspiBackup den ich mal fixen muss :oops: Benutze die Option Code:-L backup. Dann wird es in Deinem Backupverzeichnis abgelegt. Du koenntest aber auch mit der Option Code:-u /var/log/syslog excluden vom Backupprocess.
In der naechsten Release von raspiBackup kannst Du exakt den Pfad angeben wo das Log abgelegt werden soll.

Cu framp
#1067 Axel 2018-06-04 13:30
Hi Framp,

danke! Ich nutzt den PI als rsyslogd und dachte daher, ein Dienststop sei nicht nötig. Das habe ich jetzt nachgeholt; leider stoppt der tar dennoch an derselben Stelle. Die letzten noch offenen Dienste sind wie unten aufgeführt (ich habe den Dienst für die Analyse manuell angehalten):

root@somehost:~# /etc/init.d/rsyslog stop
[....] Stopping rsyslog (via systemctl): rsyslog.serviceWarning: Stopping rsyslog.service, but it can still be activated by:
syslog.socket
. ok
root@somehost:~# lsof / | awk 'NR==1 || $4~/[0-9][uw]/'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 4836 root 11w REG 179,2 45082404 18984 /var/log/syslog
rsyslogd 4836 root 13w REG 179,2 18842 38289 /var/log/daemon.log
rsyslogd 4836 root 14w REG 179,2 45042434 39394 /var/log/messages

Kann und soll ich hierfür noch weitere Dienste anhalten?

LG
Axel
#1066 framp 2018-06-04 13:01
Moin Axel,

tar RC 1 bedeutet i.d.R. da hat sich eine Datei während des Backups geändert. FAQ18 erklärt wie man die zu stoppenden Services identifiziert. Du kannst auch die KonfigOption Code:DEFAULT_TAR_IGNORE_ERRORS=1 setzen. Dann wird der Fehler ignoriert. Ich empfehle dieses aber nicht da Du nicht genau weisst ob sich vielleicht eine wichtige Datei geändert hat.

Cu framp
#1065 Axel 2018-06-04 12:48
Moin framp,

coole Sache! Vor allem freue ich mich über die wunderschöne Dokumentation!

Nach erfolgreichem "-F" bricht bei mir das backup immer bei "/sbin/halt" ab. Sicherung per tar, Komprimierung testweise über Kommandozeile abgeschaltet.

OS: Raspbian Stretch
Aufruf: raspiBackup.sh -g -v -z- -l debug
(Aufruf als root)

Letzte Zeilen:
/sbin/request-key
/sbin/mkfs.bfs
/sbin/dumpe2fs
/sbin/halt
??? RBK0021E: Backupprogramm des Typs tar beendete sich mit RC 1.
--- RBK0026I: Logdatei wird in /root/syslog01-raspiBackup.log gesichert.
--- RBK0043I: Unvollständiges Backup /mnt/backup/syslog01/syslog01-tar-backup-20180604-123631 in wird gelöscht. Das wird etwas dauern. Bitte Geduld.
--- RBK0105I: Neues Backupverzeichnis /mnt/backup/syslog01/syslog01-tar-backup-20180604-123631 wird gelöscht.
??? RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

Hast Du irgendeine Idee?

LG
Axel
#1064 framp 2018-05-28 22:23
Moin Matthias,

ist natuerlich bloed dass der Backup einfach so haengenbleibt. :cry:

ich vermute mal Du benutzt von beiden Raspis dasselbe Backupdevice. Ich vermute dort liegt irgendwo der Hase im Pfeffer :-)

Ich sehe folgende Ansaetze fuer Dich um die Ursache einzugrenzen:
1) Rufe raspiBackup mit der zusaetzlichen Option Code:-l debug auf und suche im Log nach der Zeile die Code:Command executed: enthaelt. Das ist der native Linux Befehl der von raspiBackup benutzt wird um das Backup zu erstellen. Rufe den mal direkt auf als root. Damit pruefst Du ob die Ursache in raspiBackup liegt (ich vermute allerdings nicht)
2) Benutze mal ein anderes Backupdevice, z.B. ein lokal angeschlossener USB Stick.
3) Benutze eine andere Backupmethode

Ich hoffe das hilft Dir bei der Ursachenforschung.

Cu framp
#1063 Matthias 2018-05-28 20:20
Hallo framp,

ich hatte ja geschrieben, dass das raspiBackup bei mir immer irgendwie stehen bleibt. Ich habe es darauf hin mehrfach mit der Option -v getestet und auch auf mehreren raspis. Er bleibt dabei jedes mal bei der selben Datei stehen, aber auf jedem raspi bei einer anderen:
1. raspi
```
lib/modules/4.9.35+/kernel/drivers/media/rc/keymaps/rc-genius-tvgo-a11mce.ko
lib/modules/4.9.35+/kernel/drivers/media/rc/keymaps/rc-gotview7135.ko
lib/modules/4.9.35+/kernel/drivers/media/rc/keymaps/rc-hauppauge.ko
lib/modules/4.9.35+/kernel/drivers/media/rc/keymaps/rc-imon-mce.ko
lib/modules/4.9.35+/kernel/drivers/media/rc/keymaps/rc-imon-pad.ko
```
2. raspi
```
lib/modules/4.9.35+/kernel/drivers/media/pci/ttpci/
lib/modules/4.9.35+/kernel/drivers/media/pci/ttpci/ttpci-eeprom.ko
lib/modules/4.9.35+/kernel/drivers/media/platform/
lib/modules/4.9.35+/kernel/drivers/media/platform/bcm2835/
lib/modules/4.9.35+/kernel/drivers/media/platform/bcm2835/bcm2835-v4l2.ko
```
und dort passiert über Stunden nichts mehr. Ich habe auch beim 1. raspi von verschiedenen Computern versucht den Befehl auszuführen mit dem gleichen Ergebnis. Hast du noch irgend eine Idee, wie ich den Fehler weiter eingrenzen kann?

Viele Grüße,
Matthias
#1062 framp 2018-05-24 21:22
Moin HolgerW,

Du solltest eine Ja/Nein Abfrage bekommen. Dass bei -R ein Backup angestossen wird ist auch merkwuerdig :sad:

Um Dein Problem eingrenzen zu koennen brauche ich ein Debuglog von raspiBackup. Bitte gib noch zusaetzlich die Option Code:-l debug zum Restore an und schicke mir dann das Debug log an meine eMail. Du findest sie auf der Kontaktseite ;-)

Cu framp
#1061 HolgerW 2018-05-24 14:28
Hallo, ich versuche gerade ein Restore, aber es kommen die folgenden Meldungen und es geht nichts weiter. Sollte hier eine Abfrage J/n oder so erscheinen?
Es ist ein Raspbian GNU/Linux 8 (jessie) aktueller Stand.
Aufruf ist: sudo raspiBackup.sh -d /dev/sdb /backup/raspi_rocrail/raspi_rocrail-tar-backup-20180523-202052/
Es handelt sich um einen Raspi 3. Speichermedium ist USB Stick, keine SD Karten. Wenn ich -R angebe dann versucht er zu sichern, nicht zu restoren.
Holger

--- RBK0009I: raspberrypi-openhab: raspiBackup.sh V0.6.3.2a (1015c57) um Do 24. Mai 14:24:59 CEST 2018 gestartet.
--- RBK0128I: Logdatei ist /home/pi/raspiBackup.log.
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
--- RBK0138I: Bootbackup /backup/raspi_rocrail/raspi_rocrail-tar-backup-20180523-202052/raspi_rocrail-tar-backup-20180523-202052.tar wird benutzt.
--- RBK0068I: Bootpartitionsdateien des Backups aus dem Verzeichnis /backup/raspi_rocrail/raspi_rocrail-tar-backup-20180523-202052 die mit raspi_rocrail-backup beginnen werden benutzt.
!!! RBK0006W: Ziel /dev/sdb mit 7.22 GiB ist kleiner als die Backupquelle mit 7.47 GiB. Die root Partition wird entsprechend verkleinert. HINWEIS: Der Restore kann fehlschlagen wenn sie zu klein wird.
!!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht.
#1060 framp 2018-05-13 19:16
Moin Heikoh81,

vielen Dank fuer die Rueckmeldung. Erfreulich dass durch die Umstellung auf samba der Fehler verschwunden ist :-)

Im Forumsthread klappt es weder mit samba noch mit nfs. Das Problem ist schon mysterioes :cry:

Auch dass samba schneller ist als nfs. Das widerspricht allen Performancetests. Vielleicht ist ja die nfs Implementierung der NAS Box nicht performant?

Anyhow: Wenigstens läuft jetzt der Backup wieder :thumbsup:

Cu framp
#1059 heikoh81 2018-05-13 18:59
Zwischenzeitlich habe ich einen zweiten Raspi3b+ hier, um einen Hardware-Fehler auszuschließen. Auch bei diesem funktioniert das Backup mit dd nicht zuverlässig. Erstaundlicherweise ist es nach dem ersten Start aber durchgelaufen.

Nach Hinweisen auf einen ähnlichen Thread im Raspberry-Forum von framps habe ich aber meinen NSF-Mount durch einen Samba-Mount ersetzt.

Nun läuft das dd-Image zuverlässig durch, auch wenn der Raspi schon einige Tage uptime hat.
Die Performance ist übrigens nochmal deutlich besser.
Statt 11-15 MB/s bei NFS schafft dd nun 22-25 MB/s. Mehr kann der Raspi3b+ ja technisch fast nicht...

Viele Grüße,
Heiko
#1058 framp 2018-05-04 21:51
Take your time :-) Don't hurry be happy :lol:
#1057 heikoh81 2018-05-04 21:35
Ich werde dies gleich morgen vormittag machen.
Momentan (21:30) kann ich die Haussteuerung nicht herunterfahren, da in den nächsten 2 Stunden viele Timer anstehen (Licht innen & außen, Rolladen)... ;-)
#1056 framp 2018-05-04 21:17
Moin heikoh81,

vielen Dank fuer die Infos. Ich habe beide Versionen verglichen. Es sind nur ein paar Aenderungen und ich kann keinen Grund finden warum es ploetzlich so langsam geht :sad:
Kannst Du bitte die v0.6.3.2a noch mal mit den zusaetzlichen Optionen Code:-l debug --timestamps -L current starten und mir dann das debuglog an meine eMailAdresse zwecks Analyse zuschicken? Die eMailAdresse findest Du auf der KontaktSeite.

Vielen Dank.

Cu framp
#1055 heikoh81 2018-05-04 20:36
Nun noch der Output mit Update und dem Abbruch:

Code:
root@fhem:~# sudo raspiBackup.sh -U
--- RBK0009I: fhem: raspiBackup.sh V0.6.3.2 (5659ee1) started at Fri 4 May 17:17:18 CEST 2018.
--- RBK0031I: Checking whether a new version of raspiBackup.sh is available.
--- RBK0190I: Upgrading raspiBackup.sh from version 0.6.3.2 to 0.6.3.2a.
--- RBK0038I: Are you sure? y/N y
--- RBK0057I: Downloading file raspiBackup.sh from https://www.linux-tips-and-tricks.de.
--- RBK0072I: /usr/local/bin/raspiBackup.sh updated from version 0.6.3.2 to version 0.6.3.2a. Previous version saved as /usr/local/bin/raspiBackup.0.6.3.2.sh.
RBK0072I: Don't forget to test backup and restore with the new version now.
root@fhem:~# sudo raspiBackup.sh -a "service apache2 start && service fhem start && service smbd start" -o "service apache2 stop && service fhem stop && service smbd stop" -u "--exclude=/backup/*" -p "/backup" -t dd
--- RBK0009I: fhem: raspiBackup.sh V0.6.3.2a (1d77d56) started at Fri 4 May 17:17:44 CEST 2018.
--- RBK0128I: Using logfile /backup/fhem/fhem-dd-backup-20180504-171744/fhem-backup.log.
--- RBK0116I: Using config file /usr/local/etc/raspiBackup.conf.
--- RBK0151I: Using backuppath /backup.
--- RBK0008I: Stopping services: 'service apache2 stop %1%1 service fhem stop %1%1 service smbd stop'.
--- RBK0081I: Creating backup of type dd in /backup/fhem/fhem-dd-backup-20180504-171744.
--- RBK0085I: Backup of type dd started. Please be patient.
^C??? RBK0163E: Script execution canceled with CTRL C.
--- RBK0007I: Starting services: 'service apache2 start %1%1 service fhem start %1%1 service smbd start'.
--- RBK0026I: Saving logfile in /root/fhem-raspiBackup.log.
--- RBK0043I: Removing incomplete backup in /backup/fhem/fhem-dd-backup-20180504-171744. This will take some time. Please be patient.
--- RBK0105I: Deleting new backup directory /backup/fhem/fhem-dd-backup-20180504-171744.
??? RBK0005E: Backup failed. Check previous error messages for details.
#1054 heikoh81 2018-05-04 20:35
Danke für deine Antwort.
Ich habe mal den Output der Konsole kopiert, da sieht man denke ich auch die genauen Code-Stände?

Es beginnt mit dem Mount des NFS-Shares, dann das erfolgreiche Backup mit der 0.6.3.2, danach sieht man das Update, dann erneut das Backup. Ich habe es nach ca. 60min und nur 1,1 GB abgebrochen (mein Image hat nach PiShrink so ca. 5,6 GB).

Es passt nicht alles in einen Kommentar, deshalb poste ich es auf 2x.

Code:
root@fhem:~# sudo mount 192.168.178.204:/raspibackup /backup
root@fhem:~# sudo raspiBackup.sh -a "service apache2 start && service fhem start && service smbd start" -o "service apache2 stop && service fhem stop && service smbd stop" -u "--exclude=/backup/*" -p "/backup" -t dd
--- RBK0009I: fhem: raspiBackup.sh V0.6.3.2 (5659ee1) started at Fri 4 May 16:56:40 CEST 2018.
--- RBK0128I: Using logfile /backup/fhem/fhem-dd-backup-20180504-165640/fhem-backup.log.
--- RBK0116I: Using config file /usr/local/etc/raspiBackup.conf.
--- RBK0151I: Using backuppath /backup.
--- RBK0008I: Stopping services: 'service apache2 stop %1%1 service fhem stop %1%1 service smbd stop'.
--- RBK0081I: Creating backup of type dd in /backup/fhem/fhem-dd-backup-20180504-165640.
--- RBK0085I: Backup of type dd started. Please be patient.
--- RBK0007I: Starting services: 'service apache2 start %1%1 service fhem start %1%1 service smbd start'.
--- RBK0010I: fhem: raspiBackup.sh V0.6.3.2 (5659ee1) stopped at Fri 4 May 17:15:08 CEST 2018.
--- RBK0017I: Backup finished successfully.


Viele Grüße,
Heiko
#1053 framp 2018-05-04 17:59
Moin heikoh81,

das ist merkwürdig, denn es wird in beiden Faellen das Standard dd Tool benutzt. Ich vergleiche gerne die beiden Codestaende. Vielleicht finde ich ja irgendwas. Dazu brauche ich aber die genauen Codestaende die Du benutzt. Gibt mir bitte von beiden benutzten Versionen die Ausgabe von
Code:raspiBackup.sh -h | grep ^raspiBackup

Cu framp
#1052 heikoh81 2018-05-04 17:47
Hallo framps,

ich setze einen Raspi3b+ mit relativ frisch aufgesetztem Raspbian Stretch ein.

Mit 0.6.3.2 läuft das dd-Backup mit sehr guter Performance durch. Auf eine NFS-Freigabe auf meinem Qnap212p teilweise mit 23 Mbit, was für einen Raspi ja sehr gut ist.

Nun Update gemacht 0.6.3.2a.
Unter gleichen Voraussetzungen läuft das Backup extrem langsam, und in Schüben. D.h. es werden mal 200MB aufs Qnap geschrieben, aber dann passiert wieder ewig gar nichts (ich sehe die ein- und ausgehenden Daten im Qnap Control Panel).

Da dies meine produktive Haussteuerung ist, ist eine derart lange "Downtime" für ein Backup nicht wünschenswert.

Sofort wieder 0.6.3.2 aus dem Backup wiederhergestellt - raspibackup läuft wieder mit "voller Geschwindigket".

Hat dieses Problem sonst noch jemand?
Kannst du bitte mal danach schauen und das Problem beheben?

Dies sind meine Aufrufe:
Code:sudo mount 192.168.178.204:/raspibackup /backup
sudo raspiBackup.sh -a "service apache2 start && service fhem start && service smbd start" -o "service apache2 stop && service fhem stop && service smbd stop" -u "--exclude=/backup/*" -p "/backup" -t dd



Viele Grüße,
Heiko
#1051 framp 2018-05-03 20:48
Moin Tobi,

Moin Tobi,

vermutlich meinst Du die Backwardkompatibilitaet mit den Optionen
Code:RSYNC_IGNORE_ERRORS
TAR_IGNORE_ERRORS


Diese ist in der aktuellen Version 0.6.3.2a enthalten (Siehe dazu hier). Lade einfach die aktuelle Version runter ;-)

Allerdings empfehle ich lieber die Ursache zu beseitigen und diese Optionen nicht zu benutzen.

Cu framp
#1050 framp 2018-05-03 20:45
Moin Matthias,

solange Du nichts manuell an den Backupdateien aenderst kann durch die Hardlinks nichts durcheinandergebracht werden.
Der tar Debug Modus wird mit der Option Code:-veingeschaltet. Alternativ kannst Du die Option Code:-g benutzen. Siehe Details zu den Optionen hier :-)

Cu framp
#1049 Tobi 2018-05-02 11:28
Hallo

Ich erhalt die RC1 Fehlermeldung. Ich hätte gerne den hotfix zugeschickt.

Danke
Tobi
#1048 Matthias 2018-04-30 20:02
Moin framp,

ich habe mir die Partition anscheinend mit anderen Versuchen unbrauchbar gemacht, vielleicht lag daran auch das Problem mit den Hardlinks. Ich habe den Stick noch einmal neu formatiert und das Backup vom lokalen Raspi läuft. Allerdings scheint das Backup von einem anderen Rechner ewig zu dauern bzw. einfach keinen Fortschritt mehr zu machen. Gab es nicht irgendwie eine Möglichkeit, die verbose-Ausgabe vom tar anzuzeigen? Damit könnte ich das Problem vielleicht eingrenzen.

Vielen Dank,
Matthias
#1047 framp 2018-04-22 19:39
Moin Matthias,

das ist merkwuerdig :sad:

Da es leider mit dem tar Backup immer wieder Probleme gibt kann mittlerweile auch ein rsync Backup ohne Hardlinksupport erstellt werden. Wenn allerdings Hardlinks moeglich sind werden sie benutzt und wenn keine benutzt werden koennen wird eine entsprechende Meldung ausgegeben.

Um Dir sagen zu koennen was genau die Ursache des von Dir geschilderten Verhaltens ist benoetige ich ein Debuglog. Benutze bitte einmal zusaetzlich die Option
Code:-l debug
und schicke mir das Debuglog zu. Die eMail findest Du auf meiner Kontaktseite ;-)

Cu framp
#1046 Matthias 2018-04-22 19:29
Hallo framp,

nach einiger Zeit reibungslosen Betriebs ist mir meine USB-Festplatte ausgestiegen und ich musste auf einen 64GB Stick ausweichen. Leider klappen dort die Hardlinks irgendwie nicht. Weißt du vielleicht, woran das liegen könnte? Ich habe auch extra vor dem Test den Stick nochmal neu mit ext4 formatiert.
Hier die Ausgabe auf meiner Konsole:
```
pi@Pimatic:~ $ sudo raspiBackup.sh
--- RBK0009I: Pimatic: raspiBackup.sh V0.6.3.2a (1d77d56) um So 22. Apr 14:41:00 CEST 2018 gestartet.
--- RBK0151I: Backuppfad /mnt/Backup wird benutzt.
--- RBK0036I: Partitionslayout wird gesichert.
--- RBK0158I: rsync Backup "/mnt/Backup/Pimatic/Pimatic-rsync-backup-20180422-144100" wird erstellt.
--- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld.
--- RBK0010I: Pimatic: raspiBackup.sh V0.6.3.2a (1d77d56) um So 22. Apr 15:44:49 CEST 2018 beendet.
--- RBK0017I: Backup erfolgreich beendet.
pi@Pimatic:~ $ sudo raspiBackup.sh
--- RBK0009I: Pimatic: raspiBackup.sh V0.6.3.2a (1d77d56) um So 22. Apr 15:45:52 CEST 2018 gestartet.
--- RBK0151I: Backuppfad /mnt/Backup wird benutzt.
--- RBK0036I: Partitionslayout wird gesichert.
--- RBK0158I: rsync Backup "/mnt/Backup/Pimatic/Pimatic-rsync-backup-20180422-154552" wird erstellt.
--- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld.
--- RBK0010I: Pimatic: raspiBackup.sh V0.6.3.2a (1d77d56) um So 22. Apr 15:53:22 CEST 2018 beendet.
--- RBK0017I: Backup erfolgreich beendet.
```
früher gab es immer noch eine Meldung über die Verwendeten Verzeichnisse für Hardlinks, das fehlt jetzt. Dadurch lief mein Stick schon einmal voll (Memo an mich selbst: ich sollte eine eMail-Benachrichtigung einrichten) und es konnten keine Backups mehr gemacht werden. In der Konfig sind Hardlinks aktiviert:
```
# Hardlinks werden für rsync benutzt (0 = nein, 1 = ja)
DEFAULT_HARDLINKS=1
```

Viele Grüße,
Matthias
#1045 framp 2018-04-06 12:32
Moin Christian,

das habe ich leider vergessen zu dokumentieren :oops: . Ich werde das nachholen.

Definiere in der Config:
Code:
TAR_IGNORE_ERRORS="1"


Der Vollstandigkeit halber: Fuer rsync ist es
Code:
RSYNC_IGNORE_ERRORS="23 24"


Sorry for the inconvenience.

Cu framp
#1044 Christian 2018-04-06 11:02
Hallo,
ich bekomme seit der Version 0.6.3.2 auch die Fehlermeldung: "Backupprogramm des Typs tar beendete sich mit RC 1".
Nun habe ich den hotfix installiert, aber ich kann nirgends die Option finden, wo ich die RCs ignorieren kann. Wie stelle ich das an?
Beste Grüße
Christian
+1 #1043 framp 2018-04-01 21:47
Moin phiomet,

wie Du schon richtig erkannt hast ist das kein raspiBackup Problem sondern nfs Konfig Problem und letztendlich ein Berechtigungsproblem :-)

Versuche mal
Code:rw,sync,no_subtree_check,no_root_squash
in Deiner /etc/exports ;-)

Cu framp
#1042 phiomet 2018-04-01 21:05
Servus aus Wien,

erstmal danke für das echt tolle Tool. Ich verzweifel aber langsam an RSYNC.

Ich hab im Log immer wieder stehen:

Zitat:
rsync: chown "/backup/raspberrypi/raspberrypi-rsync-backup-20180401-174928/etc/alternatives/rmid" failed: Operation not permitted (1) rsync: chown "/backup/raspberrypi/raspberrypi-rsync-backup-20180401-174928/etc/alternatives/rmid.1" failed: Operation not permitted (1) rsync: chown "/backup/raspberrypi/raspberrypi-rsync-backup-20180401-174928/etc/alternatives/rmiregistry" failed: Operation not permitted (1) rsync: chown "/backup/raspberrypi/raspberrypi-rsync-backup-20180401-174928/etc/alternatives/rmiregistry.1" failed: Operation not permitted (1)
und nach einer Weile bleibt er bei irgendeiner Datei hängen und macht nix mehr, allerdings ist da auch keine Fehlermeldung in einem Log zu finden bis ich händisch unterbreche.

Das ganze läuft via NFS mount.

Server (Debian 9.4) /etc/exports:
Zitat:
/backup 192.168.1.0/24(rw,root_squash,subtree_check)
Pi /etc/fstab:
Zitat:
192.168.1.16:/backup /backup nfs rw,async,hard,intr,noexec 0 0
Ideen?
#1041 bcutter 2018-03-20 21:04
Also, das vor Stunden gestartete TAR-Backup ist jetzt durch. Konsole (+ Log) zeigen an der einzigen Stelle (Übergang Abschluss TAR-Backup zurück zu raspiBackup):

Zitat:
/root/.bash_history
/lost+found/
/dev/
tar: /: Datei hat sich beim Lesen geändert.
??? RBK0021E: Backupprogramm des Typs tar beendete sich mit RC 1.
Ich weiss, dass unter raspiBackup v0.6.2 immer angezeigt wurde was sich geändert hat - das fehlt jetzt. Bzw. soll mir die Pfadangabe "/" wohl sagen: Irgendetwas hat sich auf jeden Fall geändert :-)

Sei´s drum: Ja, ich brauche deinen Hotfix (eMail hast du über das Formular), konkret für RC 1, da ich auch befürchte mit RSYNC das gleiche Problem zu haben. Jetzt noch weiter zu debuggen (Parameter "-l" für raspiBackup?) wäre zwar interessant, aber zunächst einmal will ich wieder überhaupt ein Backup haben.
#1040 framp 2018-03-20 20:43
Moin bcutter,

ich habe eben eingebaut dass man fuer tar und rsync bestimmte rcs wieder ignorieren kann. Damit ist raspiBackup backward compatible. Ich kann Dir also einen Hotfix zuschicken wenn Du willst. Es kann sein dass Du auch einen rc !=0 auch mit rsync bekommst und wenn DU das nicht beseitigen willst brauchst Du den Hotfix ;-)

zu 2.c: Dann ist alles OK.

symlinks werden vonn samba an Windows weitergeleitet. Es muss nur in der Samba config enabled werden ;-)

Cu framp
#1039 bcutter 2018-03-20 19:51
@framp:

Danke für deine Antworten!

Zum TAR RC 1:
Ja, das war das Stichwort. Ich stoppe und starte keine Services, obwohl ich deine FAQ dazu kenne. Grund: bei einem Restore letztes Jahr lief bis auf zwei Kleinigkeiten alles glatt. Ich bin bisher also bewusst das Risiko eingegangen und habe dafür zero downtimes während des raspiBackups gewonnen. Werde ich aber je nach Dauer des zukünftigen RSYNC-Backups ändern, kürzere downtimes sind akzeptabel.

Zu 1): OK, hab ich verstanden.
Zu 2.c): Nicht falsch verstehen: die Backup-Platte (die jetzt von NTFS auf EXT4 geändert wird) ist eine lokale Platte, direkt am Pi. Diese Platte soll über einen (unveränderten) Mounting point jedoch wieder über SAMBA an Windows-Clients geshared werden. NICHT gemeint ist jedoch, dass die Backup-Platte eine EXT4 ist die über SAMBA für den Pi erreichbar ist.
--> Ist so also unproblematisch oder? Kann Windows vielleicht mit den hardlinks nicht umgehen? Oder löst das der SAMBA intern auf - Windows sieht ja nur ein SAMBA-Share.

Danke im voraus für deinen Input dazu; bin gerade am Daten sichern und der "sudo mkfs.ext4 /dev/sda1"-Befehl steht schon bereit :-)
#1038 framp 2018-03-20 19:27
Moin bcutter,

meine Antworten ;-)

zu 1) Das ist ein inherentes Feature von rsync bzw von ext3/4. Du erhaeltst mit rsync auch pro Backup einen Snapshot. Allerdings nicht in einer komprimierten Datei sondern in einem Verzeichnis. Dabei werden unmodifizierte Dateien mit Hardlinks 'geshared' und nicht n Mal kopiert bzw gespeichert.
zu 2) Ja, nur ext3/4 unterstuetzen Hardlinks
zu a) Ja. Konvertieren geht nicht. Du musst kopieren.
zu b) Ja
zu c) Nein. Samba unterstuetzt keine Hardlinks auch wenn das zugrundeliegende Filesystem ext3/4 ist. Du musst entweder eine lokale Platte/USB Stick benutzen oder nfs.

Cu framp
#1037 framp 2018-03-20 19:17
Moin bcutter,

Du solltest weitere Details im Log sehen wenn Du die Option -l detailed benutzt. Du kannst es mir ja mal zuschicken und ich sehe nach.

Der rc 1 von tar kann alle moegliche Ursachen haben. Sehr haeufig ist es einfach eine Meldung dass sich eine Datei beim Backup geaendert hat. Diesen Fehler kann man je nach Datei durchaus ignorieren. Aber ich empfehle diese Meldung zu beseitigen durch stoppen von entsprechenden Services (Siehe auch [url=https://www.linux-tips-and-tricks.de/en/faq#a18]faq18{/url].

Ich werde eine Konfigoption fuer tar einbauen mit der man definieren kann welcher rc ignoriert wird. Wenn Du den Weg gehen moechtest lass es mich wissen und ich schicke Dir einen Hotfix zu.

Cu framp
#1036 bcutter 2018-03-20 18:03
Kleine Offtopic-Frage zu den Backup-Typen (überlege aufgrund der mittlerweile vorhandenen Datengrösse und daher der extrem langen Backupzeiten von TAR auf RSYNC umzusteigen): Das mit den Hardlinks habe ich noch nicht verstanden.

Jetzt mit TAR habe ich pro Backup einen eigenen Ordner mit einem vollständigen "Snapshot" zum Backupzeitpunkt. Der Vorteil von RSYNC ist ja das differenzielle Sichern - jedoch habe ich dann am Backupzielort genau EINE Momentaufnahme - die des letzten Backups.

Fragen:
1) Wie baust du um diese Eigenschaft mit Hardlinks "drumherum"; habe ich am Ende mit RSYNC-Backups auch wieder eine Struktur "Pro Backupzeitpunkt ein vollständiger Snapshot"? Folglich also die Möglichkeit, einen Snapshot zu restoren.
2) Muss der (ganze) Backupzielspeicherort ein ext3/ext4-Filesystem haben?

Je nachdem müsste ich nur noch
a) die Backup-Platte von NTFS auf EXT3/EXT4 konvertieren,
b) den raspiBackup-Job anpassen (-t) und
c) gucken, dass die Platte auch mit ext3/ext4 noch immer über Samba den Windows-Clients bereitgestellt werden kann,

wobei c) für dich/euch hier natürlich nicht von Interesse ist :-)
#1035 bcutter 2018-03-20 17:00
@framp:

Spannende Sache - zumal ich im Juni 2017 mit der v0.6.2 erfolgreich ein Backup restoren konnte.

Ich lasse das Backup gerade durchlaufen mit zusätzlichen "-g -v" und hoffe, von tar Infos/Indizien angezeigt zu bekommen. Das Faken mit "-F" bringt ja nichts, da es das eigentliche Backup (tar in meinem Fall) nicht triggert.

Im "raspiBackup.log" steht übrigens nicht mehr drin, als das was ich eh schon vom Laufzeit-Log gepostet habe. Laufzeit-Log heisst bei mir "/var/log/raspiBackup/Servername.log".

Irgendwie schon ironisch das ganze (mit Fehler lief das Backup inkl. Restore, mit gefixtem Fehler nicht mehr...), aber auf jeden Fall eine ungute Sache :-)
#1034 framp 2018-03-19 20:44
Moin bcutter,

in v0.6.2 war ein Bug drin der dazu geführt hat dass tar Fehler nicht zum Abbruch gefuehrt haben :oops: . Das ist nun gefixed.
Du solltest dringend nachsehen warum Du einen RC 1 vom tar bekommst. Die Details stehen im raspiBackup.log. Oder Du benutzt noch zusaetzlich die Option -v um die tar Fehlermeldung zu bekommen.

Cu framp
#1033 framp 2018-03-19 20:31
Moin Krakas,

der Test dient dazu zu prüfen ob Sym- und Hardlinks unterstützt werden. Per CIFS werden keine Hardlinks unterstützt. Siehe dazu auch FAQ19

D.h. Du musst entweder Deinen Backupspace per nfs mounten oder den tar Backup nehmen ;-)

Cu framp
#1032 Karkas 2018-03-19 11:32
Das Script funktioniert nicht im Rsync modus. Backup verzeichnis ist /backup, ein per CIFSmount eingebundenes NAS. Nach dem Starten kommt der Fehler:

ln: die symbolische Verknüpfung '//backup/raspiBackup.slinklink' konnte nicht angelegt werden: Keine Berechtigung

Warum sind da zwei Slashe? ein "touch /backup/test" funktioniert problemlos
+1 #1031 bcutter 2018-03-19 01:07
Hi raspiBackup-Meister :)

Nachdem ich vor einigen Tagen von v0.6.2 auf v0.6.3.2 aktualisiert habe, musste ich nun feststellen, dass meine Backups nicht mehr laufen.

1) Zunächst scheint sich an der Syntax etwas geändert zu haben (-a und -o), das habe ich gefixt (glaube ich, siehe unten).
2) Dennoch läuft das Backup nicht mehr durch - am Ende des TAR-Backup wird alles wieder gelöscht.

Aufruf vorher:
/usr/local/bin/raspiBackup.sh -a: -o: -t tar -k 20 -N "PushingBox_NotifyBackup" /mnt/backup/target

Aufruf jetzt:
/usr/local/bin/raspiBackup.sh -a " " -o " " -t tar -k 20 -N "PushingBox_NotifyBackup" /mnt/backup/target

Auszug ab der interessanten Stelle des Laufzeit-Logs:
--- RBK0085I: Backuperstellung vom Typ tar gestartet. Bitte Geduld.

??? RBK0021E: Backupprogramm des Typs tar beendete sich mit RC 1.
--- RBK0043I: Unvollständiges Backup /mnt/backup/target/raspberry-tap-20180318-212328 in wird gelöscht. Das wird etwas dauern. Bitte Geduld.
--- RBK0105I: Neues Backupverzeichnis /mnt/backup/target/raspberry-tap-20180318-212328 wird gelöscht.
??? RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen.

Wo ist der Fehler? Was will mir "RC 1" von tar sagen?

Fun fact:
Fake ich das Backup (-F), läuft es erfolgreich durch. Das macht das tar-Backup selbst wieder höchst verdächtig...

Freue mich über Licht im verzweifelten Dunkel! :)
#1030 Kai 2018-03-18 13:52
Hallo framp,
vielen Dank, dann entscheide ich mich für die gefixte Variant :-)
meine voller Befehl lautet:
sudo raspiBackup.sh -a : -o : -m detailed -c -u "--exclude=/backup/*" -s sendEmail -E "-f mail@mydomain.de -s smtp.myprovider.de -xu mail@mydomain.de -xp GEHEIM" -e mail@mydomain.de -A
Vielen Dank im voraus

Viele Grüße
Kai
#1029 framp 2018-03-18 13:43
Moin Kai,

leider ja :oops: Eine kleine CodeZeile fehlt genau bei -V. Wenn Du mir noch zeigst wie Dein -E Parameter aussieht kann ich das auch noch fixen und Dir eine Version von 0.6.3.2 zuschicken wo alles gefixed ist. D.h. Du kannst dann entscheiden ob Du zurueckgehen willst oder die gefixte Version benutzt :-)

Cu framp
#1028 Kai 2018-03-18 13:24
Hallo framp,
danke für deine schnelle Antwort!
Ich habe probiert, die Option -u wegzulassen allerdings habe ich dann bei der -E Option das nächste Problem :-(
Die -E Option habe ich meinem vorigen Beitrag verschwiegen, weil es irrelevant war.
Also habe ich mich entschlossen die vorige Version zu nutzen. Doch mit dem Befehl "sudo raspiBackup.sh -m detailed -V" wirkt es so, als würde garnichts ausgeführt werden. Auch nach 5 Minuten terminiert der Befehl nicht. Da hilft dann nur noch STRG + c...

Habe ich noch einen Bug gefunden oder ist es das selbe Problem mit dem Optionsparser?

Gibt es noch eine andere Möglichkeit auf die vorige Version zurück zu wechseln?

Viele Grüße
Kai
#1027 framp 2018-03-18 12:41
Moin Kai,

in der neuen Version habe ich den Optionsparser erweitert und in der Tat: Du hast einen Bug gefunden :oops:

Es gibt jetzt zwei Möglichkeiten für Dich:
1) Du gehst auf die vorherige Version mit -V zurueck
2) Du benutzt im Konfigfile DEFAULT_EXCLUDE_LIST="--exclude=/backup/*" und lässt -u "--exclude=/backup/*" beim Aufruf weg.

Allerdings wundere ich mich etwas. Denn raspiBackup excluded automatisch den Backuppfad. D.h. Du müsstest /backup nicht excluden.

Anyhow: Nun muss ich ueberlegen wie ich das fixe. :o

Cu framp
#1026 Kai 2018-03-18 12:22
Hallo,
leider funktioniert das Backup bei mir nicht mehr nach der Aktualisierung auf die neue Version 0.6.3.2

meine Aufruf:
raspiBackup.sh -a : -o : -m detailed -c -u "--exclude=/backup/*"

Bei der Ausführung erhalte ich folende Meldung:
??? RBK0090E: Option -u erwartet ein Argument.

Mache ich was falsch oder habe ich einen Bug gefunden?

Viele Grüße
Kai
#1025 framp 2018-03-14 19:06
Moin Marco,

freut mich dass es jetzt läuft. In die Default Config habe ich es mit Absicht nicht aufgenommen weil jeder Benutzer sich mit dem Thema auseinandersetzen und eine Entscheidung treffen soll. In der FAQ Section ist das Thema ausgiebig behandelt ;-)

Cu framp
#1024 Marco 2018-03-14 16:47
Hallo framp,

danke für die Nachricht. Es scheint jetzt zu laufen. Musste bei den Vor- und Nachbefehlen noch in der Config einen ":" einbauen. Hatte es irgendwo hier bei den Kommentaren gelesen. Vielleicht kannst du das ja in die default Config aufnehmen.
#1023 framp 2018-03-13 22:23
Moin Marco,

Du solltest eigentlich vorher noch eine meldung haben die auf die Ursache eines Fehlers, der zum Löschen führt, hinweist. Welche Meldungen bekommst Du denn alles? Falls Du keine weitere Fehlermeldung bekommst rufe raspiBackup noch mit den Optionen
Code:-l debug -L current auf und schicke mir das Debuglog zur Analyse an emine eMail zu. Die eMailAdresse findest Du auf der Kontaktseite.

Cu framp
#1022 Marco 2018-03-13 09:03
Hi,

probiere gerade das Skript aus. Komme aber nicht weiter. Versuche ein TGZ des Raspberrys zu erstellen und auf einen Samba Share abzulegen. Habe die Standardkonfiguration genommen und nur den Sicherungspfad angepasst. Doch irgendwie versucht er ein Verzeichnis gleich am Anfang zu löschen anstatt es zu erstellen.

--- RBK0105I: Neues Backupverzeichnis /mnt/smb/ls-wxl/Sicherung/pi.garage/pi.garage-tgz-backup-20180313-090021 wird gelöscht.
#1021 Andreas 2018-03-13 05:22
Hallo Framp,

tausend Dank für die schnelle Hilfe - erneutes Runterladen hat geholfen! Jetzt läuft das Backup wieder korrekt durch.

Grüße, Andreas
#1020 framp 2018-03-12 19:37
Moin Andreas,

da bist Du aber einer von der fixen Sorte gewesen :-) Über Nacht ist bei mir auch genau derselbe Fehler aufgetreten. Ich hatte noch kurz vor dem Publish einen kleinen Fix eingebaut und leider damit das Problem verursacht. Am darauffolgenden Morgen habe ich es sofort gefixed.

Fix:
Entweder reinstallierst Du noch einmal die 0.6.3.1 mit Option -V und rufst dann die alte Version noch einmal mit der Option -U auf um die neue Version zu installieren oder Du lädst Dir die aktuelle Version manuell runter und kopierst sie auf /usr/local/bin.

Sorry for the inconvenience :oops:

Cu framp
#1019 Andreas 2018-03-12 18:20
Hallo framp,

bei mir funktioniert das Backup leider nicht mehr seit dem Update auf 0.6.3.2:

Nach dem Aufruf mit "sudo /usr/local/bin/raspiBackup.sh" wird Folgendes ausgegeben.

--- RBK0009I: XXX.local: raspiBackup.sh V0.6.3.2 (82cc58d) um Mo 12. Mär 17:59:20 CET 2018 gestartet.
raspiBackup.sh 0.6.3.2, 2018-03-10/19:28:48 - 82cc58d
Aufruf: raspiBackup.sh [Option]* {Backupverzeichnis}

-Allgemeine Optionen-
-A Logfile wird in eMail angehängt (Standard: nein)
...
Hier wird der komplette Text von "usageDE" ausgegeben und dann ist Schluss. Es wird keine Logdatei erstellt und auch kein Backup. Was mache ich falsch?

Danke für Eure Hilfe, Andreas
#1018 Philipp 2018-03-11 21:40
zitiere framp:
Moin Philipp,

vielen Dank für den Hinweis denn Du hast mich damit auf eine Sache hingewiesen die ich schlichtweg vergessen habe beim Publishen der neuen Version 0.6.3.2 :oops: - die beiden Konfigdateien (DE & EN) mit den neuen Optionen zu versehen. Ich werde es noch heute tun. :-)

Morgen wirst Du dann die Datei runterladen können. Ein automatischer Merge der neuen Optionen in die Konfigdatei wäre sicherlich schön - aber den gibt es nicht. Ich schreibe das mal als Issue ins git.

Cu framp


Hi framp,

kein Stress, gerne doch :)

Wie du möchtest, allerdings ist das manuelle hinzufügen ja auch kein Problem, ein bisschen Arbeit kriegen wir schon noch hin, sonst wird es ja auch langweilig :-)

Grüße
+1 #1017 framp 2018-03-11 18:32
Moin Philipp,

vielen Dank für den Hinweis denn Du hast mich damit auf eine Sache hingewiesen die ich schlichtweg vergessen habe beim Publishen der neuen Version 0.6.3.2 :oops: - die beiden Konfigdateien (DE & EN) mit den neuen Optionen zu versehen. Ich werde es noch heute tun. :-)

Morgen wirst Du dann die Datei runterladen können. Ein automatischer Merge der neuen Optionen in die Konfigdatei wäre sicherlich schön - aber den gibt es nicht. Ich schreibe das mal als Issue ins git.

Cu framp
#1016 Philipp 2018-03-11 18:24
Hi framp,

eine (für dich hoffentlich einfache) Frage die ich selbst nicht so ganz heraus bekommen habe. Ich nutze seit der Installation von RB die Config Datei, alles soweit super, mit der neuen Version 0.6.3.2 ist z. B. die Funktion Timestamps dazu gekommen. Da sich die Konfig Datei allerdings nicht ändert (logischerweise) bei einem Update fehlt auch die zusätzliche Syntax.

Selbst ergänzen ist natürlich kein Problem, allerdings würde mich interessieren ob ich die Default Datei auch irgendwo von dir beziehen kann um sie abzugleichen und einfach neue Funktionen (falls vorhanden) selbst nachzutragen.
Diesen Link habe ich als erstes versucht https://www.linux-tips-and-tricks.de/downloads/raspibackup-de-conf/download , da ist die Datei noch in alter Version, vielleicht hast du sie auch nur noch nicht ausgetauscht, dann siehe die Frage gerne als gegenstandslos an :)

Einen schönen Sonntag wünsche ich noch und wie immer danke für dein geniales kleines Tool (was mir schon öfter den Arsch + heimischen Frieden gerettet hat :D)

Grüße
#1015 framp 2018-02-28 19:46
Moin Dennis,

kann ich gerne machen. So wie ich das sehe ist das kein grosser Aufwand. Allerdings brauche ich jemanden der die Funktion dann auch testet. Wenn Du mir versprichst das zu tun gehe ich es an.
In der Vergangenheit gabe es leider vermehrt Anfragen nach neuer Funktion und dann hat sich derjenige klanglos verpieselt :o so dass ich jetzt nicht mehr einfach so neue Funktionen einbaue.

Cu framp
#1014 Dennis G 2018-02-28 14:07
Hallo,

Leider wird MSMTP nicht unterstützt als Mail Client, wohl aber SSMTP.
SSMTP wird schon seit Jahren nicht mehr weiterentwickelt und MSMTP ist der direkte Nachfolger. Bitte auch MSMTP inkludieren bei den erlaubten Mail clients.

Cheers,
Dennis
#1013 Avaatar 2018-02-03 21:17
Hi Framp,

ja hast Du, vielen lieben Dank :) Aktuell arbeite ich daran von meiner Workstation (Windows) per Task und plink dd aufzurufen und das Ergebnis direkt zu übertragen, was aber nicht einfach ist. Aber ich habe schon eine Idee :)

Schönen Abend noch.
#1012 framp 2018-02-03 20:36
Moin Avaatar,

ich persoenlich benutze rsync weil das die beste Kombination aus Backupzeit und benutzem Backupplatz ist.

Bei Samba kannst Du kein rsync benutzen. Dazu brauchst Du nfs. D.h. fuer Dich gibt es nur tar oder dd. tar verkleinert das Backup. Bei dd wird immer die ganze SD Karte gesichert. Du kannst es aber minimieren wenn Du FAQ 16 liest.

Viele Windowsbenutzer nehmen den dd Backup weil der auch unter Windows mit dem win32diskimager restored werden kann.

Ich hoffe ich habe Dir ein wenig die Unterschiede aufzeigen können. :-)

Cu framp
#1011 framp 2018-02-03 20:27
Moin G. Neiß,

das ist schlecht mit der Fehlermeldung :oops:

Schicke mir bitte das Log welches Du mit der Option -l erstellt hast zur Analyse an meine eMailAdresse zu. (Siehe eMail auf der Kontaktseite)

u framp
#1010 framp 2018-02-03 20:23
Moin G. Neiß,

es gibt dazu schon ein Issue in github. Leider bin ich bislang noch nicht dazu gekommen den zu behandeln :sad:

Ich werde es aber als nächstes angehen :-)

Cu framp
#1009 G. Neiß 2018-02-03 20:18
... und noch ein Problem :-(
Beim Versuch des Rückspielens eines tgz Backups, kommt die Fehlermeldung (-l debug -v)
tar (child): --xattrs: Cannot open: No such file or directory
#1008 Avaatar 2018-02-03 18:55
Vielen Dank für das Skript, ich glaube es wird sehr nützlich sein. Ich kann mich allerdings nicht für einen Backupmodus entscheiden. Auf meinem Raspberry läuft Raspbian mit einem Samba 4 als Active Directory Domain Controller. Eventuell kommt noch DHCP dazu. Welcher Backupmodus (dd, tar,rsync) ist hier der geeignete? Da ich stark aus der Windows Welt komme tendiere ich zu dd. Ist das falsch?

Viele Grüße.
#1007 G. Neiß 2018-02-03 18:41
Beim ersten Austesten fällt mir auf, das es zwar einen Parameter zum einschalten der Komprimierung (-z), aber keinen zum ausschalten gibt. Hat man das in der conf eingeschaltet kann man nicht "mal eben" ein unkomprimiertes erzeugen, sondern muss die conf ändern.
In meinem Anwendung nutze ich als Standard tgz, Für eine Gesamtsicherung möchte ich jedoch (via Command) schnell ein dd backup erzeugen.
#1006 framp 2018-01-31 20:44
Moin Paul,

mit raspiBackup nur wenn das Backup von einer Raspi3 die ohne SD Karte bootet erstellt wurde.

Cu framp
#1005 Paul 2018-01-31 20:01
Kann ich ein Backup einer SD-Kartex auf einen USB-Stick zurückspielen?
#1004 framp 2018-01-31 19:42
Moin Paul,

das kann icht an den Extended Attributes liegen. Da bekommst Du später im laufenden Linux u.U. Probleme. Ich vermute die SD Karte ist defekt. Das ist bei meinen Restoretests damals auch öfter aufgetreten. Wenn man eine SD Karte häufig beschreibt wie ich es bei den Restoretests getan habe strecken die Karten irgendwann den Löffel. Es gibt sogar irre Effekte dass das Linux zwar startet aber Du keine Datei mehr ändern kannst weil der Superblock auf der SD Karte defekt ist :sigh:

Cu framp
#1003 Paul 2018-01-31 15:26
Ich wollte wieder mal ein Backup zurückspielen, aber jetzt komme ich auf gar keinen grünen Zweig mehr.
Immer dieser blinkende Cursor nach dem Raspbian-Bootlogo und einigen Zeilen Boot-Ausgabe ohne Fehler.

Die Extended Attributes sind sowohl am Hilifssystem ausgeschalten als auch in dem zurück zu spielenden Raspbian.

Wer hat noch Tipps für mich? Ich bin mittlerweile ratlos.


zitiere framp:
Moin Paul,

es ist eine Vermutung und ich glaube aber eher nicht. Es gab schon verschiedentlich Anfragen zum Thema xattr. Da verweigerte aber rsync den Backup und raspiBackup brach auch mit einer Fehlermeldung ab.
Wie sehen denn die Fehlermeldungen im syslog aus?

Cu framp
#1002 framp 2018-01-19 19:17
Moin Fredi69,

das ist dumm :cry: . Ich hatte Deine Antwort dass es ohne sudo nun funktioniert so interpretiert dass es nun OK ist.

es scheint ja ein Morseverhalten zu sein - lang - kurz - lang - kurz. Ist das richtig?

In jedem Falle lass doch mal den Backup immer mit
Code:-l debug -L backup laufen und schicke mir die Logs von einem langen und einem kurzen Backuplauf zur Analyse zu.

Solltest Du einen rsync Backup erstellen könnte es sein dass aus irgendeinem grunde Probleme mit den Hardlinks existieren. Beim rsync werden normalerweise nur Dinge kopiert die sich geändert haben. Ausser es liegt kein vorhergehender Backup vor auf den mit Hardlinks gezeigt werden kann.

Cu framp
#1001 Fredi69 2018-01-19 08:35
zitiere framp:
Fredi's Problem ist gelöst :-) Es ist momentan technisch noch nicht klar warum der Backup per cron viel länger dauert. Aber nachdem Fredi die sudo's in der -a und -o Parametern entfernt hatte lief alles wieder wie immer.

Leider hat sich das Problem nicht gelöst.
Ich mache wöchentlich ein Backup, hier mal die Laufzeiten der letzten 4 Wochen:
KW52 Laufzeit 29 Minuten
KW 1 Laufzeit 186 Minunten
KW 2 Laufzeit 22 Minuten
KW 3 Laufzeit 370 Minuten

Es hat sich am System oder Konfiguration nichts zwischendurch verändert. Kann sich das jemand erklären?
Vielen Dank für die Unterstützung.
Fredi
#1000 framp 2018-01-11 18:48
Moin Chris,

das ist natuerlich dumm :-/

Irgendwie sieht es so aus als waere Deine Kopieraktion auf die NAS wohl die Ursache. Am leichtesten waere es fuer mich wenn Du ein raspiBackup Log von dem Backup haettest wo die Services nicht gestartet wurden. Einfach die Optionen -l debug -L backup angeben. Dann findest Du das Log dort wo auch das Backup abgelegt wurde.

Ist denn raspiBackup fertig geworden oder lief das noch? Es kann auch sein dass einer der Services beim Starten einen Fehler bekommen hat. Hast Du da mal in den Logs nachgesehen? Dann solltest Du aber auf alle Faelle eine Fehlermeldung von raspiBackup bekommen haben.

Kurzum:

1) Pruefe ob nicht einer oder mehrere Services beim Starten ein Problem bekommen haben (->/var/log/syslog bzw mysql und apache logs)
2) Schalte einfach mal das Loggen immer an und wenn der Fehler wieder auftritt schicke mir das Log zu (eMail auf der Kontaktseite)

Cu framp
#999 Christian Wulff 2018-01-11 08:04
Moin Framp,

ich hab da eine komische Sache….
Mein Volkszähler läuft nun seit über einem Jahr.

Ich lasse täglich um 2:00h per cron ein Backup mit raspiBackup auf eine angeschlossene SSD erstellen.
Alles kein Problem.

Gestern habe das Backup von der SSD auf ein NAS kopiert.
Der Kopiervorgang war um 0:30h abgeschlossen.
Dann wurde wieder um 2:00h das Backup erstellt.
…..und aus

Der Raspi läuft noch, aber es werden keine Daten mehr gespeichert und ich kann über die middleware auch keine Daten mehr runterladen.
Hab mir dann mit pstree die laufenden Prozesse angesehen und sehe das da was fehlt.
Hab dann die drei Services wieder gestartet mit
sudo service mysql start
sudo service apache2 start
sudo service vzlogger start
Dann life es wieder.
Hab dann aber zur Sicherheit nochmal
sudo reboot now
zum neu starten gemacht.
Nun läuft auch wieder alles wie gewohnt.

Aber warum passiert das?
Das interessante ist, das ich das beim letzten Mal genauso hatte. Da hat dann ein reboot geholfen.

Beim raspiBackup werden die Services gestoppt und nach dem Backup wieder gestartet.
Funktioniert täglich einwandfrei seit über einem Jahr.
Die Services werden aber scheinbar nicht mehr neu gestartet, wenn ich vorher die Backupdateien von der SSD auf das NAS kopiere (nicht verschiebe).

Das kann ich nicht nachvollziehen, was das Problem ist.

Hast du vielleicht eine Idee?

Lieben Gruß,
Chris
+1 #998 framp 2018-01-10 19:36
Moin Christian,

es gibt jetzt eine neue InstallerVersion bei der man die Installationsverzeichnisse mit den Optionen -C, -E und -B angeben kann. Ausserdem bekommst Du eine Meldung wenn ein Installationsverzeichnis nicht existiert.

Wenn es immer noch Probleme gibt brauche ich das Installationslog ;-)

Cu framp
+1 #997 framp 2018-01-10 17:46
Moin Christian,

Es sieht so aus als gibt es /usr/local/bin nicht. Welches OS benutzt Du?

Cu framp
#996 framp 2018-01-10 17:23
Moin Christian,

Kannst du mir noch den log zeigen? Dann ist es einfacher für mich dein Problem zu finden.

Cu framp
#995 Christian 2018-01-10 16:58
Ich bekomme leider folgenden Fehler:
--- RBI0032I: Checking if there is a beta version available.
--- RBI0014I: Downloading raspiBackup.sh...
mv: failed to access '/usr/local/bin/raspiBackup.sh': Not a directory
??? RBI0019E: mv of /usr/local/bin/raspiBackup.sh failed.
--- RBI0021I: See logfile ./raspiBackupInstall.log for details.
--- RBI0022I: Cleaning up...
rm: cannot remove '/usr/local/bin/raspiBackup.sh': Not a directory
??? RBI0016E: Installation of raspiBackup failed. Check ./raspiBackupInstall.lo$
#994 Jerome 2018-01-10 10:03
Many thx. Werde ich heute Abend testen !
#993 framp 2018-01-09 20:12
Moin Jerome,

Du brauchst mir kein Log mehr zuzuschicken. Ich konnte Deinen Installationsfehler reproduzieren und er ist jetzt gefixed. ;-)

Cu framp
#992 framp 2018-01-09 17:23
Moin Jerome,

Das habe ich aus deinen ersten Kommentar lesen können. Wenn du das log noch hättest würde das mir sehr helfen. Der zweite Kommentar hat mich verwirrt. D.h. Also dein Backup funktioniert jetzt?

Cu framp
#991 Jerome 2018-01-09 14:45
Wollte damit nur aufzeigen, das die StandardInstallationsProzedur auf meinem Raspi3@RaspbianStretchLite fehlgeschlagen ist.
Deswegen habe ich händisch versucht zu installieren/ans fliegen zu bekommen
#990 framo 2018-01-08 21:51
Moin Jerome,

Jetzt weiss ich nicht was Deine Kommentare mir sagen sollen. :sad:

Cu framp
#989 Jerome 2018-01-08 20:29
Die SSD hat nur 2 Partitionen:

sda1
sda2 = RootFS
#988 Jerome 2018-01-08 20:28
Hi,

danke für die schnelle Rückmeldung.
Code:pi@rpi3ssd:~ $ sudo raspiBackupInstall.sh
--- RBI0001I: raspiBackupInstall.sh 0.3.6.5, 2018-01-04/21:06:54 - dbfcf04
--- RBI0032I: Prüfung ob eine Betaversion verfügbar ist.
--- RBI0041I: Bei keiner Eingabe wird der Wert in GROSSBUCHSTABEN benutzt.
--- RBI0002I: Sprache der Meldungen (DE|en) : DE
--- RBI0003I: Normaler oder partitionsorientierter Modus (N|p) : p
--- RBI0004I: Backuptyp (tar|RSYNC) : tar
--- RBI0025I: Backup komprimieren (j|N) : j
--- RBI0006I: Anzahl der Backups (1-52) : 3
--- RBI0008I: Ausführliche Meldungen (J|n) : n
--- RBI0042I: Gewählte Konfiguration: Sprache der Meldungen: de, Backupmodus: partitionsorientiert, Backuptype: tar
--- RBI0048I: Gewählte Konfiguration: Backup komprimieren: j, Anzahl Backups: 3, Ausführliche Meldungen: n
--- RBI0009I: Konfiguration OK (j|N) : j
--- RBI0017I: Existierende Datei raspiBackup.sh wurde als /usr/local/bin/raspiBackup.sh.0.6.3.1.sh gesichert.
--- RBI0014I: raspiBackup.sh wird aus dem Netz geladen...
--- RBI0037I: /usr/local/bin/raspiBackup.sh wurde erstellt.
??? RBI0019E: mv von /usr/local/bin/raspiBackupInstall.sh nicht möglich.
--- RBI0021I: Siehe Logdatei ./raspiBackupInstall.log für weitere Details.
--- RBI0022I: Räume auf...
??? RBI0016E: Installation von raspiBackup fehlerhaft beendet. Prüfe ./raspiBackupInstall.log.[/code)

--- RBI0032I: Prüfung ob eine Betaversion verfügbar ist.
--- RBI0041I: Bei keiner Eingabe wird der Wert in GROSSBUCHSTABEN benutzt.
--- RBI0002I: Sprache der Meldungen (DE|en) : --- RBI0003I: Normaler oder partitionsorientierter Modus (N|p) : --- RBI0004I: Backuptyp (tar|RSYNC) : --- RBI0025I: Back$
--- RBI0048I: Gewählte Konfiguration: Backup komprimieren: j, Anzahl Backups: 3, Ausführliche Meldungen: n
--- RBI0009I: Konfiguration OK (j|N) : --- RBI0017I: Existierende Datei raspiBackup.sh wurde als /usr/local/bin/raspiBackup.sh.0.6.3.1.sh gesichert.
--- RBI0014I: raspiBackup.sh wird aus dem Netz geladen...
--- RBI0037I: /usr/local/bin/raspiBackup.sh wurde erstellt.
cp: '/usr/local/bin/raspiBackupInstall.sh' und '/usr/local/bin/raspiBackupInstall.sh' sind die gleiche Datei
??? RBI0019E: mv von /usr/local/bin/raspiBackupInstall.sh nicht möglich.
--- RBI0021I: Siehe Logdatei ./raspiBackupInstall.log für weitere Details.
--- RBI0022I: Räume auf...
??? RBI0016E: Installation von raspiBackup fehlerhaft beendet. Prüfe ./raspiBackupInstall.log.


Da wurde ich überhauptnicht nach dem BackupPfad gefragt. Also habe ich ihn händisch in raspiBackup.sh geändert..war wohl der falsche Weg...
#987 framp 2018-01-08 19:56
Moin Jerome,

die Meldung "RBK0027E: Kein externes Gerät an %1 verbunden. Die SD Karte würde für das Backup benutzt werden." zeigt, dass Du keine externe Partition auf /media/fritz/backup gemounted hast. Hast Du den Backuppfad auch in der Konfig geaendert - oder als Aufrufparameter mitgegeben ? Der Default ist /backup. Mit
Code:mount
kannst Du sehen welche Partitionen wo gemounted sind.

Cu framp
#986 Jerome 2018-01-08 19:41
Hallo,

der Raspi3 kann auch ohne SD-Karte betrieben werden. Z.B. mit einem USB-Stick oder einer SSD@USB.
Dabei RootFS ist dann auf sda2, und boot auf sda1 installiert (statt mmcblk0p1 /p2).

Ich wollte jetzt das Script testen, leider bekomme ich als Fehlermeldung "RBK0027E".

Als BackupPfad habe ich ein gemountetes Verzeichnis /media/fritz/backup eingestellt.

Hast Du eine Idee wie ich hier weiterkomme ?

LG
J.
+1 #985 framp 2018-01-04 05:27
Moin codiak,

Lösche mal die Datei /var/lock/raspiBackup. :-)

Cu framp
#984 codiak 2018-01-04 01:29
Hallo,

ich bekomme seit kurzem die Meldung:
MSG ??? RBK0015E: Es ist schon eine Instanz von raspiBackup aktiv.
Ich kann keinen laufenden Prozess erkennen. Ich habe raspiBackup auch schon einmal de- und neu installiert. aber die Meldung bleibt bestehen.
#983 framp 2018-01-02 21:21
Moin Frank,

das ist ein Schutz damit man nicht aus Versehen sein Backup auf der SD Karte bzw der externen Rootpartition ablegt, denn das Backup sollte natuerlich auf einem separaten Geraet angelegt werden.

Du musst Deine Backuppartition auf /backup gemountet haben. Dazu gibt es den Befehl Code:mount. Bei mir sieht dann das Ergebnis z.B. so aus (eine per nfs gemountete Partition):
Code:
raspifix:/backup on /backup type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=14,retrans=2,sec=sys,clientaddr=192.168.178.123,local_lock=none,addr=192.168.178.10)


Cu framp
#982 Frank 2018-01-02 20:59
Hallo,

erst einmal ein großes Dankeschön für die Veröffentlichung und Weiterentwicklung von raspiBackup.

Aber nun zum Grund für meinen Post: Ich habe raspiBackup installiert, bekomme es aber nicht zum (fehlerfreien) Laufen:

Ausgangskonfiguration: 1 Raspi 2b, eine SD-Karte für's Booten, eine USB-Platte mit einer normalen Partition und einer Swap-Partition.

Beim starten des Backup's (mit Option -F) bringt das Skript immer den Fehler RBK0027E - kein externes Gerät an /backup gefunden. Andere Fehlermeldungen tauchen nicht auf.

Ich habe die Vermutung, dass die Ursache bei meiner Konfiguration mit der USB-Platte liegt und suche jetzt einen Ratschlag zur Behebung. Würde eine separate Partition auf der gleichen Platte für /backup reichen?

Ich habe schon nach einer Auflistung der Fehlernummern und deren Bedeutung gesucht, aber nichts gefunden.

Schon mal vielen Dank!
Frank
#981 framp 2017-12-13 19:08
Fredi's Problem ist gelöst :-) Es ist momentan technisch noch nicht klar warum der Backup per cron viel länger dauert. Aber nachdem Fredi die sudo's in der -a und -o Parametern entfernt hatte lief alles wieder wie immer.
#980 framp 2017-12-07 21:32
Das ist ein valides Argument pro tar. Ich werde raspiBackup dementsprechend erweitern. Kannst Du ein Issue auf githubdazu erstellen?
#979 jay 2017-12-07 21:11
naja, es kommt mir nicht auf die komprimierung an, sondern auf mögliche defekte. wenn man eine partition per dd speichert merkt man u.u. nicht wenn teile der alten oder neuen sd karte defekt sind und man dann entweder ein dateisystem mit defekten daten in seinem dd hat, oder beim schreiben solche erzeugt.
beim lesen per tar und formatieren mit badblocks schließt man das aus.
jay
#978 framp 2017-12-07 20:02
Moin jay,

das ist kein Bug sondern ein Feature :-)

Als raspiBackup anno 2013 entstand dachte ich die Bootpartition muesste binaer gespeichert werden. Mittlerweile weiss ich dass es nicht notwendig ist :-* . Es ist aber bislang keinem aufgefallen und es hat sich auch niemand dazu gemeldet.
56M ist nicht sehr gross und es lohnt sich nicht das noch zu komprimieren bei den heutigen grossen Speichermedien. Es gibt auch noch die Option DEFAULT_LINK_BOOTPARTITIONFILES mit der man die Bootpartition noch per Hardlinks sharen kann falls es wirklich auf jedes Bit ankommt ;-)

Cu framp
#977 jay 2017-12-07 03:38
hallo,
wenn ich als backupmethode tar angebe, wird die boot partition trotzdem als dd gesichert.
ist das absicht oder ein bug?
wenn ersteres, weshalb?
jay
#976 framp 2017-12-03 11:20
Moin Matthias,

Code:curl -s -L -O https://www.linux-tips-and-tricks.de/raspiBackupInstall.sh && sudo bash raspiBackupInstall.sh funktioniert. Welchen Link meinst Du?

Cu framp
#975 Matthias 2017-11-30 20:32
kann es sein dass der Link zum Skript nicht mehr funktioniert?
#974 framp 2017-11-28 20:03
Moin Fredl,

wie ich schon schrieb. Ohne ein Log von Dir kann ich nicht herausfindedn worin die Ursache liegt. Es gibt offensichtlich Umgebungsunterschiede.

Benutze Code:-l debug um das Log beim cron Job zu erstellen und schicke es mir zur Analyse an meine eMail zu (Siehe Kontaktseite).

Cu framp
#973 Fredi 2017-11-27 19:44
zitiere framp:
Moin Fredi,

Natürlich nicht :sad: schick mir bitte das debug Log zu. Emal ist auf der kontaktseite

Cu framp

Heute lief das Backup wieder über einen cronjob ca. 4h.
Kopiere ich den Cronjob und starte das gleich Backup manuell dauert es nur ca. 30 Min.
Woran kann das liegen?
#972 framp 2017-11-16 19:16
Moin Butch,

Ein Kernel Panic habe ich noch nie WG falscher partuuid gesehen. Die Raspi bleibt dann beim Booten einfach stehen. Auch sollte das raspiBackup abändern.
Bist Du sicher dass die SD Karte auf die Du Restore hast OK ist?

Ich kann mir gerne das Restore Log ansehen. Schick auch den Screenshot. Vielleicht kann ich was erkennen.

Meine e-mail findest Du auf der Kontakt Seite

Cu framp
#971 Butch 2017-11-15 20:13
Hey framp,

erstmal ein riesiges Lob für die Arbeit die du leistest.
Ich versuche momentan von dd auf rsync umzustellen.
Der Backupvorgang läuft augenscheinlich auch ohne Probleme und der Restore auf die SD zurück läuft soweit auch durch. Boote ich den RasPi jetzt von der wiederhergestellten SD bricht er den Bootvorgang mit Kernel Panic ab. Ein Foto vom Screen ist vorhanden und das Backup-Log auch.
Aber erstmal grundlegend die Frage, woran könnte das eventuell liegen? Unter /boot/cmdline.txt die falsche PartUUID bei root vielleicht oder irgendwas anderes?
Für Hilfe wäre ich sehr dankbar.

Gruß
#970 harrison 2017-11-11 00:50
Dank framps Unterstützung konnte ich meinen Fehler nun finden:
Ich habe in der /boot/cmdline.txt "PARTUUIDS" verwendet und in der /etc/fstab mit "UUIDS" gearbeitet.

Das war historisch bedingt und wurde von mir wieder mal erfolgreich verdrängt :-*
Also alles wieder gut in der Version 0.6.3.1
#969 framp 2017-11-10 19:11
Moin harrison,

ab der Version 0.6.2 wird nach dem Restore nachgesehen ob eine uuid benutzt wird und entsprechend die cmdline.txt und fstab updated. Die aktuelle Version ist 0.6.3.1. 0.3.6.2 ist asbachuralt :-) Vermutlich hast Du irgendwo einen Zahlendreher :D

Solltest Du die aktuelle Version benutzt haben ist das ein Bug. Schicke mir dann bitte das Log zu wenn Du den Restore mit der Option -l debug ausgefuehrt hast. Meine eMailAdresse findest DU auf der Kontaktseite.

u framp
#968 harrison 2017-11-10 15:58
Hallo framp,
erst mal auch von mir einen "thumps up" für das tolle Skript.
Ich verwende die aktuelle Version 0.3.6.2 und habe ein kleines Problem bezügl. des Restores (rsync-Backup erstellen klappt ohne Fehlermeldung):
raspi:
/boot: auf SD-Karte_aktuell
/: auf externer USB-Platte_aktuell

Scenario:
SD-Karte_aktuell und externe USB-Platte_aktuell: beide defekt ->
sollen durch SD-Karte_neu und USB-Platte_neu ersetzt werden
Restore wird über das letzte erfolgreiches rsync-Backup initiert.

Rsync-Restore läuft auch ohne Fehlermeldung durch, aber folgendes Problem tritt dann beim Neustart nach dem Wechseln der SD-Karte_neu auf:

Boot-Vorgang OK (PARTUUID von USB-Festplatte_neu wird korrekt in die cmdline.txt geschrieben), dass Dateisystem auf USB-Platte_neu wird jedoch nur RO gemounted.

-> Leider wird beim Restore nicht die aktuelle UUID der /-Partition von USB-Platte_neu in die /etc/fstab geschrieben, es verbleibt dort der Eintrag der UUID der /-Partition der vorherigen USB-Platte_aktuell.

Sicherlich nichts Dramatisches, aber man muss halt hier selbst noch einmal händisch nachjustieren.

Darf man auf einen Fix hoffen oder sollte man dies selber über die Pluginerweiterung lösen?

Vielen Dank.
#967 framp 2017-11-06 18:20
Moin Fredi,

Natürlich nicht :sad: schick mir bitte das debug Log zu. Emal ist auf der kontaktseite

Cu framp
#966 Fredi 2017-11-06 15:06
Nachdem ich mal wieder seit langem ein Update auf Version V0.6.3 gemacht habe, dauert mein DD Backup anstatt ca. 30 Minuten jetzt 3:20 Stunden. Ist das jetzt normal?
#965 framp 2017-11-05 20:58
Ab sofort gibt es eine neue Version 0.6.3.1. Benutzer des tar Backup Modes sollten sofort auf diese Upgraden.
#964 framp 2017-11-03 10:44
Leider hat sich herausgestellt, dass seit der Version v0.6.2 ein Bug in raspiBackup existiert, der dazu fuehrt, dass Fehler, die beim Erstellen von tar Backups vom tar Tool berichtet werden, nicht von raspiBackup erkannt und ignoriert werden :sad:

Ein Fix dafür existiert bereits in der Beta Version von v0.6.3.1 und die demnaechst allgemein verfugbar sei wird. Wer sie testen möchte findet die Beta auf https://raw.githubusercontent.com/framps/raspiBackup/beta/raspiBackup.sh

Jedem, der tar Backups benutzt wird dringend empfohlen sobald die Version v0.6.3.1 verfuegbar ist auf diese zu upgraden.

Details zu dem Problem sind hier in Englisch verfuegbar.
#963 framp 2017-11-02 15:20
Moin Tobi,

vielen Dank fuer den Hinweis. Mittlerweile stelle ich die verschiedenen Dateien ins github. Da kann ich alles besser kontrollieren als hier auf der Webseite. Den Link habe ich gefixed. Er ist jetzt so ;-)

Cu framp
#962 tobi 2017-11-02 14:27
Leider ist die Datei raspiBackupWrapper.sh nicht mehr erreichbar. Kannst du prüfen, woran es liegt? Danke! :-)
#961 framp 2017-10-31 13:11
Problem gelöst. Es fehlten die Optionen -a und -o :-)
#960 framp 2017-10-31 11:24
zitiere Lars:
... Düfte ich Dir mal das komplette LOG zusenden?...

Klar. Meine eMailAdresse findest Du auf der Kontaktseite. Aber bitte nicht die Option -l debug vergessen ;-)
#959 Lars 2017-10-31 11:15
Hallo framp,
Danke für Deine Antwort, es wird kein err sonst ausgegeben oder ich kann den nicht erkennen. Düfte ich Dir mal das komplette LOG zusenden? (Bitte nur den Teil hier veröffentlichen, der dann zum Fehler führt..) Danke Dir!
(sorry, wird dann hier zu lang direkt reinzupasten, kann ichs
Dir per Email zusenden?) Danke , Grüße!

EDIT framp: eMailAdresse aus dem Kommentar gelöscht
#958 framp 2017-10-31 11:04
Moin Lars,

Du solltest auch noch eine Meldung bekommen haben die die genauere Ursache angibt. So wie ich es sehe gibt es ein Problem mit dem Backuppfad /backup.

Cu framp
#957 Lars 2017-10-31 10:18
Guten Morgen!
Leider bekomme ich das Script/Backup für meinen Raspberry Pi (Raspbian GNU/Linux 9 (stretch)) einfach nicht ans Laufen. Was bedeutet Fehlermeldung RC 107? Danke!!
--- schnipp
20171031-084428: DBG -- Found partitions on /dev/mmcblk0: 2
20171031-084428: DBG >> isPathMounted: /backup
20171031-084428: DBG -- Path: /backup
20171031-084428: DBG > exitError 107
20171031-084428: DBG > cleanup
20171031-084428: DBG >> cleanupBackup
20171031-084428: DBG -- Got trap EXIT
20171031-084428: DBG -- rc: 107
---schnapp
#956 framp 2017-10-29 17:43
zitiere Matthias:
... Es lag grundlegend daran, dass ich no_root_squash nicht eingeschaltet hatte für die nfs Freigabe. Dadurch kamen die genannten Probleme beim RSync auf und irgendwie hat es sich dabei vermutlich aufgehängt.
Perfekt :thumbsup: Aber jetzt nicht vergessen auch noch den Restore zu testen ;-)

Cu framp
#955 Matthias 2017-10-29 17:30
Hallo framp,

ich habe nach dem Problem allgemein nochmal gesucht und eine Lösung gefunden. Es lag grundlegend daran, dass ich no_root_squash nicht eingeschaltet hatte für die nfs Freigabe. Dadurch kamen die genannten Probleme beim RSync auf und irgendwie hat es sich dabei vermutlich aufgehängt.
Jetzt konnte ich auf zwei verschiedenen RPis folgendes lesen:
--- RBK0017I: Backup erfolgreich beendet.
Vielen Dank für deine Hilfe.

VG Matthias
#954 framp 2017-10-29 14:02
Moin Matthias,

jetzt gilt es rauszufinden ob es an der Raspi oder dem Netzwerk liegt. Dass die ausführende Raspi nichts mehr tut glaube ich nicht so ganz. Hast Du mal mit top oder htop nachgesehen?
Ich würde einfach mal einen Backup auf einen lokal angeschlossenen USB Stick/Platte erstellen. Damit kannst Du schon mal rausfinden an welchem Ende es bei Dir klemmt. 2MB/s ist schon sehr langsam für eine 100MB Netzwerkanbindung. Bist Du sicher dass die Leitung OK ist? Was bekommst Du denn raus mit ipperf? Was passiert wenn Du mal eine grosse Datei kopierst?

Cu framp
#953 Matthias 2017-10-29 13:30
Hallo framp,

danke für deine Hilfe. Ich habe das ganze wie du sagtest mal verfolgt beim manuellen ausführen. Mit ethstatus habe ich gleichzeitig die Netzwerkaktivität auf dem Ziel-RPi verfolgt. Am Anfang kommen Daten mit ungefähr 2MB/s an. Das ist recht langsam, könnte aber an meiner alten USB-Festplatte liegen.
Nach einiger Zeit bewegt sich aber auch auf dem ausführenden Pi nichts mehr und das Netzwerk auf dem Ziel geht auf
#952 framp 2017-10-28 21:35
Moin Matthias,

es hängt von verschiedenen Dingen ab:
1) Backupgröße
2) rsync das erste mal oder existiert schon ein rsync Backup. Der erste Backup dauert lange.
3) Netzwerklatenz

8 Stunden ist schon sehr lang. Benutze doch mal die Option -g oder -v um den Fortschritt zu sehen.

Cu framp
#951 Matthias 2017-10-28 19:56
Hey framp,

ich habe mein Problem mit den Schreibrechten auf der nfs Freigabe inzwischen gelöst und habe Backups zum testen eingestellt. Ich habe dazu einfach mal täglich eines machen lassen. Nachdem ich mich gewundert habe, warum dabei viele Ordner allerdings leer waren (auch kein log) habe ich es manuell ausgeführt: "es wird bereits eine Instanz von raspiBackup ausgeführt. (oder so ähnlich).
Nach dem Reboot erstellt das erst Backup zumindest Dateien, aber keine Logdatei. Ich habe heute vormittag mal einen Reboot gemacht und dann das Backup in der Console angestoßen. Nach über 8 Stunden ist er noch immer nicht fertig...
```
pi@RPi-Bad-unten:~ $ sudo /usr/local/bin/raspiBackup.sh
--- RBK0009I: RPi-Bad-unten: raspiBackup.sh V0.6.2.2 (fc2f04a) um Sa 28. Okt 11:34:40 CEST 2017 gestartet
--- RBK0128I: Logdatei ist /mnt/Backup/RPi-Bad-unten/RPi-Bad-unten-rsync-backup-20171028-113438/RPi-Bad-unten-backup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
--- RBK0031I: Prüfe ob neue Version verfügbar ist
--- RBK0080I: ;-) Es gibt eine neuere Version von raspiBackup 0.6.3 zum downloaden. Die momentan benutze Version ist 0.6.2.2 und es kann mit der Option -U die lokale Version aktualisiert werden
--- RBK0114I: Besuche https://www.linux-tips-and-tricks.de/de/versionshistorie/ um die Ã
nderungen in der neuen Version kennenzulernen
--- RBK0159I: Prüfe ob eine Beta Version verfügbar ist
--- RBK0151I: Backuppfad /mnt/Backup wird benutzt
!!! RBK0157W: Keine Services sind zu stoppen
--- RBK0081I: Backup vom Typ rsync wird in /mnt/Backup/RPi-Bad-unten/RPi-Bad-unten-rsync-backup-20171028-113438 erstellt
--- RBK0036I: Partitionslayout wird gesichert
--- RBK0044I: Backup der Bootpartition wird in /mnt/Backup/RPi-Bad-unten/RPi-Bad-unten-rsync-backup-20171028-113438/RPi-Bad-unten-backup.img erstellt
--- RBK0044I: Backup des Partitionlayouts wird in /mnt/Backup/RPi-Bad-unten/RPi-Bad-unten-rsync-backup-20171028-113438/RPi-Bad-unten-backup.sfdisk erstellt
--- RBK0046I: Backup des Masterbootrecords wird in /mnt/Backup/RPi-Bad-unten/RPi-Bad-unten-rsync-backup-20171028-113438/RPi-Bad-unten-backup.mbr erstellt
--- RBK0133I: Verzeichnis /mnt/Backup/RPi-Bad-unten/RPi-Bad-unten-rsync-backup-20171028-105311 wird für Hardlinks benutzt
--- RBK0158I: rsync Backup "/mnt/Backup/RPi-Bad-unten/RPi-Bad-unten-rsync-backup-20171028-113438" wird erstellt
--- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte etwas Geduld
```
selbiges auch von einem weiteren RPi, der per NFS zugreift. Ist RSync einfach so langsam? Wie lange sollte ein Backup normalerweise ungefähr dauern?

Grüße,
Matthias
#950 framp 2017-10-23 19:27
Moin topa,

das kling mir schwer danach dass die SD Karte ersetzt werden sollte. Du kannst noch mal probieren ob Du einen tar oder rsync Backup durchbekommst. Da wird ja nicht die gesamte SD Karte gelesen. Dann hast Du wenigstens vom aktuellen Stand noch ein Backup und musst nicht den vorherigen Stand restoren.

Cu framp

PS: Irgendwie liegt es wohl am Wetter. Du bist nicht der Einzige der gerade feststellt, dass die SD Karte das Zeitliche segnet :cry:
#949 topa 2017-10-23 11:39
Habe die Blocksize erstmal auf 1MB belassen und mit -l debug das ganze mitgeloggt.

Folgende Fehler treten wieder bei 2,25GB auf (backupImage Größe)

- Eingabe / Ausgabefehler, das Dateisystem ist nur lesbar.

/root
bin/data

und noch andere Verzeichnisse, leider wird auch das debug Log nirgends gespeichert, daher hier nur manuell ein Auszug aus der Konsole.

Hat die SD Card einen weg?
#948 Paul 2017-10-22 20:47
es waren tatsächlich die extended attributes, danke für den Tipp!
#947 framp 2017-10-22 15:59
Moin Paul,

es ist eine Vermutung und ich glaube aber eher nicht. Es gab schon verschiedentlich Anfragen zum Thema xattr. Da verweigerte aber rsync den Backup und raspiBackup brach auch mit einer Fehlermeldung ab.
Wie sehen denn die Fehlermeldungen im syslog aus?

Cu framp
#946 Paul 2017-10-22 14:19
Das Backup hab ich zwar leider ohne Debug-Funktion erstellt, das Log enthält jedoch keine einzige Fehlermeldung. Kann es trotzdem an den xtended Attributes liegen?
#945 framp 2017-10-22 13:55
Moin Paul,

ich koennte mir vorstellen dass das was mit xtended Attributes zu tun hat (Siehe hier. Hast Du mal nachgesehen ob es im Log vom Erstellen des Backups solche Fehler gegeben hat oder andere die aus irgendeinem Grunde von raspiBackup ignoriert wurden?

Cu framp
#944 Paul 2017-10-22 13:20
der blinkende cursor kommt erst nach dem raspbian screen und einigen startbefehlen, die sd karte sollte also in Ordnung sein. Ich habe jetzt einmal ins syslog geschaut und jede Menge Permission denieds entdeckt mit denen ich jedoch leider nichts anfangen kann.
#943 framp 2017-10-22 12:09
Moin topa,

ich kann mich an einen Kommentar hier erinnern dass jemand ein aehnliches Problem hatte weil der Backup über das Netz abgelegt wurde. Du kannst ihn mit der Option -b ändern :-) Lass uns bitte wissen ob Dein Problem mit einer anderen Buffergrösse gelöst werden kann.

Zu Deiner zweiten Frage: Ab Version 0.6.3 gibt es die Option -g. Ausserdem gibt es die Option -v die aber nur bei tar und rsync Wirkung zeigt.

Cu framp
#942 topa 2017-10-22 11:48
Hallo,

seit einiger Zeit bricht das dd backup immer bei 2,25Gb ab, die SD Größe ist normal 8Gb. Raspi ist nicht mehr zu bedienen, Konsole hängt etc. Kann das an der eingestellten Blockgröße (1MB) liegen?

Kann man eigentlich den Backupvortagng irgendwo mitloggen, damit man vielleicht sieht wann und warum das crasht? Danke
#941 framp 2017-10-21 20:34
Moin Paul,

testest Du gerade raspiBackup oder hat es vorher schon funktioniert?

Wenn nur ein blinkender Cursor kommt wird kein Bootcode gefunden. Hast Du mal eine andere SD Karte ausprobiert? Ist sehr möglich dass die SD Karte nicht OK ist oder zu klein.

Cu framp
#940 Paul 2017-10-21 13:33
Hallo!
Ich habe ein rsync-Backup konfiguriert, welches immer fehlerfrei durchläuft. Nun möchte ich ein Restore durchführen und der Vorgang wird auch fehlerfrei beendet. Starte ich den Raspberry nun, kommt das Boot-Logo von Raspbian, danach bleibt der Bildschirm jedoch leider schwarz mit einem kleinen blinkenden Cursor.
Hat hier wer eine Idee?
lg.
#939 Paul 2017-10-21 12:55
Ich verwende ein rsync Backup welches immer fehlerfrei lief. Nun möchte ich ein solches zurückspielen und der Restore wird auch fehlerfrei beendet. Wenn ich den Raspberry dann starten möchte kommt das Raspbian Bootlogo danach bleibt der Bildschirm jedoch schwarz mit einem blinkenden Cursor. Hat hier jemand eine Idee?
#938 Matthias 2017-10-18 21:57
Hey framp,
ich habe es glaube ich inzwischen hinbekommen... ich habe festgestellt, dass es nach einem nfs-kernel-server restart klappt. Ich habe es erst mit deiner Anleitung versucht (https://www.linux-tips-and-tricks.de/de/raspberry/492-clnt-create-rpc-program-not-registered), aber das hat nicht zum Erfolg geführt. Jetzt habe ich einfach in der crontab den restart mit @reboot reingeschrieben, schon klappt alles. Nur noch die Berechtigungen sind fraglich, ich kann im Moment noch nicht auf das nfs mount schreiben. Ich habe auf allen RPis den user pi, wie kann ich da einfach die Schreibrechte vergeben?

Grüße, Matthias
#937 framp 2017-10-18 21:43
Moin Matthias,

mein Tipp ist die Suchmaschine Deines Vertrauens zu besuchen und/oder dieses Raspi Forum zu besuchen und dort erst zu suchen, dann probieren und dann Deine Probleme die Du bei Deinen Versuchen bekommst zu schildern ;-)

Cu framp
#936 Matthias 2017-10-18 20:48
Hi framp,

dann lohnt sich wohl der 'Kampf' mit nfs... hast du irgendwelche Tipps, wie man das einfach auf einem RPi zum laufen kriegt? Ich schlage mich gerade mit verschiedenen Meldungen rum...
von
clnt_create: RPC: Program not registered
bis
pi@OctoPi:~ $ showmount -a
All mount points on OctoPi:
pi@OctoPi:~ $
ist fast alles dabei, aber nichts läuft...
#935 framp 2017-10-17 21:56
Moin Matthias,

Du hast offensichtlich dieselben Anforderungen wie ich :-)
Auch bei mir läuft eine Raspi als LAN Server, die sich auf einer lokalen Platte selbst sichert und per nfs Backupspace anbietet, der von anderer Raspis benutzt damit die sich darauf sichern können. Alle Raspies benutzen nfs und rsync Backup. Wenn Du samba benutzt nutzen Hardlinks nichts, d.h. rsync bringt nichts und Du musst tar benutzen.

Cu framp
#934 Matthias 2017-10-17 20:48
Hallo allerseits,

ich habe noch einigen Crashs durch Power-cut jetzt mal dieses tolle Tool probiert. Das erste Backup ist auch gut durchgelaufen, weitere Tests und ein Restore-Test stehen noch aus. Jetzt will ich natürlich gleich weiter denken:
Ich habe an meinem Test-Raspi eine 500GB USB Platte mit ext4 angehängt. Ich habe noch mehrere weitere Raspis, die ich gern mit auf diese HDD sichern würde. Wie mache ich das am sinnvollsten? Das einfachste wäre sicherlich eine samba-Freigabe, aber werden dabei auch hardlinks richtig gesetzt? Muss ich erst noch NFS einrichten? Ich wäre für Hinweise sehr dankbar.

Grüße,
Matthias
#933 framp 2017-10-16 20:15
Moin Hendrick,

leider habe ich ähnliches beim Beta3 Test festgestellt. Ein tar Backup startet nur wenn die Netzwerkdefinitionen per networkd-systemd vorgenommen werden. Bei rsync funktioniert es auch mit DHCP. Ich habe hier um Hilfe gefragt aber leider keine lösungsführende Antwort gefunden :sad:

D.h. ich sehe folgende Lösungen für Dich:
1) Auf systemd-networkd umstellen -> Details
2) dd Backup
3) rsync Backup

Leider habe ich keine bessere Lösung :sigh:

Cu framp
#932 Hendrik 2017-10-16 19:52
Noch ein Nachtrag:
Ich habe jetzt auch nochmal tar ausprobiert, wo letztendlich der gleiche Fehler wie beim tgz auftritt. Ich habe direkt nach dem restore einmal fsck auf den beiden Partitionen ausgeführt und einen Fehler bekommen:

pi@raspberrypi:~ $ sudo fsck -a /dev/sda1
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.
Performing changes.
/dev/sda1: 148 files, 42853/82644 clusters

Kann das der Grund für den Fehler beim Booten sein?

Also nächstes werden ich jetzt wirkflich einmal ein dd Backup testen, auch wenn das aufgrund der Größe und der Belastung der Karte eher keine Option für mich ist.
#931 Hendrik 2017-10-16 18:05
Hallo,

ich habe jetzt ein bisschen weiter experimentiert und hatte etwas mehr Erfolg. Statt des rsync Backups habe ich jetzt ein tgz Backup erstellt. Nach dem restore fährt das System auch normal hoch, mit einer Ausnahme. Ich bekomme folgenden Fehler beim Booten:

Failed to start dhcpcd on all interfaces. See 'systemctl status dhcpcd.service' for details.

Und dort steht dann folgendes:
Active: failed...
Process: 357 ExecStart=sbin/dhcpcd -q -w (code=killed, signal = SEGV)
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommendend.

Damit kann ich als Linux-Anfänger natürlich nicht wirklich was anfangen. Hat hier jemand eine Idee?

Viele Grüße
Hendrik
#930 framp 2017-10-14 20:53
Ja, die Beschreibung von Micha wie man manuell restored ist sehr hilfreich.

Es gibt mittlerweile ein raspiBackup Hilfscript welches ein tar oder rsync Backup in ein dd Image restored und anschliessend per pishrink maximal verkleinert. Ist jetzt zu spät - aber das haette Dir auch geholfen :-)
#929 Marco 2017-10-14 16:50
Danke Micha, danke framp,

mit Hilfe deiner Anleitung ist es mir nun endlich gelungen meinen Raspi von 128GB auf eine 16GB Karte zu schrumpfen. Ohne das geniale raspiBackup Skript hätte das nicht geklappt. Damit konnte ich es nun händisch erledigen, perfekt. Danke für eure Zeit die ihr damit verbringt und das es kostenlos zu Verfügung gestellt wird!
Weiter so! Bin ein neuer FAN dieser Seite und vor allem des raspiBackup Skripts!
Besten Dank, Marco
#928 Peter 2017-10-13 20:32
Ich hab nochmal etwas genauer geschaut und die bash mit -x durchlaufen lassen. Das Verzeichnis /usr/local/etc gab es bei mir noch nicht. Deshalb der Abbruch.

LG

Peter
#927 Peter 2017-10-13 20:24
Das oben ist schon der komplette Inhalt der ./raspiBackupInstall.log. Mehr ist da leider nicht :-/

Danke für die schnelle Reaktion!

Peter
#926 framp 2017-10-13 20:01
Moin Peter,

das ist natuerlich schlecht :sad: . Ich habe es gleich bei mir ausprobiert und es funktioniert.

zitiere Peter:

??? RBI0016E: Installation of raspiBackup failed. Check ./raspiBackupInstall.log


Sieh doch mal in der Logdatei nach was Du fuer Fehlermeldungen findest.

Cu framp
#925 Peter 2017-10-13 19:52
Hallo zusammen,

leider habe ich schon Probleme beim Installieren. Kann es sein, dass die Config-Dateien aktuell nicht da sind?

--- RBI0032I: Checking if there is a beta version available.
--- RBI0041I: Default for option is the parameter in UPPERCASE.
--- RBI0002I: Message language (de|EN) : --- RBI0003I: Normal or partition oriented mode (N|p) : --- RBI0004I: Backuptype (dd|tar|RSYNC) : --- RBI0006I: Number of backups (1-52) : --- RBI0008I: Verbose messages (Y|n) : --- RBI0042I: Selected configuration: Message language: en, Backupmode: normal, Backuptype: rsync
--- RBI0048I: Selected configuration: Compress backups: n, Number of backups: 5, Verbose messages: y
--- RBI0009I: Configuration OK (y|N) : --- RBI0014I: Downloading raspiBackup.sh...
--- RBI0037I: Created /usr/local/bin/raspiBackup.sh.
--- RBI0037I: Created /usr/local/bin/raspiBackupInstall.sh.
--- RBI0014I: Downloading raspiBackup.conf...
chmod: cannot access '/usr/local/etc/raspiBackup.conf': No such file or directory
??? RBI0018E: chmod of /usr/local/etc/raspiBackup.conf failed.
--- RBI0021I: See logfile ./raspiBackupInstall.log for details.
--- RBI0022I: Cleaning up...
rm: cannot remove '/usr/local/etc/raspiBackup.conf': No such file or directory
??? RBI0016E: Installation of raspiBackup failed. Check ./raspiBackupInstall.log

Grüße

Peter
#924 hotte 2017-10-11 20:21
Hi Hendrik,
Zitat:
Ich habe das Backup von einer 16 GB Karte erstellt und auf eine 32 GB Karte wieder hergestellt: Ist das ein Problem?
Beim Backup mit dd ist das keine Problem, da darf das Zielmedium nicht kleiner sein wie die Quelle des Backups (Ausnahmen mit tieferer Kenntnis möglich).
Bei mir funktionierte das Restore eines dd Backups auch nicht (hab es nur mit dd gemacht nicht mit raspiBackup.sh). Ein zweiter Versuch mit dem gleichen Backup auf das gleiche Medium ging dann mit folgendem Befehl doch: sudo dd if=~/SDCardBackup.img of=/dev/sdb bs=1M
Vielleicht ist es der bs (Blockszise), denn standardmäßig sichert raspoBackup mit dieser Blockgröße. dd allergings beim Restore mit äußerster Vorsicht anwenden--> es muss sicher sein das dei "of" auch das Medium beschreibt welches eingelegt hast (s. Dokus im Netz). df -h .... z.B.
Grüße
hotte
#923 framp 2017-10-11 20:07
Moin Hendrick,

ein Bootfehler ist ziemlich blöd und sollte nicht passieren :cry: Merkwürdig ist dass kein Backuptyp startet :o Es kann diverse Ursachen haben.

Ich wuerde folgendes probieren:
1) Eine andere SD Karte benutzen. Es kann sein dass die SD Karte einen weg hat
2) Mountest Du noch externe Partitionen die Du beim Restore nicht angeschlossen hast?
3) Probiere mal den dd Backup.

Cu framp
#922 Hendrik 2017-10-11 19:06
Hallo zusammen,

ich habe auf meinem Raspberry PI openhabian installiert ein rsync Backup erzeugt (sowohl ein normales als auch ein partitionsorientiertes Backup). Das hat auch gut funktioniert. Es kam jedoch die Meldung, dass sich einige Dateien verändert haben und daher ignoriert wurden.

Beim Test des Backups stoße ich jedoch auf Probleme und komme nicht weiter. Der Restore an sich funktioniert, nur leider bootet der Raspberry PI anschließend nicht. Beim normalen Backup bekomme ich beim Hochfahren kernel panic, beim partitionsorientierten Backup kommt kein offensichtlicher Fehler. Es kommen eine Menge Ausgaben, am Ende random: crng init done, weiter geht es dann nicht. Ich bin leider total Linux-Anfänger und kann damit daher nichts anfangen.

Wichtig noch zu erwähnen: Ich habe das Backup von einer 16 GB Karte erstellt und auf eine 32 GB Karte wieder hergestellt: Ist das ein Problem?

Ich bin für jede Hilfe und jeden Tip dankbar.

Viele Grüße
Hendrik
#921 framp 2017-10-08 16:39
Moin Christian,

Du hast Recht :-) . -z schaltet das nur ein. Ausschalten geht nicht mehr :sad: . Ich werde es so aendern das -z den Switch toggled - also in den jeweils anderen Zustand umschaltet.
Dazu habe ich eben zum Tracken diesen Issue erstellt.

Beim rsync ist die Meldung dazu gedacht einen Benutzer darauf hinzuweisen, dass er eine Option gewaehlt hat, die mit rsync keinen Sinn macht.

Cu framp
#920 Christian 2017-10-08 14:50
Hallo framp,
raspiBackup 0.6.2.2

Ich habe da eine kleine Problematik mit Standardconfig und Parameter.
Wenn in der Standardconfig DEFAULT_ZIP_BACKUP="1" ist, bekommt man kein ungezipptes Backup mehr zusammen. Selbst bei -t rsync schlägt das Script auf ("-z nicht erlaubt"), weil damit natürlich nicht gezippt werden kann .

Es gibt keinen Parameter, um das Zippen aufzuheben (z.B. "-z-"), bzw. sollten nicht-zippbare Methoden das ZIP-Default-Setting ignorieren.

Herzliche Grüße,
Christian
#919 hotte 2017-10-06 22:43
i.O. alles ist Gut :lol:
Habe jedes mal die Option -a -o mit gegeben .... :oops: das ist aber falsch da ja alles aus der conf-Datei gezogen wird wenn vorhanden.
Escapen von dem @ bringt nichts, außer das die Meldungen in der Konsole korrekt dargestellt werden.

Viele Grüße
hotte
#918 hotte 2017-10-04 22:37
i.O. , ich schicke dir den debug-log. Habe das in der conf schon so eingestellt.
Zitat:
Das muss ich bei mir nachstellen. Benutzt Du genau diesen Befehl oder hast Du etwas maskiert?
si, ohne Maskierung: systemctl stop home-assistant@homeassistant (homeassistant ist ein systemuser) Interessantes Projekt:
https://home-assistant.io/
thx zu später Stunde :zzz :lol:
hotte
#917 framp 2017-10-04 22:13
Ich denke am besten rufst Du raspibackup mit der zusaetzlichen Option -l debug auf und schickst mir das Debuglog an meine eMail (Siehe Kontaktseite). Da steht alles drin was ich zum debuggen und fixen brauche.
#916 framp 2017-10-04 21:48
Moin hotte,

wie kann man denn auch nur so ein komisches Konstrukt benutzen :lol:

Da scheint raspiBackup Probleme bei der Parameterübergabe im bash Script zu haben :oops:

Das muss ich bei mir nachstellen. Benutzt Du genau diesen Befehl oder hast Du etwas maskiert?
Code:systemctl stop home-assistant@[your user]

Ich muss genau wissen was Du da benutzt um es nachstellen zu können.

Cu framp
#915 hotte 2017-10-04 21:24
Hi,
vorweg: prima das das alles hier geteilt wir :-) . Bei mir läuft das Script nicht richtig. Folgende Umgebung: Paspian Jessi light. Ein Dienst läuft bei mir in einer virtuellen Umgebung:
  • Dienst so gestoppt / gestartet: systemctl stop home-assistant@[your user]
  • in raspiBackup conf-Datei ist das auch so eingetragen
  • beim debuggen ausgeführt: systemctl stop home-assistant

Letzteres funktioniert aber nicht. Scheinbar wir das @ - Zeichen nicht korrekt interpretiert. Wie bekomme ich das hin? Ich einem Echtlauf wird schließlich gemeldet das -o ein falsche Argument ist ...
Viele Grüße
hotte
#914 framp 2017-10-03 11:44
Moin bliblabl8,

vielen Dank fuer das Log. Da kann ich sehen dass Du mehr als 9 Partitionen fuer dein NOOBS Image benutzt und damit hat raspiBackup ein Problem :oops: Ich habe einen Fix erstellt und Dir zum verifizieren per eMail zugeschickt :-)

Cu framp
#913 framp 2017-10-02 22:22
Moin bliblabl8,

wie ich schon geantwortet habe: Ohne ein Debuglog von raspiBackup kann ich keine Aussage machen warum Du diese Meldungen bekommst. :cry:

Cu framp
#912 bliblabl8 2017-10-02 22:16
Hi, wird sicher ein wunderbares Backup wenn ich es denn richtig konfiguriert bekomme. Ich habe ein Synology NAS und der Mount funktioniert auch per nfs.

Frage: ich habe meines Wissens keine Partition mit fat32.

Ich bekomme folgende Meldung:

RBK0031I: Prüfe ob neue Version verfügbar ist
??? RBK0109E: Nicht unterstütztes Filesystem fat32
fat16
ext4
fat32
ext4
fat32
ext4
fat32
ext4
fat32
ext4 auf Partition mmcblk0p1
??? RBK0109E: Nicht unterstütztes Filesystem ext4 auf Partition mmcblk0p2
??? RBK0005E: Backup fehlerhaft beendet mit RC 107. Siehe vorhergehende Meldungen

Ich habe meines Wissens und laut /proc/self/mounts keine Partition mit fat32.

Komischerweise kommt aber auch die Meldung das ext4 nicht unterstützt würde.
#911 framp 2017-10-02 21:55
Moin bliblabl8,

natuerlich wird ext4 unterstuetzt. Du hast offensichtlich eine exotische Konfiguration wo es Probleme gibt :sad:

Benutze noch zusaetzlich die Option -l debug (kleines L) und schicke mir das Debuglog an meine eMailAdresse (Siehe Kontakt Seite)

Cu framp
#910 bliblabl8 2017-10-02 21:45
Hi, wird sicher ein erinnerndes Backup wenn ich es konfiguriert bekomme.

Frage: wird ext4 nicht unterstützt?

Ich bekomme folgende Meldung:

RBK0031I: Prüfe ob neue Version verfügbar ist
??? RBK0109E: Nicht unterstütztes Filesystem fat32
fat16
ext4
fat32
ext4
fat32
ext4
fat32
ext4
fat32
ext4 auf Partition mmcblk0p1
??? RBK0109E: Nicht unterstütztes Filesystem ext4 auf Partition mmcblk0p2
??? RBK0005E: Backup fehlerhaft beendet mit RC 107. Siehe vorhergehende Meldungen
#909 framp 2017-09-30 20:22
Moin MarkusM,

die Info reicht mir. Ich habe Dir eine Testversion von raspiBackup zugeschickt :-)

Cu framp
#908 MarkusM 2017-09-30 14:30
Ist ganz einfach warum er nicht funktioniert.
Du prüfst den Mountpoint /boot, der ist bei mir aber kein eigener Mountpoint, da der Ordner mit im root-Verzeichniss liegt.
Daher wird von ganz /dev/sda1 ein dd Image gemacht.

Filesystem Size Used Avail Use% Mounted on
/dev/root 59G 16G 41G 28% /
devtmpfs 486M 0 486M 0% /dev
tmpfs 98M 288K 97M 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 195M 0 195M 0% /run/shm
/dev/mmcblk0p2 30G 12G 17G 42% /backups
tmpfs 20M 4.0K 20M 1% /ram


root@bananapi ~ # mountpoint -d /boot
8:1
root@bananapi ~ # mountpoint -x /dev/sda1
8:1
root@bananapi ~ # mountpoint -d /
8:1
#907 framp 2017-09-30 12:43
Moin MarkusM,

Eine weitere Option deswegen einzufuehren ist prinzipiell auch moeglich und sicherlich der schnellste Weg.

Eigentlich sollte aber der BootPartitionsDetectionAlgorithmus funktionieren :-* Da er offensichtlich bei Dir nicht funktioniert moechte ich gerne wissen warum und fixen. Kannst Du den Backup mal mit der zusaetzlichen Option -l debug aufrufen und mir das Log per eMail zuschicken? (Die Email findest Du auf der Kontaktseite).

Cu framp
#906 MarkusM 2017-09-30 10:21
Erstmal vielen Dank für das tolle Script.
Ich hätte da noch einen Vorschlag für ne neue Option bzw. Verhaltensänderung.
Ich nutze einen BananaPi und dieser bootet bei mir von der Sata-Platte. Auf der 1. Partition der SD Karte ist der eigentliche Bootloader und die config File. Dort wird gesagt, dass von /dev/sda1 gebootet werden soll.
Alles zum booten ist dann auf sda1 vorhanden auch /boot liegt auf sda1.
Daher erkennt das Script die boot-Partition falsch und erzeugt von der kompletten Platte ein dd-Image obwohl ich tar als Backupverfahren angebeben habe.

Ich habe mir das Script mal angeschaut und gesehen, dass es einen Parameter -Z gibt der $REGRESSION_TEST auf 1 setzt und dadurch wird die boot-Partition fest auf /dev/mmcblk0p1 festgelegt und das Backup funktioniert wieder.

Könntest du die Erkennung der Bootpartition so umbauen, dass auch geprüft wird ob der Mountpoint /boot ungleich / ist und dann schauen ob es /dev/mmcblk0p1 gibt und dann diese Partition als boot nehmen?
Andere Möglichkeit währe vielleicht eine neue Option mit der man die boot-Partition angeben kann und die default auf "auto" steht und das bisherige Verhalten übernimmt.

Vielen Dank schonmal.
#905 framp 2017-09-29 20:31
Moin cmarkowitz,

wie ich sehe hast Du schon das debug Flag benutzt. :-) Schicke mir bitte das Debuglog an meine eMailAdresse (Siehe Kontakt Seinte) damit ich rausfinden kann was die Ursache für dieses merkwürdige Verhalten ist.

Cu framp
#904 cmarkowitz 2017-09-29 19:04
Hallo Leute,

Erstmals vielen Dank für die tolle Arbeit.
Ich habe es bei mir eingerichtet und möchte gerne meinen Raspi mittels DD auf mein Synology NAS sichern.

Allerdings erhalte ich diese Fehlermeldung:

root@ioBroker-RasPi:/usr/local/bin# sudo /usr/local/bin/raspiBackup.sh -t tar -k 4 -l debug -L backup -o "iobroker stop" -a "iobroker start" /mnt/Synology_Backup
--- RBK0009I: ioBroker-RasPi: raspiBackup.sh V0.6.2.2 (fc2f04a) um Do 28. Sep 21:19:45 CEST 2017 gestartet
--- RBK0128I: Logdatei ist /mnt/Synology_Backup/ioBroker-RasPi/ioBroker-RasPi-tar-backup-20170928-211945/ioBroker-RasPi-backup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
--- RBK0151I: Backuppfad /mnt/Synology_Backup wird benutzt
--- RBK0008I: Services werden gestoppt: 'iobroker stop'
--- RBK0081I: Backup vom Typ tar wird in /mnt/Synology_Backup/ioBroker-RasPi/ioBroker-RasPi-tar-backup-20170928-211945 erstellt
--- RBK0036I: Partitionslayout wird gesichert
--- RBK0044I: Backup der Bootpartition wird in /mnt/Synology_Backup/ioBroker-RasPi/ioBroker-RasPi-tar-backup-20170928-211945/ioBroker-RasPi-backup.img erstellt
??? RBK0030E: .img Datei Erzeugung mit dd endet fahlerhaft mit RC 1
--- RBK0026I: Logdatei wird in /root/ioBroker-RasPi-raspiBackup.log gesichert
--- RBK0043I: Unvollständiges Backup /mnt/Synology_Backup/ioBroker-RasPi/ioBroker-RasPi-tar-backup-20170928-211945 in wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
--- RBK0105I: Neues Backupverzeichnis /mnt/Synology_Backup/ioBroker-RasPi/ioBroker-RasPi-tar-backup-20170928-211945 wird gelöscht
??? RBK0005E: Backup fehlerhaft beendet mit RC 114. Siehe vorhergehende Meldungen
root@ioBroker-RasPi:/usr/local/bin#

Mit RSYNC geht die Sicherung.
Kann mir jemand sagen warum es mit DD bei mir nicht funktioniert ?

Vielen Dank schon mal
lg
christian
#903 framp 2017-09-14 18:37
Moin ThomasD,

vielen Dank fuer Deine Anregung.

Dieser Vorschlag wurde schon mal vor ca 3 Jahren gemacht. Ich hatte es mir dann mal angesehen wie dass mit raspiBackup implementiert werden kann. Da raspiBackup darauf ausgelegt ist auf die Backuppartition per Mount zuzugreifen erfordert das eine groessere Aenderung in raspiBackup. In Anbetracht der Tatsache dass der Bedarf dafuer sehr gering ist ist nicht geplant den Support fuer einen rsync Server einzubauen.

Cu framp
#902 ThomasD 2017-09-14 01:59
Hallo,

ich wollte mal vorschlagen als Backup Ziel noch einen Rsync-Server mit auf zu nehmen.

Schöne Grüße
Thomas
#901 framp 2017-09-10 10:02
Moin Herbert,

vermutlich hat sich von Debian 8 auf Debian 9 irgendetwas geaendert womit raspiBackup nicht mehr zurecht kommt :sad: Schicke mir bitte das Log an meine eMailAdresse (Siehe Kontaktseite) zu damit ich die Ursache rausfinden kann.

Cu framp
#900 Herbert 2017-09-10 09:31
Hallo,

ich nutze das Script schon lange und hat auch immer funktioniert. Ich lasse das DD-Image "shrinken".

Ich habe nun Raspbian von Debian 8 auf Debian 9 gewechselt. Kein Upgrade sondern vollständig neu installiert, jedoch mit selbem Setupscript.

Das Backup-Script funktioniert jetzt nicht mehr, das Image ist 0 byte. Ohne Shrink-Parameter funktioniert es weiterhin.

Liegt es am Debian 9? Oder gibt es einen Parameter der hier noch fehlt (auch wenn es unter Debian 8 funktionierte)?

Details:

DAnke im Voraus!

Mein Setup:
- Script 6.2.2
- Raspberry 3
- Raspbian vom 07.09. - Debian 9
- Backuppfad auf NAS

Änderungen zur Originalconfig in /usr/local/etc/raspiBackup.conf

DEFAULT_BACKUPPATH="/media/NAS/Backup/raspi3all"
DEFAULT_KEEPBACKUPS=5
DEFAULT_BACKUPTYPE="dd"
DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY=1
+2 Services start/stop

--- RBK0003I: Backupgröße wird von 3.70 GiB auf 0 Bytes reduziert

Ich konnte leider das ganze Log nicht anhängen da sonst der Kommentar zu lang wäre. Es waren aber keine Fehler dirn.
+1 #899 framp 2017-09-05 19:59
Moin Stefan,

vielen Dank fuer den Hinweis auf den Fehler.

Vor ein paar Tagen habe ich etwas am Installer erweitert und leider einen Bug eingebaut :oops: . Den Fehler habe ich aber eben behoben. Du musst nur noch mal das neue Installerscript runterladen ;-)

Cu framp
#898 Stefan 2017-09-05 14:58
Hallo, ich habe gerade einen frisch installierten Raspi3 mit Jessie und versuche das RaspiBackup zu installieren. Beim Aufruf von raspiBackupInstall.sh kommt der Fehler:
raspiBackupInstall.sh: line 52: LANG: unbound variable

Was kann ich hier tun?

Besten Dank und Gruß,
Stefan
#897 framp 2017-09-03 13:08
Moin Klaus,

es gab und gibt immer wieder Diskussionen ob und wenn - welche Dienste vor dem Backup gestoppt werden sollten. Ich weiss von Leuten, die stoppen nichts und der Restore funktioniert ohne Probleme. Lange Zeit waren bei raspiBackup die Optionen -a und -o nicht zwangsweise erforderlich. Erst nachdem ein Benutzer Probleme beim Restore feststellte die durch fehlendes Stoppen verursacht waren habe ich diese Optionen als Zwang eingebaut.

Ich weiss nicht ob und wie das funktionieren kann das System quasi nahezu runterzufahren und dann ein backup zu ziehen und finde es auch etwas overkill. Du kannst ja mal Code:sudo systemctl | grep running benutzen um nachzusehen was bei Dir so alles aktiv ist und mit dieser Liste: https://www.linux-tips-and-tricks.de/de/faq#a18 vergleichen. Wenn Du Services findest wo Du der Meinung bist sie sollten gestoppt werden koennen kannst Du sie ja mal hier angeben und wir diskutieren drueber. Du kannst natuerlich auch alle Services stoppen um 100% sicher zu gehen.

Cu framp
#896 Klaus 2017-09-03 12:51
Hi, ich habe nun die ersten Versuche mit raspiBackup hinter mir. Gefällt mir gut. Wir hatten letztens auch schon Kontakt wegen sed -x. Eines meiner Systeme ist recht komplex, was die zu stoppenden Prozesse angeht. Da kommt mir der Gedanke, ob es nicht sinnvoll/möglich ist den Raspi für das Backup in einem niedrigeren runlevel zu versetzen, das Backup durchzuführen und dann ein reboot zu veranlassen. Die Dienste sind z.Z. des Backups sowieso nicht verfügbar - also stört ein reboot auch nicht. Leider stecke ich in dieser Materie nicht so tief drin und würde deshalb sicher einige Stunden experimentieren müssen. Deshalb wende ich mich wegen der Machbarkeit gleich an Dich, den Experten. Wäre es nicht eine Möglichkeit, um Unsicherheiten bezüglich laufender Prozesse und der damit möglichen Inkonsistenz der Backups zu begegnen, den Raspi vor dem Backup in einen Zustand zu versetzen, in dem nur die nötigsten Dienste laufen?
Gruß, Klaus
#895 framp 2017-08-28 19:33
Moin Klaus,

das ist komisch. Bei mir sieht es wie folgt aus:
Code:curl -s -L -O https://www.linux-tips-and-tricks.de/raspiBackupInstall.sh && sudo bash raspiBackupInstall.sh
--- RBI0001I: raspiBackupInstall.sh 0.3.5, 2017-08-20/15:37:12 - 69741e9
--- RBI0032I: Prüfung ob eine Betaversion verfügbar ist.
--- RBI0041I: Bei keiner Eingabe wird die in GROSSBUCHSTABEN geschriebene Option benutzt.
--- RBI0002I: Sprache der Meldungen (DE|en) :
--- RBI0003I: Normaler oder partitionsorientierter Modus (N|p) : n
--- RBI0004I: Backuptyp (dd|tar|RSYNC) : tar
--- RBI0025I: Backup komprimieren (j|N) : n
--- RBI0006I: Anzahl der Backups (1-52) : 3
--- RBI0008I: Ausführliche Meldungen (J|n) : n
--- RBI0042I: Gewählte Konfiguration: Sprache der Meldungen: de, Backupmodus: normal, Backuptype: tar, Backup komprimieren: n, Anzahl Backups: 3, Ausführliche Meldungen: n
--- RBI0009I: Konfiguration OK (j|N) : j
--- RBI0017I: Existierende Datei raspiBackup.sh wurde als /usr/local/bin/raspiBackup.sh.0.6.2.2.sh gesichert.
--- RBI0014I: raspiBackup.sh wird aus dem Netz geladen...
...--- RBI0037I: /usr/local/bin/raspiBackup.sh wurde erstellt.
--- RBI0037I: /usr/local/bin/raspiBackupInstall.sh wurde erstellt.
--- RBI0017I: Existierende Datei raspiBackup.conf wurde als /usr/local/etc/raspiBackup.conf.0.6.2.2 gesichert.
--- RBI0014I: raspiBackup.conf wird aus dem Netz geladen...
--- RBI0037I: /usr/local/etc/raspiBackup.conf wurde erstellt.
--- RBI0024I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird angepasst.
--- RBI0023I: Installation von raspiBackup erfolgreich beendet.

Benutzt Du die aktuellste Version? Welche Meldungen bekommst Du alles?

Cu framp
#894 Klaus 2017-08-28 16:08
Hallo, leider bekomme ich das Script unter Wheezy nicht installiert. Die Installation endet mit Fehler:
--- RBI0014I: raspiBackup.sh wird aus dem Netz geladen...
--- RBI0037I: /usr/local/bin/raspiBackup.sh wurde erstellt.
--- RBI0037I: /usr/local/bin/raspiBackupInstall.sh wurde erstellt.
sed: Ungültige Option -- z
Vielen Dank für die Hilfe
Gruß, Klaus
#893 framp 2017-08-16 22:33
Micha hat mir sein Log zugeschickt und die Ursache ist auch gefunden: Das Ausgabeformat von sfdisk hat sich offensichtlich mit Debian 9 geändert und raspiBackup kam mit dem neuen Format nicht zurecht.

In der nächsten Version von raspiBackup ist das gefixed.

Vielen Dank an Micha der das Problem reported und den Fix verifiziert hat.
#892 framp 2017-08-15 21:22
Moin Alex,

das ist in der Tat nicht richtig :sad: . Du kannst ja mal zusaetzlich -l debug benutzen und mir das Backuplog zuschicken damit ich nachsehen kann warum es nicht funktioniert. eMail -> Kontakt Seite

Cu framp
#891 Alex 2017-08-15 21:18
Upps, dann läuft bei mir vermutlich irgendwas schief, da mit Erreichen der angegebenen Anzahl Backups (= 3) keine weiteren Backups erstellt werden. Muss mal sehen, woher etwaige Seiteneffekte kommen.
#890 framp 2017-08-15 19:19
Moin Micha,

die Zahl gibt an wieviele Backup vorgehalten werden sollen. Danach wird bei jedem Backup das älteste Backup gelöscht. Die Zahl muss groesser 0 und kleiner 365 sein. Es macht keinen Sinn eine unbegrenzte Zahl von Backups vorzuhalten. Irgendwann platzt das Backupmedium.

Was meinst Du mit rdiff? Differentielles Backup? tar kann das - aber das macht den Restore komplexer und er dauert auch länger. Deshalb empfehle ich immer den rsync Backup, denn der ist ein differentieller Backup aber trotzdem hat man zum Restore einen Vollbackup.

Cu framp
#889 Alex 2017-08-15 18:43
Hi framp,
wenn man bei rsync die Anzahl der Backups angibt, werden genau so viele gemacht, danach nicht mehr, oder? So war das zumindest bei mir.
Was passiert eigentlich, wenn man nichts angibt? Wird das Backup dann einfach ständig weiter geführt? Muss ich mal ausprobieren.
Auch wenn die Datenmengen bei z.B. einem täglichen Backup letztlich recht klein sind, summieren sich die Verzeichnisse nach einer gewissen Zeit auf.
Wäre es denn aufwendig, so etwas wie rdiff-backup o.ä. zusätzlich zu ergänzen (kenn ich jetzt nur vom lesen, dass man die Anzahl und Menge praktisch einstellen kann). Oder könnte man das in der Nachbearbeitung über das Wrapper-Skript anstoßen?

Grüße A
#888 framp 2017-08-13 19:08
Moin Micha,

vielen Dank fuer Deine Beschreibung wie man manuell ein partitionsorientierten Backup restoren kann :-) Das ist ja eine Prämisse für raspiBackup gewesen, dass man auch zur Not den Restore manuell vornehmen können soll und vielleicht hilft es ja mal jemandem.

Allerdings sollte das eigentlich nicht notwendig sein. Wenn Du mir das Log welches Du mit den zusaetzlichen Optionen
-l debug -m detailed -L current
erstellt hast per eMail zuschickst kann ich nachsehen warum es nicht mit raspiBackup geht. Meine eMail findest Du auf der Kontaktseite.

Cu framp
+1 #887 Micha 2017-08-13 18:22
Teil 3:

# logItem "Syncing filesystems"
sync

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

# SD-Karte auswerfen:
eject /dev/sdb

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

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

So kann ich mir selber helfen und das reicht mir alle mal. Vielen Dank für das Skript! Solange das Backup da ist, ist nun der Restore auch nicht mehr schlimm. :-)
#886 Micha 2017-08-13 18:21
Teil 2 des Restores:

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

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

# Fake-HW-Clock patchen:
# logItem "Updating hw clock"
echo $(date -u +"%Y-%m-%d %T") > /mnt/sdb7/etc/fake-hwclock.data
#885 Micha 2017-08-13 18:19
Ich weiß nicht, wo im Skript der Fehler steckt, aber mein manueller Restore klappt 1a :-)
Ich habe den Restore-Teil des Skripts gelesen und die wichtigen Teile per Hand gemacht. Vielleicht hilfts ja auch anderen weiter. :-)

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

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

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

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

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

mount /dev/sdb1 /mnt/sdb1
mount /dev/sdb5 /mnt/sdb5
mount /dev/sdb6 /mnt/sdb6
mount /dev/sdb7 /mnt/sdb7
#884 framp 2017-08-12 18:04
Moin Philipp,

dem Code nach ist Dein Bootdevice weder /dev/sdx noch /dev/mmcblk. Desshalb kommt die assertion Failed Meldung.

Was ist denn Dein Bootdevice?

Fuege mal noch die zusaetzlichen Optionen -m detailed und -l debug hinzu und lass mich das Log mit den debug Zeilen sehen.

Cu framp
#883 Micha 2017-08-12 17:22
Also ich bekomme ein komplettes rsync-Backup nicht zurück gesichert. :-(
Die Quelle ist ein Raspberry Pi 3 mit 32 GB SD-Karte. Darauf ist ein NOOBs mit:
root@pi:~# cat /etc/debian_version
9.1

Das Backup läuft sauber durch.

Die Wiederherstellung soll unter einer Debian 9 VM laufen, wo eine neue 64 GByte große SD-Karte per Adapter in die VM gemountet ist, d.h. das Ziel ist größer als die Quelle (ist ein Thema anderes Thema "Restore SD ist kleiner als Source SD"...)

Dies ist die Ausgabe:
https://pastebin.com/wwr2L8WH

Was soll ich da machen? Es sieht so aus, als würde das Formatieren der SD-Karte nicht funktionieren.

Was soll ich da machen?
+1 #882 framp 2017-08-11 18:27
Moin Philipp,

vielen Dank fuer den Hinweis auf den Typo. Der ist seit Anbeginn der Configdatei drin. Aber hat keine schlimmen Auswirkungen. Es ist auch eher unueblich den Verbose Mode in der Config anzuschalten.

Cu framp
#881 Philipp 2017-08-11 10:39
Hi framp,

noch ein kleiner Hinweis, in der Configdatei vom 03.08 ist unter "DEFAULT_VERBOSE" ein Schreibfehler "DEFAULT_VEBOSE". Hab die Option noch nicht testen können daher weiß ich nicht ob sich der Fehler irgendwie auswirkt :)

Grüße
#880 Alex 2017-08-11 09:41
Danke framp, hatte tatsächlich DEFAULT_ZIP_BACKUP auf 1 in der config.
Nun funtzt es!
#879 framp 2017-08-10 19:21
Moin Alex,

Du versuchst die Option -z zusammen mit rsync zu benutzen. Das geht nicht :cry: . -z kannst Du nur mit dem Backuptp tar oder dd benutzen.
Die Fehlermeldung ist etwas unglücklich formuliert. Ich habe sie eben geändert. :-)

Cu framp
#878 Alex 2017-08-10 00:15
hi,
hab gerade einen neues raspbian lite aufgesetzt und das backup eingerichtet. Beim test erhalte ich einen Fehler Das rsync unbekannt ist.??? Jemand eine tipp was ich falsch mache?

pi@rpi2a:/var/log $ sudo /usr/local/bin/raspiBackup.sh
--- RBK0009I: rpi2a: raspiBackup.sh V0.6.2.1 (16b628f) um Do 10. Aug 00:11:25 CEST 2017 gestartet
??? RBK0079E: Unbekannter Backuptyp rsync für Option -z
/usr/local/bin/raspiBackup.sh: Zeile 3615: moentionHelp: Kommando nicht gefunden.
mail: Invalid header: /home/pi/rpi2a-raspiBackup.log
--- RBK0105I: Neues Backupverzeichnis /mnt/backup_router/RPI/rpi2a/rpi2a-rsync-backup-20170810-001124 wird gelöscht
??? RBK0005E: Backup fehlerhaft beendet mit RC 107. Siehe vorhergehende Meldungen
pi@rpi2a:/var/log $
#877 Philipp 2017-08-09 22:38
Hi framp,

alles klar, ich werde beide Wege einfach probieren, kostet ja nix :)
Danke für deine Hilfe und dein grandioses Tool.

Grüße
+1 #876 framp 2017-08-09 22:17
Moin Philipp,

ganz grob weiss ich das Pi-Hole die Werbung auf Deinen Clients reduziert. Allerdings habe ich es nicht am Laufen. Deine Clients werden sicherlich über Nacht schlafen so dass es unbedenklich ist den Backup irgendwann gegen fruehen Morgen zu erstellen.

Aber trotzdem bin ich der Meinung dass Du den DNS auch nicht stoppen musst. (Argumente siehe unten).

Du kannst beide Wege gehen und die Entscheidung in
welche Richtung triffst Du :-)

Cu framp
#875 Philipp 2017-08-09 21:25
Hi framp,

danke für deine super (schnelle) Antwort. Ich mache alles über die Konfigurationsdatei, heißt ich gebe keine Parameter mit. Hab deinen Tipp probiert und 1m sleep in die Config Datei angehängt, klappt nun super mit sendEmail an meine GMail Adresse.

Zu der anderen Sache, ich weiß nicht wie sehr du mit dem Pi-Hole Projekt vertraut bist, aber da meine Clients ständig an meinen PiHole anfragen und dieser auch loggt hat es für mich Sinn gemacht vor allem Services wie dnsmasq und lighttpd zu stoppen da du auch in deiner FAQ meintest generell Services zu stoppen welche Dateien schreiben.
Einen Nachbar DNS hab ich (noch) nicht, ist mein PiHole Down funktioniert erstmal gar nichts, weswegen ich das Backup auch monatlich irgendwann in die Nacht legen werde.

Wenn ich einen Denkfehler habe bei der ganzen Sache dann gerne darauf hinweisen :lol:

Grüße
+1 #874 framp 2017-08-09 18:54
Moin Philipp,

freut mich dass Dir das Installationsscript gefaellt :-) Die Installation soll ja auch moeglichst einfach sein um eben mal schnell zu Testen. Das Feintuning der Optionen und Parameter kann man dann spaeter in einer ruhigen Stunde vornehmen.

Es ist sehr gut dass Du Dir Gedanken über das Stoppen und Starten von Services gemacht hast. Ich denke aber den DNS brauchst Du nicht zu stoppen. Sollten wirklich ein paar neue DNS Eintraege im Backup fehlen wird sich der DNS die fehlenden Infos vom Nachbar DNS holen.
Auch ist in dieser Zeit kein DNS Server für Deine Clients verfügbar. Das kann schon zwischen 30-60 Minuten dauern. Solange kannst Du die Clients dann nicht benutzen :-(

Willst Du trotzdem eine Verzoegern geht das ganz leicht. Du musst nur am Ende der Parameter fuer -a " .... ; sleep 1m" eintragen. Die Parameter werden der bash zum Ausführen gegeben und da kannst Du jeden bash Befehl wie z.B. den sleep aufnehmen ;-)

Cu framp
#873 Philipp 2017-08-09 15:04
Hi framp,

ich habe eine relativ kleine Frage. Die Installation und Einrichtung des Scripts ist echt super einfach, danke dafür.

Ich möchte es nutzen um meinen Pi2 auf dem Raspbian läuft per rsync auf einen USB Stick zu sichern. Das Problem liegt am Ende beim E-Mail Versand.

Der PI läuft bei mir als DNS Server (PiHole), da ich beim Backup die relevanten Services stoppe ist natürlich meine Verbindung "Down". Problem ist das auch die E-Mail nicht versendet werden kann weil beim Start die Services etwa 30 sek vorlauf brauchen bis wieder eine Verbindung steht.

Ist es irgendwie möglich ein Wait zwischen Start der Services und E-Mail Versand manuell einzubauen um das zu umgehen?
#872 framp 2017-07-10 19:39
Moin Tom,

Du musst anstelle von raspiBackup ein Testscript aufrufen welches testet ob Dein NfsServer verfügbar ist und wenn ja raspiBackup startet.

Ich habe eben ein kleines Script welches dieses tut auf github hingestellt ;-)

Cu framp
#871 e-raser 2017-07-10 19:37
Ich nehme mal an gar nicht, bzw. andersrum könnt´s was werden:

CronJob starten, zu Beginn prüfen ob Backup-Storage verfügbar ist, wenn ja: GO, wenn nein: exit.

Das heisst aber (ohne aktiven Trigger durch das Backup-Storage) bei entsprechender Taktung des CronJobs auch: Deine raspiBackup-Versionen sind entweder VIELE aktuelle oder wenige alte...
#870 Tom 2017-07-10 12:33
Moin und vielen Dank für das tolle Skript !

Ich sichere alle meine Raspi (2+3,zero) mit nfs auf eine synology - die Synology läuft aber nicht immer.

Wie kann ich einen cronjon erstellen, der nur startet, wenn die synology mit der nfs Freigabe zur Verfügung steht ?
#869 framp 2017-05-20 22:11
Moin Andreas,

freut mich das es jetzt mit dem Exclude funktioniert :-) .

raspiBackup hat noch nie externe gemountete Partitionen gesichert. raspiBackup sichert nur die SD Karte und ein externes Rootfilesystem soweit vorhanden.

Wenn Du die zur selben Zeit sichern möchtest wenn raspiBackup läuft musst Du mein raspiBackup Wrapper Script benutzen und selbst Code zufügen der die externe Partition sichert. Beim Restore musst Du dann auch manuell die externe Partition wieder zurückspielen.

Cu framp
#868 Andreas 2017-05-20 19:39
Hi framp,

vielen Dank für Deine Unterstützung. Jetzt funktioniert alles so wie ich es haben möchte, zumindest mit dem exclude.

Jedoch habe ich noch folgende Frage: ich habe einen USB-Stick angehängt (ext4) und würde auch diesen mit in die Sicherung (per rsync) aufnehmen. Ich meine mich erinnern zu können, daß dies bei einer alten Version vom raspiBackup ging, doch jetzt scheint es nicht mehr zu gehen.
Gibt´s´auch hier irgendeinen Tipp, wie dies durchführbar ist?

Merci,
Andreas
#867 framp 2017-05-18 19:23
Moin Andreas,

das ist zugegebenermassen etwas kompliziert :sigh:

Beipiel:

DEFAULT_EXCLUDE_LIST="--exclude=/backup/* --exclude=/rsnapshot/* --exclude=/www-data*/*"

Zum Testen ob das Excluden wie gewünscht funktioniert würde ich wie folgt vorgehen:

rsync --dry-run -v "--exclude=/backup/* --exclude=/rsnapshot/* --exclude=/www-data*/*" / /backup

Damit wird rsync im Trockenmodus aufgerufen und kopiert nichts - zeigt aber an welche Dateien kopiert werden würden.

Wenn dann die Excludeliste dann stimmt kann sie dann in die Konfig reingeschrieben werden.

Wenn Du ein -P Backup erstellst müssen die Zeilen etwas anders aussehen. Siehe dazu https://www.linux-tips-and-tricks.de/de/raspibackup#parm_u

Beim rsync musst Du aufpassen da alles relative Links sind. Beim normalen Modus ist beim raspiBackup root immer / - waehrend beim -P Modus es /tmp/ ist, Siehe dazu auch www.thegeekstuff.com/2011/01/rsync-exclude-files-and-folders/?utm_source=feedburner

Ich hoffe die Info hilft Dir weiterzukommen. :roll:

Cu framp
#866 Andreas 2017-05-18 14:59
Hi framp,

vorweg ein sehr großes Lob an Dich für das tolle tool, funktioniert bei mir tadellos.
Jedoch habe ich nun die Konstellation, daß ich mehrere Verzeichnisse vom backup ausnehmen möchte. Leider bringt mich dieser Umstannd etwas zur Verzweiflung, denn in der Konfigurationsdatei bei der Option "DEFAULT_EXCLUDE_LIST" habe ich schon mehrere Varianten probiert, mehrere Verzeichnisse hier einzutragen, mit immer unterschiedlichen Trennzeichen - doch leider immer ohne Erfolg.
Hast Du da irgendeinen Hinweis, wie ich das anstellen kann, damit´s mit RSYNC funktioniert?

Besten Dank im Voraus,
Andreas
#865 Christian 2017-05-03 22:14
Alles klar :-) Läuft jetzt jedenfalls ;-)
#864 framp 2017-05-03 22:04
Moin Christian,

ja das weiss ich. Ich habe ja auch viele Restoretests auf meinem LinuxDesktop vorgenommen. Aber in der V 0.6.2 hat sich was durch den Raspi3Support verschiedenes geändert. Leider habe ich alle Restoretests auf der Raspi vorgenommen und dadurch nicht entdeckt dass es auf einem normalen LInux nicht mehr geht :sad: Ich werde das fixen.

Cu framp
#863 Christian 2017-05-03 22:00
Hi framp,

hm, habe definitiv mit 0.6.1.3b(?) schon auf dem Laptop restored...!?

Werde es mal mit -Z probieren

Danke.
#862 framp 2017-05-03 21:53
Moin Christian,

dem Prompt nach restorest Du auf einem Laptop. raspiBackup erwartet aber ein gemountetes Verzeichnis /boot. Das existiert bei Dir natuerlich nicht auf dem LinuxLaptop. Zugegebenermassen ist das blöd dass man kein Backup auf einem normalen Linuxrechner - also nicht der Raspberry - restoren kann. Ich sehe mir das mal an und ändere das.

Benutze aber mal die undokumentierte Option -Z. Damit sollte es funktionieren ;-)

Cu framp
#861 Christian 2017-05-03 21:29
Hallo,

ich bekomme ebenfalls den Fehler "Kein Bootgerät gefunden". Allerdings nicht beim Backup, sondern beim Restore. Was könnte das Problem sein?

root@chrille-laptop:/home/chrille# raspiBackup.sh -m 1 -l 1 -d /dev/mmcblk0 -R /dev/sdb1 /backup/myraspberries/oscam/oscam-rsync-backup-20170502-172116/
--- RBK0009I: chrille-laptop: raspiBackup.sh V0.6.2 (74c0a8d) um Mi 3. Mai 21:29:17 CEST 2017 gestartet
--- RBK0128I: Logdatei ist /home/chrille/raspiBackup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
--- RBK0138I: Bootbackup /backup/myraspberries/oscam/oscam-rsync-backup-20170502-172116 wird benutzt
--- RBK0068I: Bootpartitionsdateien des Backups aus dem Verzeichnis /backup/myraspberries/oscam/oscam-rsync-backup-20170502-172116 die mit oscam-backup beginnen werden benutzt
??? RBK0155E: Kein Bootgerät gefunden
#860 framp 2017-05-02 19:31
Moin Matt,

raspiBackup sichert eine Boot- und eine Rootpartition. Es scheint so als ist unter Armbian nichts unter /boot gemounted. Deshalb kommt der Fehler. Wo liegt denn bei Armbian das Bootverzeichnis? U.U. könnte man mit einem Symlink nachhelfen.

Cu framp
#859 Matt 2017-04-30 20:49
Hi,
nachdem ich von Bananian derzeit den Umstieg auf Armbian (Ubuntu) teste, habe ich versucht mit Raspibackup 0.6.2 unter Armbian ein Backup zu erstellen.
Leider schlägt dies fehl, die letzten Zeilen des Log sehen so aus:
20170430-203856: DBG getRootPartition
20170430-203856: DBG -- RootPartition: UUID=64383220-a185-4473-b3ab-ef1612d4d94c
20170430-203856: DBG > inspect4Backup
20170430-203856: DBG -- ls /dev/mmcblk*:
/dev/mmcblk0
/dev/mmcblk0p1
20170430-203856: DBG -- ls /dev/sd*:

20170430-203857: DBG -- part:
20170430-203857: MSG ??? RBK0155E: No bootdevice found
20170430-203857: DBG >> exitError 102
20170430-203857: DBG
#858 framp 2017-04-26 14:50
Moin e-raser,

sorry für die späte Antwort. Aber ich komme gerade erst aus dem Urlaub zurück :-)

Ich habe dummymaessig Deine Konfig nachgestellt und das Script wird genau einmal aufgerufen.

Mein Vorschlag: Du rufst einmal raspiBackup mit den zusaetzlichen Optionen
-l debug -m detailed
auf und schickst mir das erstellte Log an meine eMailAdresse (Siehe Kontakt Seite). Dann kann ich exakt sehen wie häufug raspiBackup Deine Extension aufruft ;-)

Zum bash Debuggen würde ich
set -x
am Anfang reinschreiben und am Ende
set +x

Oder einfach mal ein paar Debugausgaben per echo in eine Datei. Z.B.
echo "TestAusgabe" >> /tmp/rsp.log

Sofern Dein Script überschaubar ist kannst Du es mir auch gerne zuschicken und ich sehe es mir mal an.

Cu framp
#857 e-raser 2017-04-22 18:06
Hi raspiBackup-Meister,

mir ist nun schon mehrfach aufgefallen, das das Post-Skript mehrfach ausgeführt wird.

Skript:
"/usr/local/bin/raspiBackup_PushingBox_NotifyBackup_post.sh"

Aufruf via Cron:
"/usr/local/bin/raspiBackup.sh -a: -o: -t tar -k 24 -N "PushingBox_NotifyBackup" /mnt/Backups/"

Soweit so langweilig. Leider kann ich nicht recherchieren, wo der Fehler passiert. Zur Erklärung: Das Post-Skript setzt nur eine Meldung (Push + Mail) ab; die habe ich nun schon den 2. Backup-Lauf (weekly) in Folge jeweils DREIMAL erhalten.

Irgendeine Idee wie ich das "down tracken" kann, also: liegt es am Raspi-Backup?

Bin noch auf v0.6.1.3b, werde jetzt zunächst auf v0.6.2 aktualisieren und über den Simulationsparameter das Backup erneut "durchführen".
#856 framp 2017-03-20 19:48
Moin Thomas,

raspiBackup sichert nur eine externe root Partition im normalen Modus mit. Aber Du meinst sicherlich irgendwelche anderen Partitionen wie z.B. Datenpartitionen.

Also leider nein :sad:

Du bist aber nicht der Erste der nach sowas fragt. Ich habe u.A. auch dafür ein kleines Wrapperscript bereitgestellt. Dort kannst Du vor oder nach dem Backup mit raspiBackup noch die Sicherung weiterer Daten aufnehmen.
Vielleicht meldet sich ja jemand von denen und stellt seine Implementierung zur Verfügung. Viel ist es nicht. Ein paar Zeilen reichen um per tar oder rsync andere Partitionen zu sichern.

Beim Restore musst Du dieses natürlich auch manuell vornehmen. Dummerweise ist das Wrapperscript nicht darauf ausgelegt auch im Restorefalle zu funktionieren.

Ich nehme Deine Nachfrage zum Anlass das zu ändern :-)

u framp
#855 Thomas Pfaffinger 2017-03-20 12:16
Hallo,
gibt es eigentlich die Möglichkeit, externe Daten mitzusichern?

Ich habe einen USB-Stick mit an den PI angeschlossen, udn würde die Daten von dem Stick gerne direkt mitsichern lassen.,

mfg
Thomas Pfaffinger
#854 framp 2017-03-18 18:10
Moin Balou,

kann ich verstehen. Never touch a running system :lol: Und ja - Du kannst eine normale Raspbian Installation mit zwei Partitionen auch im paritionsorientierten Modus sichern. Nur wird dann keine externe Rootpartition gesichert :cry:

Cu framp
#853 Balou 2017-03-18 16:37
Framp

Fehler wohl gefunden, ich hatte in der Conf Datei noch
Partionsbackup eingestellt. Sieht erstmal soweit alles okay aus. Morgen teste ich dann mal den Restere.

Balou
#852 Balou 2017-03-18 15:26
Hallo Framp,

Du weißt ja wie das ist. Man fängt mal an und solange man nicht über Probleme stolpert läßt man es so. Sicherlich Noobs an sich benötige ich nicht.
Ich habe meine Installation auf eine SD Karte ohne Noobs geschubst. Jetzt wird die SD gesichert. Beide Partionen,aber die externe Root wird nicht gesichert.
Gibt es da noch einen Fallstrick? Ich habe die externe Partion über die PARTUUID eingebunden.
Gruß Balou
#851 framp 2017-03-18 11:18
Moin Balou,

die Funktionalität von raspiBackup war initial von meinen eigenen Bedürfnissen getrieben.

1) Nur SD Karte und dd Backup
2) Nur SD Karte und tar Backup
3) Nur SD Karte und rsync Backup
4) Auslagerung der Rootpartition auf USB Platte

Danach gab es verschiedentlich Nachfragen nach einem NOOBs Backup welches ich nicht brauche aber dann nach einer Weile implementiert habe. Dort fehlt aber der Support für eine externe Partition da ich nicht davon ausging dass jemand das benötigt, denn NOOBS ist in meinen Augen nur zum Probieren und Evaluieren gedacht. Meine Meinung ist: Wer seine Raspi in Produktion einsetzt benutzt kein NOOBs sondern nur ein einziges Betriebssystem und kann dann im normalen Modus mit raspiBackup eine externe Partition mitsichern.

Du benutzt NOOBS mit einer externen Partition und fällst damit in das Loch dass das Sichern von externen Partitionen von raspiBackup aus o.g. Gründen im partitionsorientierten Modus nicht unterstützt wird :sad:

D.h. Dein erster Weg ist eine Möglichkeit Dein Problem zu lösen. Ich vermute Du benutzt das Wrapperscipt dazu. Der Restore geht dann nicht ausschliesslich mit raspiBackup denn Du musst ja noch manuell die Rootparition restoren - was aber relativ einfach ist. Nur eben nicht ganz so bequem wie mit raspiBackup alleine :-)
Dein zweiter vorgenschlagener Weg geht nicht da raspiBackup im normalen Modus meckert wenn mehr als zwei Partitionen auf der SD Karte sind und sagt man solle den paritionsorientierten Modus nehmen.

Ich würde an Deiner Stelle aber überlegen ob Du wirklich NOOBS brauchst und wenn nicht alles einmal vom NOOBS auf ein raspbian umziehst. Dann kann ein vollständiger Backup und Restore von raspiBackup vorgenommen werden.

Cu framp
#850 Balou 2017-03-18 10:48
Hi Framp

Ich bastele derzeit an meinen Raspberry 3 rum. Ich nutze
schon dein Script bei meinen alten Raspberry und soweit alles super. Also mal besten Dank für deine Klasse Arbeit.

Im Moment habe ich meine Root Partionen auf eine Externe SSD ausgelagert. Installiert ist Raspian mit Noobs. Die Sicherung mache ich einmal im partitionsorientierten Backupmodus und dann sichere ich mein Root Partionen noch mit tar. Klappt auch soweit auch.
Ein andere Gedanke ist einmal im normalen modus ein Backup zu erstellen das meine extern Root mitsichert und dann im partionsmodus die restlichen partionen zu sichern.
Oder gibt es im Script noch einen Modus den ich übersehen habe?
#849 framp 2017-03-12 09:46
Moin Thanatos,

vielen Dank für Dein Interesse die Beta zu testen helfen. Du kannst die aktuelle Beta hier runterladen. Verständlicherweise wirst Du primär Dein Einsatzszenario testen wollen. Wenn Du dann aber auch noch ein oder zwei noch nicht getestete Szenarien testen und bestaetigen könntest würdest Du sehr helfen ;-)

Cu framp
#848 thanatos 2017-03-12 01:03
Hi framp,

nutze hier mittlerweile auch nen Pi 3 für NFS backups auf eine Synology. Läuft soweit ganz gut. Wenn Bedarf besteht teste ich ein bisschen mit deiner Beta.

cheers,
thanatos
#847 framp 2017-03-06 19:55
Moin John,

sag ich doch dass der Captcha erscheint :-)

So wie ich es sehe macht das nur beim Restore Sinn, da der interaktiv abläuft. Ich hatte das auch schon mal auf dem Radar als Goodie. Bislang gab es aber wichtigere Sachen zu implementieren.

Ich nehme es mal auf meine Todoliste. BTW: Die nächste Version ist gesprächiger sowohl beim Backup als auch Restore.

Cu framp
#846 john 2017-03-06 08:52
Hallo Framp,

Jetzt gehts irgendwie doch .. ( wahrscheinlich ist bei mir Zuhause die browser Einstelllungen ztu restriktiv wg. der VPN.

Ja du hast recht in Bezug auf PV ( siehe https://github.com/framps/raspiBackup/issues/5 )
sehe ich einfach die Möglichkeit bei Aufruf von der commandline zwecks Testläufe oder was du schon angesprochen hast um zu sehen, wie weit das Update im Restore Prozess ist.

Weiss nicht inwieweit das schwierig ist zu integrieren, aber ich kann es auch ganz einfach per Pipe machen sowie ich es im Post steht.


@Immi:

Für die Mailübertragung benutz am besten nullmailer ... easy zu konfigurieren und sehr cpu arm ...

grüsse john
#845 framp 2017-03-05 10:14
Moin Kurt,

dem Parameter -d muss die Ausgabe-SDKarte folgen (/dev/sdc bei Dir) . Mit Code:sudo raspiBackup.sh -d /dev/sdc -l debug -m detailed -L current /media/Back/raspberrypi/raspberrypi-rsync-backup-20170219-200701/ Sollte es funktionieren ;-)

Cu framp
#844 Kurt 2017-03-05 10:03
Moin framp,

ich habe also das restore erneut versucht mit folgendem Befehl:

sudo raspiBackup.sh -d -l debug -m detailed -L current /dev/sdc /media/Back/raspberrypi/raspberrypi-rsync-backup-20170219-200701/

Es ist also ein rsync backup, das ich auf eine 16GB Karte zurück spielen will.

Es kommt ein Fehler:
??? RBK0147E: debug nicht gefunden

Kurt
#843 immi 2017-03-04 15:22
Ok danke dir :)
+1 #842 framp 2017-03-02 07:58
Moin immi,

wenn Du Dir eMails zuschicken lassen willst muss ein eMailServer verfügbar sein und Du musst den so konfigurieren dass er Dir eMails zuschicken kann. postfix würde ich nicht benutzen. Zu kompliziert zu konfigurieren. Fuer den Heimgebrauch reicht exim2. Das habe ich z.B. auf meinen raspis installiert und konfiguriert. exim2 schickt die eMails an meinen eMail Account und natuerlich muss dafür irgendwo Credentials abgelegt sein. Da kommst Du nicht drum rum.
Wie man einen exim eMailServer aufsetzt musst Du im Netz suchen. Du kannst z.B. hier suchen. Ich glaube da war irgendwo im Tutorial beschrieben wie man exim aufsetzt. Ich bin immer froh wenn mein exim läuft denn eMailServer sind ein Buch mit 7 Siegeln für mich :cry:

Cu framp
#841 immi 2017-03-02 01:00
Hi framp,
ich nutze gerade dein script und finde es echt klasse.
Was mir gerade ein wenig schleierhaft ist - muss ein postfix auf meinem system konfiguriert sein damit ich emails versenden kann? Möchte ungern einen externen Server wie z:B. den von Googlemail nutzen da ich ja dann ein passwort in der Konfig hinterlegen müsste. über eine Antwort und ggf. Anleitung wie ich das recht simpel zum rennen bekomme würde ich mich freuen.
Gruß aus Stuttgart nach Stuttgart :)
#840 gNeandr 2017-02-28 20:39
Danke Framp für den Hinweis!
Es ist wohl dies:
Zitat:
# Anzahl der zu vorhaltenden Backups
DEFAULT_KEEPBACKUPS="1"
... was du mit KEEP=1 meinst.

Sorry für die unscharfe Beschreibung, ich dachte hiermit ist es klar ausgedrückt:
Zitat:
Damit wird der USBstick ganz mit dem neuen Backup überschrieben.
Werde mal den DEFAULT_KEEPBACKUPS Wert ändern.
Gruß
Günter
#839 framp 2017-02-28 19:46
Moin gNeandr,

Zitat:
...Mein Versuch auf den USBstick ein zweites backup zu schreiben klappt nicht....
Klappt nicht ist eine ungenaue Beschreibung. Welchen Fehler bekommst Du oder was fuer eine Erscheinung hast Du sonst genau aus der Du vermutest dass alles überschrieben wurde?

Hier ist die Backupverzeichnisstruktur beschrieben. Daraus siehst Du dass unter dem Backupverzeichnis pro Backup immer ein Ordner mit dem Hostnamen der Raspi gefolgt von einem Verzeichnis welches den Backuptyp sowie das Backupdatum enthält erstellt wird. Damit kannst Du beliebig viele Backupversionen sichern. Hast Du vielleicht KEEP 1? Dann wird natürlich am Ende eines erfolgreichen Backups immer das vorherige Backup geloescht und es bleicbt nur das Neue uebrig :-)

Cu framp
#838 gNeandr 2017-02-28 16:32
Zusatzfrage:
Mein Versuch auf den USBstick ein zweites backup zu schreiben klappt nicht. Ich habe diese Befehle benutzt (siehe auch Post#823):
Zitat:
-- Genutzt wird ein USBstick (4GB), gemountet mit: pi@rpi4:/ $ sudo mkdir media/backup pi@rpi4:/ $ sudo mount -t ext4 -o defaults /dev/sda1 /media/backup -- dann backup mit: pi@rpi4:/ $ sudo bash /usr/local/bin/ raspiBackup.sh -p /media/backup -t tar -a : -o :
Damit wird der USBstick ganz mit dem neuen Backup überschrieben. Wie kann ich das script ändern, damit ich ein weiteres Sicherungsdirectory bekomme? Und ändert sich dann auch das Restore?
#837 gNeandr 2017-02-28 00:24
Hallo Framp!
Alles klar, backup zurückgeschrieben und läuft wie vorher im RPI .. mit der "eingestellten" IP!

Danke
Günter :-)
#836 framp 2017-02-27 23:28
Moin gNeandr,

vielen Dank für den Hinweis. Ich habe es gefixed (clear cache im Browser aber notwendig :-)

Cu framp
#835 gNeandr 2017-02-27 23:08
Danke, schau ich mir an.
Allerdings ist hier ein toter link:
https://www.linux-tips-and-tricks.de/de/
bei
Überblick
raspiBackup erstellt Backups vor Raspberry Pis. Das ...
(hinter raspiBackup: https://www.linux-tips-and-tricks.de/de/component/content/13-raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself?Itemid=107)
#834 framp 2017-02-27 22:13
Moin gNeandr,

Es existiert eine eigene Seite für den Restore ;-) . Auf der rechten Seite der Webpräsenz gibt es einen eigenen Bereich mit den wichtigesten Links zu raspiBackup. Ausserdem findet sich der Link im Inhaltsverzeichnis Punkt 8 zu der raspiBackupseite ;-)
Dort findet sich auch ein Beispiel für 'Restore auf eine SD Karte'

In Deinem Falle muss es wie folgt aussehen:
Code:sudo raspiBackup.sh -d /dev/sdc /media/gn/RPIbackup/<backupDirectory>
Die SD Karte wird neu formatiert und partitioniert (Genaueres steht bei der Beschreibung der Optionen für den Restore). Man sollte also schon schon sehr sorgfältig sein und wirklich die /dev/sdx wo die SD Karte drin ist angeben. Ansonsten ist eine Platte Deines Linuxes platt :-) .

Cu framp
#833 gNeandr 2017-02-27 21:27
Zitat:
>> -- Kann ich den USBstick in eine LinuxMaschine stecken, ebenfalls die SDcard und per Befehl die SDcard neu schreiben, also das backup restoren?
> Ja das funktioniert. Es muss nicht unbedingt die raspi sein. Es muss einfach ein Linux sein. Bei mir läuft ein Mint/Ubuntu/Debian und der Restore mit raspiBackup funktioniert perfekt.

Leider hatte ich hier nicht wie vorstehend gefragt .. (Mit welchem Befehl?)

Kannst du mir da Hinweise geben wie das wäre?
Also wie bei dir Mint/U/Debian, mit USBstick und SDcard gibt es:

$ df -h
Filesystem Size Used Avail Use% Mounted on
...
/dev/sdb1 3,7G 1005M 2,5G 29% /media/gn/RPIbackup
/dev/sdc1 63M 21M 42M 33% /media/gn/boot
/dev/sdc2 30G 990M 27G 4% /media/gn/0aed834e-8c8f-412d-a276-a265dc676112

Wie sieht der /raspiBackup.sh Schreib-Befehl dann aus um von sdb1 auf die sdc1/2 zurück zu schreiben?
Muss/sollte die SDcard vorher formatiert werden?
#832 framp 2017-02-27 20:18
Moin gNeandr,

zitiere gNeandr:
-- Diesen Stand möchte ich als Basis für Anwendungsinstallationen (pilight/piSchedule) nutzen und ggf. diesen auf die SDcard zurück speichern um neu anzufangen.
Dafür ist raspiBackup natürlich auch geeignet
Zitat:

Fragen:
-- Kann ich das Restore auf dem gleichen RPI machen, dh. das bestehende System durch ein Restore einfach überschreiben und nach Ende rebooten und gut is'es?
(Mit welchem Befehl?)
Nein, das geht nicht. Damit sägt man sich quasi den Ast auf dem man sitzt ab und versucht anschliessend einen anderen Ast anzukleben :-)
Zitat:

-- Kann ich den USBstick in eine LinuxMaschine stecken, ebenfalls die SDcard und per Befehl die SDcard neu schreiben, also das backup restoren?
Ja das funktioniert. Es muss nicht unbedingt die raspi sein. Es muss einfach ein Linux sein. Bei mir läuft ein Mint/Ubuntu/Debian und der Restore mit raspiBackup funktioniert perfekt.
Zitat:
Ich habe die Schwierigkeiten mit dem Jessie Light gelesen, fehlende IP etc, ist dies hier auch befürchten?
Meine bisherige Installation mit /etc/dhcpcd.conf folgt den Hinweisen von Jeff Geerling auf:
https://www.jeffgeerling.com/blog/2016/setting-static-ip-address-raspbian-jessie-lite-on-raspberry-pi
... und das läuft ohne Problems.
Mit Jessie Light habe ich es nicht getestet. Probiere einfach den Restore aus. Im Fehlerfall auf systemd-networkd umstellen.

Cu framp
#831 gNeandr 2017-02-27 18:35
So jetzt ist es so weit .. Backup/Restore muss sein :D
Allerdings benötige ich einige zusätzliche Hinweise.

Das ganze geschieht auf RPI2 mit Jessie Light (!).
Das Backup soll den Installationsstatus festhalten nach
-- der initialen Jessie Light Installation mit durchgeführtem updates
$ sudo apt-get update
$ sudo apt-get upgrade
-- und:
pi@raspberrypi ~ $ sudo raspi-config

-- Diesen Stand möchte ich als Basis für Anwendungsinstallationen (pilight/piSchedule) nutzen und ggf. diesen auf die SDcard zurück speichern um neu anzufangen.

-- Genutzt wird ein USBstick (4GB), gemountet mit:
pi@rpi4:/ $ sudo mkdir media/backup
pi@rpi4:/ $ sudo mount -t ext4 -o defaults /dev/sda1 /media/backup
-- dann backup mit:
pi@rpi4:/ $ sudo bash /usr/local/bin/raspiBackup.sh -p /media/backup -t tar -a : -o :

-- das wird erfolgreich beendet mit:
--- RBK0010I: rpi4: raspiBackup.sh V0.6.1.3b um Mo 27. Feb 11:15:36 CET 2017 beendet
--- RBK0017I: Backup erfolgreich beendet
pi@rpi4:/ $

Nach guter Sitte müsste ich jetzt das Backup testen/ zurück speichern, da bin ich mir nicht sicher wie soll das erfolgen?

Fragen:
-- Kann ich das Restore auf dem gleichen RPI machen, dh. das bestehende System durch ein Restore einfach überschreiben und nach Ende rebooten und gut is'es?
(Mit welchem Befehl?)

-- Kann ich den USBstick in eine LinuxMaschine stecken, ebenfalls die SDcard und per Befehl die SDcard neu schreiben, also das backup restoren?

Ich habe die Schwierigkeiten mit dem Jessie Light gelesen, fehlende IP etc, ist dies hier auch befürchten?
Meine bisherige Installation mit /etc/dhcpcd.conf folgt den Hinweisen von Jeff Geerling auf:
https://www.jeffgeerling.com/blog/2016/setting-static-ip-address-raspbian-jessie-lite-on-raspberry-pi
... und das läuft ohne Problems.

Hope for help!
#830 framp 2017-02-05 11:57
Moin Christian,

vielen Dank für das Log. Ich denke ich habe die Ursache gefunden und Dir per eMail geantwortet :-)

Cu framp

EDIT: Eben hat Christian meine Annahme bestaetigt: Es war die root Partition noch ein weiteres mal gemounted und deshalb konnte sie nicht umounted werden. Ich habe an der Stelle jetzt eine vernünftige Fehlermeldung eingebaut.
#829 Christian 2017-02-05 10:06
Moin framp,

ich hatte ursprünglich ein paar mehr Infos untergebracht, die Begrenzung von 2500 Zeichen hat mich dann einiges löschen lassen ;-)

Zunächst einmal benutze ich die aktuelle Version 0.6.1.3, ganz frisch aufgesetzt. Auf der SD Karte des Raspi befindet sich die Boot Partition, die Root Partition ist auf USB Stick ausgelagert. Ich benutze ein Wrapper Script. Die Sicherung erfolgt auf ein Synology NAS per NFS Mount. Ich kann dir gern auch mal das Wrapper Script und meine conf zukommen lassen.

Gruß, Christian
#828 framp 2017-02-04 23:44
Moin Christian,

das sieht ziemlich böse aus :cry:

Ich habe versucht rauszufinden was wohl bei Dir die mögliche Ursache ist und leider keinen Erfolg gehabt. Primär ist das dadurch bedingt dass ich nicht weiss welchen Codestand Du benutzt. Das werde ich in der nächsten Version 0.6.1.4 verbessern dass das im Stacktrace angezeigt wird.

Anyhow - benutze zusaetzlich die Optionen -m 1 -l 1 und schicke mir dann bitte das Log an meine Mail -> Kontakt Seite.

Cu framp
#827 Christian 2017-02-04 18:04
Hallo,

ich versuche schon den ganzen Tag erfolglos einen Restore zu testen. Folgendes Fehlerbild, vor und nach Bestätigung der Sicherheitsabfrage erscheint ein Stacktrace:

??? RBK0142E: @@@@@@@@@@@@@@@@@@@@ Stacktrace @@@@@@@@@@@@@@@@@@@@
RBK0000E: Undefined messageid
File "/usr/local/bin/raspiBackup.sh", line 4417, in main
doit # no return for backup
File "/usr/local/bin/raspiBackup.sh", line 3000, in doit
doitRestore
File "/usr/local/bin/raspiBackup.sh", line 4039, in doitRestore
restoreNonPartitionBasedBackup
File "/usr/local/bin/raspiBackup.sh", line 3457, in restoreNonPartitionBasedBackup
writeToConsole $MSG_LEVEL_MINIMAL $MSG_CURRENT_PARTITION $ROOT_DEVICE
File "/usr/local/bin/raspiBackup.sh", line 872, in writeToConsole
msg="$(getMessageText $LANGUAGE "$@")"
File "/usr/local/bin/raspiBackup.sh", line 724, in getMessageText
logStack
--- RBK0146I: Keine Partitionstabelle auf /dev/sdb gefunden
--- RBK0038I: Bist Du sicher? j/N
j
--- RBK0050I: Backup wird von /backup/myraspberries/smarthome/smarthome-rsync-backup-20170204-165210 zurückgespielt
??? RBK0001E: Zusicherungsfehler in Zeile 2621
??? RBK0142E: @@@@@@@@@@@@@@@@@@@@ Stacktrace @@@@@@@@@@@@@@@@@@@@
File "/usr/local/bin/raspiBackup.sh", line 4417, in main
doit # no return for backup
File "/usr/local/bin/raspiBackup.sh", line 3000, in doit
doitRestore
File "/usr/local/bin/raspiBackup.sh", line 4039, in doitRestore
restoreNonPartitionBasedBackup
File "/usr/local/bin/raspiBackup.sh", line 3485, in restoreNonPartitionBasedBackup
restore
File "/usr/local/bin/raspiBackup.sh", line 2621, in restore
(( ! $? )) && assertionFailed $LINENO
File "/usr/local/bin/raspiBackup.sh", line 921, in assertionFailed
logStack
??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=101
??? RBK0077E: Restore fehlerhaft bendet: Assertion error (RC 101)


Jemand eine Idee?
#826 framp 2017-02-02 20:32
Jupp, Die Parameter -a und -o habe ich vergessen. Siehe dazu https://www.linux-tips-and-tricks.de/de/faq#a18 Ansonsten sieht es mir aus als hast Du generell ein Problem mit der crontab. Kannst Du denn Code:/bin/df / benutzen?
#825 Marc 2017-02-02 20:05
Hallo framp

Habe das gerade versucht siehe unten
ohne crontab funktioniert das leider auch nicht das sagt er option -a -o missing und wenn ich die mit rein nehme klappt es auch nicht ??

00 19 * * 4 root /usr/local/bin/raspiBackup.sh -t tar -k 4 /media/backupusb

Feb 2 19:00:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Thu Feb 2 19:01:31 2017 [try http://www.rsyslog.com/e/2007 ]
Feb 2 19:00:01 raspberrypi CRON[3634]: (pi) CMD (root /usr/local/bin/raspiBackup.sh -t tar -k 4 /media/backupusb )
Feb 2 19:00:01 raspberrypi CRON[3630]: (CRON) info (No MTA installed, discarding output)
#824 framp 2017-02-02 19:20
Moin Marc,

das ist hier der richtige Platz um Fragen zu raspiBackup zu stellen. zitiere Marc:

ich selber habe mir alles was ich über linux weis selber beigebracht (immer noch blutiger Anfänger)

Ein jeder hat mal mit Linux angefangen ;-)
zitiere Marc:

40 15 * * 4 bin/bash --login /usr/local/bin/raspiBackup.sh -p /media/backupusb -t tar -k 1

Ich gehe davon aus dass der Backup ohne Crontab funktioniert ;-)
Ich habe oben ein Beispiel für die Crontab gebracht.
1) Warum benutzt Du bin/bash --login ? Das ist nicht nötig. Und jenachdem wie Du die crontab änderst muss noch ein root einfügen.
2) -k 1 ist ungeschickt denn dann wird immer nur ein Backup vorgehalten. Es sollte sicherlich schon für ein paar Wochen ein Backup gehalten werden. Also z.B. -k 4 für 4 Wochen.
3) Die Option -p ist veraltet und wird irgendwann verschwinden

Versuche es mal mit
Code:40 15 * * 4 /usr/local/bin/raspiBackup.sh -t tar -k 4 /media/backupusb
bzw
Code:
40 15 * * 4 root /usr/local/bin/raspiBackup.sh -t tar -k 4 /media/backupusb


Cu framp
#823 Marc 2017-02-02 16:49
Hallo liebe User

ich habe wiedereinmal mit dem Raspberry angefangen leider komme ich immer wieder an einen Punkt wo ich nicht weiter komme das system schotte und dann aufgebe um ein paar Monate später wieder anzufangen.

ich selber habe mir alles was ich über linux weis selber beigebracht (immer noch blutiger Anfänger)

also bin dem Blog von wenzlaff gefolgt und habe versucht ein automatisches update mit raspiBackup.sh jeden Donnerstag um 15:40 zu schalten
email server habe ich nicht installiert da das glaube ich meine Kenntnisse vorerst übersteigt (suche noch gutes tut)

Hier der fehlercode /var/log/syslog
Feb 2 15:40:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Thu Feb 2 15:41:31 2017 [try http://www.rsyslog.com/e/2007 ]
Feb 2 15:40:01 raspberrypi CRON[2705]: (pi) CMD (bin/bash --login /usr/local/bin/raspiBackup.sh -p /media/backupusb -t tar -k 1 )
Feb 2 15:40:01 raspberrypi CRON[2701]: (CRON) info (No MTA installed, discarding output)

der crontab:
40 15 * * 4 bin/bash --login /usr/local/bin/raspiBackup.sh -p /media/backupusb -t tar -k 1

zur info 8 GB SD Karte 16GB Stick ext4 formatiert

hoffe auf Hilfe frage das erste mal nach Hilfe wenn infos fehlen tut mir das leid werde sie dann sofort ergänzen
#822 framp 2017-02-01 19:29
Moin Elektrofreak,

Du hast eine interessante Backupstrategie. Aber raspiBackup unterstützt ja alle Backuptypen und ist deshalb auch gut dafür geeignet :-)

Warum jetzt die Netzwerkverbindung beim tar Backup abbricht kann ich mir nicht erklären. raspiBackup manipuliert definitiv nichts am Netzwerk. Du kannst mal den tar Backup mit der zusaetzlichen Option -v aufrufen. Dann wird im Detail protokolliert was tar so anstellt. Vielleicht findest Du dann eine Fehlermeldung die Dir weiterhilft die Ursache herauszufinden.

Cu framp
#821 Elektrofreak 2017-02-01 09:56
Hallo,

ich nutze das Script jetzt schon seit einigen Monaten. Dabei ist mir folgendes Problem aufgefallen:

- Backups per DDZ und RSYNC funktionieren ohne Probleme
- Backups per TAR lassen das Betriebssystem abstürzen. Es sieht aber so aus, dass der komplette Sicherungsvorgang erfolgreich war. Die Verbindung zum Netzwerk ist allerdings danach unterbrochen
- Ich sichere jeweils 1x im Monat per DDZ und TAR und jeden anderen Tag per RSYNC.
- Mails bekomme ich für DDZ und RSYNC, aber nicht für TAR (Netzwerk schon unterbrochen)

Leider kann ich mir nicht vorstellen, was die Ursache von dem Problem sein kann. Ist es möglich, dass der Lesevorgang vom TAR-Packer auf bestimmte Dateien das Betriebssystem oder den Netzwerkstack lahm legen?

Was kann ich machen, um das Problem herauszufinden?

Vielen Dank!
#820 framp 2017-01-24 20:56
zitiere Robert:
Das ist aber widersinnig, um ein Backup zu machen muss man vorher eine ganze Partition löschen.
Du musst nicht. Wenn die Partition ihren Sinn hat kannst Du sie ja bestehen lassen.
Zitat:
Damit ist das Backupscript für mich wertlos.
Wieso? Benutze den partitioneorientierten Modus
Zitat:
Der Partitionsorientierte Modus scheint aber nicht mit TAR zu gehen, das ist aber der einzige Modus der mich interessiert. Die Backups werden nur durch die ganzen unbenutzten Sektoren aufgebläht.
Das geht. Wenn nicht hast Du einen Bug im Script gefunden.
Zitat:
Fazit: Dem Script fehlt die Option "Mach was ich will und überlass das denken mir - du bist ein Raspberry und kein Apple"
Es sind seit der Urfassung des Scripts eine Menge weitere Optionen dazugekommen weil Benutzer diese haben wollten. Wie gesagt kannst Du im -P Mode viel gezielt festlegen.

Cu framp

Cu framp
#819 Robert 2017-01-24 20:48
zitiere framp:
Entweder löschst Du die dritte Partition auf der SD Karte oder Du nimmst einfach den partitionsorientierten Modus mit Option -P und sagst mit Option -T "1 2" dass Du nur die ersten beiden Partitionen sichern willst. ;-)


Das ist aber widersinnig, um ein Backup zu machen muss man vorher eine ganze Partition löschen. Damit ist das Backupscript für mich wertlos. Ich habe die Partition ja extra angelegt um dort Daten abzulegen die nie gesichert werden sollen. Auch beim restore kann er sie meinetwegen komplett ignorieren.

Der Partitionsorientierte Modus scheint aber nicht mit TAR zu gehen, das ist aber der einzige Modus der mich interessiert. Die Backups werden nur durch die ganzen unbenutzten Sektoren aufgebläht.

Fazit: Dem Script fehlt die Option "Mach was ich will und überlass das denken mir - du bist ein Raspberry und kein Apple"
#818 framp 2017-01-24 20:29
Moin Robert,

die gemountete Paritition erzeugt nicht die Fehlermeldung. Du hast auf Deiner SD Karte mehr als 2 Paritionen. Der normale Modus sichert genau 2 Partitionen. Entweder löschst Du die dritte Partition auf der SD Karte oder Du nimmst einfach den partitionsorientierten Modus mit Option -P und sagst mit Option -T "1 2" dass Du nur die ersten beiden Partitionen sichern willst. ;-)

Cu framp
#817 Robert 2017-01-24 19:59
Hi.

ich versuche bei meinem RasPi die ersten zwei Partitionen als tar-backup auf einen USB-Stick zu ziehen.

Die dritte Partition (ext4, gemountet unter /mnt/irgendwas) ist unwichtig und soll nicht im Backup landen.

sudo raspiBackup.sh -t tar -v -u "/mnt/*" /media/usb0/

Das Problem ist die Fehlermeldung
"Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ oder der Option -P gesichert werden können" - wies sage ich ihm dass ich das weiß und es mir egal ist?
#816 framp 2017-01-23 19:19
Moin Kermit,

das wird unterstützt. Das war eine der Neuerungen in der Version 0.6.1.3 ;-)
Siehe FAQ#16

Cu framp
#815 Kermit 2017-01-23 12:05
Hallo,

ich habe seit längerem das Script im Einsatz und nutze es (automatisiert) regelmäßig um Sicherungen meines RasPi vorzunehmen. Nun habe ich einen Restore machen müssen... Karte defekt. Dank DD Image keine große Sache. Image kopiert, neue Karte eingelegt und Tadaaa es fehle ein paar Sektoren... Die neue Karte ist minimal kleiner als die Alte. Um Datenverlust zu vermeiden habe ich eine größere Karte bestellt und darauf zurück gesichert. Das System Funktioniert soweit auch wieder. Nur werden die neuen Backups nun doppelt so groß. Meine Frage ist, wie ich es einrichten kann , dass die Images so groß wie meine Partitionen werden und ich aber auch den Komfort erhalte (einfaches zurückspielen eines Images über Win32). Ein Vorschlag war die Blockgröße und zu sichernden Anzahl zu begrenzen... kann ich dies unter den Optionen machen ?:

# blocksize used for dd
DEFAULT_DD_BLOCKSIZE=1MB
# addition parms used for dd
DEFAULT_DD_PARMS=""

Die Partitionsorientierte Sicherung ist mit DD leider mit dem Script nicht möglich.

Danke für eure Hilfe.
#814 framp 2017-01-10 18:59
Moin Balli,

habe Deinen Kommentar gesehen. Du bist auf der Beta2 Liste :-)

Cu framp
#813 BaLLi 2017-01-09 06:33
huhuu
Ich habe so eben mal wieder dein Backup-Tool auf meinem Raspi3 installiert und wollte es eben ausführen. Nur Problem an der Sache ist, dass ich meinen Raspi von USB-Stick booten lasse und das Script natürlich erkennt, dass ich keine SD-Karte installiert habe. Kann man da vielleicht etwas machen? :-)

Gruß
BaLLi
#812 framp 2016-12-27 21:07
Moin Christoph,

wie Du sicherlich schon festgestellt hast gibt es keine Option dafür :sad:

Du kannst aber entweder das Wrapperscript einsetzen um nach dem Backuplauf das Backup zu verschlüsseln oder auch eine Extension schreiben.

Beim Restore musst Du dann vorher das Backup wieder entschlüsseln.

Cu framp
#811 Christoph 2016-12-27 20:47
Hi

Gibt es auch die möglichkeit das tar/tgz mit einen Kennwort zu versehen ?

Super Arbeit übrigens

LG
#810 framp 2016-12-20 18:48
Es gibt verstärkt Nachfrage nach Support der Raspberry3 in raspiBackup. Besitzer einer Raspberry3 können helfen und sollten https://www.linux-tips-and-tricks.de/de/raspberry/485-raspibackup-raspberry3-unterstuetzung lesen.
#809 framp 2016-12-19 09:56
Moin Andreas,

ich verstehe nicht ganz Dein Problem :sigh:

raspiBackup verlangt die Optionen -a und -o. Sie sind sind auf https://www.linux-tips-and-tricks.de/de/raspibackup#parameter sowie auch bei den FAQs https://www.linux-tips-and-tricks.de/de/faq#a18 beschrieben.

D.h. Du gibst die beiden Optionen im Aufruf mit den jeweiligen Parametern mit und dann startet raspiBackup.

Ich hoffe ich habe Deine Frage soweit richtig verstanden. Ansonsten musst Du sie noch mal anders formulieren :-)

Cu framp
#808 Andreas 2016-12-19 01:30
HI,

mit der Version 6.1.3b erhalte ich diesen Fehler:

root@cbgpi2home:/media/link/bckup# raspiBackup.sh
--- RBK0009I: cbgpi2home: raspiBackup.sh V0.6.1.3b um Mo 19. Dez 01:26:22 CET 2016 gestartet
--- RBK0128I: Logdatei ist /var/log/raspiBackup/cbgpi2home.log
??? RBK0019E: Option -a und -o nicht angegeben
--- RBK0026I: Logdatei wird in /var/log/raspiBackup/cbgpi2home.log gesichert
--- RBK0043I: Unvollständiges Backup /media/link/bckup/cbgpi2home/cbgpi2home-dd-backup-20161219-012622 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
??? RBK0102E: Backup fehlerhaft beendet


Ich verstehe, dass das Skript die Restore-Services vor und nach dem Backup wissen will, aber da ich keine Angaben gemacht habe kann ich mir den Fehler nicht erklären.

Habe mir das Skript eben neu heruntergeladen und den Bckup-Pfad natürlich noch geändert....

Geht bei mir nicht.
#807 framp 2016-12-18 00:06
Es sind nur noch 7 Tage ... Deshalb wird es also Zeit ...

Allen Freunden von raspiBackup wünsche ich schöne Weihnachten und einen guten Rutsch ins neue Jahr. Ausserdem dass sie raspiBackup nicht einsetzen müssen um korrupte Daten zu recovern :-)

Wer Lust hat kann sich ja noch eine kleine Slideshow mit Photos von verschiedenen Weihnachtsmärken ansehen. Garantiert von mir photographiert und garantiert virenfrei :-) -> Klick mich

Cu framp
#806 framp 2016-12-08 21:04
Die Anfragen bzgl Erweiterungen sowie Fehler in raspiBackup bereiten mir langsam Probleme der Menge wegen. Ich möchte deshalb ab sofort jeden bitten Anfragen bzgl neuer Funktion oder auch Fehlerberichte auf dieser Seite auf github zu formulieren.

Wer Probleme mit github hat kann sie natürlich auch gerne hier in einem Kommentar formulieren oder mich per eMail (Siehe Kontakt Seite) kontaktieren.

Cu framp
#805 framp 2016-12-07 16:54
Moin Alex,

vielen Dank fuer Dein Log und den ausfuehrlichen Informationen ueber Deinen Setup. Die Ursache habe ich anhand der Logs gefunden: Du benutzt Ubuntu und dieses hat offensichtlich eine andere sfdisk Version und die Ausgabe sieht geringfuegig anders aus. Deshalb entdeckt raspiBackup keine Partitionen die zu sichern sind und da kein fehler auftritt wird auch gemeldet der Backup waere OK.

Ich werde den regulaeren Ausdruck der die Partitionsinformationen aus sfdisk rausliest entsprechend abaendern so dass auch das bei Dir vorliegende sfdisk Format akzeptiert wird und Partitionen erkannt werden. Ich schicke Dir dann die geaenderte Version zur Verifizierung per eMail zu.

Ausserdem werde ich eine Notbremse einbauen wenn keine Partitionen gefunden wurde. Es darf nicht sein dass raspiBackup die Erstellung eines Backups meldet und tatsaechlich nichts gesichert hat :o

Cu framp
#804 framp 2016-12-04 11:29
Moin Alex,

Das sieht sehr merkwürdigig aus :sigh: . Leider hilft mir Dein Logauszug nicht die Ursache zu lokalisieren. Schicke mir bitte Dein Log zwecks Analyse an meine eMailAdresse die Du auf der Kontaktseite findest.

Cu framp
#803 Alex 2016-12-04 00:27
Hallo zusammen,

nachdem ich meinen Raspi endlich vollständig eingerichtet habe, habe ich heute angefangen, mich mit dem Thema Datensicherung mit raspiBackup zu beschäftigen. Dabei stehe ich allerdings aktuell vor folgendem Problem:

Meine SD-Karte hat 4 Partitionen (bzw. 3, da boot wohl nicht gesichert wird), welche ich auf einen USB-Stick mit rsync sichern möchte. raswpiBackup wurde per config-file eingerichtet, störende Services ab- und wieder angestellt, die Sicherung erfolgt partitionsbasiert und alle Logs werden mit höchstem Detailgrad erstellt.

Wenn ich raspiBackup nun starte, läuft das Programm innerhalb von Sekunden (!) ohne Fehlermeldung durch und endet mit RBK0017I: Backup finished successfully.

Allerdings finde ich im entsprechenden Backup-Ordner (welcher korrekt erstellt wird) nur ein fdisk, mbr, parted, und sfdisk-file, allerdings keine Unterordner für die einzelnen Partitionen. Im Log-files kann ich auch keinen Fehler entdecken, einzig der folgende Abschnitt kommt mir etwas spanisch vor:

20161203-235113: DBG -- Found partitions on /dev/mmcblk0: 4
20161203-235113: DBG >> isPathMounted: /backup
20161203-235113: DBG -- Path: /backup
20161203-235113: DBG > supportsHardlinks: /backup
20161203-235113: DBG -- Links: 2
20161203-235113: DBG > checksForPartitionBasedBackup
20161203-235113: DBG >> collectPartitions
20161203-235113: DBG -- RootPartition: /dev/mmcblk0p2
20161203-235113: DBG -- PARTITIONS_TO_BACKUP: *
20161203-235113: DBG -- backupAllPartitions: 1
20161203-235113: DBG
#802 codiak 2016-11-26 20:52
Ach, die sind ein muss? OK, das probiere ich,

Danke!
#801 framp 2016-11-26 20:13
Moin codiac,

im Log finde ich dass Du die Meldung
20161126-195848: MSG ??? RBK0019E: Option -a und -o nicht angegeben
erhalten hast ;-) . Siehe dazu die Beschreibung der Optionen -a und -o sowie https://www.linux-tips-and-tricks.de/de/faq#a18

Cu framp
#800 codiak 2016-11-26 20:02
Moin framp,

das Log findest du hier: http://pastebin.com/XECGcFWA

Gruss,
codiak
#799 framp 2016-11-26 15:38
Moin codiak,

wenn Du zusaetzlich die Optionen

-l debug -m detailed -L current

benutzt bekommst Du detailiertere Meldungen sowie eine Logdatei im aktuellen Verzeichnis. Zeige dann mal die Ausgabe die Du dann erhaelst.

Cu framp
#798 codiak 2016-11-26 15:32
Hallo,

herzlichen Dank für das Script.
Ich habe es auf meinem BananaPi installiert aber leider klappt das Backup nicht Ich habe bereits alle Logfunktionen aufgedreht, bekomme aber ausser "ExitError 107" keine weitere Informationen.
Kann mir jemand weiterhelfen?

Gruss,
codiak
#797 babu 2016-11-25 16:18
zitiere framp:

Also probiere es bitte noch mal mit dem curl.


Läuft :) Danke!
+1 #796 framp 2016-11-24 20:10
Moin bau,

vielen Dank fuer den Hinweis. Da liegt eine Misskonfiguration auf meiner Webseite vor. Offensichtlich gibt es da Unterschiede im Verhanlten zwischen FF und Chrome. Mit dem FF funktioniert der download (Damit teste ich immer). Es sollte jetzt auch wieder mit dem curl funktionieren.
Beim Chrome muss ich noch genauer untersuchen was die Ursache ist.

Also probiere es bitte noch mal mit dem curl.

Sorry für die Unannehmlichkeiten :oops:

Cu framp
#795 babu 2016-11-24 17:46
Ich komm leider nicht an die raspiBackup.conf ran. Mit Chrome krieg ich bei allen Downloads ERR_TOO_MANY_REDIRECTS (www.linux-tips-and-tricks.de hat Sie zu oft weitergeleitet). Mit JD konnte ich dann zumindest die raspiBackupInstall.sh runterladen.

Wenn ich wie in 1 unter Installation beschrieben "curl -s -L -O https://www.linux-tips-and-tricks.de/raspiBackupInstall.sh && sudo bash raspiBackupInstall.sh" auf dem raspi aufrufe beendet sich der Aufruf 3 zu 1 ohne rückmeldung nach einigen sekunden. Wenn es klappt sieht das ganze so aus.
(Nach ca. 10 läufen kein erfolg)

--- RBI0001I: raspiBackupInstall.sh 0.3.2, 2016-11-08/20:59:34 - 408aaf2
--- RBI0002I: Sprache der Meldungen (de|en) : de
--- RBI0003I: Normaler oder partitionsorientierter Modus (n|p) : n
--- RBI0004I: Backuptyp (dd|tar|rsync) : dd
--- RBI0025I: Backup komprimieren (j|n) : n
--- RBI0006I: Anzahl der Backups (1-52) : 1
--- RBI0008I: Ausführliche Meldungen (j|n) : j
--- RBI0009I: Konfiguration OK (j|n) : j
--- RBI0014I: raspiBackup.sh wird aus dem Netz geladen
--- RBI0014I: raspiBackup.conf wird aus dem Netz geladen
??? RBI0015E: raspiBackup_de.conf kann nicht aus dem Netz geladen werden. HTTP code: 000
--- RBI0021I: Siehe Logdatei ./raspiBackupInstall.log für weitere Details

--- RBI0022I: Räume auf
??? RBI0016E: Installation von raspiBackup.sh fehlerhaft beendet
pi@raspberrypi:~ $
#794 framp 2016-11-20 10:13
Moin Frank,

freut mich dass es Dir geholfen hat :-)

Cu framp
#793 Frank 2016-11-20 10:06
Vielen Dank für dieses praktische Tool! Mir hat es vor allem dabei geholfen, eine Installation auf einer defekten SD-Karte zu retten. Mit dem tar-Backup war das kein Problem, und ich konnte das Backup einfach auf einer intakten Karte restaurieren :)
#792 framp 2016-11-15 19:45
Moin thanatos,

ich habe mir erlaubt Deinen LInk auf das Log zu löschen. Logs enthalten viele Informationen (ich habe gesehen dass Du schon Dinge maskiert hast) die man generell einfach nicht öffentlich zur Verfügung stellen sollte ;-)

Zu Deinen Problemen:

1) //192.168.78.101/uStor01/pibackup on /media/7362/pibackup type cifs (rw,relatime,vers=1.0,cache=strict,username=xxxxxx,domain=xxxxxx,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.78.101,unix,posixpaths,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1)
tmpfs on /run/user/106 type tmpfs (rw,nosuid,nodev,relatime,size=99648k,mode=700,uid=106,gid=109){/code]
Demnach hast Du Dein Backupspace per CIFS gemounted. Darüber kannst Du keine Hardlinks, die von rsync Backup benötigt werden, benutzen ! Die nächste Version von raspiBackup prüft dieses sehr genau und erlaubt die Benutzung von rsync nicht mehr wenn CIFS benutzt wird.

2) Aus dem Log sieht man dass der rsync läuft. Er dauert so lange weil Du Dein Backupspace auf /media gemounted hast und dieses NICHT excluded wird ! Du musst in Deinem Falle die Option -U "--exclude=/media/*" noch mit aufnehmen.

3) Wenn Du noch zusätzlich die Option -v benutzt siehst Du was rsync alles sichert ;-)

4) Ich werde noch eine weitere Fortschrittsmeldung in raspiBackup aufnehmen wenn der rsync beginnt. Ist irritierend wenn raspiBackup schreibt den mbr zu sichern obwohl der rsync schon läuft.

Cu framp
#791 thanatos 2016-11-15 17:14
Hi zusammen,
versuche verzweifelt ein rsync backup zu erstellen. Das script hängt allerdings reproduzierbar hier:
RBK0046I: Backup des Masterbootrecords wird in /media/7362/pibackup/raspi/raspi-rsync-backup-20161112-195318/raspi-backup.mbr erstellt

Das backup soll auf eine externe per cifs gemountete ext4 HDD. Sämtliche Dienste habe ich nach bestem wissen und Gewissen gestoppt (znc, nginx, seafile,...)
Backup-Aufruf: sudo raspiBackup.sh -l 1 -m 1 -o : -a :

Ein komplettes logfile liegt hier:
EDIT framp: Link gelöscht aus Sicherheitsgründen

Jeder Tip ist willkommen,

Cheers,
thanatos
#790 framp 2016-11-07 20:13
Moin aktivomat,

es gab schon verschiedene raspiBackup Benutzer die ueber dasselbe Problem gestolpert sind.Es hat mit den extended Attributes zu tun, die von rsync nicht unterstützt werden :sad: So wie ich es verstanden habe wird das primär von manchen Programmen aus Securitygründen benutzt. Soweit ich weiss haben die anderen Benutzer mit demselben Problem - da es eine kleine überschaubare Anzahl von Dateien waren - bei denen die extended Attribute entfernt und raspiBackup lief dann erfolgreich durch.

Cu framp

PS: Vielleicht schildert ja jemand von den o.g. Benutzern ob meine Aussage richtig ist bzw wie sie das Problem sonst gelöst haben.
#789 aktivomat 2016-11-07 10:48
Mahlzeit framp!

Ich mal wieder... bin am verzweifeln... habe jetzt aaaalles soweit eingerichtet (inkl. Zeitsteuerung sogar inkl. Mail Versand), mit -F getestet (ohne Probleme), aber bekomme beim "realen Durchlauf" folgende Fehlermeldung:

rsync: rsync_xal_set: lsetxattr(""/mnt/nfs/raspberrypi/raspberrypi-rsync-backup-20161107-101438/bin/ping"","security.capability") failed: Operation not supported (95)
rsync: rsync_xal_set: lsetxattr(""/mnt/nfs/raspberrypi/raspberrypi-rsync-backup-20161107-101438/bin/ping6"","security.capability") failed: Operation not supported (95)
rsync: rsync_xal_set: lsetxattr(""/mnt/nfs/raspberrypi/raspberrypi-rsync-backup-20161107-101438/usr/bin/systemd-detect-virt"","security.capability") failed: Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]

Das hat jetzt wohl irgendwas mit den Rechten zu tun, oder? Nur was?

Und wieder mal... DANKE!!
#788 aktivomat 2016-11-06 14:48
NFS ist am Start und läuft jetzt erstmal.

Au mann... Du hast natürlich recht! Hab lokal ja gar keinen NFS-Server am laufen. Sorry, für die doofe Frage ;-)

Als nächstes wage ich mich dann an den Zeitplan.
#787 framp 2016-11-06 14:14
Moin aktivomat,

die Testlogik auf Hardlinks ist nicht in der aktuellen Version drin :oops: . Sie kommt erst mit der nächsten Version. Dann erhälst Du eine Fehlermeldung wenn Hardlinks nicht funktionieren. :-) Nimm nfs und gut ist :-)

Bzgl nfs-server: Du brauchst keinen lokalen nfs-server auf der Raspi um per nfs auf einen remoten nfs-server zuzugreifen.

Cu framp
#786 aktivomat 2016-11-06 13:58
Morgääähn framp!

Ja, war für mich einfach nicht nachzuvollziehen, dass es 1,5 Stunden für schlappe 4GB (das waren es letztendlich) braucht. Aber gut. Dann ist das halt so. Damit kann ich schon leben, wenn das nachts läuft.

Aaaaaber, du hast natürlich recht! Da der zweite Durchgang ähnlich lange gedauert hat habe ich mal nachgeschaut und die beiden Backups hatten exakt die gleiche Größe. Also nix Hardlinks (obwohl es im Terminal bei der Ausführung so angezeigt wurde und keine Fehlermeldung kam).

Jetzt probiere ich es mal über NFS (erschien mir am Anfang zu kompliziert mit der Einbindung, aber habe es jetzt hinbekommen). Aber auch hier die Frage... Du schreibst in den FAQs der nfs-kernel-server service soll gestoppt werden... aber wie kann dann ein Backup über NFS erfolgen?

Und nochmals danke für die tolle Unterstützung hier!!
#785 framp 2016-11-05 23:39
Moin aktivomat,

man unterschätzt doch sehr lcieht wie lange es dauert Daten zu übertragen :-) Der zweite Backuplauf sollte auch nicht mehr so lange gedauert haben.

Etwas verwundert bin ich dass Du smb benutzt. Mein bisheriger Wissensstand war dass per smb keine Hardlinks unterstützt sind. Allerdings prüft raspiBackup genau ob es wirklich Hardlinks erstellen kann und das hat ja wohl funktioniert. Im FAQ Teil habe ich beschrieben wie man prüfen kann ob wirklich Hardlinks benutzt werden. Kannst Du das mal überprüfen?

Cu framp
#784 aktivomat 2016-11-05 23:09
... was soll ich noch sagen... es hat geklappt!!! Nach guten 1,5 Stunden war es durch! Juchee!!

Und jetzt, da ich zum Test noch einen zweiten Anlauf gestartet habe kommt auch die Zeile mit den Hardlinks. Ist ja auch logisch, dass das erst beim zweiten mal kommt:
--- RBK0133I: Verzeichnis /mnt/smb/raspberrypi/raspberrypi-rsync-backup-20161105-212346 wird für Hardlinks benutzt

PERFEKT!!! Danke!

Dann habe ich nur noch eine (wahrscheinlich sehr sehr doofe) Frage (wie gesagt, totaler Neuling). Du schreibst, dass unter anderem der SMB Service gestoppt werden sollte. Aber ich mache ja das Backup auf mein NAS über SMB. Wie sollte man denn hier vorgehen?
#783 framp 2016-11-05 22:51
Moin aktivomat,

leider sagt es mir nichts wenn Du was von einer Hardlinkzeile schreibst :sad:
Wenn das Problem auch morgen früh noch bestehen sollte rufe raspiBackup noch mal mit den Optionen -l 1 -m 1 auf und schick mir bitte das Log zu. Da steht alles drin was ich brauche um das Problem zu analysieren.

Cu framp
#782 aktivomat 2016-11-05 22:36
Nabend framp!

1.000 Dank für die schnelle Antwort! Na da bin ich ja erstmal beruhigt, dass es offenbar normal ist, dass es beim ersten rsync so lange dauert (habe aber nur ne 16GB SD und nur das Nötigste drauf).

Was mich nur so gewundert hat ist, dass beim ersten Versuch die "Hardlink-Zeile" bereits nach ca. 15 Minuten kam. Und jetzt nach über einer Stunde... nix. Aber gut, dann warte ich noch mal ein Stündchen und lasse mich überraschen.

Dann mal nen schönen Abend und nochmals danke!
#781 framp 2016-11-05 22:11
Moin aktivomat,

beim ersten Aufruf mit -t rsync werden Deine gesamten Daten der Raspberry gesichert. Das dauert schon seine Zeit - spezielle wenn es eine Menge Daten sind (32GB SD Karte?) ... Alle nachfolgenden Backups werden wg der Benutzung der Hardlinks dann aber schneller gehen. Übe einfach etwas Geduld und lass den ersten Backup einfach lang genug laufen :-)

Cu framp
#780 aktivomat 2016-11-05 21:52
Hallo Zusammen!

Also vorab: ich bin absoluter Neuling mit dem Raspberry und versuche mich gerade einzuarbeiten. Habe es aber mittlerweile geschafft meine Hausautomation mit pimatic zu steuern. Jetzt, nachdem ich alles schön eingerichtet habe, wollte ich mich mal ans Backup machen. Da bietet sich ja dieses Script an.

Nun habe ich folgendes Problem: ich möchte das Backup auf mein NAS (Qnap) machen. Habe es auch schon geschafft das NAS beim pi zu integrieren (sudo mount -t cifs -o user=[username],password=[password],rw,file_mode=0777,dir_mode=0777 //192.168.13.28/pibackup /mnt/smb/).

Nach langem Probieren habe ich das Script endlich zum Laufen gebracht. Es startet ganz brav und Schreibt aufs NAS, bleibt aber dann einfach bei folgender Zeile stehen: --- RBK0046I: Backup des Masterbootrecords wird in /mnt/smb/raspberrypi/raspberrypi-rsync-backup-20161105-212346/raspberrypi-backup.mbr erstellt

Hier noch mein Aufrufsyntax:
sudo raspiBackup.sh -a "sudo service pimatic start" -k 10 -o "sudo service pimatic stop" -t rsync /mnt/smb

Beim NAS Netzwerk-Monitor sehe ich, dass das pi nach wie vor Daten schreibt, aber mittlerweile läuft das seit über einer Stunde. Beim ersten Versuch hatte ich es leider nach ca. 30 Min. abgebrochen, weil ich dachte, dass da was nicht stimmt. Da kam es eine Zeile weiter. Da stand irgendwas von "Hardlinks". Aber soweit kam es nur beim ersten mal.

Jetzt weiß ich nicht mehr was ich noch machen kann, weil ja auch keinen Fehlermeldung kommt. Oder kann es etwa sein, dass es beim ersten mal so lange dauert?

Über Eure Hilfe wäre ich sehr dankbar!
#779 Deten 2016-11-03 21:22
Hallo framp,

Fehler gefunden. Wer lesen kann ist schwer im Vorteil. Wie beschrieben den Doppelpunkt für die Services eingetragen und nun geht das Backup wieder (":").

Sorry.

Danke für die Mühe und das tolle Programm.

Grüße Deten
#778 framp 2016-10-29 23:18
Moin rpbuser,

der Fix ist unterwegs zu Dir. Ausserdem ist vielleicht für Dich noch die Konfigurationsoption DEFAULT_LINK_BOOTPARTITIONFILES interessant mit der man noch weiteren Backupspace sparen kann ;-)

Cu framp
#777 rpbuser 2016-10-29 22:33
Hi,
natürlich funktioniert das Script auch so. Mir ist es nur aufgefallen, da ich wenig Platz auf dem Backup-Medium habe, und so um jedes MB mit excludes "kämpfe" :-)
Ich kann das gerne testen, wenn Du mir den Hotfix zusendest.


zitiere framp:
Moin rpbuser,

good catch. Das ist in der Tat ein Bug :oops: .

Bei meinen Tests zum paritionsorientierten Mode habe ich offensichtlich vergessen zu prüfen ob diese Verzeichnisse excluded werden. Das ist aber bislang auch sonst keinem Benutzer aufgefallen :roll: Allerdings funktioniert raspiBackup deshalb trotzdem - nur sind die Backups langsamer da zu viel gesichert wird.

Wäre nett wenn Du den Fix bei Dir testen würdest. Ich würde ihn Dir per eMail zuschicken.

Cu framp
#776 framp 2016-10-29 09:51
Moin rpbuser,

good catch. Das ist in der Tat ein Bug :oops: .

Bei meinen Tests zum paritionsorientierten Mode habe ich offensichtlich vergessen zu prüfen ob diese Verzeichnisse excluded werden. Das ist aber bislang auch sonst keinem Benutzer aufgefallen :roll: Allerdings funktioniert raspiBackup deshalb trotzdem - nur sind die Backups langsamer da zu viel gesichert wird.

Wäre nett wenn Du den Fix bei Dir testen würdest. Ich würde ihn Dir per eMail zuschicken.

Cu framp
#775 rpbuser 2016-10-28 23:43
Hallo,
erst mal danke für die viele Arbeit, die in raspibackup steckt!
Ich habe gerade versucht, im tar-Modus einzelne Partitionen zu sichern (also '-P -T "1 2"). Dabei ist mir aufgefallen, dass die excludes (z.B. "/proc") nicht funktionieren, da ja die Partition nach /tmp gemounted.
Bug oder feature?
Mit diesen Informationen kann man sich seine eigene exclude-Liste (/tmp/*/proc/*) bauen und das Backup damit funktioniert prima...


CU
#774 jeenser 2016-10-25 23:04
Mahlzeit framp,

hab den Parameter in der /usr/local/etc/raspiBackup.conf
geändert, und jetzt läuft das Backup. Danke.

best regards
#773 framp 2016-10-25 18:41
Moin jeenser,

die Meldung

??? RBK0013E: Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ oder der Option -P gesichert werden können

sagt eigentlich genau wo das Problem liegt ;-)
Siehe dazu auch https://www.linux-tips-and-tricks.de/de/faq#a3

Cu framp
#772 jeenser 2016-10-25 13:12
Hallo framp,

kannst du mit dem Fehler "Miscellaneous error (RC: 114)" etwas anfangen" ? Ist ist der ursächlich für das "unvollständige Backup".

root@raspberrypi:/media/usbstick/raspberrypi# /usr/local/bin/raspiBackup.sh -p /media/usbstick -t tar -k 4 -l 1 -m 1 -v
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.1.3b um Di 25. Okt 13:01:06 CEST 2016 gestartet
--- RBK0128I: Logdatei ist /media/usbstick/raspberrypi/raspberrypi-tar-backup-20161025-130105/raspberrypi-backup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
??? RBK0013E: Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ oder der Option -P gesichert werden können
--- RBK0026I: Logdatei wird in /home/pi/raspberrypi-raspiBackup.log gesichert
--- RBK0043I: Unvollständiges Backup /media/usbstick/raspberrypi/raspberrypi-tar-backup-20161025-130105 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
??? RBK0005E: Backup fehlerhaft beendet: Miscellaneous error (RC: 114)
root@raspberrypi:/media/usbstick/raspberrypi#

raspberrypi-raspiBackup.log
20161025-130106: DBG >> doitBackup 0
20161025-130106: DBG >> commonChecks
20161025-130106: DBG > exitError
20161025-130106: DBG > cleanup
20161025-130106: DBG >> cleanupBackup
20161025-130106: DBG -- Got trap EXIT
20161025-130106: DBG -- rc: 114
Invocation parms: ' -p /media/usbstick -t tar -k 4 -l 1 -m 1 -v'
20161025-130106: DBG -- emailTitle: raspberrypi: Backup nicht erfolgreich !!!
20161025-130106: DBG >> cleanupBackupDirectory
20161025-130106: MSG --- RBK0026I: Logdatei wird in /home/pi/raspberrypi-raspiBackup.log gesichert
20161025-130106: MSG --- RBK0043I: Unvollständiges Backup /media/usbstick/raspberrypi/raspberrypi-tar-backup-20161025-130105 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
20161025-130106: MSG ??? RBK0005E: Backup fehlerhaft beendet: Miscellaneous error (RC: 114)
20161025-130106: DBG > cleanupTempFiles
20161025-130106: DBG -- Removing mailfile /media/usbstick/raspberrypi/raspiBackup.maillog
20161025-130106: DBG
#771 framp 2016-10-23 13:37
Moin Karsten,

das sollte prinzipiell möglich sein. Du moechtest also dass man den Pfad für die temporären Dateien konfigurieren kann.
Ich sehe mir das mal die Woche an ob sich der Aufwand in Grenzen hält. Wenn ja schicke ich Dir dann eine Version mit der Änderung zu so dass Du testen kannst.

Cu framp
#770 Karsten Römke 2016-10-23 12:21
Hallo,
vielen Dank für das Skript, bisher habe ich die Karte immer per dd gesichert, aus dem laufenden Betrieb heraus, ist das Script natürlich sehr viel schöner und zudem "platzsparender ".
Eine Anregung, falls Zeit und Interesse besteht:
Ich benutze meinen Pi als Internetradio und habe die Partitionen read only gemounted (einige Verzeichnisse sind auf ramdisks gelegt).
Das Backupscript schreibt in einigen Zeilen jedoch temporäre Log-Dateien auf das Dateisystem. Es wäre schön, wenn der Ort konfigurierbar wäre, dann könnte man dies auf die Ram-Disk setzen (natürlich kann ich das für mich machen, vielleicht können es aber auch andere brauchen).
Grüße
Karsten
#769 framp 2016-10-22 18:41
Moin Warthmuth,

freut mich dass es (fast) anstandslos geklappt hat :lol:

Wenn es ein Problem war was auch andere Benutzer bekommen könnten solltest Du es hier schildern. Vielleicht kann ich irgendwas verbessern (Code oder Doku) oder zukünftige Benutzer können auf Deine Fehler- und Lösungsbeschreibung zurückgreifen ;-)

Cu framp
#768 Whartmuth 2016-10-22 18:27
Hallo Framp,
tolle Seite. Ich musste raspBackup sofort auf meinem Raspi installieren. Hat fast (war mein Problem) auf Anhieb einen sauberen Backup auf einen USB-Stick gemacht.

Gruß
Wolfgang
#767 framp 2016-10-02 11:51
Moin heikoh81,

raspiBackup unterstützt keinen rsync server, also rsync über ssh. Es gab schon den Request das zu implementieren und ich habe mir das angesehen. Aber der Aufwand das im existierenden Code einzubauen ist einfach zu hoch. raspiBackup kann mit allen Backuspaces arbeiten wenn sie ganz normal gemountet sind, d.h. nfs (ist die performanteste Lösung), smb, sshfs usw.
Warum es Berechtigungsprobleme mit den Daten gibt, die per rsync über ssh kopiert worden sind weiss ich nicht. Eigentlich sollte das meinem Verständnis nach funktionieren. Vielleicht probierst Du es noch mal mit den zusaetzlichen Optionen -A und -X.
Der andere Weg ist wohl wie Du schon vorschlägst die Daten per nfs zu kopieren.

Cu framp
#766 heikoh81 2016-10-02 11:02
@framp:
Danke für die Antwort.
Hardlinks sollen funktionieren.

Der Grund meiner Frage:
Per raspiBackup-Skript habe ich ein Backup auf ein qnap-NFS erstellt (Wiederherstellung und booten klappt).

Dieses qnap sichere ich per Rsync gelegentlich noch auf ein MyBookLive. Um die Hardlinks zu erhalten, habe ich folgenden Befehl ergoogelt:
rsync -a -H --delete --progress --numeric-ids /share/raspibackup/ root@mybookliveip:/shares/Backups/raspibackup

Anschließend habe ich ein Restore von diesem MyBookLive versucht (vorher den Share per NFS auf dem Raspi gemounted).
Die Wiederherstellung scheiterte, das RaspiBackup-Skript hat mehrere hundert rsync-Fehlermeldungen ausgegeben "permission denied", z.B. auf das mysql-Verzeichnis.

Also nochmals mittels rsync vom MyBookLive zurück auf das qnap kopiert, ohne irgendwas an den Rechten oder so auf dem MyBookLive zu ändern:
rsync -a -H --delete --progress --numeric-ids root@mybookliveip:/shares/Backups/raspibackup/ /share/raspibackup/TEST

Dann diesen TEST-Folder (der wieder auf dem qnap gespeichert ist) per NFS auf dem Raspi gemounted, restore, hat funktioniert, booten von der SD ebenso.

Also ziemlich viele Schritte, aber ich mache eigentlich immer noch ein Backup vom Backup, und die Wiederherstellung sollte dann natürlich auch funktionieren...

Vermutlich liegt es daran, dass mein rsync-Backup vom qnap auf das MyBookLive eben per SSH lief.
Wahrscheinlich besser, ich mounte den MyBookLive-Pfad auf dem Qnap per NFS und lasse dann das rsync laufen?

Viele Grüße,
Heiko
#765 framp 2016-10-01 18:14
Moin heikoh81,

wenn ich Dich richtig verstehe möchtest Du per ssh bzw scp das Backup auf den Backupspace bringen. Solltest Du einen rsync Server haben - der wird nicht von raspiBackup unterstützt. Geht es wirklich nicht den per nfs anzubinden? Das ist die performanteste Art. Andere Alternativen sind

cifs/samba Netzwerklaufwerk
sshfs Netzwerklaufwerk
webdav Netzwerklaufwerk
ftpfs Netzwerklaufwerk

In Deinem Falle kannst Du per sshfs oder ftpfs den remoten Backupspace an der Raspi z.B. unter /backup mounten. Allerdings unterstützt sshfs und ftpfs keine Hardlinks, d.h. ein rsync Backup ist nicht möglich. Es geht dann nur tar oder dd.

Cu framp
#764 heikoh81 2016-10-01 17:35
Wie muss ich als Backup-Ziel ein über ssh angebundenes System angeben?

raspiBackup.sh -a "service apache2 start" -o "service apache2 stop" -u "--exclude=/backup/*" -p "root@192.168.178.200:/backup"
#763 framp 2016-09-18 18:55
Moin Jürgen,

schon komisch dass es jetzt plötzlich Probleme gibt :o

Beim ersten Restore hast Du aber offensichtlich CTRL-C gedrueckt und damit den Restore bewusst abgebrochen ;-)

Beim zweiten Restore ist ein Fehler beim rsync aufgetreten. Eigentlich solltest Du die genaue Fehlermeldung auch auf der Konsole sehen. Das habe ich extra in 0.6.1.3 eingebaut. Ansonsten sieht man den exakten rsync Fehler aber im Log welches per -l 1 -m 1 erstellt wird. Hast Du da mal reingesehen? Ansonsten schicke mir mal das restore Log zu (eMail auf der Kontaktseite).

Cu framp
#762 Jürgen 2016-09-18 18:27
Hallo framp

nach länger Zeit melde ich mich wieder mit einer Bitte um Hilfe.

Nachdem ich die Sicherung auf rsync auf einen USB-Sick umgestellt habe, laufen diese mit durchschnittlich 1 Std. für mich zufriedenstellend. (Soll einmal im Monat)

Jetzt bin ich den Restore am testen, laufe aber dabei auf Fehler
Zitat:
sudo raspiBackup.sh -d /dev/sdb /media/usb0/raspberrypi/raspberrypi-rsync-backup-20160915-010001
Mit der ersten Karte hatte ich
Zitat:
--- RBK0055I: Zweite Partition (Rootpartition) /dev/sdb2 wird zurückgespielt ^C??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=103 ??? RBK0077E: Restore fehlerhaft bendet: CtrlC detected (RC 103)
Dann habe ich eine andere Karte genommen und formatiert
Zitat:
??? RBK0035E: Backupprogramm rsync endete beim Restore mit Fehler RC 23 ??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=113 ??? RBK0077E: Restore fehlerhaft bendet: Native restore tool error (RC 113)
Beide Karten funktionierten vorher.
Die Parameter Zitat:
-l 1 -m
brachten in der Logdatei eigentlich nur die config.

Ich hoffe auf deinen fachmännischen Rat.

Gruß
Jürgen
#761 framp 2016-09-18 14:38
Merkwürdig dass man das Attribute nicht löschen kann. Beim Hin und Herkopieren ist offensichtlich irgendwie das Attribute verlorengegangen. Aber das wolltest Du ja erreichen :-)
#760 Mario 2016-09-18 14:09
Icke nochmal: Habe die Datei jetzt mal auf ein anderes Dateisystem verschoben (NFS) und dann wieder zurückkopiert, damit verschwindet dass attr augenscheinlich auch.

Die Tiefen der Linux-Dateisystem ...
#759 Mario 2016-09-18 13:55
Danke für den HInweis mit den attr, ich habe hier neuerdings auch diesen Fall, augenscheinlich nur bei systemd-detect-virt.

Dumm, nur, dass ich es nicht gelöscht bekomme. Hast Du noch eine Idee?
Zitat:
pi@fhem ~ $ sudo attr -r capability /usr/bin/systemd-detect-virt
attr_remove: Keine Daten verfügbar
Konnte "capability" von /usr/bin/systemd-detect-virt nicht entfernen
#758 framp 2016-09-17 16:44
Es hat sich herausgestellt, dass die Fehlermeldung die Michael berichtet hat vom rsync erzeugt wird. Es ist kein Fehler von raspiBacktp. nfs unterstützt einfach keine extended Attribute :-(.
Das ist jetzt das zweite Mal dass jemand extended Attributes bei seinem Linux gefunden hat und dieses hier berichtete.

Was kann man machen wenn man ein rsync Backup auf einem nfs Space erstellt und einen Fehler wie

rsync: set_acl: sys_acl_set_file(mmcblk0p7/media/pi, ACL_TYPE_ACCESS):
Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1183) [sender=3.1.1]

bekommt?

Die extended Attribute suchen mit
sudo find / -type f -exec attr -l {} \;
und dann muss man sich entscheiden ob sie wichtig sind oder nicht. Bislang waren sie immer unwichtig. Dann löscht man sie mit dem attr Befehl.
Ansonsten bleibt nur das tar Backup zu benutzen und zusaetzlich die Option
DEFAULT_TAR_BACKUP_ADDITIONAL_OPTIONS="--xattr" in der Konfigurationsdatei setzen oder aber auch ein dd Backup zu benutzen.
#757 framp 2016-09-14 21:05
Moin Michael,

Du kannst doch leicht mit -V auf die vorherige Version zurückgehen. Dann kannst Du mir ja morgen per eMail (Siehe Kontakt Seite) mitteilen ob der Fehler immer noch auftritt. Dazu schicke mir bitte das Log mit den Fehlermeldungen welches durch die zusätzlichen Optionen -l 1 -m 1 erstellt wird. Dann können wir offline das Problem weiter eingrenzen.

Cu framp
#756 Michael 2016-09-14 20:28
Hi

Ich lasse mir beim täglichen Update immer eine Email schicken und die Meldung hatte ich bis gestern nie. Habe am System sonst nichts geändert. Ich könnte natürlich nochmals auf die vorherige Version zurück um sicher zu sein.

Michael
#755 framp 2016-09-14 19:59
Moin Michael,

bist Du Dir sicher dass es mit der neuen Version zusammenhängt? Es gab schon einen ähnlichen Fehler (Siehe https://www.linux-tips-and-tricks.de/de/raspibackup#comment-1213) und da lag es am OS Update und extended Attributen.

Cu framp
#754 Michael 2016-09-14 11:35
Hallo zusammen

Habe heute auf die aktuelle Version gewechselt und bekomme jetzt folgende Fehlermeldung:

rsync: set_acl: sys_acl_set_file(mmcblk0p7/media/pi, ACL_TYPE_ACCESS): Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]

Jemand eine Idee? Ich verwende das Script "raspiBackupWrapper.sh" (mount QNAP, backup, unmount QNAP).
#753 Mario 2016-09-13 11:34
Okay, ich brauche sowohl -a als auch -o, jetzt geht's.

Nix für ungut und danke!
#752 Mario 2016-09-13 10:20
Moin!

Nach dem Update renne ich in ein Problem mit den mandatory -a/-o Optionen.

Hier mal von der Kommandozeile:
Zitat:
root@rpi01:~# raspiBackup.sh -a ":"
--- RBK0009I: rpi01: raspiBackup.sh V0.6.1.3 um Di 13. Sep 10:19:13 CEST 2016 gestartet
--- RBK0128I: Logdatei ist /var/log/raspiBackup/rpi01.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
??? RBK0019E: Option -a und/oder -o nicht angegeben
--- RBK0026I: Logdatei wird in /var/log/raspiBackup/rpi01.log gesichert
--- RBK0043I: Unvollständiges Backup /media/nfs/backups//rpi01/rpi01-rsync-backup-20160913-101912 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
??? RBK0102E: Backup fehlerhaft beendet
Die Option ist doch gesetzt (auch mit dem Doppelpunkt, wie von Dir vorgeschlagen), warum kommt dann also doch noch der Abbruch?

BG
Mario
#751 framp 2016-09-05 19:43
Moin Stefan,

freut mich dass es jetzt klappt.

Die Meldung kannst Du ignorieren. Aber Du solltest sie eigentlich nicht bekommen :sad: . Sie sollte nur im Debuglog auftauchen. Unterdrücken kannst Du das indem Du am Ender der Zeile in der Crontab
&>/dev/null # Meldung unterdrücken
oder
&>/var/log/raspiBackup.cron.log # Meldung in Log
schreibst.

Wenn Du dann einmal einen Backuplauf mit den Parametern -l 1 -m 1 durchlaufen lassen und mir das Log zuschicken würdest kann ich vielleicht rausfinden wieso diese Meldung geschrieben wird. Meine eMail findest Du auf der Kontaktseite.

Cu framp
#750 framp 2016-09-05 19:27
Moin Kurt,

das ist natürlich ärgerlich. Speziell da keine eMail geschickt wird. Das ist aber jetzt in der Version 0.6.1.3 gefixed :-*

Zu der Meldung 27E: Bist Du Dir sicher dass an /media/Backupbig etwas gemountet ist? Wenn ja schicke bitte das Log (-l 1 -m 1) an meine eMail (Siehe Kontakt Seite).

Cu framp
#749 Stefan 2016-09-05 17:36
Hi framp,

nach dem Backup habe ich auch den Restore getestet. Funktioniert alles. Vielen Dank!!

Eine Frage habe ich noch: Ich starte das Tool über die Crontab jeden Sonntag. Danach bekomme ich vom cronjob eine email mit folgendem Inhalt:

sfdisk: Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.

Ich sichere eine NOOBS SD-Karte mit mehreren Partitionen. In der crontab habe ich schon eingestellt, dass ich nur emails bekomme, wenn ein Fehler auftritt. Aber die Meldung oben wird wohl als Fehler interpretiert. ;-)

Hast du einen Tipp, ob ich das irgendwie korrigieren kann? (ohne die cronjob-emails komplett zu deaktivieren...)
#748 Kurt 2016-09-04 22:28
Hallo framp,

ich hatte vor Wochen mein wöchentliches backup (cron job) auf rsync umgestellt (siehe meinen letzten thread). Ich habe heute das backup Verzeichnis angeschaut und verwundert festgestellt, dass es leer ist, vorher waren dort drei rsync backups vom 14., 21. und 28.8. (5.5GB, 4xxMB, 6yy MB).

Ich habe darauf hin ein backup manuell angestoßen was aber nicht erfolgreich war mit einem Fehler:
20160904-210341: MSG ??? RBK0027E: Kein externes Gerät an /media/Backupbig verbunden. Die SD Karte würde für das Backup benutzt werden.
Das Laufwerk /media/Backupbig ist gemounted, das Verzeichnis raspberry ist aber leer.

Hast Du eine Idee was da nicht passt? Bei Bedarf kann ich das log file Dir senden.

Kurt

P.S: Habe vor dem manuellen backup heute auf 0.6.1.3 aktualisiert.
#747 framp 2016-09-04 18:05
Moin Jürgen,

für mich gibt es nur einen Grund warum man ein dd Backup wählen sollte: Es kann als einziges Backup mit wind32diskimager unter Windows restored werden und man möchte nicht LInux für den Restore benutzen.
Ansonsten würde ich immer tar oder rsync wählen. Und so schwer ist es auch nicht das Backup auf der raspi zu restoren. Man muss es eben nur mal etwas üben :-)

Cu framp
#746 Jürgen 2016-09-04 17:46
Hallo Framp

danke für deine Geduld :-)

Zitat:
Natürlich wird das Verzeichnis auf welches gesichert wird nicht mitgesichert. Der Mountpunkt wird aber mitgesichert.
ist genau das was ich wissen wollte.

Das mit der Partitionierung übersteigt dann doch mein Linux-Verständnis.
Zitat:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 14.9G 0 disk ├─mmcblk0p1 179:1 0 56M 0 part /boot └─mmcblk0p2 179:2 0 14.8G 0 part /
Wahrscheinlich werde ich dann doch mittels einer der anderen Methoden auf einen USB-Stick direkt an der PI sichern

Danke
Jürgen
#745 framp 2016-09-04 14:54
Moin Jürgen,

vielen Dank für Deine nützlichen Hinweise !

1) Den Namen habe ich irgendwann geändert, denn er war mir zu ungenau. Die Änderung habe ich in der Doc nicht nachgezogen :oops: . Ist jetzt aber korrigiert.

2) Auch habe ich nicht nur diesen sondern noch andere fehlende Konfig Definitionen in den Konfig Datei nachgezogen.

Der DD Parameter wirkt nur wenn die root Partition verkleinert wurde. Der Meldung nach hast Du das nicht getan. Mit lsblk kannst Du Dir die aktuellen Partitionsgrössen ansehen. Ich empfehle zum Repartitionieren gparted zu benutzen. Wenn Du kein Linux hast musst Du aber erst ein raspbian von einer anderen SD Karte booten und dann damit die andere SD Karte repartitionieren. Unter Windows kannst Du nicht repartitionieren, da Windows kein ext3/4 Dateisystem kennt.

Zu Deiner Frage zur NAS. Die verstehe ich leider nicht so ganz. Natürlich wird das Verzeichnis auf welches gesichert wird nicht mitgesichert. Der Mountpunkt wird aber mitgesichert. Sollte das nicht Deine Frage gewesen sein musst Du sie noch einmal etwas genauer formulieren :-)

Cu framp
#744 Jürgen 2016-09-04 11:16
Hallo framp

ich habe jetzt den neuen DD-Parameter getestet. Kann es sein, dass die Doku oben nicht aktuell ist und er Zitat:
$ DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY="1"
heißen müßte. Es wäre auch gut, wenn er in der Muster-Config (Link oben) stehen würde.

Zum Ergebnis.Zitat:
RBK0003I: Backupgröße wird von 14.83 GiB auf 14.83 GiB reduziert
. Da hat sich scheinbar nichts getan, oder ?

Dann habe ich noch eine Frage: ich sichere ja über einen Mountpunkt auf die FritzNas. Wie wird eigentlich das auf dem Raspberry liegende Verzeichnis mit den Daten auf dem externen Laufwerk behandelt ?

Danke und Gruß
Jürgen
#743 framp 2016-09-02 22:32
Moin Rene,

wenn Du sicher bist nichts zu starten und zu stoppen zu muessen - was ich schon etwas merkwuerdig finde - dann benutze den Doppelpunkt als Argument fuer -a und -o - also -a ":" -o ":".

Cu framp

PS: Hintergrund ist dass es schon vorgekommen ist das Benutzer die Parameter aus Unkenntnis nicht benutzt haben und sich wunderten dass der Restore inkonsistent war :-)
#742 René 2016-09-02 21:22
Hi framp,

nach dem Update auf die neue Version bekomme ich:
??? RBK0019E: Option -a und/oder -o nicht angegeben
In den Release Note habe ich gelesen, dass diese Params nun mandatory sind, ich habe aber keine Services zu stoppen oder zu starten.
Was mache ich falsch?

Danke & Grüße

René
#741 framp 2016-08-29 09:02
Moin Mathias,

Dein Anwendungsszenario verstehe ich und ich hatte es auch als ich noch XBMC im Einsatz hatte. Ich verstehe aber nicht warum Du der Meinung bist, dass raspiBackup dafuer ungeeignet ist :sigh:
Lies Dir bitte mal die FAQ #3 und #4 durch sowie die Beschreibung der Optionen -t und -z ;-)

Cu framp
#740 Mathias 2016-08-29 06:43
da ich Kodi über eine externe Festplatte laufen lasse, ist diese Backup-Variante für mich (und einige andere auch) sinnlos.
Gefragt sind Backup-Methoden, die auch komprimieren, bzw ein Backup der Daten machen. Beispiel: Backup per DD macht bei mir 500GB. Backup der selben Platte per Clonezilla macht 4GB.
#739 framp 2016-08-25 19:55
Moin Jürgen,

aus Deinem Beitrag entnehme ich, dass bei Dir nun auch der Restore funktioniert :-)

3 Stunden ist recht lange. Mit den nächsten Version sollte Dein dd Backup dann schneller gehen wenn Du die root Partition entsprechend verkleinerst :-*

Cu framp
#738 Jürgen 2016-08-25 19:03
Hallo framp

tausend Dank für das klasse Tool und deine hervorragende Unterstützung. :-) :-) :-)

Den Cronjob habe ich jetzt für den ersten im Monat um 01 Uhr eingestellt. Da kann ich die Laufzeit von 3 Stunden verschmerzen.

Die Anwendungsdaten sichere ich zusätzlich täglich.

Jürgen
#737 framp 2016-08-24 20:29
Moin Jürgen,

Du bist jetzt schon der Zweite der das Problem mit mpack berichtet. Eigentlich wird das in raspiBackup geprüft. Ich muss mir den Code da noch mal genauer ansehen und das fixen.

Es gibt zwei Workarounds:
1) sudo apt install mpack
2) DEFAULT_APPEND_LOG=0 in der Konfig setzen

Willst Du wirklich das Log per eMail zugeschickt haben? Die Funktion stammt eigentlich noch aus der Anfangszeit als ich raspiBackup entwickelt habe. Eigentlich braucht man das nicht mehr. Somit wäre (2) meine Empfehlung.

Ansonsten sieht das mit dem Starten gut aus wie ich soweit beurteilen kann. Die Stopbefehle hast Du sicherlich auch - nur eben umgekehrt - definiert.

Damit sollte dann der Restore auch brauchbare Ergebnisse liefern ;-)

Cu framp
#736 Jürgen 2016-08-24 10:18
Hallo framp

was hätte ich eine erfolgsmeldung gegeben, jedoch kommt nach 2 Std nach dem Starten der Services die Meldung:
Zitat:
/usr/local/bin/raspiBackup.sh: line 1555: mpack: command not found
Kannst du da was mitanfangen ?

Meine Start-Services sehen so aus (Samba gegen SMBD ausgetauscht wegeb Fehlermeldung)
Zitat:
DEFAULT_STARTSERVICES="/etc/init.d/fhem start; sudo /home/pi/svrpi/svfb.sh start; service smbd start"
Es wird alles korrekt gestoppte und gestartet !

Danke
Jürgen
#735 framp 2016-08-23 20:56
Moin Wolfgang,

eigentlich prüft raspiBackup ob mpack installiert ist. Allerdings ist da ein kleiner Bug im Script. Ich habe das eben in der nächsten Version gefixed.
Zitat:
ssmtp: 550 invalid DNS MX or A/AAAA resource record
Das klingt merkwürdig. Bist Du sicher dass Dein ssmtp richtig konfiguriert ist?
Rufe doch mal bitte das Script mit -l 1 -m 1 auf und siehe im Log nach. Dort steht eine Zeile

Sendig email with ssmtp

und die folgende Zeile gibt genau den Befehl aus, den raspiBackup benutzt um die eMail zu schicken. Kannst Du diesen Befehl in der Befehlszeile ausführen?

Cu framp
#734 Wolfgang 2016-08-23 20:13
Hi,
hier noch eine Ergänzung.
Ich habe in Zeile 1555 gesehen, das es einen Zusammenhang zum AppenLog gibt.
Bei meinem ersten Versuch stand AppenLog auf 1.
Setzte ich es auf 0 kommt folgende Meldung:
ssmtp: 550 invalid DNS MX or A/AAAA resource record

LG

Wolfgang
#733 Wolfgang 2016-08-23 20:03
Hallo framp,

ich wollte die Mails mit ssmtp verschicken. Habe es installiert und kann von der Konsole damit Mais verschicken. Wenn ich in der raspBackup.conf als Mail-CLient ssmtp eintrage, bekomme ich bei raspiBackup.sh -F folgenden Fehler

/usr/local/bin/raspiBackup.sh: Zeile 1555: mpack: Kommando nicht gefunden.

Schreibe ich zum Test statt ssmtp in der conf SSMTP, wird gemeldet, dass SSMTP nicht unterstützt wird.

Wie kann ich ssmtp nutzen?

Gruß

Wolfgang
#732 Stefan 2016-08-22 21:23
Was es alles für Befehle gibt... :oops:

Hier die Outputs der beiden Varianten:

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

Wenn also "du -sh *" den realen Speicherbedarf anzeigt, dann passt ja alles. Da belegen die Folgebackups ja nur noch einige MB.
#731 framp 2016-08-22 20:50
Moin Stefan,

das ist ja das schöne dass Du denkst Du hast die Daten n Mal - aber in Wirklichkeit nur 1 Mal :-)

In der nächsten Version von raspiBackup wird geprüft ob Du Hardlinks anlegen kannst. In der aktuellen Version werden immer Kopien erstellt wenn keine Hardlinks unterstützt werden :cry:

Benutze mal
du -sh *

und

du -shl*

in deinem Backupverzeichnis und vergleiche die Ergebnisse (Siehe auch dazu http://stackoverflow.com/questions/19951883/du-counting-hardlinks-towards-filesize)

Und ja ... Teste den Restore vor dem Ernstfall. Gab schon Spezl die erst dann merkten dass sie nicht wissen wie das geht :o

Cu framp
#730 Stefan 2016-08-22 20:30
Ähm...ja...nachgemessen habe ich nicht wirklich per Befehl. Sondern mir einfach die Ordnergröße anzeigen lassen. Kann auch durchaus sein, dass die Ordner nicht 100%ig gleich groß sind, aber eben alle so ca. 4.6GB.

Ich habe (vermutlich irrtümlich) gedacht, dass ein Hardlink nur einen Bruchteil des Speicherplatzes der Originaldatei belegt (eben ein Link). Aber es scheint ja so zu sein, dass der Hardlink die gleiche Größe hat. Korrekt?

Wenn ich einen "find" absetze, kommt auch ein ähnliches Ergebnis. Scheint also doch zu funktionieren bei mir. ;-)

Dann werde ich jetzt noch den Restore testen.

Dank dir,
Stefan
#729 framp 2016-08-22 20:17
Moin Stefan,

wie hast Du nachgemessen (genaue Befehl) das die Kopie wieder genauso gross ist?

Du kannst uebrigens auch recht einfach pruefen ob Hardlinks benutzt wurden.

Anbei habe ich mal in einem Backupverzeichnis meiner raspberrypi einen find abgesetzt. Da siehst Du dass immer eine 3 vor root/root steht. Da ich drei Backups habe ist die Datei auch 3 Mal mit Hardlinks verlinked (pro Backup wird ein softlink noch gelistet). So sollte es bei Dir auch aussehen, denn wenn Deine Synology ext3/4 per nfs exportiert werden auch Hardlinks benutzt.

framp@raspifix /disks/silver/backup/rsync/raspberrypi $ find . -iname which -exec ls -la {} \; 2>/dev/null
lrwxrwxrwx 3 root root 10 Jul 8 2012 ./raspberrypi-rsync-backup-20160821-033001/usr/bin/which -> /bin/which
-rwxr-xr-x 3 root root 946 Jul 8 2012 ./raspberrypi-rsync-backup-20160821-033001/bin/which
lrwxrwxrwx 3 root root 10 Jul 8 2012 ./raspberrypi-rsync-backup-20160814-033001/usr/bin/which -> /bin/which
-rwxr-xr-x 3 root root 946 Jul 8 2012 ./raspberrypi-rsync-backup-20160814-033001/bin/which
lrwxrwxrwx 3 root root 10 Jul 8 2012 ./raspberrypi-rsync-backup-20160807-033001/usr/bin/which -> /bin/which
-rwxr-xr-x 3 root root 946 Jul 8 2012 ./raspberrypi-rsync-backup-20160807-033001/bin/which

Cu framp
#728 Stefan 2016-08-22 19:13
Hallo framp,

erst einmal vielen Dank für dein Script. Ich möchte damit meinen RPi3 auf eine Synology sichern. Eingebunden ist sie über ein NFS share. Das funktioniert auch. Mount über das Wrapper-Script.

Das Backup ist als rsync-Backup konfiguriert. Das Initial-Backup dauerte eine Weile und hat 4,6GB gesichert. Ich habe direkt danach einen weiteren Backuplauf gestartet, um zu sehen, ob beim zweiten Mal dann nur noch (wie ja gewünscht) die geänderten Daten gesichert werden. Jedoch umfasst die zweite Sicherung wieder 4,6GB. Lief aber schneller durch (5 statt 15 Minuten).

Soll das so sein?

Hardlinks stehen auf "1" in der Config. Und der Synlogy-Share ist wie im Tutorial hier als nfs3-share eingebunden.

Du schreibst ja, dass rsync nur mit ext3/ext4 funktioniert. Ist das vielleicht das Problem, weil hier ja nfs genutzt wird?

Gruß,
Stefan
#727 framp 2016-08-21 21:15
Moin Jürgen,

bitte denke daran, dass Du vor dem Sichern Deine laufenden Dienste wie FHEM und vermutlich auch solarview und andere stoppen musst, denn sonst sicherst Du keinen konsistenten Datenstand. Dazu hast Du bei raspiBackp die Parameter -a und -o. Es gibt Benutzer die sichern und restoren ihre FHEM erfolgreich. Leider kenne ich mich mit FHEM nicht aus und kann deshalb auch nicht weiterhelfen.
Vielleicht kann jemand von den Mitlesern, die FHEM im Einsatz haben, die Argumente für -a und -o hier posten. Ansonsten würde ich an Deiner Stelle mal im FHEM Forum nachfragen -> https://forum.fhem.de

Alternativ kannst Du die Parameter auch in der Konfig eintragen. Bei mir sehen sie z.B. so aus (kein FHEM System)

DEFAULT_STARTSERVICES="service nfs-kernel-server start; service samba start; service pilight start; service cups start; service minidlna start; startPiScheduler.sh"

DEFAULT_STOPSERVICES="stopPiScheduler.sh; service minidlna stop; service cups stop; service pilight stop; service samba stop; service nfs-kernel-server stop"

Ich hoffe die Info hilft Dir weiter.

Cu framp
#726 Jürgen 2016-08-21 19:42
Hallo Framp

danke der Nachfrage. Ja, das Sichern inkl. Mail läuft prima. :-) :-) :-) Aber jetzt fangen die Probleme leider erst recht an. Vielleicht kannst du da auch helfen, wenngleich das weniger mit deinem Tool direkt zu tun hat.

Vielleicht zum Hintergrund: Auf der PI laufen fhem und solarview (wahrscheinlich hast du davon gehört.) Das Backup wollte ich für den absoluten Desasterfall haben: die SD-Karte gibt ihren Geist auf. Somit wollte ich ein Image haben, mit der releativ schnell eine neue Karte erstellt werden kann,

Zitat:
Denke daran auch den Restore zu testen
. Damit habe ich den Nachmittag verbracht.

Mit win32diskimager wollte ich das Image wiederherstellen. Für die anderen Wege müßte ich ja erst ein Dummy-System, welches im Netzwerk funktioniert, erstellen, dann die USB-Devices ermitteln etc (Linux-Dummie).

Die erste SD tats nicht. Die 2. startete. In den Netzwerkverbindungen sah ich die PI auch mit der alten IP. Jedoch mit putty konnte ich nicht zugreifen. :sad: Dann sah ich auch, dass die Netzwerk-LED nicht an war.

FHEM war nicht erreichbar, Solarview fehlten Daten.

Ach so: Die PI hängt per Kabel an einen Fritz-WLAN-Repeater.

Mit der alten SD läuft wieder alles prima.

Und was nun ? :cry:
#725 framp 2016-08-21 15:40
zitiere Jürgen:
Hallo framp
vielen Dank für das tolle Tool und die sehr gute Unterstützung :D


Moin Jürgen,

draus schliesse ich dass Du jetzt wohl Backups mit raspiBackup erfolgreich erstellen kannst :-) Denke daran auch den Restore zu testen. Wie man einen Restore macht und ob er funktioniert. Es kam schon öfters vor dass erst im Notfall wenn das Backup dringend benötigt wurde Benutzer fragten was sie denn machen müssen :o

Cu framp
#724 framp 2016-08-21 14:43
Moin strobl jakob,

die Meldung RBK011E sagt es doch :-)

Entweder ein dd Backup erstellen oder den Parameter -P benutzen.

Cu framp
#723 strobl jakob 2016-08-21 14:38
Das Script funktioniert leider nicht.

root@garry-1:~# /usr/local/bin/raspiBackup.sh -p /backup -t tar -k 4
--- RBK0009I: garry-1: raspiBackup.sh V0.6.1.2 um So 21. Aug 14:36:30 CEST 2016 gestartet
--- RBK0128I: Logdatei ist /var/log/raspiBackup/garry-1.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
??? RBK0013E: Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ oder dem Parameter -P gesichert werden können

Was soll ich tun?
#722 Jürgen 2016-08-21 13:14
Hallo framp
vielen Dank für das tolle Tool und die sehr gute Unterstützung :D
#721 framp 2016-08-20 18:39
Moin Jürgen,
zitiere Jürgen:
...Gestatte mir 2 Nachfragen:
Dazu ist die Kommentarfunktion da :-)
Zitat:
Du empfiehlst exim4, dennoch ist der nicht bei den unterstützten EMail-Client aufgeführt.
Ist es für mich nicht einfacher mit SMTP ?
SMTP ist das eMailProtokoll das benutzt wird. raspiBackup bietet mail|sendEmail|ssmtp an. sendEMail und ssmtp sind eMailProgramme die Du installieren kannst. Das Programm mail wird von diversen eMailProgrammen angeboten. Dazu gehört z.B. postfix, sendmail und auch exim4.
Zitat:
Wenn ich es richtig verstanden habe, ist DD das einzige Format, welches win32diskimager unterstützt. Ist der Parameter bei DD, der das Problem minimal abweichender Kartengrößen zu lösen, DEFAULT_SAVE_
USED_PARTITIONS_ONLY ?
Ihn finde ich nicht in der Config ?! Wie muss er gesetzt werden ?
Das ist ein Parameter der schon dokumentiert ist aber erst in der nächsten Version 0.6.1.3 angeboten wird ;-) Ende August wird sie wohl verfügbar sein. Bis dahin kannst Du aber die Version 0.6.1.2 benutzen. Wenn die neue Version verfügbar ist wird Dich raspiBackup darauf hinweisen und Du kannst leicht mit -U upgraden.
Zitat:
Danke und ein schönes Wochendende
Danke, Dir auch.

Cu framp
#720 Jürgen 2016-08-20 17:59
Hallo framp

danke für die schnelle Reaktion

ich habe mir nochmals die komplette Log-Datei angeschaut und da steht mein Fehler:
"No space left on device"

Den kleinen Stick hatte ich nur aus anderen Gründen an der Fritzbox. Werde ihn jetzt austauschen.

Gestatte mir 2 Nachfragen:

Du empfiehlst exim4, dennoch ist der nicht bei den unterstützten EMail-Client aufgeführt.
Ist es für mich nicht einfacher mit SMTP ?

Wenn ich es richtig verstanden habe, ist DD das einzige Format, welches win32diskimager unterstützt. Ist der Parameter bei DD, der das Problem minimal abweichender Kartengrößen zu lösen, DEFAULT_SAVE_
USED_PARTITIONS_ONLY ?
Ihn finde ich nicht in der Config ?! Wie muss er gesetzt werden ?

Danke und ein schönes Wochendende
#719 framp 2016-08-20 17:12
Moin Jürgen,

mir ist eben aufgegangen, dass ich Dich vielleicht falsch verstanden habe :oops:

Mit dem Parameter -F ist raspiBackup im Fakemodus und erstellt kein Backup. Sinn macht der Parameter nur zum Testen der Emailbenachrichtigung.

Zitat:
??? RBK0043E: Unvollständiges Backup /media/fritzbox -usb/raspberryp i/raspberrypi-d d-backup-201608 20-162553
Diese Meldung kommt bei -F immer und bedeutet keinen Fehler. Ich werde die Meldung rausnehmen bei -F.

Wenn Du also -F weglässt wird raspiBackup ein Backup erstellen wie es in der Konfigdatei beim Installieren von Dir konfiguriert wurde.

Cu framp
#718 framp 2016-08-20 16:47
Moin Jürgen,

das sieht alles soweit eigentlich OK aus. Wenn Du keine eMail erhälst liegt das daran dass

1) Du keinen eMailer auf der Raspi konfiguriert hast (ich benutze z.B. exim4) (Siehe z.B. Zitat:
http://www.forum-raspberrypi.de/Thread-tutorial-die-post-geht-ab-mails-mit-dem-pi-versenden
)

2) Du die Parameter -e und -s nicht oder falsch angegeben hast

3) der Parameter -E fehlt oder falsch ist (je nachdem was Du bei -s angegeben hast)

Wenn Du Probleme beim Konfigurieren des eMailers hast solltest Du in Raspberry- oder auch LinuxForen suchen und fragen.

Wenn Du zwar eMails von der Raspi schreiben kannst - Du aber keine von raspiBackup erhältst - brauche ich Deine Aufrufparameter (eMail und u.U. Kennwörter aber bitte maskieren :-* )

Cu framp
#717 Jürgen 2016-08-20 16:33
Hallo
vielen Dank für das Tool. Als total Unwissender in Linux habe ich aber ein Problem.

Ich rufe auf:
sudo raspiBackup.sh -F

Alle Oarameter stehen in der config (soweit als möglich Standard)

Als Ergebnis bekomme ich
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.1.2 um Sat 20 Aug 16:25:55 CEST 2016 gestartet
--- RBK0128I: Logdatei ist /var/log/raspiBackup/raspberrypi.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
!!! RBK0124W: Simulationsmodus an
--- RBK0081I: Backup vom Typ dd wird in /media/fritzbox-usb/raspberrypi/raspberrypi-dd-backup-20160820-162553 erstellt
--- RBK0085I: Backuperstellung vom Typ dd läuft. Bitte Geduld
--- RBK0010I: raspberrypi: raspiBackup.sh V0.6.1.2 um Sat 20 Aug 16:25:57 CEST 2016 beendet
--- RBK0017I: Backup erfolgreich beendet
??? RBK0043E: Unvollständiges Backup /media/fritzbox-usb/raspberrypi/raspberrypi-dd-backup-20160820-162553 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)

Ich habe keinen Nachlauf, kein Exclude, kein Mail (außer Standard) definiert. Was läuft da falsch ?

Kannst du bitte helfen ? Welche Infos benötigst du ?

Danke vorab
#716 framp 2016-08-10 20:54
Moin Elektrofreak,

zu Deinem Feature Request: Ich biete zu raspiBackup ein Wrapperscript an => https://www.linux-tips-and-tricks.de/de/raspibackup#wrapper welches genau für solche Zwecke gedacht ist ;-)

Zu Deiner Frage: Ich persönlich halte nichts von einer Mixtur von verschiedenen Backups - aber die Möglichkeit besteht natürlich und wird auch benutzt.

Du definierst alle Hauptkonfigurationsparameter von raspiBackup in /usr/local/raspiBackup.conf und überschreibst den Typ und/oder die Backupanzahl über Aufrufparameter von raspiBackup in der crontab.

Cu framp
#715 Elektrofreak 2016-08-10 12:23
Hallo,

erst mal vielen Dank für das tolle Script!

Da hast geschrieben, dass verschiedene Backup-Methoden kombiniert werden können. Könntest du hierfür ein Beispiel machen? (bzw. wie man verschiedene Konfigurationsdateien verwendet. Crontab ist ja schon erklärt :-))

Ein weiteres "feature request" wäre, dass man vor der Ausführung des Scriptes Netzlaufwerke oder andere Laufwerke per "sudo mount -a" einbindet. Das müsste ich ansonsten jedes mal per Hand vorher prüfen bzw. ausführen.

Vielen Dank!
#714 framp 2016-08-03 22:51
Moin bcutter,

-F ist zugegebenermassen mal aus der Not entstanden und nur halbherzig in raspiBackup implementiert. Ich muss das mal in einer naechsten Version richtig glattziehen und dann auch wirklich als Simulation beschreiben.

Zum Abbruch: Das kannst Du selbst kontrollieren. Du musst in der Extension nur ein
exit 0
am Ende stehen haben. Damit wird raspiBackup signalisiert dass alles OK ist.

Cu framp
#713 bcutter 2016-08-03 21:12
Update zu Frage 1: "-F" gefunden. Vielleicht magst du ja auf der Seite mal das Stichwort "Simulation / simuliert" aufnehmen :)
#712 bcutter 2016-08-03 21:10
Okay.

Frage 1: Wie (hab keinen Parameter gefunden) kann ich das Backup simulieren (ohne es jedoch durchzuführen)? Will den Fehler so eingrenzen.

Zitat:
ein Fehler in der Extension führt immer zum Abbruch von raspiBackup und damit auch zum Löschen des Backups.
Bitte 1: Dieses Verhalten konfigurierbar machen :) Im Zweifel ist mir das post-Skript egal, Hauptsache ich habe mein Backup :)

Na klar wird das verwendet - weiß ich sehr zu schätzen dieses Feature! :D
+1 #711 framp 2016-08-03 19:52
Moin bcutter,

ja, ein Fehler in der Extension führt immer zum Abbruch von raspiBackup und damit auch zum Löschen des Backups. Es wird ja auch in einer Meldung darauf hingewiesen:
??? RBK0043E: Removing incomplete backup /mnt/Backups/raspberry-tar-backup-20160803-084227 (May take some time. Be patient)

Dein curl in der Extension meldet
curl: (56) Recv failure: Connection reset by peer
und das ist der rc den raspiBackup von der Extension zurückbekommt.

D.h. Du musst dafür sorgen, dass der curl keinen Fehler mehr bekommt. Dann wird raspiBackup wieder durchlaufen.

rc 56 bei curl ist 'Failure in receiving network data. ' Sieht man ja auch im Log.

Schön zu sehen dass die Extensionmöglichkeit von raspiBackup auch genutzt wird :-)

Cu framp
#710 bcutter 2016-08-03 11:27
Hi framp,

ich habe seit ca. 2 Wochen das Phänomen, dass das raspiBackup nicht mehr durchläuft. Weder über Cron, noch manuell. Log-File habe ich, aufgefallen sind mir hier (hier nur das Ende, kann dir das ganze Log gerne (per eMail direkt) zusenden):

Zitat:
...
...
tar: ./tmp/.lxterminal-socket\:1.0-pi: socket ignored
!!! RBK0049W: Some files were changed or vanished during backup. RC: 1 - ignoring change
20160803-091942: MSG !!! RBK0049W: Some files were changed or vanished during backup. RC: 1 - ignoring change
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
^M 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (56) Recv failure: Connection reset by peer
??? RBK0107E: Extension raspiBackup_PushingBox_NotifyBackup_post.sh failed with RC 56
20160803-091944: MSG ??? RBK0107E: Extension raspiBackup_PushingBox_NotifyBackup_post.sh failed with RC 56
Invocation parms: ''
??? RBK0005E: Backup failed in task main with RC 104. See logfile /var/log/raspiBackup/raspberry.log for details
20160803-091944: MSG ??? RBK0005E: Backup failed in task main with RC 104. See logfile /var/log/raspiBackup/raspberry.log for details
??? RBK0043E: Removing incomplete backup /mnt/Backups/raspberry-tar-backup-20160803-084227 (May take some time. Be patient)
20160803-091944: MSG ??? RBK0043E: Removing incomplete backup /mnt/Backups/raspberry-tar-backup-20160803-084227 (May take some time. Be patient)
- Der RC 56 ist seltsam. Kann es sein, dass - sofern ein Post-Skript nicht ausgeführt werden kann, das ganze Backup einfach wieder gelöscht wird? Das Post-Skript enthält nur einen CURL-Aufruf, welcher (genau wie das ganze Skript) manuell einwandfrei durchläuft.
- Die Datenpartition welche gesichert wird hatte in den letzten Wochen vereinzelte Dateisystem-Fehler, diese wurden jedoch (cold) via FSCK gefunden und behoben.
- raspiBackup-Version ist aktuell (0.6.1.2)
- Aufruf des Backups wie folgt: "/usr/local/bin/raspiBackup.sh -t tar -k 12 -N "PushingBox_NotifyBackup" /mnt/Backups/"
- Backup hat ca. 17 GB, am Ziel sind ca. 39 GB frei.

Hast du eine Idee für mich? *verzweifelt*
#709 Ka 2016-07-31 22:00
Moin framp,
ja das ist es wohl, tar-Datei ist jetzt über 4GB. Werde mal rsync probieren und mir unter Windows einen Treiber besorgen. Besten Dank! :-)

Gruß
Ka
#708 ralf 2016-07-31 21:45
was soll ich sagen: danke :-)
#707 framp 2016-07-28 20:12
Moin Ka,

das haettest Du gleich sagen sollen, dass Du auf FAT32 sicherst ;-) Bei FAT32 kann eine Datei maximal 4GB gross sein. Vermutlich ist Dein tar Backup jetzt mit Jessie größer. Du könntest es noch mit compression versuchen (-z Option). Beim rsync werden alle Dateien einzeln gesichert so dass Du da nicht an diese Grenze kommst.

Du könntest auch einen ext3 Treiber unter Windows installieren. Dann kannst Du auch rsync Backup benutzen und das unter Windows lesen.

Cu framp
#706 Ka 2016-07-28 11:09
Moin framp,
so, habe neue Erkenntnisse, die vielleicht weiterhelfen Habe mit neuen Sticks versucht Backup zu machen. Mit einem ext4-formattierten lief das Backup erfolgreich. Mit einem gleichen Stick aber vfat-formattiert (unter Windows FAT32) laufe ich auf den bisherigen Fehler. Möchte aber FAT32 verwenden, da ich den Stick dann auch unter Windows lesen kann.

Viele Grüße
Ka
#705 framp 2016-07-20 19:09
Moin Kurt,

freut mich dass es doch noch geklappt hat :-)

Wäre nur nett wenn Du mir sagen könntest welcher Link nicht OK ist?

Zitat:
Zum download: mit der oben genannten URL bekomme ich eine kleine Datei, die besagt, dass das Dokument gemoved ist nach http://www.linux-tips-and-tricks.de/de/downloads/raspibackuplinstall-sh/download.
Cu framp
#704 Kurt 2016-07-20 16:35
Hi framp,

Du kannst meine letzte mail ignorieren.

Ich habe /dev/sde1/ durch /dev/sde ersetzt und danach lief das restore komplett durch.

Habe gerade Daten auf mySQL übertragen (Daten liegen extern auf einem USB stick) und sie waren dort angekommen. Kann also zunächst nur konstatieren, dass das restore erfolgreich war.

Bin sehr erleichtert! :-)

Good job Dein raspiBackup!
Werde als nächstes ein weiteres dd backup machen und dann einen wöchentlichen cron job einrichten.

Danke.
Kurt
#703 Kurt 2016-07-20 10:07
Moin framp,

Habe gerade einen restore Versuch gemacht. Die Zielkarte habe ich FAT32 formatiert (auf meinem Mac, bin kein Windows user!). Ich habe sie dann mit einem Kartenleser am raspi angeschlossen. Dort ist sie als /dev/sde1 zu finden.
Mein Backup ist ein dd Backup. Der restore Aufruf sieht dann konkret so aus:

sudo /usr/local/bin/raspiBackup.sh -d /dev/sde1 /media/Backupalt/…weiterer Pfad zum dd Ordner.
Ich bekomme einen Fehler: „PBK0086E: Widerherstellungsgerät darf keine Partition sein“.

Wenn ich dann die Option -R hinzufüge (sudo /usr/local/bin/raspiBackup.sh -R -d /dev/sde1 /media/Backupalt/…weiterer Pfad zum dd Ordner) kommt die Fehlermeldung:
PBK0034E: Datei /dev/sde1 nicht gefunden.

Was muss ich ändern, damit das restore durchläuft?

Danke,
Kurt
#702 Kurt 2016-07-19 23:09
Moin framp,

mit dem rechtzeitigen restore hast Du natürlich recht. Ich habe es bisher halt nicht gemacht.

Zum download: mit der oben genannten URL bekomme ich eine kleine Datei, die besagt, dass das Dokument gemoved ist nach http://www.linux-tips-and-tricks.de/de/downloads/raspibackuplinstall-sh/download.

Damit bekomme ich trotzdem keinen download, gleicher Fehler im file.

Was läuft denn da falsch?

(Bin Mac User!)
#701 framp 2016-07-19 22:08
Moin Kurt,

das ist natürlich blöd. Aber dafür ist ja raspiBackup da :-)

Ich bin aber sehr irritiert, denn bei der Installationsanweisung steht deutlich

Zitat:
Anschließend sollte ein Restore auf eine weitere SD Karte vorgenommen werden um sich mit der Art, wie das Backup zu restoren ist, vertraut zu machen und das Backup zu testen. Es ist nichts ärgerlicher, wenn man zu dem Zeitpunkt, wenn man das Backup benötigt, feststellt, das das Backup nicht alles enthält oder sogar nicht brauchbar ist.
D.h. Du solltest wissen wie man den Restore ausführt, denn Du hast ihn ja schon probeweise durchgeführt ;-)

Ich vermute Du bist kein Linuxuser. Dann lies bitte auf
https://www.linux-tips-and-tricks.de/de/faq Punkt 2 nach.

Wenn Du einen DD Backup hast benutze win32diskimager auf Deinem WIndowssystem.

Ansonsten kommst Du dann auf der Restoreraspi an die Backupverzeichnisse indem Du Dein Backupmedium an die raspi mountest.

Weitere Details zum Restore siehe https://www.linux-tips-and-tricks.de/de/raspibackup-restore#winrestore

Cu framp
#700 Kurt 2016-07-19 21:46
Moin framp,

bei mir hat sich heute im laufenden Betrieb die boot SD Karte mit einer kernel panic verabschiedet, sie bootet nicht mehr komplett hoch.

Wie kann ich denn da den backup wieder restoren? Backup.sh muss auf der frischen SD karte sein, aber wie komme ich an die backup Verzeichnisse?

Kurt
#699 framp Es gab Problem 2016-07-17 17:28
Moin Ka,

sorry - ich habe da auch keine bessere Idee als das Auschlussverfahren. Die Fehlermeldung vom tar ist wirklich sehr generisch und ungenau. Die bisherige Erfahrung mit diesen Fehlern und raspiBackup ist dass es Probleme mit dem Backupmedium gibt.

Viel Erfolg.

Cu framp
#698 Ka 2016-07-17 17:24
Moin framp,
Ok, werde ich mal versuchen. Kann aber etwas dauern, da nächste Woche keine Zeit. Erst mal vielen Dank und bis dann.
Gruß
Ka :-)
#697 framp 2016-07-17 15:20
Moin Ka,

dass sieht ja eigentlich alles ganz gut aus. Da Du nfs und samba nicht kennst benutzt Du es ja wohl auch nicht :-)

Da bleibt wohl nur das Ausschlussverfahren :-?

1) Backupmedium defekt ? - Meiner Meinung nach die wahrscheinlichste Ursache. Nimm mal einen anderen USB Stick oder schliesse eine externe USB Platte an und sichere darauf

2) Es liegt am Jessie ? - Glaube ich eher nicht. Aber unmöglich ist ja nichts. Sichere mal ein Wheezy. Du kannst ja z.b. auch ein altes Wheezybackup restoren und dann noch einmal sichern. Dazu brauchst Du natürlich eine weitere SD Karte um das existierende Jessie nicht zu zerstören.

Cu framp
#696 Ka 2016-07-17 14:33
Moin framp,

puh, eine menge schwieriger Fragen für einen Anfänger.
Gibte es nicht etwas was man ausprobieren könnte um das Problem einzugrenzen?
Zu den Fragen: Es wurden schon dateien vorher gesichert. Das Backup ist ca. bis zur Hälfte des vorhergegenden angewachsen, bevor es nach dem Fehler gelöscht wird. Das Backup-Medium ist ist doppelt so groß wie die zu sichernde SD-Karte. Die SD-karte ist nur zu 25% voll. Das Backupmedium hat auch genügend freien Platz. Ob das Backup-Medium korrupt ist, kann ich nicht beurteilen auch sind mir nfs und samba noch kein Begriff.
#695 framp 2016-07-16 18:11
Moin Ka,

die Ausgaben vom tar sind auch in dem Log zu finden. Du siehst z.B. dass als letztes eine Datei aus dem /var/cache versucht wurde zu schreiben.

tar hat ein Problem die Daten zu schreiben. Die Frage ist warum :o

Folgende Fragen kommen da hoch:

Ist das die erste Datei oder wurden vorher schon Dateien gesichert?
Ist das Backupmedium vielleicht korrupt?
Ist auf dem Backupmedium nicht mehr genügend Platz?
Benutzt Du das Backupmedium per nfs oder samba und hat sich da irgendwas geändert?

Cu framp
#694 Ka 2016-07-16 17:19
Moin framp,
danke für die schnelle Antwort. Habe das mit -l 1 -m 1 -v gemacht. raspiBackup.log word dadurch ausführlicher und ich sehe zumindest wo der Abbruch stattfindet. Wo tar sein log hinschreibt weiß ich leider nicht. Hier der relevante Teil des raspiBackup.log:

./var/cache/apt/archives/libflite1_1.4-release-12_armhf.deb
tar: /media/backup/raspberrypi/raspberrypi-tar-backup-20160715-190241/raspberrypi-tar-backup-20160715-190241.tar: Nur 4095 von 10240 Bytes geschrieben
tar: Error is not recoverable: exiting now
#693 framp 2016-07-14 21:29
Moin Ka,

der tar exit code 2 bedeutet das tar einen unrecoverable error bekommen hat. Es ist also kein Fehler von raspiBackup.

In der nächsten Version von raspiBackup werden die Fehlermeldungen von den Backuptools in den Meldungen ausgegeben. Bis dahin muss man mit den zusaetzlichen Parametern -l 1 -m 1 -v ein Logfile erstellen und kann dann darin die tar Fehlermeldung finden.

Sieh mal nach was in dem Log vom tar als Fehlermeldung geschrieben wird.

Cu framp
#692 Ka 2016-07-14 21:28
Vorher steht noch
tar: ./tmp/.X11-unix/X0: Socket ignoriert
im logfile
#691 Ka 2016-07-14 20:47
Seit Umstellung auf Rasbian Version Jessie bricht Backup mittendrin ab:

tar: /media/backup/raspberrypi/raspberrypi-tar-backup-20160714-195608/raspberrypi-tar-backup-20160714-195608.tar: Nur 4095 von 10240 Bytes geschrieben
tar: Error is not recoverable: exiting now
20160714-201221: MSG ??? RBK0021E: Backupprogramm des Typs tar beendete sich mit Fehler RC 2
Invocation parms: ''
20160714-201222: MSG ??? RBK0005E: Backup fehlerhaft in Schritt main mit RC 109 beendet. Weitere Informationen finden sich im Logfile /var/log/raspiBackup/raspberrypi.log
20160714-201222: MSG ??? RBK0043E: Unvollständiges Backup /media/backup/raspberrypi/raspberrypi-tar-backup-20160714-195608 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
#690 Jerome 2016-07-01 13:40
zitiere framp:
Sorry - ich dachte es waere klar:

Deine sonstigen Aufrufoptionen musst Du natürlich auch noch mitgeben. Das sind zusaetzliche Aufrufoptionen die den Debugmodus des Scrips aktivieren und damit ein Logfile erstellt wird welches ich mir ansehen kann um die Ursache Deines Problems zu untersuchen.



Das ist mir klar.... :lol:
#689 framp 2016-06-30 22:24
Sorry - ich dachte es waere klar:

Deine sonstigen Aufrufoptionen musst Du natürlich auch noch mitgeben. Das sind zusaetzliche Aufrufoptionen die den Debugmodus des Scrips aktivieren und damit ein Logfile erstellt wird welches ich mir ansehen kann um die Ursache Deines Problems zu untersuchen.
#688 Jerome 2016-06-30 22:13
Hi Framp,

mit diesem Befehl passiert auf meinem System garnichts. Danach nimmt die Konsole keinen Befehl/Eingabe mehr an... :o
#687 framp 2016-06-30 20:52
Moin Jerome,

das sollte nicht sein :-? Rufe es mal mit

-u "--exclude=/media/* -l 1 -m 1 -v

auf und schicke mir das erstellte Logfile an meine email (Siehe Kontakt Seite) zu.

Cu framp
#686 Jerome 2016-06-30 20:28
Sorry Framp

aber bei jeder Variante

-u "--exclude=/media/*
-u --exclude=/media/*
-u--exclude=/media*/*

wurde mein MediaVerzeichnis munter mitgesichert...

LG
J
#685 Jerome 2016-06-30 13:32
*Klugscheissmodus off* :lol:
#684 Jerome 2016-06-30 12:30
:-)

Zitat:
Folgende Verzeichnisse werden immer nicht gesichert:
oder

Folgende Verzeichnisse werden NIE gesichert:
+1 #683 framp 2016-06-29 23:11
Moin Jerome,

die Beschreibung zu -u habe ich gleich nach Deiner Nachfrage zu -u auf rsync und tar erweitert. Hätte ich schon vorher mal tun können :oops: In beiden Fällen ist es ja dieselbe Syntax :-)

Cu framp
#682 Jerome 2016-06-29 23:06
Hi framp,

aha, dachte die Syntax wäre nur für rsync und für tar wäre wie im script die Syntax. Ok, Probier ich morgen aus.

Danke für Deine Geduld&Unterstützung !

Guts Nächtle
#681 framp 2016-06-29 21:46
Moin Jerome,

die Syntax ist nicht korrekt. Bei der Beschreibung der Optionen oben auf der Seite habe ich Beispiele für den rsync Backup gebracht und genauso muss es für tar aussehen ;-)

Nimm mal

-u "--exclude=/media/*"

:-)

Cu framp
#680 Jerome 2016-06-29 20:24
zitiere framp:
Moin Jerome,

das Script solltest Du nicht ändern. Für genau diese Fälle gibt es den Parameter -u und mit dem sollte es in beiden Versionen funktionieren.

Cu framp


Hallo framp,

ich habe das mit dem Parameter -u/media/* probiert, dennoch hat er das Verzeichnis mitgesichert.
Nehme ich -u /media/* kommt die Fehlermeldung "RBK0027E: Kein externes Gerät an /media/fritz/backup verbunden. Die SD Karte würde für das Backup benutzt werden."
obwohl das Laufwerk korrekt gemountet ist.

Btw. wie kann man denn ein laufendes Script (ausser Reboot) stoppen ?

LG
#679 framp 2016-06-28 22:22
Moin Christian,

vielen Dank für Deine Fixverifikation. :-)

Cu framp
#678 Christian 2016-06-28 20:40
Hey framp! Danke dir! Läuft... :)
#677 framp 2016-06-28 19:36
Moin Christian,

vielen Dank für Dein Feedback. Das ist ein kleiner Bug den ich gerade gefixed habe :-) . D.h. Du musst Dir noch mal die neue Version runterladen und dann wird es funktionieren.

Hintergund: Per cron sind keine Pfade gesetzt und damit wird auch raspiBackup, welches in /usr/local/bin steht, nicht gefunden :sad: Der Fix besteht darin, dass wenn kein PATH gesetzt ist dieser explizit im Script gesetzt wird.

Cu framp
#676 Christian 2016-06-28 14:57
Vielen Dank für die tollen Skripte! Ich weiß wieviel Arbeit man reinstecken muss, damit etwas so gut funktionierendes dabei herauskommt. Also vielen Dank nochmal.

Ein Problem habe ich. Starte ich das Backup mit raspiBackup.sh -p [...] manuell von der Shell läuft es sauber durch. Starte ich es mit raspiBackupWrapper.sh manuell von der Shell läuft es ebenfalls sauber durch. Starte ich es mit raspiBackupWrapper.sh per Cronjob, dann wird zwar der Wrapper gestartet, aber das eigentliche Backup nicht...

Im cron.log steht:
Jun 28 14:55:01 fhem cron[387]: (root) RELOAD (crontabs/root) Jun 28 14:55:01 fhem CRON[20206]: (root) CMD (/usr/local/bin/raspiBackupWrapper.sh)
Aber es wird kein Backup erstellt...

Hast du eine Idee?

VG Christian
#675 framp 2016-06-27 22:00
Moin Jerome,

das Script solltest Du nicht ändern. Für genau diese Fälle gibt es den Parameter -u und mit dem sollte es in beiden Versionen funktionieren.

Cu framp
#674 Jerome 2016-06-27 16:30
Hallo,

erstmal danke für das tolle Script.
Ich habe raspiBackup.sh für meine Konfig editiert, und zwar habe ich beim TAR-Backup den Pfad /media/* vom Backup ausgeschlossen. (analog zu proc,sys,dev etc.) Wieso wird der Pfad dennoch mitgesichert ?
In der Version "V0.5.15.7" hat das noch funktioniert.

LG
J.
#673 framp 2016-06-17 22:14
Moin Markus,

wenn Du das Pythonscript unbedingt benutzen möchtest kannst Du eine eMailExtension für raspiBackup schreiben.

Ich empfehle Dir aber einen Standard eMailClient zu installieren und zu nutzen. Ich z.B. nutze auf allen meinen Raspis exim4 und habe das nach dieser Anleitung www.forum-raspberrypi.de/Thread-tutorial-die-post-geht-ab-mails-mit-dem-pi-versenden installiert und konfiguriert. Dort in dem Forum kannst Du auch Fragen stellen wenn Du Probleme mit der exim4 Installation und Konfiguration hast.

Cu framp
#672 framp 2016-06-17 21:48
Moin Homer-S,

raspiBackup meldet Dir wenn es eine neue Version gibt und Du kannst es dann mit der Option -U sich updaten lassen.

Ein Linuxpaket für raspiBackup sowie die update Infrastruktur zu bauen ist viel zu aufwändig und übertriebener Aufwand für das kleine Script.

Cu framp
#671 Homer-S 2016-06-17 21:34
Hallo, eine kurze Frage. Kann man irgendwas irgendwo was reinschreiben (so funktioniert für mich Linux ;) um eine automatische Update Funktion zu haben oder, dass raspiBackup mit dem apt-get update/upgrade mit installiert wird?

Danke
#670 Markus Berg 2016-06-17 20:37
Hi,

erst einmal vielen Dank für das Skript, dass bis jetzt immer seine treuen Dienste getan hat. ;-)

Jetzt würde ich mir nur noch gerne nach dem Backup eine Mail mit dem Logfile zu schicken lassen und hierfür würde ich gerne das Python-Skript von hier kampis-elektroecke.de/?page_id=2324 verwenden. Aber ich habe es bis jetzt noch nicht hinbekommen. Kannst Du mir bitte helfen? Denn auch mit anderen email-clients habe ich es nicht hinbekommen.

Danke und Gruß
+1 #669 framp 2016-06-11 22:10
Bei Kurt gab es im Log eine Fehlermeldung von dd - No space left on device.

Das Backupdevice ist einfach zu klein :cry:

raspiBackup hat zugegebenermassen Probleme Laufzeitfehler der Backuptools in Fehlermeldungen auszugeben. Diese sind bislang nur in dem Log zu finden welches nicht einfach zu lesen ist :sad: . Solange ich raspiBackup alleine benutze was das kein Problem denn ich weiss wo ich nachsehen muss um Problemursachen zu finden.

Ich gehe davon aus dass Kurt bei einer entsprechenden Fehlermeldung von raspiBackup die Ursache für sein Problem selbst gefunden hätte.

Es ist dringend notwendig dass In einer der nächsten raspiBackup Versionen die Fehlermeldungen der Backuptools von raspiBackup ausgegeben werden so dass die Benutzer von raspiBackup die Fehlerursache selbst herausfinden und beheben können und ich mich nur noch um wirkliche Fehler in raspiBackup kümmern muss.
#668 kurt 2016-06-10 17:30
ok, danke. Kann ich nur nachts machen, leider erst morgen Nacht. Melde mich dann.
#667 framo 2016-06-10 14:53
Schwer zu sagen. Schicke bitte das Log von raspiBackup mit den Parametern -l 1 -m 1 erstellt an meine eMail (siehe Kontakt Seite) zwecks Analyse
#666 kurt 2016-06-10 13:07
Hi framp,

ich habe heute ein vollständiges dd backup auf einen USB stick (16GB) machen wollen, auf dem schon 3 rsync backups sind. Das backup wurde mit RBK0021E unvollständig abgebrochen.

Was ist denn da schief gelaufen?

Danke
kurt
#665 HarrySteff 2016-05-14 12:18
Hi framp,
erstmal danke für deine Hilfe, nun scheint es zu klappen... mache gerade mein erstes Backup!!! :-)
#664 framp 2016-05-14 10:11
Moin Harry,

den Backuppfad kannst Du auf zwei Arten angeben:

1) sudo -p /myBackupPath ANDEREOPTIONEN
oder der linuxgemäße Weg
2) sudo raspiBackup.sh ANDEREOPTIONEN /myBackupPath

Warum es bei Dir hängt kann ich nicht sagen. Dazu müsstest Du raspiBackup mal mit den Parametern -l 1 -m 1 -L 3 aufrufen und mir das erstellte Log zuschicken. Meine eMail findest Du auf der Kontaktseite.

Cu framp
#663 HarrySteff 2016-05-14 07:46
Guten morgen ;-)
Also jetzt werd ich bald verrückt... Jetzt bleibt er genau hier stehen: RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird ben
utzt da macht er einfach nicht weiter! Ähm, wie muss ich dem Backup-Pfad in der config angeben? Mount-Verzeichnis liegt unter /home/Pi/backup vielen Dank
#662 framp 2016-05-14 00:38
Moin Harry,

benutze mal no_root_squash. Dann wird es wohl gehen 8)

Du erlaubst damit allerdings jedem root Benutzer eines nfs Clients uneingeschränkten Zugriff. Im lokalen Netz zu Hause sollte das normalerweise kein Problem sein. Wenn ja - dann must Du Dich genauer mit den nfs Berechtigungen und deren Konfiguration auseinandersetzen.

Cu framp
#661 HarrySteff 2016-05-14 00:12
Hey,
Ist ein wdsharespace (western digital) schon älter...
Exports:
/nfs/Backup1 192.168.0.0/24(rw,async,root_squash)
Bin nach dieser Anleitung vorgegangen:

http://schworak.com/programming/linux/WD-ShareStore-Linux.pdf

Mhhh... :o
#660 framp 2016-05-14 00:03
Moin Harry,

habe eben gesehen dass das Commentplugin den Pfad auf das Backupdevice für /TestFile rausgestripped hat. Aber ich denke Du hast den Test richtig ausgeführt :-) .

Das sieht mir nach irgendeinem nfs Config Problem aus.

1) Wie sieht denn der Inhalt von /etc/exports von Deinem nfs Server aus?
2) Was hast Du als nfs server eingesetzt? synology, raspi, ...

Cu framp
#659 HarrySteff 2016-05-13 23:36
Hi framp,
Huch das ging aber schnell mit deiner Antwort... Dankeschön :-) Also wenn ich deinen Befehl eingebe kommt keine Meldung.. Aber die Datei ist nicht da! Wenn ich zum Beispiel "sudo mkdir Test" eingebe dann kommt die Meldung "Verzeichnis kann nicht angelegt werden: keine Berechtigung" mach ich's ohne sudo klappt es!

Danke!
#658 framp 2016-05-13 23:15
Moin Harry,

kannst Du auch als Benutzer root Dateien erstellen? Denn mit sudo gibst Du raspiBackup root Rechte die auch notwendig sind.

Du kannst z.B. mal
sudo touch /TestFile
eingeben. Funktioniert das und ist die Datei dann auf Deinem Backupspace zu sehen?

Cu framp
#657 HarrySteff 2016-05-13 22:59
Hallo zusammen, ich habe ein komisches Problem und weiß leider nicht mehr weiter... Vielleicht kann mir hier ja jemand einen Tipp geben... Und zwar möchte ich mein Backup auf eine NFS Freigabe meines NAS (wd sharespace) sichern NFS ist erfolgreich gemounted, ich kann mit meinem angemeldeten USER (pi) auch darin Ordner anlegen und Dateien hinkopieren! Wenn ich aber das Backup starte (sudo) kommt die Meldung das keine Schreibrechte vorhanden wären... Ich bin am verzweifeln... Benutzer pi darf also aber sudo nicht... Woran könnte das liegen? Vielen Dank!
#656 framp 2016-05-09 19:13
Moin Alex,

schwer zu sagen was das Problem ist. Benutze doch mal zusaetzlich die Parameter -l 1 -m 1 beim Aufruf und schicke mir das erzeugte Log zu. Dann kann ich sicherlich mehr sagen.

Meine eMailAdresse findest Du auf der Kontaktseite :-)

Cu framp
#655 Alex 2016-05-09 08:22
Hi,

direkt nach dem ich die OK status mail des backups erhalte bekomme ich auch immer eine mail mit
mail: Invalid header: /var/log/raspiBackup/rpi1.log
Google konnte mir kein tipp geben. Jemand eine Idee was was da verkehrt ist?
#654 framp 2016-05-03 19:18
Moin Stefan,

jetzt habe ich Deine Frage verstanden. Da Du rsync Backup benutzt kannst Du wenn nur wenig Änderungen am Image stattfinden relativ viele Sicherungsversionen vorhalten. Dummerweise wird für die Bootpartition pro Backup immer 64MB gesichert. Da Du nur 4GB Backupspace hast sind bei 10 Sicherungen 1/2 GB für die Bootbackupdoubletten belegt und reduziert unnötig Deinen Backupplatz :cry:

Du möchtest deshalb, dass die Bootpartitionsbackups auch verlinked werden solange sie identisch sind. Das macht natürlich Sinn.

Das kommt auf meine Todoliste :-)

Hintergrund dieser einfachen Lösung ist, dass ursprünglich nur eine Bootpartition gesichert wurde. Irgendwann brauchte ich mal wieder ein Backup bei mir und entdeckte dass die Bootpartition nicht mehr zur Rootpartition passte und nicht mehr bootete. Grund war ein Update der Bootpartition bei einem früheren apt-get upgrade :-? Ich konnte dann aber noch recovern.
Ich wollte aber nicht das jemand von den raspiBackup Benutzern in dasselbe Loch reinfällt und habe dann ziemlich schnell die einfache Lösung implementiert und die neue Version published. Da sich niemand gemeldet hat ist offensichtlich auch gottseidank keiner weiter in das Loch gefallen.

Die nächste Version ist im Sommer geplant. D.h. Du musst Dich gedulden oder schreibst ein Script welches diese Verlinkung vornimmt und nach raspiBackup gestartet wird.

Es ist auch nicht ganz ungefährlich wenn Du versuchst möglichst viele Backupversionen auf dem kleinen Backupspace vorzuhalten. Es muss nur mal ein größerer Update durch apt-get update reinkommen und dann verreckt raspiBackup weil kein Platz mehr auf dem USB Stick ist :eek:

Ich habe eine 1TB Platte bei mir als Backupspace und da ist genügend Luft nach oben. Deshalb hat mich das mit den 64MB auch nicht gestört.

Cu framp
#653 Stefan 2016-05-03 17:31
Ok, war definitiv zu ungenau.

Partition ist 16GB mit 1GB genutzt.
USB Disk hat 4GB (nicht 8GB, wie geschireben).

Mit rsync mache ich die Backups und da sich nicht viel ändert sollte die 4GB Disk lange reichen ohne zu purgen. Jetzt wird aber jedes mal die 64MB IMG der Bootpartition mitgesichert und das ist meiner Ansicht kein Hardlink sondern immer wieder eine neue Datei auf dem USB Stick, obwohl der Inhalt gleich ist. Hier war die Frage der Optimierung. ich brauche halt nicht 20x die gleiche IMG Datei.
#652 framp 2016-05-03 17:22
Moin Stefan,

es tut mir leid aber ich verstehe Deine Frage nicht :sad: .

Ist es der Fakt dass Du eine 64GB SD Karte hast und Du davon nur 8GB benutzt? Was hat das mit Hardlinks bzw img Dateien zu tun? Vielleicht kannst Du Deine Frage noch etwas praezisieren :-)

Cu framp
#651 Stefan 2016-05-03 16:04
Ich habe mal eine "Platzfrage" tum Thema IMG Dateien und dem rsync backup. Mein IMG ist immer 64MB groß und der Rest von meinem System sehr übersichtlich. Eigentlich würde ich auf den 8GB Backup locker >20 Backup sichern können, wenn nicht immer wieder die gleiche IMG gespeichert würde. Ein Diff hat schon gezeigt, das diese immer die gleiche ist. Kann man da nicht noch was mit Hardlinks optimieren?
#650 framp 2016-04-27 17:42
Moin DeejayT,

kommt manchmal vor dass die nfs Verbindung runterfällt. Den Test habe ich irgendwann mal eingebaut nachdem mir meine SD Karte zu 100% vollgeschrieben wurde und die Raspi dann stand :cry:

Cu framp
#649 DeejayT 2016-04-27 17:03
Hi,
habe die NFS Freigabe noch mal neu gemountet und jetzt läuft es wieder.
#648 framp 2016-04-27 15:52
Moin DeejayT,

das ist dumm :sad: . Wenn es bislang getan hat ist die Frage was Du geandert hast?

Cu framp
#647 DeejayT 2016-04-27 15:10
Hallo,

ich bekomme raspibackup nicht mehr zum laufen, es hat sonst eigentlich ohne Probleme funktioniert.

Aufruf: raspiBackup.sh -p /mnt/ipsbackup -t tar -k 2 -l 1

Fehlermeldung: Kein externes Gerät an /mnt/ipsbackup verbunden. Die SD Karte würde für das Backup benutzt werden.

/mnt/ipsbackup gibt es und ist ein gemountetes NAS Verzeichnis!
#646 Nea 2016-04-26 08:05
Dann danke ich Dir schonmal im voraus.
+1 #645 framp 2016-04-24 11:13
Moin Nea,

so wie ich das sehe ist der Aufwand relativ gering. Nach Änderungen ist der größte Aufwand immer die gesamte Funktion durchzutesten um sicherzustellen, dass nichts durch die Änderungen 'verschlimmbessert' wurde. Da die Funktion in einem neuen Codepfad untergebracht werden kann bedeutet das dass die Änderung sehr lokaler Natur sein wird. D.h. man muss nur die neue Funktion gezielt testen und dann über Nacht das Regressionstestpacket laufen lassen.

Kurzum: Ich sehe mir das mal genauer an. Du bist gewiss nicht der EInzige der diese Funktion gebrauchen kann. :-)

Cu framp
#644 Nea 2016-04-24 05:10
Hallo framp,
gerne stehe ich dir für solche Tests zu Verfügung aber wirklich nur wenn Du denkst das damit mehr Usern außer mir, auch damit geholfen wird.

Ich bin ein Programmierer alter Schule darum kenne ich nur zu gut solche Anfragen einzelner und den Ehrgeiz von sich selbst.

Ich gebe Dir Recht das die Speichermedien immer größer werden und es wahrscheinlich (zu mindest aus meiner Sichtweise) dadurch immer mehr Probleme geben wird diese zu sichern zwecks vorhandenem Speicherplatz.

Trotzdem danke ich Dir für dieses Verständnis was leider heute nicht mehr so alltäglich ist.

Gruß Nea
#643 framp 2016-04-23 19:40
Moin Nea,

Dein Benutzungszenario scheint mir durchaus häufiger vorzukommen, denn mittlerweile ist es kaum noch möglich kleinere SD Karten zu kaufen. Wenn man dann nur einen Bruchteil davon benötigt ist es natürlich unnötig die ganze SD Karte zu sichern.

Ich habe mich mal ein wenig im Netz umgesehen und es gibt tatsächlich eine Möglichkeit nur die aktiven Partitionen per dd zu sichern.

Auch habe ich mal in einer VM unter Windows den windiskimager installiert (bin eigentlich kein Windows User ...) um zu erkunden was der eigentlich sichert bzw restored. So wie ich es sehe ist es möglich, dass raspiBackup genau das Format beim dd Backup erstellt dass der windiskimager dann beim restore benutzen kann :-)

Ich werde das mal genauer untersuchen und dann vermutlich eine weitere Option einführen, die nur die existierenden Partitionen per dd sichert so dass der windiskimager damit die SD Karte wieder restoren kann. Das ist also genau das was Du suchst :roll:

Es wäre gut wenn Du oder jemand anderes, der auch dd Backups erstellt und sie mit windiskimager restored, mich beim Test der neuen Funktion unterstützen würde :-*

Ich würde mich freuen wenn sich 1-2 Leute für den Test der neuen Funktion finden würden. Einfach kurz hier antworten und ich melde mich dann direkt per eMail.

Cu framp
#642 framp 2016-04-23 13:00
Moin Nea,

vielen Dank für die ausführliche Antwort.

Ich habe keine Ahnung ob der WIndiskImager mit zwei dd Backups der Partitionen eine ganze SD Restoren kann. Wenn ja kann ich ja mal sehen ob ich wenigstens die Partitionen von raspiBackup sichern lasse.

Cu framp
#641 Nea 2016-04-23 11:25
Moin framp,
danke für Deine Antwort und die Erklärung dazu.
Ok, nun macht das Sinn. Warum ich dd Backups bevorzuge, das liegt eigentlich an der Einfachheit um schnell und ohne großen Aufwand, über Windows, das Backup auf eine neue SD-Karte flashen kann.
Das hat jetzt nichts mit Faulheit zu tun oder ähnliches aber lass es mich kurz erklären.
Auf meinem Pi läuft aktuell meine komplette Türgegensprechanlage, DoorPi, mit Video Stream [...]. [...] bei einem Ausfall der Anlage [ist] es meiner Frau nicht möglich [...] hier selbst [...] Abhilfe zu schaffen [...] Meine Frau kommt mit Windows Programmen klar aber ein .tar backup auf einem Linux System zurück flashen ist da zuviel verlangt.
Deswegen von mir die Verständnisfrage bezüglich der Größe des Backups.
Aber das ist ja kein Problem da, meine Frau, ja das Backup zurückspielen kann auch wenn es 16 GB groß ist, es dauert nur ein bisschen länger aber das wäre ja die einzige Einschränkung die Sie hätte.
Aber trotzdem vielen Dank für Dein Angebot das zu implementieren.
Da ich bestimmt der Einzigste wäre der das bräuchte, wobei brauchen tue ich es nicht notwendigerweise, wäre es unnötig hier, deine, Zeit zu investieren. Trotzdem danke.

Gruß Nea

[Edit framp: Beitrag etwas gekürzt]
#640 framp 2016-04-23 10:10
Moin Nea,

ja Du hast Recht: Es wird die gesamte SD Karte von raspiBackup gesichert und man könnte auch jede Partition einzeln per dd sichern und würde dann unbenutzten Platz der Karte nicht sichern.

Wieso ist das so? Das hat historische Gründe. Ich fing mit einem simplen dd Backup an und da ist die Sicherung der ganzen SD Karte am einfachsten (Siehe www.forum-raspberrypi.de/Thread-tutorial-automatisches-erstellen-eines-backups-pi-sichert-sich-selbst?highlight=raspibackup, da steht im Prinzip die erste Version von raspiBackup mit dd). Da damals auch die Karten nur 4GB gross waren benutzte man auch den gesamten Space. Nachdem ich auf 8GB umgestiegen bin erweiterte ich raspiBackup um den tar Backup, der schon größeren Aufwand benötigte, da ja auch die Partitionsinformationen gesichert und restore werden müssen. Da wird aber nur der wirklich belegte Platz gesichert. Zum Schluss kam noch rsync dazu wo noch durch Hardlinks Backupspace gespart wird.

Ausserdem zeigte sich dann irgendwann, dass Bedarf für die Sicherung von mehreren Partitionen gab. Dazu war nur der dd Backup in der Lage bis dann der partitionsorientierte Backup eingeführt wurde.

Weiterhin lernte ich irgendwann, dass der dd Backup der einzige Backup ist, den man auch unter Windows restoren kann.

D.h. ich empfehle Dir zu dem tar Backup zu wechseln - ausser Du hast andere dringende Gründe für ein dd Backup. Solltest Du sie haben lass mich diese bitte wissen und ich überlege mir dann vielleicht wie man den dd Backup pro Partition einbauen kann. Dann benötige ich aber Testunterstützung von Dir, denn dd Backups zu testen ist eine langwierige Sache :sigh:

Cu framp
#639 Nea 2016-04-22 23:36
Nabend framp,
ich habe mal eine Verständnisfrage, meine SD-Karte ist 16GB groß, meine Partitionen auf der Karte sind:
/dev/mmcblk0p1 = 60 MB
/dev/mmcblk0p2 = 3,8 GB

Wenn ich ein dd backup mache warum ist diese dann 16 GB groß?
Diese dürfte doch eigentlich nur 3,86 GB groß sein da der unpartitionierte Speicherplatz doch dann nicht mit gesichert wird, oder?

Danke für das tolle Programm und natürlich für Deinen tollen Support.

Gruß Nea
#638 bcutter 2016-04-18 14:11
Nachtrag: Ich habe den Aufrufparameter "-u" gesehen. Demnach sollten meine unter /mnt/ eingebundenden Datenträger ja nicht mitgesichert werden, was meine Frage #2 zu den BACKUP EXKLUSION PATHS klärt.

Bleibt noch die (neue?) Struktur von TAR-Backups am Backup-Ziel. Ist das Erstellen des Unterordners je TAR-Backup denn vermeidbar, also ein Verhalten wie "früher" wiederherstellbar?
#637 framp 2016-04-18 14:09
Moin sunjammer,

Du hattest diesen Parameter doch angefragt und ich Dir versprochen dass er in der naechsten Version drin sein wird :-) Du weisst aber ... Du benutzt den Parameter auf eigene Gefahr ;-)

Cu framp
+1 #636 framp 2016-04-18 14:07
Moin bcutter,

zu 1) Das ist einer der Gruende fuer die neue Version: Fuer Ordnung im Backupverzeichnis zu sorgen. D.h. es wird pro Backup immer ein Unterverzeichnis angelegt. Du wirst Deine Gruende haben warum Du die Unterverzeichnisse nicht haben willst - aber die neue Version erstellt immer Unterverzeichnisse. Ich sehe fuer Dich folgende Loesungsansaetze:

a) Du passt die Logik an die kein Unterverzeichnis erwartet so dass sie mit Unterverzeichnissen arbeiten kann.
b) Du benutzt das Wrapperscript und erstellst am Ende noch symbolische Links im Backupverzeichnis.
c) Du aktivierst die vorherige Version wieder mit dem Parameter -U.

a) ist fuer mich die beste Loesung da alle Erweiterungen und Fixes von raspiBackup nur auf der aktuellen Version erstellt werden.
b) Ist meine 2te Wahl - obwohl dann natuerlich wieder Unordnung ins Backupverzeichnis gebracht wird :-)
c) Wuerde ich nur nehmen, wenn Du wirklich keine andere Alternative hast.

zu 2) Es gibt die Option -u bzw das Configsetting DEFAULT_EXCLUDE_LIST. Dort kannst Du alles reinschreiben was excluded werden soll. Natuerlich muss das der Syntax des Backuptools (rsync oder tar) entsprechen.

Cu framp

PS: Ein Posting reicht ;-) Da ich manuell immer den Spam ausfiltere dauert es i.d.R. bis zu einem Tag bis ich die Postings freigebe.
#635 bcutter 2016-04-18 13:35
Hi,

ich bin nach langer Zeit mal wieder dabei (zwecks Änderung des Backup-Storage), das Skript zu aktualisieren.

Ich kam von v0.5.15 auf jetzt v0.6.1.2. Habe auch gleich den -p rausgeworfen und das Ziel an´s Ende meines Cron-Aufrufes gepackt.

Allerdings komme ich mit zwei Dingen noch nicht ganz klar:
1) BACKUP TARGET SUBFOLDERS
Wie kann ich verhindern, dass am Zielpfad ein Unterordner mit dem (hier TAR)Backup angelegt wird? Ich hätte es gerne so wie bisher, konnte aber in der Change History nichts dazu finden.
2) BACKUP EXKLUSION PATHS
Ich habe irgendwo gelesen, dass /mnt nun nicht mehr automatisch vom Backup ausgeschlossen ist. Wo kann ich dies konfigurieren bzw. als Parameter die Exklusion mit in meinen Cronjob packen?

Hoffe du kannst mir (wie immer) kurz weiter helfen in beiden Punkten! Vielen Dank :)
#634 sunjammer 2016-04-18 11:19
Hey framp,

vielen Dank für die neue Version 0.6.1.2! Habe meine uralte Version nun mal upgedated und mit den Zusatzparametern zu rsync zum Laufen bekommen. Funktioniert super! :)

Danke! :)
sunjammer
#633 bcutter 2016-04-18 01:03
Hi,

ich bin nach langer Zeit mal wieder dabei (zwecks Änderung des Backup-Storage), das Skript zu aktualisieren.

Ich kam von v0.5.15 auf jetzt v0.6.1.2. Habe auch gleich den -p rausgeworfen und das Ziel an´s Ende meines Cron-Aufrufes gepackt.

Allerdings komme ich mit zwei Dingen noch nicht ganz klar:
1) BACKUP TARGET SUBFOLDERS
Wie kann ich verhindern, dass am Zielpfad ein Unterordner mit dem (hier TAR)Backup angelegt wird? Ich hätte es gerne so wie bisher, konnte aber in der Change History nichts dazu finden.
2) BACKUP EXKLUSION PATHS
Ich habe irgendwo gelesen, dass /mnt nun nicht mehr automatisch vom Backup ausgeschlossen ist. Wo kann ich dies konfigurieren bzw. als Parameter die Exklusion mit in meinen Cronjob packen?

Hoffe du kannst mir (wie immer) kurz weiter helfen in beiden Punkten! Vielen Dank :)
#632 framp 2016-04-09 11:29
Moin Fredi,

da brauchst Du Dir keine Sorgen zu machen. Das ist normales Verhalten von Linux, dass aller Speicher genutzt wird wenn ein System arbeitet - und das tut es ja beim Backup :-)
Es gibt eine schöne Seite dazu, die das Verhalten sehr schön erklärt: www.linuxatemyram.com/

Es ist also kein Reboot notwendig :-)

Cu framp
#631 Fredi 2016-04-09 10:43
zitiere framp:
Moin Fredi,

nach Beenden des Backups sollte keine höhere CPU Last sein. Ich könnte mir vorstellen, dass Du nach dem Backup wieder verschiedene Services startest, die Du vorher beendet hast. Ich vermute dass ein oder mehrere Services beim Start irgendwelche Aktivitäten vornehmen, die die CPU Last erzeugt. Das sollte aber nach einer gewissen Zeit beendet sein.
Ansonsten musst Du mal mit top nachsehen welche Prozesse den CPU Load erzeugen.

Cu framp

Sorry, ich meinte Speicherauslaustung (RAM) nicht CPU-Auslastung. ICh beende keine Services und starte auch keine.
#630 framp 2016-04-09 08:52
Moin Fredi,

nach Beenden des Backups sollte keine höhere CPU Last sein. Ich könnte mir vorstellen, dass Du nach dem Backup wieder verschiedene Services startest, die Du vorher beendet hast. Ich vermute dass ein oder mehrere Services beim Start irgendwelche Aktivitäten vornehmen, die die CPU Last erzeugt. Das sollte aber nach einer gewissen Zeit beendet sein.
Ansonsten musst Du mal mit top nachsehen welche Prozesse den CPU Load erzeugen.

Cu framp
#629 Fredi 2016-04-09 07:47
Ich nutze das Backup wie folgt: raspiBackup.sh -p /Q/backup -t dd -k 7. Das funktioniert grundsätzlich gut. Leider liegt die CPU Last nach dem Backup bei über 90%. Normalerweiser liegt sie immer nur bei ca. 25%. Ich muss den Raspi dann immer neu starten, warum? Vielen Dank für Eure Antworten.
#628 framp 2016-04-06 19:40
Moin Wolfgang,

nun habe ich ein Laufwerk mit sshfs gemounted und konnte auch ohne Probleme auf das Laufwerk schreiben. Auch habe ich in /tmp schreiben können.

Somit kann ich Deine Fehlerszenarien leider nicht nachvollziehen :sad: . Damit bleibt nur, dass Du Deine Fehlerszenarien noch einmal bei Dir reproduzierst und die Parameter -l 1 -m 1 -L 3 benutzt. Danach schicke mir bitte die beiden Logdateien an meine eMailAdresse (Siehe Kontakt Seite) zu so dass ich genauer reinsehen kann.

Cu framp
#627 framp 2016-04-02 12:08
Moin Wolfgang,

mit einem sshfs gemounteten Laufwerk habe ich nicht getestet und mir ist auch nicht bekannt dass es schon einen Benutzer gibt der das benutzt. Das sollte aber natürlich funktionieren. Ich sehe mir das an und melde mich dann hier wieder.

Cu framp
#626 Wolfgang 2016-04-02 10:54
Hallo, ich nutze das raspiBackup seit einer Woche auf einem Piv33 mit einer externen hsb-hdd. Läuft super.
Jetzt habe ich es zusätzlich auf einem PIv2 installiert und möchte per sshfs auf die usb den PIv3 scheiben.

Der Schreibzugriff von der Konsole funktioniert.

Am PIv2 starte ich raspiBackup mit

sudo /usr/local/bin/raspiBackup.sh -p /home/pi/usb-hdd-remote/pi-sicherung/pi1 -t rsync -k 3

und bekomme folgende Meldung:
??? RBK0031E: Backuppath /home/pi/usb-hdd-remote/pi-sicherung/pi1 does not exist

Wie schon geschrieben per ls und anderen Befehlen kann ich das Verzeichnis sehen und beschreiben.

Hast du eine Idee woran das liegen kann?
Vielen Dank für die Hilfe.

Gruß

Wolfgang
#625 framp 2016-03-28 23:25
Moin Axel,

freut mich dass es Dir hilft.

raspiBackup ist über die Zeit sehr flexibel geworden und das bedeutet damit auch, dass es etwas Zeit braucht bis man die gesamten Möglichkeiten überblickt.

Wenn Du Fragen hast stelle sie hier einfach :-)

Cu framp
#624 Axel 2016-03-28 21:04
Klasse Tool!

Ich bin noch nicht in die totalen Tiefen des Scripts eingestiegen, sondern nutze es, um ein DD Backup meines Raspis per FTP auf meinem FS zu machen. Das funktioniert völlig problemlos inkl. Rücksicherung direkt auf die SD Karte. Bisher auch keine Probleme mit nicht gestoppten Diensten, es funzt Out-of-the-Box!

Danke! Nach so etwas hatte ich gesucht! 8)
#623 sunjammer 2016-03-21 17:31
Hi Gary,

nach eingehender Beratung mit framp habe ich beschlossen, diesen Fehler einfach zu ignorieren.
Das xattr Attribut wurde in meinem Fall nur bei systemd-detect-virt nach einem bestimmten Update gesetzt. Davor gab es das xattr nicht.

Ich habe zwischenzeitlich mehrfach ein Backup zurückgespielt, bei dem das xattr dann entsprechend nicht gesetzt war. Ich konnte bis heute kein Problem mit meinem System feststellen. Ich habe das xattr auch nicht manuell wiederhergestellt.
#622 Gary 2016-03-20 13:28
Hi sunjammer,
hast du mehr über den Fehler heraus gefunden? - habe das gleiche Thema.
zitiere sunjammer:

Nach einem aktuellem Update meines Raspi (Jessie) bekomme ich beim rsyncen nun folgende Fehlermeldung:
rsync: rsync_xal_set: lsetxattr(""/mnt/backup/Pie/Pie-rsync-backup-20160127-235549/usr/bin/.systemd-detect-virt.l45NJ9"","security.capability") failed: Operation not supported (95)

Wie du schon schreibst werden offenbar xattr von NFS nicht unterstützt. Offenbar wurde der Fehler vor dem Jessie Upgrade ignoriert, oder die xattr wurden erst damit am Raspberry eingeführt (ich habe es z.B. beim PING Kommando, das damit für Nicht-Root-User ausführbar gemacht wird).
Da ich nur drei Fehlerzeilen im Log habe, habe ich beschlossen, das zu ignorieren. Bei einem Restore müssten sie evtl. manuell restauriert werden.
#621 framp 2016-03-15 09:46
Moin Gary,

vielen Dank für den erfolgreichen Test. Die Funktion habe ich eben auch in die neue kommende Version 0.6.1.2 eingebaut. Du wirst sie also nach einem Upgrade dann immer noch vorfinden :-)

Cu framp
#620 framp 2016-03-12 10:12
Moin Gary,

raspibackup erstellt immer eine eMail. Das ist historisch aus folgendem Grund bedingt: Als ich raspibackup nur selbst benutzte dachte ich auch wie Du es wäre vielleicht sinnvoll nur im Fehlerfalle eine eMail zu bekommen. Leider ist das nicht ganz so einfach in allen Fehlervariationen zu testen - u.U. wird auch eine Fehlersituation übersehen und keine Fehler eMail geschickt. Das ist natürlich sehr unangenehm und deshalb habe ich dann für mich entschieden immer eine eMail schicken zu lassen. So muss ich einmal pro Woche 3 eMails bei mir löschen - bin aber sicher dass der Backup OK war. Das habe ich dann auch so gelassen wie ich raspiBackup der Allgemeinheit zur Verfügung gestellt habe. Du bist der Erste der nach dieser Funktion fragt. Aber sie macht sicherlich Sinn,

Ich werde eine modifizierte Version der 0.6.1.1k-4 für Dich erstellen und Dir zuschicken. Bitte teste sie und lass mich wissen ob sie wie gewünscht funktioniert. Aber wie gesagt: Es ist ein gewisses Risiko dabei und ich habe Dich drauf hingewiesen :-*

In den anstehenden neuen Version 0.6.1.2 werde ich die Funktion dann auch noch einbauen. Wenn ich Zeit finden sollte werde ich die Funktion dann auch noch intensiver testen. Ansonsten wird sie mit einem entsprechenden Disclaimer versehen.

Cu framp
#619 Gary 2016-03-11 23:57
Ich würde gerne ein Benachrichtigungsmail ausschließlich nur im Fehlerfall bekommen - derzeit verwende ich Parameter -e und bekomme aber nach jedem Backup das Protokoll. Geht das, wie kann ich das einschränken?

Danke und lG, Gerald
#618 framp 2016-03-09 20:57
zitiere Balou:
Wer lesen kann ist klar im Vorteil . Ist ja oben auch beschrieben.

Naja, die Infos sind schon etwas verstreut :-*
Zitat:
Werde mal in mich gehen ob ich für mich eine smarte Lösung finde. Dein Script ist ja erweiterbar.
Könnte ja ein Script einbinden was meinen Stick sichert.
Ich glaube dass es wenig Sinn macht raspiBackup in diesem Falle zu benutzen, denn es ist nun mal darauf ausgelegt die SD Karte zu sichern.
Hm ... mir fällt gerade was auf. Kann es sein dass Du noch alle Noobs Partitionen auf der SD Karte hast ausser der einen Rootpartition eines Noobsimages? Dann kannst Du natürlich schon raspiBackup benutzen um die SD Karte zu sichern. Wenn Du dann das Wrapperscript benutzt musst Du nur noch ein tar der USB Partition anfertigen und Du hast eine Sicherung. Den Restore der USB Partition musst Du dann aber manuell vornhemen.

CU framp
#617 Balou 2016-03-09 18:05
framp

Wer lesen kann ist klar im Vorteil . Ist ja oben auch beschrieben.
Habe mir erstmal damit geholfen das ich im Terminal per TAR die Root Partionen von dem USB Stick gesichert habe.

Werde mal in mich gehen ob ich für mich eine smarte Lösung finde. Dein Script ist ja erweiterbar.
Könnte ja ein Script einbinden was meinen Stick sichert.
#616 framp 2016-03-09 16:37
Moin Balou,

leider nein. Im Kapitel 'Vergleich partitionsorientierter Backup und normaler Backup' weiter oben habe ich genau beschrieben wie die jeweiligen Modi arbeiten. Da steht beim normalen Modus, dass nur im tar oder rsync Backup eine externe Rootpartition mitgesichert wird. Das geht aber nur wenn kein NOOBs Image vorliegt. Beim dd Backup wird nur die SD Karte gesichert.

Kurzum: Bei einem NOOBs Image sichert raspiBackup keine externe Rootpartition mit :cry:

Cu framp
#615 Balou 2016-03-09 16:10
framp
>>benutzt wohl den partitionsorientierten Backup (Parameter -P) benutzen

Ja, habe ich bisher so gemacht. Bisher halt nur die SD Card. Ich habe das so verstanden das wenn ich Noobs habe auch das partitionsorientierten mit -P einschalten muß.

Wenn ich -P nicht nutze gibt es folgende Meldung "Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ oder dem Parameter -P gesichert werden können" wenn ich ein TAR Backup erstellen will.

Also DD oder DDZ nehmen, dann würde die komplette SD Karte und der USB Stick in einer Img Datei gesichert werden. Verstehe ich jetzt mal so. 8 GB SD Card und 16 GB USB Stick = 24 GB Image

Oder?



,
#614 framp 2016-03-09 14:56
Moin Balou,

Du wirst da Du Noobs benutzt wohl den partitionsorientierten Backup (Parameter -P) benutzen. Bei dem werden nur die SD Kartenpartitionen gesichert. Nur beim normalen Backup ohne -P wird auch eine externe Rootpartition gesichert.

Cu framp
#613 Balou 2016-03-09 13:49
Hi,

Ich bin gerade dabei einen Raspi neu zu installierern. Ich habe diesmal die / auf den USB Stick verschoben. Läuft auch soweit. Das ganze mit dem aktuellen Noobs 1.8.
Soweit ich dein Script verstanden habe müßte doch auch die Root Partionen vom dem USB gesichert werden. Oder?
#612 framp 2016-03-01 20:22
Moin Stefan,

Du hast nichts falsch gemacht ;-) . Es liegt wohl irgendwo ein kleines Problem in raspiBackup vor :oops: . Es wundert mich allerdings, denn ich benutze exakt dieselbe Version mit rsync und habe eben noch mal geprüft: Bei mir ist alles OK.

Ich habe eine gewisse Vermutung. Bitte schicke mir das Log eines BackupLaufes, wo Dateien gelöscht werden müssen, mit den Parametern -l 1 -m 1 an meine auf der Kontaktseite angegebene eMailAdresse zu damit ich den Fehler lokalisieren kann.

Cu framp
#611 Stefan 2016-03-01 17:30
Ich habe mit der 0.6.1.1k ein Problem mit dem Aufräumen der sfdisk dateien. Mein Kommando lautet:
00 22 * * * /usr/local/bin/raspiBackup.sh -p /backup -t rsync -k 15

Also 15 Versionen. Das passt auch von den Verzeichnissen. Bei den *img, *mgr und *sfdisk (das ist das Problem) wird nicht aufgeräumt so dass der USB Stick überläuft. Irgendwas, was ich falsch gemacht habe?
#610 lum! 2016-02-22 23:14
Ok danke framp. Werde das dann mal testen :)

Gruß
#609 framp 2016-02-21 15:48
Moin lum,

ja so ist es. Aber anschliessend kannst Du mit raspi-config oder gparted die root Partition extenden so dass Du dann den ganzen Platz der SD Karte nutzt ;-)

Cu framp
#608 lum! 2016-02-21 15:23
Hallo, so wie ich das verstanden habe ist es also so dass wenn ich komplettes Backup Image von einer 4GB SD Karte gemacht habe (verwende Securepoint Imaging Tool) man dieses schon auf eine 8GB SD Karte raufmachen kann, aber das OS dann nur 4GB zur Verfügung hat?
#607 Balou 2016-02-20 15:28
Ich hatte ja vor einiger Zeit mal einen Kommentar #580 geschrieben. Wo mein Problem letztlich auf eine defekte SD Card zurückzuführen waren. Das war eine SanDisk Ultra 32gb. War quasi nach 2 Monaten platt. Da lief Munin das mein beiden Raspi und die Fritzbox überwacht drauf. Bis mein System lief hatte ich paar mal neuinstalliert und Restore durchgeführt.
Anderseits läuft in meinen ersten Rapsi seit ca 2 jahren immer noch die erste Karte. ist eine 16gb SanDisk
Als Interner Email Server mit Daten auf USB Stick läuft der 24/7 ohne Probleme. Das ist mir nur mal das Netzteil verreckt.
Sonst habe ich noch einen Raspi als Testsystem, da probiere immer mal was aus. Da habe mittlerweile SD Karten verschiedener Hersteller und Größen am laufen gehabt. Bestimmte Auffälligkeiten hinsichtlich Lebenszeit habe ich dabei nicht gewonnen.
#606 framp 2016-02-19 19:18
zitiere maui:
du scheinst schon deine Erfahrungen gemacht zu haben.
Naja, seit 3 Jahren laufen bei mir 2 Raspis 7/24 und ich habe raspiBackup entwickelt und getestet. Dabei gewinnt man so seine Erfahrungen :-) Zitat:
Hast du einen gaaanz groben Zeitrahmen bei dir feststellen können?
Das ist nicht möglich, da es von der Intensität der Schreibtätigkeit auf die SD Karte sowie die Qualität der SD Karte selbst anhängt. Zitat:
Ich hab zb. einen Pi mit fhem, da wäre ich dann nicht enttäuscht, wenn nach 1 Jahr die SD hinüber ist.
Ich würde da mal im fhem Forum nachfragen wie häufig bei den Nutzern Ausfälle auftreten um eine gewisse Hausnummer zu bekommen. Oder Mitleser, die auch fhem betreiben teilen ihre Erfahrungwerte mit :-* .Zitat:
Das Problem mit backups ist ja, dass jedes Backup bzw. die Häufigkeit von Backups der Lebensdauer entgegenwirkt. Deswegen plane ich derzeit auch nur pro Monat 1 Backup von jedem System zu machen.
Nein, es ist nur die Schreibfrequenz relevant. Beim Backup wird aber nur gelesen. D.h. Du kannst also durchaus jeden Tag ein Backup erstellen sofern das notwendig ist.
Bei meinen Restoretests mit raspiBackup habe ich um die 5 SD Karten geschrottet. Aber erst als ich den Backup soweit getestet hatte und dann mit dem Restoretest anfing. Da habe ich dann auch über längere Zeit immer wieder die SD Karte vollständig neu beschrieben. Das geht dann schon an die Sustanz der Karte :roll:

Cu framp
#605 maui 2016-02-18 22:03
du scheinst schon deine Erfahrungen gemacht zu haben. Hast du einen gaaanz groben Zeitrahmen bei dir feststellen können? Mir ist bewusst, dass die Lebensdauer maßgeblich davon abhängt, wie häufig auf die SD zugegriffen wird.
Ich hab zb. einen Pi mit fhem, da wäre ich dann nicht enttäuscht, wenn nach 1 Jahr die SD hinüber ist.
Das Problem mit backups ist ja, dass jedes Backup bzw. die Häufigkeit von Backups der Lebensdauer entgegenwirkt. Deswegen plane ich derzeit auch nur pro Monat 1 Backup von jedem System zu machen.
#604 framp 2016-02-18 18:25
zitiere maui:
...Jetzt nur noch hoffen, dass meine SD-Karten lange leben und ich nicht so schnell einen Restore in Angriff nehmen muss...

Das wünsche ich Dir - aber Du wirst sehen - das wird passieren. Das ist so sicher wie das Amen in der Kirche :cry: Aber mit einem aktuellen Backup ist das ja nicht so dramatisch :-)
#603 Christian 2016-02-18 17:05
Hallo Alex,

das muss eine Einschränkung des Mailhubs sein, denn ich sende mit ssmtp und eigenem Absender und das geht auch bei mir. Jedoch ist mein Mailserver auch von mir selbst betrieben und ich habe dementsprechend auch keine Einschränkungen darauf bzw. kann diese selbst steuern.

Grüße,
Christian
#602 maui 2016-02-18 16:17
So, hab das jetzt auch hinbekommen. War denke ich ein fehlendes
"-o tls=auto"
Jetzt nur noch hoffen, dass meine SD-Karten lange leben und ich nicht so schnell einen Restore in Angriff nehmen muss.
Gruß
#601 framp 2016-02-18 15:58
Moin Maui,

fein dass es jetzt (fast) klappt. Wg sendEmail musst Du mal im Netz suchen. Ist wahrscheinlich doch noch eine Konfig Datei die unterschiedlich ist :-*

Wg VEBOSE - nee, das ist ein MiniBug im Helptext :oops: . Das fixe ich in der naechsten Version. Vielen Dank fuer den Hinweis.

Cu framp
#600 maui 2016-02-18 13:24
hey framp.
Danke für deine tipps.
Dank verbose mode konnte ich das Problem finden.
Es war docker, welcher sich 100GB an nicht vorhandenem Speicher einfach schonmal reserviert hat.
Und tar war so brav und wollte das natürlich alles ins tar mitnehmen :-)
Das einzige, was jetzt noch nicht geht, ist sendEmail. Ist zwar sehr komisch, da es auf beiden Pis mit der identischen Konfiguration geht, aber bei der cubox mit folgendem Fehler fehl schlägt.
ERROR => ERROR => SMTP-AUTH: Authentication to mail.gmx.net:587 failed.
sendEmail direkt benutzen ohne raspibackup geht leider auch nicht.
Aber das ist mir auch nicht soo wichtig, wichtiger ist, dass er regelmäßige Backups erstellt :)
PS: Die Parameter-Variable VERBOSE änderst du sicherlich bewusst nicht von VEBOSE zu VERBOSE aus Komp. Gründen oder?
Grüße
#599 framp 2016-02-18 12:54
Moin Alex,

raspiBackup kann definitiv mit ssmtp eMails schicken. Der Support kam ja rein weil Benutzer danach gefragt haben und die haben dann ja den Code getestet und benutzen es nun auch.

Ich kenne mich mit ssmtp leider nicht aus :sad: . So wie ich es sehe ist es irgendwie eine Konfigurationssache beim ssmtp die falsch ist oder fehlt. Vielleicht antwortet ja jemand hier der sich mit ssmtp auskennt bzw es mit raspiBackup benutzt und mitliest.
Ansonsten musst Du wohl im Netz suchen wie man das Problem loesen kann.

Cu framp
#598 Alex 2016-02-17 23:14
Hi framp, danke für die Infos. Ich muss die Zeile

echo -e "To: receiver@mail.de\nFrom: root@$(hostname -f)\nSubject: OSMC log\nlogfiles" | "$EMAIL_PROGRAM " "$EMAIL"

in

echo -e "To: receiver@mail.de\nFrom: foo@bar.com\nSubject: OSMC log\nlogfiles" | "$EMAIL_PROGRAM " "$EMAIL"

ändern, dann wird die E-Mail gesendet. Will heißen, dass der verwendete STMP Relay den Versand nur akzeptiert, wenn meine reale Absenderadresse hinter From: angegeben wird.

ssmtp verwendet, soweit ich verstanden habe, normalerweise die Datei /etc/ssmtp/revaliases, um dem user eine entsprechende Absender-Adresse zuzuordnen. Da steht bei mir Sinngemäß root:foo@bar.com:....
Den Versand habe ich aber bisher nur mit einem nicht-root-User per sudo probiert, vielleicht liegt`s daran. Ich lerne täglich dazu ;-)

Beste Grüße
#597 framp 2016-02-17 19:15
Moin Maui,

freut mich dass Dir raspiBackup so gut gefällt, dass Du es auch fuer Deine cubox-i benutzen willst. raspiBackup ist eigentlich auf Raspis ausgelegt. Aber Du kannst es ja mal probieren - aber atürlich auf eigene Gefahr :-)

Wenn Du -v Als Parameter mitgibst, siehst Du im log was alles an Dateien gesichert wird.

Ich sehe folgende Optionen:
1) Wenn es wirklich irgendwelche Daten sind, die nicht gesichert werden sollen kannst Du sie mit der EXCLUDE_LIST ausschliessen. Das geht bei tar und rsync.
2) Versuche mal den partitionsorientierten Modus (-P). Der sichert 100% keine externe Platten sondern nur die SD Kartenpartitionen.

Es muss aber eine SD Karte mit /dev/mmcblk0p existieren. Ansonsten kannst Du raspiBackup nicht benutzen :sad:

Cu framp
#596 maui 2016-02-17 13:17
hallo framp,

erstmal danke fürs bereitstellen des scriptes. Super Sache. Läuft auf meinen 2 Pi's gut und ein testweiser Restore hat auch geklappt.
Habe allerdings noch ein cubox-i mit Debian Jessie (armbian.com).
Prinzipiell müsste das script doch auch außerhalb vom Pi auf unix-systemen laufen oder?
Mit der cubox habe ich das Problem, dass beim Erstellen des tar-Archivs (unkomprimiert) das Archiv immer größer wird. Habe eine 8GB-Karte drin die ca. halb voll ist. Bei 80GB habe ich das Backup abgebrochen, weil unsinnig.
Komisch ist auch, dass beim Pi die foo.img nur ca 250MB groß sind und bei der cubox genau die 8GB groß sind.
Vielleicht hilft es, wenn ich von einem pi sowie dem cubox mal den output von "df -h" anhänge.
Am Pi 2 mit OSMC:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs 362M 0 362M 0% /dev
tmpfs 367M 9,6M 358M 3% /run
/dev/mmcblk0p2 29G 18G 11G 64% /
tmpfs 367M 0 367M 0% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 367M 0 367M 0% /sys/fs/cgroup
/dev/mmcblk0p1 240M 44M 197M 19% /boot
//192.168.1.150/Volume_2 3,6T 3,2T 456G 88% /media/nasv1
tmpfs 74M 0 74M 0% /run/user/1000

und bei der cubox mit debian jessie:
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.3G 3.7G 3.3G 53% /
devtmpfs 373M 0 373M 0% /dev
tmpfs 501M 0 501M 0% /dev/shm
tmpfs 501M 51M 451M 11% /run
tmpfs 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 501M 0 501M 0% /sys/fs/cgroup
//192.168.1.150/Volume_2 3.6T 3.2T 456G 88% /media/nasv1

Meine Vermutung wäre, dass bei der cubox das tar versucht, auch die nas-platte mit zu sichern.
Habe auch schon versucht, in der exclude list /media hinzuzufügen, aber das hat leider auch nicht zum Erfolg geführt.
Läuft auch kein Programm, welches permanent so große Daten erzeugen könnte.
Danke schonmal für eure/deine Hilfe
#595 framp 2016-02-15 20:56
Moin Alex,

der -E Parameter hat genau bei ssmtp keinen Effekt :sad: Das habe ich leider nicht so dokumentiert - sorry. In der nächsten Version wird aber auch -E bei ssmtp benutzt werden.

Da ich kein ssmtp benutze kann ich bei Deinem Problem nicht viel helfen. Die Befehle für ssmtp haben mir Benutzer des Scripts geholfen zu erstellen. In den Kommentaren gab es öfter mal Diskussionen zu ssmtp. Vielleicht liest Du auch da mal nach und Du findest raus was bei Dir anders ist.

Der ssmtp Aufruf im Script sieht wie folgt aus:

echo -e "To: $EMAIL\nFrom: root@$(hostname -f)\nSubject: $subject\n$content" | "$EMAIL_PROGRAM" "$EMAIL"

Da musst Du zum Testen für $EMAIL die eMailAdresse einsetzen, für $subject irgendeinen Subjecttext, für $content irgendeinen Text der in der eMail enthalten sein soll und für $EMAIL_PROGRAM ssmtp.

Ich schlage vor Du testest mal ob mit dem Befehl bei Dir eine eMail verschickt wird. Ansonsten poste doch mal den Befehl der bei Dir mit ssmtp funktioniert um eMails zu senden. Vielleicht kann ich da ja irgendwas anpassen - z.B. auch den -E Parameter mit einspielen und Dir dann eine neuere ScriptVersion zukommen lassen. :-)

Cu framp
#594 Alex 2016-02-15 07:48
Ich versuche ssmtp zum laufen zu bekommen. Beim Testen von ssmtp kann ich Mails versenden, wenn ich das Skript aufrufe, bekomme ich ein:
ssmtp: 550 5.7.1 ... AUTHID foo@bar.com not allowed for sending mails for root@osmc
unabhängig davon, ob ich die Einstellungen in der .conf eintrage oder versuche, -E zu nutzen. (... -e receiver@mail.de -s ssmtp -E "-f foo@bar.com -s smtp-server:25 -xu foo@bar.com -xp pwd")
Ich denke, es liegt an den Parametern, ich finde aber nix dazu.

Einstellung in ssmtp.conf:
root=foo@bar.com
mailhub=smtp.bar.com:465
hostname=bar.com
UseTLS=YES
AuthUser=foo@bar.com
AuthPass=pwd
FromLineOverride=YES

und in revaliases
root:foo@bar.com:smtp.bar.com:465

(wobei foo@bar.com = Absenderadresse und receiver@mail.de = Empfängeradresse)

Hat jemand eine Idee?
#593 framp 2016-02-13 12:57
Eben hat mir Balou mitgeteilt, dass seine Probleme (siehe Kommentar #580) verschwunden sind seitdem er eine neue SD Karte benutzt und kann nun erfolgreich mit raspiBackup backuppen und restoren :-)
Es ist schon wundersam was für Effekte man bei einer defekten SD Karte so alles bekommen kann :o
#592 framp 2016-02-12 18:36
Moin Herr Z,

freut mich dass Du die Ursache mit dem Log selbst gefunden hast :-)
Beim Restore gibt es bei ddz in der 0.6.1.1k Version noch ein Problem was erst in der naechsten Version gefixed sein wird. Du kannst es aber auch schnell selbst fixen. Sie dazu http://www.linux-tips-and-tricks.de/de/raspibackup-restore/#comment-1225

Cu framp
#591 Herr Z. 2016-02-12 18:04
Danke Framp - die Parameter haben mir schon geholfen. Habe mir das Logfile angeschaut und den Fehler gefunden. Er war hier: gzip -c if=...
Hatte das Image schon entpackt und jetzt den Dateinamen von ddz in dd umbenannt und jetzt wird es richtig entpackt.
Ich habe die Stelle im Skript nicht gefunden wo gzip aufgerufen wird, aber da irgendwo ist der Fehler.

Tausend Dank.
#590 framp 2016-02-12 17:44
Moin Herr Z,

das ist leider nicht schoen :cry: . Leider kann ich ohne ein Log nichts zu der Problemursache sagen. Bitte den Backup sowie den Restore mit folgenden Parametern aufrufen und mir beide Logs per eMail an meine auf der Kontaktseite genanten eMail zwecks Analyse zuschicken : -l 1 -m 1 -v.

Cu framp
#589 Herr Z. 2016-02-12 17:29
Hi Framp,

erstmal danke für das Script.
Ich habe heute das Backup auf eine andere SD-Karte wiederhergestellt, aber es hat nicht funktioniert. Das Image ist knapp 8GB groß. Wenn ich es zurückspiele ist es innerhalb einer Sekunde fertig und beendet sich mit RBK0076I: Restore erfolgreich beendet, aber es wird nichts auf der SD-Karte geschrieben.
Wenn ich es manuell mit dd zurückschreibe funktioniert es auch nicht richtig. Kann man irgendwo die Parameter einsehen? Habe einfach nur dd mit if und of benutzt.

Danke schonmal.
#588 framp 2016-02-08 20:24
Moin DeejayT,

wenn Du es direkt in die /etc/crontab reinschreibst muss es wie folgt aussehen:

30 1 * * 0 root /usr/local/bin/raspiBackup.sh -p /mnt/ipsbackup -t tar -k 2 -l 1

Oder Du benutzt

sudo crontab -e.

Dann ist kein root notwendig in der Zeile.

Cu framp
#587 DeejayT 2016-02-08 16:43
Hy framp,

ich versuche dein tolles Tool zum laufen zu bekommen.
Im crontab habe ich folgenden Befehl:
00 03 * * 0 /usr/local/bin/raspiBackup.sh -p /mnt/ipsbackup -t tar -k 2 -l 1

Ich habe diesen Befehl zum testen Nachmittags ohne die Zeitangabe ausgeführt. Dies hat ohne Probleme funktioniert. So wie ich es verstanden habe sollte dann durch crontab jeden Tag um 03Uhr ein Backup erstellt werden. Dies wurde aber nicht gemacht und das Logfile wurde auch nicht um 03Uhr geändert. Dort steht nur etwas zu meinem manuellen Backup drin.

Hast du einen Tip?
#586 framp 2016-02-07 16:45
Moin Balu,

das klingt natürlich merkwürdig dass das Backup plötzlich so gross ist :o Kann man was im Log erkennen? ANsonsten den Debuglevel mit -l 1 erhöhen, nochmal ein Backup erzeugen lassen und im Log nachsehen was passiert ist.
Falls Du nichts im Log findest schicke es mir einfach mal an meine eMail (Siehe Kontaktseite).

Cu framp
#585 Balou 2016-02-07 16:32
Mein Raspi2 läuft mit Jessie auf einer 32Gb SD, nachts läuft die Sicherung auf mein NAS. In der Crontab habe
/usr/local/bin/raspiBackup.sh -p /mnt/nas/ServerPi2/System -P -t tar -k 2 -e root -b / stehen.
Heute vormittag wundere ich mich das mein Backup auf einmal ca. 460 GB groß ist. Backup vorher ist ca 5 gb groß. Ist auch das was ich sonst haben.

Ist die SD Karte bzw das Dateisystem beschädigt? Das NAS ist laut Systembericht i.o. Heute abend muß ich mir mal die Logs von Raspi ansehen.
Script Version 0.6.1.1k
#584 framp 2016-01-28 15:27
Moin sunjammer,

das ist natuerlich dumm dass die neuere Version bei Dir nicht mehr funktioniert. Dein Problem werden wir aber schon loesen :-) . Nur muss ich das Problem dazu besser verstehen dass ich einen Fix bauen kann.

Ich schlage vor Du gehst erste einmal wieder auf die alte Version zurueck mit -V und wir klaeren alles Weitere offline.

Ein paar Fragen schon mal vorweg:
1) Welche 'alte' Version hast Du benutzt?
2) Hast Du den rsync call im Script mit --no-inc-recursive erweitert?
3) Ich vermute Du benutzt den normalen Backupmodus - nicht den partitionoriented Modus, denn der ist ja neu. Richtig?

Bitte schicke Deine Antworten an meine eMailAdresse (Siehe Kontaktseite) und wir handeln Dein Problem offline ab.

Cu framp
#583 sunjammer 2016-01-28 12:57
Hallo framp,

ich benutze nachwievor eine ältere Version von deinem Script, in dem ich bei rsync die option --no-inc-recursive mit drin hab. Ich rsynce meinen Raspi über NFS3 über mein lokales Netz.

Nach einem aktuellem Update meines Raspi (Jessie) bekomme ich beim rsyncen nun folgende Fehlermeldung:

rsync: rsync_xal_set: lsetxattr(""/mnt/backup/Pie/Pie-rsync-backup-20160127-235549/usr/bin/.systemd-detect-virt.l45NJ9"","security.capability") failed: Operation not supported (95)

Ich lese im Internet, dass das Übertragen von xattr über NFS nicht funktioniert, weil das NFS das nicht unterstützt.

Was soll ich nun machen? Hast du einen Tip? Soll ich das X aus den Optionen von rsync wegmachen? Habe ich dadurch Nachteile? Auf eine andere Backupmethode wechseln? Von NFS weggehen?
Eigentlich würde ich gerne bei dem rsync über NFS gerne bleiben. Das hat bisher immer super geklappt. Der Restore hat immer einwandfrei mit deinem Skript funktioniert.
#582 framp 2016-01-27 11:19
Moin Alex,

ich habe keine OSMC Erfahrung. Aber alle laufenden Service zu stoppen ist sicherlich overkill. Es reichen sicherlich die Services, die irgendwelche Datenbanken haben. Vielleicht hat ja ein Mitleser hier eine Empfehlung welche Services bei OSMC gestoppt werden sollten.

Cu framp
#581 framp 2016-01-24 15:44
Moin Gerald,

freut mich dass der Restore jetzt doch funktioniert. Ist ja auch gottseidank nicht mehr so kalt :lol:

Sowas ähnliches ist mir auch mal passiert: Ich hatte auch den Restore an einer anderen Raspi getestet und sie kam auch nicht hoch. Das lag aber daran, dass in der fstab noch eine Platte definiert war, die ich nicht angeschlossen hatte :cry:

Cu framp
#580 Gerald 2016-01-24 15:26
[quote name="Gerald"]von 5 raspibackup läuft bei mir nur 1 Restore korrekt, der Rest geht mit dem Raspi im Heimnetz nicht online.

Problem gelöst !! :-)
es laufen alle Restore korrekt.
Ich habe, da ich bei der Kälte draußen nicht auf eine Leiter steigen wollte, die SD-Karte auf einem anderen Raspi getestet.
Da die Mount-Eintragung in fstab hier nicht passte, kam ich (von mir unbemerkt) in den emergency mode und der Raspi ging damit nicht online.
Man kann Restore auf einem anderen Raspi testen, wenn man die Mount-Eintragung in fstab unwirksam macht.
#579 framp 2016-01-23 13:33
Eben bin ich über einen sehr hilfreichen Beitrag im Netz gestolpert, der beschreibt, wie man ein dd Image verkleinern kann, so dass es auf eine kleinere SD Karte passt. Kleine kann hier auch bedeuten, dass beide Karten - die Quell und ZielSD Karte zwar als 32 GB ausgewiesen sind - aber die ZielSDKarte doch ein paar Bytes kleiner ist.

Da ich immer mal wieder gefragt werde, wie man ein von raspiBackup erstelltes dd Backup auf kleiner SDKarten bekommt verlinke ich hier darauf.

softwarebakery.com/shrinking-images-on-linux

Hinweis: Man benötigt dazu ein Linux. Da man das alles auch mit dem nicht graphischen Tool parted vornehmen kann eignet sich also auch ein einfaches raspbian auf der Raspberry :-)
#578 framp 2016-01-23 09:58
Moin creamware,

Zitat aus der Beschreibung:
Zitat:

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.
D.h. das Script entdeckt beim Normalen Modus automatisch dass Du eine externe Rootpartition hast und sichert die sofern Du nicht den dd Backupmodus benutzt. :-)

Das Backupmedium muss dann natürlich entsprechene Kapazitaet haben um die Sicherungen des USB Sticks aufzunehmen.

Cu framp
+1 #577 creamware 2016-01-23 07:59
Hallo,
erstmal danke für das Supertool. Was mir jetzt noch fehlt, bzw. wo ich nicht weiß wie es funktioniert. Ich starte zwar von einer SD Karte, aber alle Daten sind auf einem USB Stick, da mir gesagt wurde, die halten länger als die SD Karte. Wie kann ich denn nun sichern ? es ist ja in diesem Fall das dev/sda das gesichert weden muss, und nicht die dev/mmcblk0 ??

Danke schonmal
#576 framp 2016-01-19 21:06
Moin Gary,

das ist eine interessante Messung. Ich muss gestehen, dass ich solche Vergleiche nicht vorgenommen habe, da ich mit rsync zufrieden bin. Wäre nett wenn Du uns an Deinen weiteren Messergebnissen teilhaben lassen würdest :-)

Die Dauer eines rsync ist durch mehrere Parameter bestimmt die es gilt zu berücksichtigen:

1) Das erste Backup ist ein Vollbackup und dauert länger als ein dd Backup.
2) Alle weiteren Backups müssen alle Änderungsdaten aller Dateien prüfen und das dauert auch seine Zeit
3) Alle weiteren Backups sichern nur noch die neuen Dateien und die alten werden mit Hardlinks auf die alten Daten verlinked. Dadurch belegen nur die neuen Dateien Plattenplatz.
4) Wenn die maximale Backupzahl erreicht wurde und ein altes Backup gelöscht werden muss dauert das seine Zeit.

Aus dem Log (mit -l 1 erzeugt) welches Zeitstempel hat kann man die Zeit von 1 und 2+3 sowie 4 herauslesen.

Wenn Du Probleme hast die Zeiten im Log zu finden lass mich wissen. Schicke mir dazu am besten Deine Logs mit -l 1 erstellt (erster rsync, weiterer rsync, rsync mit Löschen einer Version) an meine eMailAdress (siehe Kontaktseite) zu.

Cu framp
#575 Gary 2016-01-19 20:50
Ich möchte den partitionsorientierten RSYNC Typ für ein tägliches inkrementelles Backup sowie den DD Typ für ein monatliches Full Backup auf mein NAS verwenden. Allerdings läuft RSYNC mit 40 min wesentlich länger als DD mit nur 16 min. Ich dachte es sollte genau umgekehrt sein und rsync viel schneller sein! Das hardlinking und rotieren meiner drei daily Backupverzeichnisse funktioniert, das habe ich kontrolliert. Was habe ich übersehen?
#574 framp 2016-01-19 18:49
Moin Seb,

um die Ursache zu finden benoetige ich das Log welches beim Backup erstellt wird. Bitte erstelle das Backup noch Mal und füge die Parameter -l 1 -m 1 -v dazu. Das Log wird durch -v sehr gross. Bitte benutze zip oder tar um das Log zu verkleinern und schicke es mir an die auf der Kontaktseite angegebene eMail.

Cu framp
#573 Seb 2016-01-19 17:02
Wie muss ich meinen NFS Server einrichten damit das rsync Backup funktioniert? Ich bekomme zwar immer gesagt, dass das Backup abgeschlossen wäre, aber irgendwie wird nur die Verzeichnisstruktur gesichert. Die Ordner sind alle leer.

Gruß
Seb
#572 framp 2016-01-19 13:25
Moin Gerald,

das ist natuerlich nicht OK. Bitte schicke mir an meine eMail (Siehe Kontaktseite) das Log von einem Backuplauf (mit Parameter -l 1 -m 1) sowie dem dazugehoerigen Restorelauf (Auch mit -l 1 -m 1).

Gibt es irgendwelche offensichtlichen Unterschiede zwischen dem Backup welches Du erfolgreich restoren kannst und dem wo es nicht funktioniert?

Cu framp
#571 Gerald 2016-01-19 11:22
von 5 raspibackup läuft bei mir nur 1 Restore korrekt, der Rest geht mit dem Raspi im Heimnetz nicht online.
Ich starte sudo /usr/local/bin/raspiBackup.sh -p /media/nas per Putty und bekomme auf der NAS auch anscheinend korrekte Images (zumindestens stimmt die Größe).
Beim Backup läuft kein Dienst und auch die Programme sind nicht gestartet.
Was läuft verkehrt?
#570 Hans-Werner 2016-01-15 19:34
Vielen Dank,
meine Version ist 0.5.14.8, 2015-03-27/18:07:23.
Danke für deine Mühen, werde ich so machen!

cu Hans-Werner
#569 framp 2016-01-15 19:06
Moin Hans Werner,

eben wollte ich das Upgradescript schreiben und habe dabei festgestellt, dass ich damals bei der Erstellung des Installationsscripts schon für den UpgradeFall vorgesorgt habe: Es wird bereits automatisch ein Backup des existierenden raspiBackups sowie der Config vorgenommen :-)

Kurzum: Einfach das aktuelle Installationsscript benutzen und dann die Configdateien mit den alten Werten anpassen .

Cu framp
#568 framp 2016-01-15 18:44
Moin Hans Werner,

Du musst raspiBackup.sh -h eingeben. Dann bekommst Du die aktuelle Version am Anfang des Hilfetextes angezeigt.

Wenn es mit 0.5 beginnt ist es die alte Version, die nicht mehr gepflegt wird. Die Option -U funktioniert leider nicht, da es keinen Update der 0.5er Version mehr gibt.

D.h. Du musst Dir die neue 0.6er Version neu mit der Config installieren wie auf der Webseite beschrieben wird. Vorher solltest Du Deine raspiBackup.conf sichern damit Du Deine alten Parameter in die neue Config einpflegen kannst. Ich würde mir auch die alte raspiBackup Scriptversion sichern (in raspiBackup.x.x.x.sh umbenennen wobei x.x.x die Scriptversion des Script ist).

Ich muss zu meiner Schande gestehen, dass ich für den Upgrade von 0.5 auf 0.6 nicht daran gedacht habe ein Upgradescript zu erstellen :oops: . Wenn Du es möchtest kann ich ein UpgradeScript für Dich erstellen

Cu framp
#567 Hans-Werner 2016-01-15 18:19
Hallo,
ich habe raspibackup schon länger im Einsatz.
weiß aber nicht welche Version genau irgend etwas mit 0.5.x
glaube ich.

Wie kann ich genau feststellen welche Version ich habe und kann ich auch bei o einer alten Version die neueste nach Anleitung installieren
#566 framp 2016-01-14 10:34
Moin BaLLi,

raspiBackup hat dann eine Fehlermeldung geschrieben die Du vom Cron bekommen haben solltest. Aber es ist richtig, dass dann keine eMail geschrieben wird. D.h. Du kannst durch das Fehlen der eMail vom erfolgreichen Backup schliessen, dass da was schiefgelaufen ist. Das ist aber zugegebenermassen nicht sehr schoen. Ich nehme Deine Anregung auf und werde in einer der naechsten Versionen auch Fehlermeldungen die beim Start bzw der Verifizierung von Parameters von raspiBackup erstellt werden per eMail versenden lassen.

Cu framp
#565 framp 2016-01-14 10:28
Moin Fred,

es muss 0 oder 1 sein. 0 = false/nein und 1 =true/ja. ich nehme Deinen Kommentar zum Anlass das besser zu dokumentieren.

Cu framp
#564 BaLLi 2016-01-14 07:44
Hallo, ich mal wieder.
Ich wollte nur eine kurze Frage stellen. Ich habe mein Backup jetzt mehrere Tage nicht mehr kontrolliert. Heute ist mir aufgefallen, dass mein Backuppunkt (Mount von meinem NAS) nicht gemountet war und deshalb kein Backup erstellt werden konnte. Kann bei solchen Fehlern nicht auch eine eMail mit dem Fehler gesendet werden?

Gruß
#563 Fred 2016-01-13 23:42
Wenn ich DEFAULT_PARTITIONBASED_BACKUP nutze, wie ist der Wert in der .conf ?
0 oder 1
yes oder no
also DEFAULT_PARTITIONBASED_BACKUP="yes" ?
#562 framp 2016-01-13 18:50
Achtung !!!

Ich weise noch einmal dringend darauf hin, dass Benutzer von raspiBackup, die die Version 0.6.1.1h mit dem Backuptyp dd oder ddz benutzen sofort auf die aktuelle Version 0.6.1.1k upgraden müssen. Leider hat sich bei der h Version ein böser Bug eingeschlichen, der alle bereits existierenden dd und ddz Backups löscht sowie auch den eben gerade neu erstellten Backup. Somit werden keine Backups mehr erstellt obwohl die eMail dummerweise einen erfolgreichen Backup meldet :((( .

Sorry for the inconvenience

Cu framp
#561 framp 2016-01-05 19:52
Moin Siggi,

Dein Problem ist in einem Problem im Fake Modus begründet :sad:

Es gibt folgende Möglichkeiten das zu lösen:

1) Du gibst bei -T all Deine Partitionsnummern an die zu sichern sind und benutzt -F
2) Du lässt -F weg. Dann wird allerdings wirklich ein Backup von allen Partitionen gezogen
3) Du benutzt die geänderte Version, die ich für Dich erstellt habe und Dir per email zuschicken werde. Ist allerdings ungetestet und es könnte sein dass es immer noch Probleme gibt. Wäre nett wenn Du - auch wenn Du den Weg (1) oder (2) gehst, das mal ausprobierst und mich wissen lässt, ob es jetzt funktioniert mit -F und -P damit ich das fixen kann. Leider habe ich beim Design der -P Option den -F Parameter völlig vergessen zu berücksichtigen

Cu framp
#560 Siggi 2016-01-05 19:44
Hallo Framp,

finde ich das Super das Du Dein Script hier allen zur Verfügung stellst. Habe genau so was gesucht. Leider läufts bei mir noch nicht ganz rund und vielleicht kannst du mir helfen.

raspiBackup.sh hab ich nach Deiner Anleitung hier auf dieser Seite installiert. Ich habe einen BananaPro mit bananian-15.04. als Betriebssystem. Als Bootloader nutze ich Berryboot 2.0.

Zum Austesten verwende ich raspiBackupWrapper.sh. Am Banana hängt ein USB-Stick den ich manuell mounte und der mit ext4 formatiert ist. Der Aufruf im Wrapperscript fürs Backup lautet:
raspiBackup.sh -p $BACKUP_PATH -F -P -T "1"

Wenn ich raspiBackupWrapper.sh aufrufe erhalte ich folgende Ausgabe:
root@BananaPro ~ # raspiBackupWrapper.sh
--- /mnt/mmb1 already mounted
[ ok ] Stopping MySQL database server: mysqld.
[ ok ] Stopping NTP server: ntpd.
[ ok ] Stopping OpenBSD Secure Shell server: sshd.
Stopping nginx: nginx.
--- RBK0009I: BananaPro: raspiBackup.sh V0.6.1.1k um Di 5. Jan 19:19:28 CET 2016 gestartet
--- RBK0128I: Logdatei ist /root/raspiBackup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
!!! RBK0124W: Simulationsmodus an
df: „/squashfs“: Datei oder Verzeichnis nicht gefunden
/usr/local/bin/raspiBackup.sh: Zeile 2968: : Datei oder Verzeichnis nicht gefunden
grep: : Datei oder Verzeichnis nicht gefunden
/usr/local/bin/raspiBackup.sh: Zeile 2968: : Datei oder Verzeichnis nicht gefunden
grep: : Datei oder Verzeichnis nicht gefunden
!!! RBK0108W: Unformatierte Partition mmcblk0p1 () wird nicht gesichert
--- RBK0010I: BananaPro: raspiBackup.sh V0.6.1.1k um Di 5. Jan 19:19:30 CET 2016 beendet
--- RBK0017I: Backup erfolgreich beendet
??? RBK0043E: Unvollständiges Backup /mnt/mmb1/BananaPro/BananaPro-dd-backup-20160105-191927 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
Starting nginx: nginx.
[ ok ] Starting OpenBSD Secure Shell server: sshd.
[ ok ] Starting NTP server: ntpd.
[ ok ] Starting MySQL database server: mysqld . ..
[info] Checking for tables which need an upgrade, are corrupt or were
not closed cleanly..

Ich hoffe du kannst mir weiterhelfen und vielen Dank schon mal im voraus

Gruß Siggi
#559 framp 2015-12-28 19:56
Aus gegebenem Anlass wird ab sofort keine Änderung ausser dringender Bugfixes in raspiBackup mehr vorgenommen werden bis die bislang existierenden Regressiontests so erweitert wurden und wesentlich mehr Testszenarien durchlaufen werden, so dass eine große Testabdeckung zukünftig sicherstellt, dass ein wie in der Version 0.6.1.1h eingebaute Fehler beim Regressiontest zukünftig entdeckt werden wird.
#558 framp 2015-12-28 19:23
Achtung ! Achtung ! Achtung !

Alle Benutzer der Version 0.6.1.1h die den Backuptyp dd oder ddz benutzen müssen sofort auf die aktuelle Version 0.6.1.1j upgraden. Leider hat sich bei der h Version ein böser Bug eingeschlichen, der alle bereits existierenden dd und ddz Backups löscht sowie auch den eben gerade neu erstellten Backup. Somit werden keine Backups mehr erstellt obwohl die eMail dummerweise einen erfolgreichen Backup meldet :((( .

Sorry for the inconvenience

Cu framp
#557 framp 2015-12-19 16:01
Jens hatte in Kommentar #549 einen Fehler reported. Den Fix, den ich ihm daraufhin geschickt habe hat er heute als erfolgreich verifiziert gemeldt.
D.h. es wird noch einmal eine neue Version geben :-) . Diese räumt dann alle Bootbackups ab, die kein zugehöriges Rootbackup haben.

Noch einmal vielen Dank an Jens für seinen Test.
#556 framp 2015-12-15 23:16
Eben habe ich noch mal den Kompatibiltätsmodus zu 0.6.1.1. der Allgemeinheit bereitgestellt.

Wer damit ein Backup welches pre 0.6.1.1 erstellt wurde mit der aktuellen Version restored muss die Dateien nicht mehr kopieren. Diese werden nun automatisch benutzt wenn keine post 0.6.1.1 BootBackupDateien existieren.

Der Fix steht schon seit längerem zur Verfügung und eigentlich wollte ich noch die Verifikation von Nea abwarten. Leider erfolgte da keine zeitnah :sad:

Somit habe ich den Fix jetzt nach nochmaligem erfolgreichem lokalem Test published .
#555 framp 2015-12-15 18:45
Moin jens,

vielen Dank für Deinen Fehlerreport.

In Kommentar #527 hat BaLLi wie ich es bei Dir verstehe dasselbe berichtet. Das habe ich in der Version 0.6.1.1c gefixed und getestet und BaLLi hat es auch verifiziert.

Ohne ein Logfile kann ich leider nicht untersuchen warum das trotzdem bei Dir noch passiert. Bitte benutze beim nächsten Backuplauf die Parameter -l 1 -m 1 und schicke mir die Datei raspiBackup.log an meine auf der Kontaktseite genannten email Adresse.

Cu framp
#554 jens 2015-12-15 07:04
Hallo framp,

also mit der aktuellen Version deines Programms werden bei mir die mbr, img und sfdisk Dateien NICHT gelöscht sondern immer nur neue dazugeschrieben. Während die tar Dateien gelöscht werden. Ich habe eigentlich hier über die config eingestellt, das nur 3 Backups zurückbleiben sollen.
Wie gesagt das funktioniert mit den tar Dateien auch.
gruß
Jens
#553 framp 2015-12-13 13:54
Moin Kurt,

rsync benutzt Hardlinks um Backups effizient zu erstellen. Diese werden nur von ext3/ext4 unterstützt. Ich sehe folgende Alternativen für Dich:

1) Du exportierst per nfs Server von Deiner NAS ein ext3/ext4 Laufwerk und mountest es per nfs auf Deine Raspi
2) Du benutzt ein tar Backup.

PS: Zeigt sich, dass dieser Schutz vor unbeabsichtigtem Erstellen eines Backups auf der SD Karte durchaus nützlich ist, denn ansonsten hättest Du Dein Backup auf der SD Karte erstellt (Die ist ja ext4 formatiert) und vermutlich wäre Deine Raspi dann irgendwann einfach stehengeblieben weil die SD Karte voll ist. Ist mir beim Testen auch passiert :oops: - und daraufhin habe ich diesen Test in raspiBackup eingebaut.

Cu framp
#552 Kurt 2015-12-13 11:10
Hallo framp,

das NAS war wohl nicht gemounted. Nach mount kommt trotzdem die Fehlermeldung, dass das Dateisystem des rsync Verzeichnisses /media/networkshare/... entweder ext3 oder ext4 sein muss. Derzeit ist es cifs. Geht das nicht mit rsync?

Kurt
#551 framp 2015-12-12 18:01
Moin Kurt,

das kann zwei Gründe haben:

1) Der Parameter -p spezifiziert kein gemountetes Gerät sondern ein lokales Verzeichnis
2) Der Mountpoint liegt lokal auf der SD Karte

Zu 1: Das kann man mit dem Befehl mount prüfen und korrigieren
Zu 2: Das dient dazu zu verhindern, dass man sich aus Versehen seine SD Karte mit dem Backup vollschreibt. Wenn Du sicher bist dass Deine SD Karte noch genügend Platz hat und das Backup aufnehmen kann kannst Du den Parameter -c zufügen und wirst die Meldung nicht mehr bekommen. Ob es Sinn macht das Backup auf der SD Karte abzulegen musst Du entscheiden.

Cu framp
#550 framp 2015-12-12 17:30
Moin Nea,

zitiere Nea:
...Der Parameter -V steht der allein, oder muss hier noch etwas stehen?...


Nein. Es reicht der Parameter -V. Allerdings siehst Du nur alte Versionen, die Du vorher mit -U aktualisiert hast.

BTW: Deinen Kommentar nehme ich zum Anlass noch einen Fallback auf das alte Format einzubauen. D.h., wenn es zu einem Backup keine Bootbackups mit Datum gibt wird das Bootbackup ohne Datum genommen. Eine Warnungsmeldung wird darauf hinweisen, denn dadurch könnte ja ein boot&root Pärchen zusammengefügt werden, was nicht zueinander passt.

Cu framp
#549 Kurt 2015-12-12 16:29
Hallo framp,

ich habe heute ein versucht, ein NAS als backup medium zu verwenden (steht als device in fstab). Das backup (zuvor mit -U aktualisiert) bricht ab mit RBK0027E. Ich sehe aber, dass das script einen backup folder angelegt hat.

Was passt denn da nicht?

Grüße
Kurt
#548 Nea 2015-12-12 14:00
Danke,
dachte ich mir schon aber daran soll es nicht scheitern.

Der Parameter -V steht der allein, oder muss hier noch etwas stehen?
Danke
#547 framp 2015-12-12 13:51
Moin Nea,

wie ich in Kommentar 518 geschrieben habe gab es ein Problem mit der bootpartition und seitdem wird immer ein backup der bootpartition erstellt. D.h. dass die Dateien .sfdisk, .mbr und .img immer den Zeitstempel des Backups der rootpartition bekommen.

Leider habe ich keinen guten Weg gefunden wie ich die alten bootbackups zu den rootbackups korrelieren kann. :sad:

D.h. Du musst leider die Korrelation manuell vornehmen indem Du die 3 Dateien kopierst und ihnen dabei den Zeitstempel des Backups, welches Du restoren willst, gibst.

Beispiel:
Dein Backup heisst raspberrypi-rsync-backup-20151124-211358
Dann muessen Deine Kopien der drei Dateien wie folgt heissen:

raspberrypi-backup-20151124-211358.img
raspberrypi-backup-20151124-211358.mbr
raspberrypi-backup-20151124-211358.sfdisk

Eine andere Alternative ist, dass Du mit dem Parameter -V eine ältere Version von raspiBackup die älter ist als 0.6.1.1 wieder aktivierst, also z.B. 0.6.1 oder noch älter.

Cu framp
#546 Nea 2015-12-12 13:38
Danke für deine Hilfe.
Das Paket habe ich nach installiert. Bekomme aber eine Fehlermeldung:
.....sfdisk nicht gefunden
Diese Datei ist vorhanden:
raspberrypi-backup.sfdisk

Ist diese nicht mehr kompatibel?
#545 framp 2015-12-12 11:58
Moin Nea,

die Option -X brauchst Du nicht mehr in der aktuellen Version angeben (Siehe restore Seite und die Beschreibung der Parameter :-) )

Die Meldung 131E sagt, dass Du bc installieren musst:
1) sudo apt-get update
2) sudo apt-get install bc

Danach wird der Restore funtkionieren.

Cu framp
#544 Nea 2015-12-12 10:41
Guten Morgen,
Ich habe hier 2 Fehlermeldungen:
Aufruf ist dieser:
sudo raspiBackup.sh -X -d /dev/sda -r /backup.....
Fehlermeldung:
??? RBK0089E: Unbekannte Aufrufoption -X
Mit einem kleinem x geht es, was mich aber zum 2. Fehler bringt.
Aufruf:
sudo raspiBackup.sh -x -d /dev/sda -r /backup......
Meldung:
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.1.1e um Sa 12. Dez 10:21:57 CET 2015 gestartet
--- RBK0128I: Logdatei ist /home/pi/raspiBackup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
??? RBK0131E: Programm bc nicht gefunden. Paket bc nicht installiert

Kannst du mir bitte noch einmal helfen, Danke.

Ich weiss aber das es vorher ging da ich so schon mehrere Backups zurück gespielt hatte.
Gruß Nea
#543 framp 2015-12-10 22:23
Moin BaLLi,

ich komme auf Dein Angebot zurück :-)

Die Messlatte liegt hoch. Sigi hat das Beta 0.6 perfekt getestet !

Cu framp
#542 BaLLi 2015-12-10 22:01
Also prinzipiell bin ich für jede Schandtat bereit :) Falls ich hier oder da mal was ausprobieren soll, sag bescheid :) Dann lass ich mal ein Backup laufen und schick dir das Log :)
#541 framp 2015-12-10 20:16
Moin BaLLi,

wenn Du oben Dir die Beispielverzeichnisstruktur für beide Backuptypen ansiehst wirst Du sehen, dass das bei dem partitionsorientierten Backup fast wie Du es wünschst angelegt wird. Nur das Log wird nicht im Unterverzeichnis abgelegt.

Beim alten normalen Backup ist das historisch begründet: Mir was es damals als ich raspiBackup für mich schrieb übersichtlich genug. Du hast allerdings recht, dass es jetzt mit der Änderung, dass auch immer die Bootpartition gesichert wird, schon unübersichtlicher geworden ist.

Ich nehme Deinen Vorschlag auf und werden das mir vormerken. Da das aber eine Änderung ist, die gut getestet werden muss, und ich erst einmal mit raspiBackup Tests nach der neuen Release 0.6 genug habe wie auch die aktuelle Version wieder stabiler werden muss, wird das etwas dauern. Wenn Du bei dem Test dazu helfen würdest würde es natürlich schneller gehen :-*

Alternativ könntest Du auf den partitionsorientierten Backupmodus umsteigen. Das geht aber nur wenn Du keine externe Rootpartition hast.

Cu framp
#540 BaLLi 2015-12-10 12:28
Hey, ich mal wieder :) Heute ohne Bugmeldung und nur mit einer Nachfrage:
Wie steht es denn um die Möglichkeit, die Backups (Root und Bootbackup und evtl. log) in einem eigenen Ordner mit Timestamp, wie bei den Dateien, zu legen?! So ist es noch übersichtlicher :)

Gruß
#539 framp 2015-12-02 22:35
Anhand der Logs von BaLLi fand ich den Bug und die neueste verfügbare Version enthält jetzt auch den Fix dafür :-*

Vielen Dank an BaLLi, der den Bug reportet hat und heute Abend mit den Logs und Tests half das Problem zu lokalisieren und zu fixen.

Wie BaLLi schon berichtet hat hat der Bug leider doch alte ungenutzte Bootpartitionsbackups stehen lassen. Diese werden nun mit dem Fix alle gelöscht.
#538 BaLLi 2015-12-02 11:35
Ja, bitte melde dich bei mir. Habe es gerade eben noch einmal mit der Antwortfunktion auf die "Auto-eMail" wegen des Kommentars versucht aber bekomme den selben Fehler.

Gruß
#537 framp 2015-12-02 11:01
Moin BaLLi,

das ist so beabsichtigt dass ab der Version 0.6.1.1 immer ein Datum beim Bootbackup steht damit dann das Backup immer konsistent ist.

Ja, bitte schicke mir das Log zu. Wg der Fehlermeldung: Offensichtlich hast Du nicht die richtige eMailAdresse genommen. Sie ist bewusst nicht ganz leicht zu erkennen um Spam zu vermeiden. Sieh sie Dir bitte noch mal genau an. Im Prinzip kann man die emailAdresse auch erraten wenn man sich den Header dieser Webseite ansieht :-)

Falls es nicht klappen sollte melde ich mich dann heute Abend per eMail offline bei Dir.

Cu framp
#536 BaLLi 2015-12-02 09:17
Leider habe ich gerade nach dem Senden der eMail an dich folgende Antwort von deinem MX bekommen:
Betreff: Mail delivery failed: returning message to sender
"...
mailbox unavailable
550 invalid DNS MX or A/AAAA resource record
..."
#535 BaLLi 2015-12-02 09:11
Hi framp

Danke für deine schnelle Antwort.
Ich gönne mir eben den Spaß und habe mein Backupordner durch das Script komplett neu anlegen lassen und mache nun mehrere Backups. Das erste was mir aufgefallen ist, er legt kein Bootbackup ohne Zeitstempel mehr an. Keine Ahnung ob das so gewollt ist :-) Zum anderen habe ich gerade 4 Backups gemacht, 2 soll er vorhalten, was auch super funktioniert. Nur die Logs bzw. das Bootbackup der 2 ältesten sind immernoch vorhanden.
Das Log was du dir wünscht ist von meinem fünften Backup und hoffe du kannst was damit anfangen.
#534 framp 2015-12-01 22:58
Den Beitrag 528 habe ich eben korrigiert da dort ein paar Typos bzgl Boot und Root drin waren :oops:
#533 framp 2015-12-01 17:23
Moin BaLLi,

nachdem ich das umgestellt habe dass bei jedem Backup auch die Bootpartition gesichert wird bekommt jedes Bootbackup einen Zeitstempel und ist damit dem Rootbackup zuortbar. Dann habe ich natuerlich auch Code eingebaut, der am prueft, ob es Bootbackups gibt die keine RootBackupverzeichnisse bzw -dateien mehr haben weil sie zwischenzeitlich geloescht wurden da das Backuplimit ueberschritten wurde.

Das Bootbackup ohne Datum wird allerdings niemals geloescht, denn es ist leider nicht moeglich festzustellen ob es noch dazugehoerige RootBackups gibt, da der Zeitstempel fehlt.

D.h. Du solltest immer maximal einen BootBackup mehr haben (den ohne Zeitstempel) als das Du RootBackups hast. Wenn Du z.B. schon 30 Backups vor dem Fix erstellt hast wirst Du feststellen, dass nach und nach immer neue Bootbackups entstehen werden fuer neue Backups. Am Ende wenn nur noch Backups der neuen Version existieren solltest Du dann 30 Bootbackups und 30 Rootbackups haben und ein Bootbackup ohne Zeitstempel.

Wenn Du tatsaechlich aber mehr Bootbackups bekommen solltest dann gibt es noch ein Problem beim Aufraeumcode. Bitte lass dann einen Backuplauf mit den Parametern -m 1 -l 1 -v -L 3 laufen und schicke mir das Log an die auf der Kontaktseite genannten EmailAdresse damit ich Problemanalyse betreiben und einen Fix erstellen kann.

Cu framp
#532 BaLLi 2015-12-01 07:30
Erst einmal Danke für diese Klasse Arbeit. Jedoch nach dem neuen Update sichert das Script zwar Root- und Bootpartition, doch bei der Bootpartiton werden immer neue Backups angelegt. Zählt denn nicht der selbe Parameter um beispielsweise nur 2 Backups vorzuhalten?
Hoffe hab mich jetzt nicht zu missverständlich ausgedrückt ;)
#531 framp 2015-11-29 13:57
Vielen Dank strawmeas für die ausführliche Beschreibung.

Ich nehme Dein AnwendungsSzenario auf und werde mir überlegen wie man die sfdisk Datei komfortabel ändern kann, so dass man nicht mehr diese starre Einschränkung hat, dass die ZielKarte wenigstens so gross sein muss wie die Quellkarte und die ZielPartitionen auch kleiner sein dürfen als die Quellpartitionen.

Die Funktion wird in einer der nächsten Versionen verfügbar sein.
#530 strawmeas 2015-11-29 13:28
Hallo,

vor ein paar Tagen hatte ich hier ein Problem beim partitionsorientierten Backup einer 16-GB-SD-Karte FÜR ein Restore auf eine 8 GB-Karte gepostet. Grundidee war, auf der 16GB-Karte die Root-Partition so zu verkleinern, dass sie dann beim Restore auf eine 8 GB-Karte passt. Das kann man z.B. mit gparted bewerkstelligen, aber auch Lösungen auf der Kommandozeile findet man im Netz.

Nachdem ich ein partitionsorientiertes Backup erstellt hatte, ergab sich allerdings dann beim Wiederherstellen, das Problem, dass raspiBackup in jedem Fall versucht, die Karte so wiederherzustellen, wie sie gesichert worden ist, d.h. über die gesamte Größe der Ursprungs-Karte. Glücklicherweise habe ich aber auf Anfrage hier auf der Website einen Hinweis erhalten, wie man sich behelfen kann. Im Ordner der Sicherung findet sich eine Datei mit der Endung *.fdisk. Dort stehen in der 1. Zeile Angaben zur Größe der Karte. Hier mal beispielhaft meine Angaben:
Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors

Die Werte für Bytes und Sektoren müssen nun so angepasst werden, dass sie zu der Root-Partition der Ursprungskarte passen, zumindest aber nicht die Größe der Ziel-Karten überschreiten.

Bei mir also z.B.:
Disk /dev/mmcblk0: 7.4 GiB, 7948206080 bytes, 15523840 sectors

Dann funktioniert das mit dem Erstellen auf der kleineren Zielkarte.

Gruß
strawmeas
#529 framp 2015-11-26 23:12
Moin Rene,

das ist merkwürdig :sad: . Du kannst ja mit dem Parameter -V wieder auf die vorherige Version zurückgehen.

Ich sehe mir das morgen mal an.

Vielleicht kannst Du vorher noch mal den Backup mit -l 1 -L 3 -m 1 -v aufrufen und mir das Log an die auf der Kontaktseite genannteneMail Adresse schicken.

Cu framp
#528 René Hillebrand 2015-11-26 22:46
Hi framp,

seit dem Update auf 0.6.1.1 klappt ssmtp nicht mehr:
ssmtp: recipients with -t option not supported
Bei 0.6.1b ging es noch?!?!

Besten Dank & Grüße

René
#527 framp 2015-11-25 21:08
Ab sofort sichert die Version 0.6.1.1 bei jedem Backup die Bootpartition und damit können die Boot- und Rootpartition nicht mehr auseinanderlaufen bei Kernelupdates. Es wird dringend empfohlen auf diese Version zu updaten.
#526 Backup exit RC 106 2015-11-25 12:45
Danke für die rasche Antwort, framp.
Ja, den Fehler RBK0047E hatte ich auch.
Zum Abbruch hat ein nicht vorhandener service nfs-kernel-server geführt. Nachdem der Eintrag aus der Liste der services entfernt war, lief das backup vollständig (ohne Optionen) durch.

Werde jetzt als nächstes ein restore ausprobieren.

Vielen Dank
Kurt
#525 framp 2015-11-24 22:58
Moin Backup exit RC 016 :lol: .. netter Nick

Du solltest noch eine Meldung
RBK0047E: Ein Fehler trat beim Starten von Services auf
bekommen haben.

Hast Du nicht bekommen? Dann lasse bitte den Backup noch mal mit den Parametern -l 1 -L 3 - m 1 -v laufen und schicke mir das Log an die auf der Kontaktseite genannten email.

Ansonsten sagt die Meldung, dass irgendwas beim Starten der Services nach dem Backup schief gelaufen ist. Ich vermute Du benutzt den -a Parameter dazu.

Rufe doch mal als root die Befehle auf, die Du beim Parameter -a mitgegeben hast. Dort wird sicherlich irgendein Fehler berichtet werden. Den musst Du beseitigen und dann wird der Backup durchlaufen.

Cu framp
#524 Backup exit RC 106 2015-11-24 22:38
Hallo,

ich habe heute (zum ersten mal) ein backup mit dem raspiBackup.sh script versucht. Das backup wurde zunächst beendet, führte dann aber zum einem Abbruch rc 106. Eine log Datei ist verfügbar.

Was kann die Ursache sein?

Kurt
#523 framp 2015-11-22 17:27


Achtung ! Achtung ! Achtung !

Dringender Hinweis an alle Benutzer von raspiBackup, die ein tar oder rsync Backup erstellen und ihr raspbian Image irgendwann von dem 3er kernel auf den 4er Kernel upgraded haben. Benutzer vom dd Backup sind nicht betroffen.

Wie findet man raus ob man den 4er Kernel benutzt?

pi@raspifix ~ $ uname -a
Linux raspifix.framp.de 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux

Wer nach dem Upgrade nicht die existierenden img, mbr und sfdisk Dateien umbenannt hat um sie für den 3er Kernel zu sichern und dadurch beim nächsten Backup automatisch der neue 4er Kernel gesichert wird, wird wie ich heute feststellen, dass ein restortes Backup welches eigentlich mit dem 4er Kernel läuft, dann aber leider noch immer mit dem 3er Kernel läuft :cry: . Ich habe das festgestellt, weil der nfs Server plötzlich nicht mehr gestartet werden konnte, da angeblich der Kernel kein nfs unterstützt.

Jeder, der vom 3er Kernel auf den 4er kernel upgradet hat, sollte dringend in seinem Backup die Dateien mit der Endung .img, .mbr und .sfdisk ind .img.3, .mbr.3 und .sfdisk.3 umbenennen (nicht kopieren!) und einen neuen Backuplauf mit raspiBackup starten um diese Dateien neu erstellen zu lassen so dass sie den 4er Kernel beinhalten.

Das Script wird entsprechend geändert werden, dass es zukünftig zu jedem Backup die 3 Dateien erstellt so dass das nicht mehr passieren kann, dass die Bootpartition und die Rootpartition auseinanderlaufen. In dem neuen partitionsorientierten Modus mit dem Parameter -P ist das schon implementiert. Die Änderung wird ein wenig dauern, da sie etwas umfangreicher ist und gut getestet werden muss.

Dieser Fehler ist mir sehr unangenehm :oops: und ich denke und hoffe dass meine Warnung noch rechtzeitig kommt um böse Überaschungen beim restore des 4er Kernels zu vermeiden, denn bislang hat noch niemand hier von diesem Fehler berichtet.

Sollte jemand anhand meiner obigen Beschreibung nicht genau wissen was zu tun ist - einfach hier fragen und ich werde entsprechend helfen.

Sorry for the inconvenience
framp :sad:
#522 framp 2015-11-16 23:09
Moin Rene,

ja so ist es. Details dazu habe ich hier beschrieben.

Am Besten die aktuelle /usr/local/etc/raspiBackup.conf sichern, das Installerscript runterladen und aufrufen. Damit wird die neue Release installiert. Danach die gesicherte Config wieder zurückkopieren und testen ob noch alles funktioniert wie vorher. :-)

Sollte es auch - aber da es so viele Änderungen in der neuen Release gibt ist es wichtig noch mal alles zu prüfen. Das sollte man ja sowieso immer mal wieder machen :roll:

Cu framp
#521 René Hillebrand 2015-11-16 22:52
Hi framp,

mit Parameter -U kommt man von 0.5.15.9 nicht auf 0.6.1 - aber das hängt wohl mit den abgeschnittenen Zöpfen zusammen, oder?

Grüße

René
#520 framp 2015-11-15 23:00
Tom hat Logs per eMail zugeschickt und es zeigte sich, dass zwei Bugs im Script im neuen Modus mit -P vorliegen, die sich unter gewissen Randbedingungen auswirken.

Diese sind gefixed (Dank an Tom für den Test des Fixes) und eine neue Version des Scripts ist ab sofort zum Download verfügbar.
#519 framp 2015-11-15 10:19
Moin Tom,

es freut mich dass Du die Release 0.6 mit der neuen Funktion -P benutzen willst :-) . Dass es Probleme gibt freut mich weniger :sad: Ohne Logs kann ich leider nicht helfen. Bitte lass mit den Parametern -l 1 -m 1 -v -L 3 ein Log im aktuellen Verzeichnis erstellen und schicke es mir an die auf der Kontaktseite angegebene eMail zu. Ich sehe es mir dann an und werde Dich offline kontaktieren.

Cu framp
#518 Tom 2015-11-14 16:14
Erstmal vielen Dank für die großartige Arbeit.
Ich habe heute die 0.6.1 getestet.
Ich habe das Raspbian mit Noobs installiert, deshalb war ich sehr gespannt auf den -P Parameter.
Erstes Problem hatte ich Partition 1. Die RecoveryPartition von Noobs. Dies kann das Script nicht sichern, weil es anscheinend ntfs ist. Unter Fdisk steht allerdings FAT16. Nagut, habe die Partition dann ausgenommen und nochmal gestartet.
Das Backup wird als gezipptes TAR erstellt.
Es wurden alle Partitionen gesichert.
Nach dem Backup hatte ich aber ein Problem. Es wurde die letzte Partition umounted, allerdings nicht wieder gemounted. Woran liegt das?
Auf der Partiton läuft mein Mailserver mit dovecot, deshalb konnte am ende auch keine mail versendet werden.
Muss eventuell vorher der service postfix und dovecot beendet werden?
Danke
Ich versuche spätr nochmal ein backup mit debug schalter, vielleicht sieht man da mehr
#517 framp 2015-11-11 21:31
Heute habe ich die neue Release 0.6.1 online gestellt. Details dazu finden sich hier.

Cu framp
#516 framp 2015-11-11 19:10
Moin serioustk,

prinzipiell geht das, aber da auch der Restore wieder die Teile zusammenfügen muss ist das Aufwand, den ich nicht spendieren will - zumal ich die letzte Zeit ziemlich an der neuen Release 0.6 gearbeitet habe und noch arbeite.

Ich sehe zwei Alternativen für Dich:

1) Du benutzt ein tar Backup gezipped. Dort wird im Gegensatz zum dd nur wirklich das gesichert was belegt ist. D.h. Deine z.B. 16GB SD Karte belegt beim dd immer 16GB brutto - und irgendwas dann netto gezipped. Dein tgz Backup wird nur das enthalten was wirklich an Daten vorliegt und wird vermutlich kleiner sein. Das musst Du einfach mal ausprobieren. Der Nachteil ist natürlich, dass es dann irgendwann doch wieder Probleme geben kann wenn Du immer mehr Daten auf Deiner SD Karte sammelst.

2) Du benutzt das Wrapperscript von mir und sicherst erst einmal temporär auf irgendein lokales Medium, und splittest es nach dem Backup und kopierst die Teile dann auf Dein davfs.

Cu framp
#515 serioustk 2015-11-11 14:32
Moin,
erst einmal: super Skript, vielen Dank!

Eine Frage: besteht die Möglichkeit, die Backups bei oder Option -ddz in mehrere Teilarchive aufzuteilen?

Ich nutze ein Webdav Mount mit davfs zur Sicherung. Das Programm wartet leider, bis eine Datei zu ende geschrieben ist, bevor diese übertragen wird. Da ich die gesamte Karte sichern möchte, läuft mir dabei immer der Speicher voll, ein Backup bekomme ich aber nicht hin...
#514 framp 2015-11-01 20:57
Moin Felicitas,

Das ist auch möglich mit raspiBackup :-)

Die /usr/local/etc/raspiBackup.conf definiert die Standarddefinitionen. Wenn Du dort als Backuptyp tar definierst kannst Du in dem monatlichen cron Aufruf mit -t dd das überscheiben. Der -k Parameter bezieht sich auf das Backupverzeichnis. D.h Du musst dann auch den -p Parameter ändern. Also -k 4 in der Konfig und -k 12 beim -t dd Aufruf um den Stand eines Jahres zu sichern.

Cu framp
#513 Felicitas 2015-11-01 20:09
Kann man dem Script mehrere unterschiedliche Konfigdateien unterjubeln?
Würde gerne bspw. wöchentlich mit tar sichern und monatlich mit dd.

Grüße und Danke für dieses großartige Projekt!
#512 framp 2015-10-09 12:33
Moin Christian,

es gab jemanden der keine bash installiert hatte und kryptische Fehler bekam. Dagegen sollte der Test schuetzen. Den Test habe ich eben auskommentiert . Da es keine neue Versionsnummer hat must Du den neuen Code manuell runterladen. -U funktioniert nicht.

Ich werde Dich offline kontaktieren um rauszufinden warum der Fehler bei Dir auftritt.

Cu framp
#511 Christian 2015-10-09 11:16
Moin Moin,

leider hat das letzte Update einen Bug, ich erhalte jetzt nur noch:

??? ERROR: Unable to execute script. Missing bash interpreter. Current interpreter is /bin/sh

Gibt es einen Fix?

Grüße,
Christian
#510 framp 2015-10-05 21:41
Moin beMoD,

vielen Dank für Deinen Update. Das ist die Erklärung für das Phänomen. :thumbsup:

Interessant zu hören, dass Du im Wrapperscript auf interne Variable des Scripts zugreifst ($BACKUPTARGET_DIR). Ist nicht ganz ungefährlich, denn es können sich da natürlich Änderungen in zukünfigen Versionen ergeben :-* . Aber dieser Variablenname wird sich ziemlich sicher nicht mehr ändern. ;-)
Der richtige Weg wäre eigentlich dafür eine Extension zu benutzen. Aber ich muss gestehen, dass das Interface momentan ziemlich leer ist. Die BACKUPTARGET_DIR Variable wäre da sicherlich ein guter Kandiat um ihn aufzunehmen. Da gibt es room for improvement ...

Wenn Du Lust und Interesse hast eine Extension zu schreiben lass mich wissen was Du noch für interne Parameter benötigst im pre oder post call. Ich werde sie dann einbauen. Und damit bist Du unabhängig von der internen Implementierung im Script bis in alle Zeiten :-)

Cu framp
#509 beMoD 2015-10-05 21:17
Hi framp,

ich weiss jetzt woran es liegt
rsync wird mit der -t Option aufgerufen, was ja auch korrekt ist, weil man die timestamps der Dateien beibehalten will. Allerdings wird dann auch der timestamp von / beibehalten und auf das Zielverzeichnis, also das Sicherungsverzeichnis übertragen. Technisch also absolut korrekt.

Ob man das jetzt anpassen will, z.B. durch ein touch $BACKUPTARGET_DIR nach dem rsync ist wohl eine Philosophiefrage. Ich werde es wohl in mein Wrapperskript einbauen, da ich häufig mit timestamps arbeite und es übersichtlicher finde mit den timestamps der Verzeichnisse zu arbeiten als mit den Verzeichnisnamen.

Grüße,
beMoD
#508 framp 2015-10-05 20:15
Moin bemod

ich muss zugeben dass mir das bislang nicht auffiel, da ich immer auf das Erstellungsdatum des Backups gesehen habe, welches im Backupnamen implizit enthalten ist ( ist der Teil mit yyyymmdd-hhmmss).

Ich habe nach dem Beitrag von Wolfgang und auch eben noch mal ein wenig im Netz gesucht - aber keine Erklärung für dieses Phänomen gefunden :sad:

hardlinks auf Verzeichnisse gibt es nicht - also liegt es vermutlich wie Du auch schon vermutest am rsync.

Die Hauptsache ist, dass die Inhalte verschieden sind - aber identische Dateien nur einmal gespeichert werden durch die hardlinks. Deshalb habe ich ja den diff Befehl genannt, mit dem man das verifizieren kann.

Cu framp
#507 bemod 2015-10-05 15:56
Hi Wolfgang,

das mit dem Datum war mir auch schon aufgefallen, ich habs aber bis jetzt ignoriert, weil es nur das eigentliche Sicherungsverzeichnis betrifft und nicht die gesicherten Daten. Jetzt, wo ich den Kommentar gelesen, schreibe ich aber doch mal.

@framp: Das Phänomen stellt sich so dar:
bemod@wohnpi:~$ ls -lad /backup
drwxr-xr-x 5 root root 4096 Sep 17 11:29 /backup

bemod@wohnpi:~$ ls -lad /backup/raspi-backup/wohnpi/*
drwxr-xr-x 23 root root 4096 Sep 17 11:29/backup/raspi-backup/wohnpi/wohnpi-rsync-backup-20150918-031001
drwxr-xr-x 23 root root 4096 Sep 17 11:29 /backup/raspi-backup/wohnpi/wohnpi-rsync-backup-20150919-031002
[..]
drwxr-xr-x 23 root root 4096 Sep 17 11:29 /backup/raspi-backup/wohnpi/wohnpi-rsync-backup-20151004-031001
drwxr-xr-x 23 root root 4096 Sep 17 11:29 /backup/raspi-backup/wohnpi/wohnpi-rsync-backup-20151005-031002

root@wohnpi:~$ touch -t 201510051111 /backup
root@wohnpi:~$ ls -lad /backup
drwxr-xr-x 5 root root 4096 Okt 5 11:11 /backup
root@wohnpi:~$ /usr/local/bin/raspiBackupWrapper.sh -t rsync
root@wohnpi:~$ ls -lad /backup/raspi-backup/wohnpi/wohnpi-rsync-backup-20151005-154312
drwxr-xr-x 23 root root 4096 Sep 17 11:29 /backup/raspi-backup/wohnpi/wohnpi-rsync-backup-20151005-154312

Aus irgendeinem Grund hat das erste backup den timestamp des /backup Verzeichnis. Alle weiteren backups bekommen den gleichen timestamp, auch nach verändern des /backup timestamps. Wenn ich raten müsste würde ich auf eine Eigenart des rsync backups mit hardlinks tippen.

Grüße,
beMoD
#506 framp 2015-10-02 19:11
Moin Wolfgang,

eine Erklärung habe ich dafür nicht :sad:

Am einfachsten kannst Du aber Unterschiede von zwei rsync Verzeichnisse sehen mit

diff -rq DIR1 DIR2

Cu framp
#505 Wolfgang 2015-10-02 17:52
Hallo, ich habe mir das Backup heute eingerichtet. Beim rsync fällt mir auf, dass die verschiedenen Versionen bei einem ls -al auf das Backupverzeichnis alle das Datum von gestern mit der Uhrzeit 18:00 Uhr haben. Die img, mbr und sfdisk-Dateien haben ein Datum von heute und die Uhrzeit des ersten rsync.
Gibt es dafür eine Erklärung, oder mach ich noch etwas falsch?
Danke ...
Gruß
Wolfgang
#504 framp 2015-10-01 18:58
Moin Odie,

jeder war mal ein Linuxneuling - also kein Problem :-)

Die Meldung des Scripts besagt, dass Du kein externes Gerät an /media/usb gemountet hast. Das ist eine Notbremse, die ich eingebaut habe, denn ansonsten würdest Du Deine SD Karte mit dem Backup vollschreiben und je nach Größe der SD Karte wird dann irgendwann kein Platz mehr frei sein und Dein OS nicht mehr starten.

Nachprüfen kannst Du das mit
mount
und dort wird bei Dir nix mit /media/usb auftauchen. Veilleicht hast Du es ja unter einem anderen Verzeichnis gemounted? Wenn ja musst Du den -p Parameter benutzen oder in Deiner Konfig Datei die Variable DEFAULT_BACKUPPATH entsprechend anpassen.

Wie Du Dein Gerät mountest hängt ganz vom Gerät ab. Am besten suchst Du dazu im Netz mit der Suchmaschine Deines Vertauens. Z.B. hier :-) oder Du suchst mal in einem Raspberryforum wie z.B. hier :-)

Cu framp
#503 Odie 2015-10-01 14:31
Hallo,
ich komme leider nicht weiter. Bin Linux-Neuling und habe versucht per Anleitung einen 16 GB Stick zu mounten. Ich denke, dass das auch funktioniert hat.
Beim ausführen von

sudo raspiBackup.sh -F

erhalte ich immer die Information

??? RBK0027E: Kein externes Gerät an /media/usb verbunden

Wie komme ich weiter?

MfG
#502 framp 2015-09-29 13:55
Moin usr240681,

vielen Dank fuer die Rueckmeldung. Das ist wirklich eine Falle in die auch andere Benutzer reinfallen koennen.
Eine andere Losung waere das .raspiBackup.conf in das Verzeichnis /root zu kopieren. Aber der richtige Platz ist schon /usr/local/etc/. Ich werde das noch mal genauer beschreiben. Vielleicht nehme ich auch das .raspiBackup.conf ganz raus. Ist eigentlich ein Leftover von meinen Testaktivitaeten in einer fruehen Phase des Scripts.

Cu framp
#501 usr240681 2015-09-29 07:39
Hallo,

mal ein Update von mir. Es funzt jetzt, auch der Cron-Job. :D

Was habe ich getan? Ich habe das Skript noch mal installiert (mit Installationsanleitung 2.2) und meine Konfig statt in /home/pi in /usr/local/etc/raspiBackup.conf abgelegt (bzw. die installierte angepasst).

Ich denke wenn der Cron-Job läuft, dann läuft der ja als root, und der root wird nicht die Konfig aus /home/pi lesen. Ich kam drauf da ich folgenden Fehler in /var/log/raspiBackup/raspberrypi.log gefunden hab: 20150928-020007: MSG ??? RBK0027E: Kein externes Gerät an /backup verbunden

Ich hatte nie das Backup für "/backup" konfiguriert, also musste der Cron-Job die falsche Konfig nehmen.

Ich danke für Rat & Tat!
#500 framp 2015-09-27 22:23
Moin Nea,

danke für Dein Verständnis. Muss aber nicht sein ... und ärgert mich auch. Danke für Deinen Hinweis.

Cu framp
#499 Nea 2015-09-27 22:02
Super, vielen Dank.
Ja das ewige Leid mit der Dokumentation kommt mir bekannt vor da das Programmieren immer schneller ist. ;-) Deswegen ist nicht schlimm man kann ja fragen.

Danke für Deine Hilfe und einen schönen Abend.

Gruß Nea
#498 framp 2015-09-27 21:40
Moin Nea,

mein Fehler :oops: ... ich habe das Installationsscript gestern updated ... und die Beschreibung nicht nachgezogen

Nimm

wget http://www.linux-tips-and-tricks.de/raspiBackupInst all.sh -O raspiBackupInst all.sh -q && sudo bash raspiBackupInstall.sh

das wird funktionieren.

Die Beschreibung ändere ich gleich

Cu framp
#497 Nea 2015-09-27 21:21
Guten Abend,
ich bekomme eine komische Meldung beim herunterladen bzw. installieren Deines Skriptes.
pi@raspberrypi ~ $ wget http://www.linux-tips-and-tricks.de/raspiBackupInstall.sh -O raspiBackupInstall.sh -q && bash raspiBackupInstall.sh
??? Command has to be invoked as root. Use sudo raspiBackupInstall.sh

Mit sudo komme ich auch nicht weiter, was ja eigentlich auch klar ist. Was stimmt denn hier nicht?

Danke für Deine Hilfe.
Gruß Nea
#496 framp 2015-09-25 20:58
Moin usr240681,

irgendwie bin ich verwirrt. Du hast geschrieben dass Du das Script nur mit
sudo bash raspiBaskup.sh
aufrufen kannt. jetzt schreibst Du Du kannst es mit
sudo raspiBackup.sh
erfolgreich aufrufen.

Was ist denn nun richtig?

Zur Crontab: Probiere mal

00 02 * * 5 /usr/local/bin/ raspiBackup.sh &> /tmp/raspiBackup.cron.log

und siehe morgen nach was an Fehlern in /tmp/raspiBackup.cron.log steht.

Cu framp
#495 usr240681 2015-09-25 14:51
Ehrlich gesagt habe ich nichts weiter getan als
$ raspiBackup.sh
aufzurufen.
Schon geht es. Es wird ein Backup angelegt und ich bekomme auch eine E-Mail.

Jetzt habe ich aber ein Problem mit dem Cron-Job:
00 02 * * 5 /usr/local/bin/raspiBackup.sh
startet leider nicht den Job. Ich dachte dass er heute morgen um 2 hätte laufen sollen...

Der Aufruf für die Crontab ist:
pi@raspberrypi ~ $ sudo crontab -e
#494 framp 2015-09-24 22:37
Moin usr240681,

freut mich dass es jetzt ganz normal aufgerufen werden kann.
Vielleicht kannst Du noch mal kurz zusammenfassen was Du getan hast, um die bash als shell einzurichten. Dann kann ich Besucher dieser Webseite, die selbiges Problem bei sich entdecken, auf Deinen Kommentar verweisen :-)

Anyhow werde ich in der nächsten Version einbauen, dass geprüft wird ob die bash benutzt wird und ansonsten eine entsprechende Fehlermeldung ausgeben.

Cu framp
#493 usr240681 2015-09-24 22:05
Wenn ich
$ env
eingeben, sagt mir
SHELL=/bin/bash

Das sollte doch passen?

Ich rufe das Skript nun ohne "sh" auf, da geht es.

Danke.
#492 framp 2015-09-24 10:17
Ich denke es reicht in /etc/passwd die shell zu aendern. Siehe hier die Details.

Aber mich wundert warum Du nicht die bash als default hast. Das ist bei raspbian der Standard. Welches OS benutzt Du denn?

Cu framp
#491 usr240681 2015-09-24 09:18
Jetzt geht's.
pi@raspberrypi ~ $ sudo bash /usr/local/bin/raspiBackup.sh -F
--- RBK0009I: raspberrypi: raspiBackup.sh V0.5.15.7 um Do 24. Sep 09:14:23 CEST 2015 gestartet
--- RBK0010I: raspberrypi: raspiBackup.sh V0.5.15.7 um Do 24. Sep 09:14:23 CEST 2015 beendet
--- RBK0017I: Backup erfolgreich beendet
pi@raspberrypi ~ $

Was stimmt denn an der Shell nicht? Und wo kann ich die Standardshell ändern?

Linux raspberrypi 4.1.6-v7+ #812 SMP PREEMPT Thu Sep 10 12:16:06 BST 2015 armv7l
#490 framp 2015-09-24 08:44
Moin usr240681,

die Konfig ist OK. Mir sieht es so aus als waere die bash nicht Deine Standardshell. Welches OS benutzt Du denn?

Rufe mal das Script wie folgt auf als pi. Damit erzwingst Du die Benutzung der bash.
sudo bash raspiBackup.sh ...

Cu framp
#489 usr240681 2015-09-24 08:00
Hier noch mal die Konfig. Das ist eigentlich die Beispielkonfig, nur mit Backuppfad geändert.

/home/pi/.raspiBackup.conf
===
# Pfad wo das Backupfile gespeichert wird
DEFAULT_BACKUPPATH="/media/pi-ext/backups"
# Anzahl der zu vorhaltenden Backups
DEFAULT_KEEPBACKUPS=3
# Typ des Backups: dd, tar, xbmc or rsync
DEFAULT_BACKUPTYPE="dd"
# zip tar oder dd backup (0 = nein, 1 = ja)
DEFAULT_ZIP_BACKUP=0
# Durch ; getrennte Befehle, die vor dem Starten des Backups auszuführen sind
DEFAULT_STOPSERVICES=""
# Durch ; getrennte Befehle, die nach dem Starten des Backups auszuführen sind
DEFAULT_STARTSERVICES=""
# emailadresse die das Backupergebnis erhält
DEFAULT_EMAIL=""
# Weitere Parameter für das eMail programm
DEFAULT_EMAIL_PARMS=""
# Log level (0 = keiner, 1 = debug)
DEFAULT_LOG_LEVEL=0
# log Ausgabe ( 0 = /var/log/syslog, 1 = /var/log/raspiBackup/.log, 2 = /raspiBackup.log, 3 = ./raspiBackup.log )
DEFAULT_LOG_OUTPUT=1
# Message level (0 = minimal, 1 = detailed)
DEFAULT_MSG_LEVEL=0
# mailprogram
DEFAULT_MAIL_PROGRAM="mail"
# Gerät wo das Backup restored wird
DEFAULT_RESTORE_DEVICE=""
# Log wird in eMail mitgeschickt (0 = nein, 1 = ja)
DEFAULT_APPEND_LOG=0
# Detailierte Logausgaben der Backupprogramme (0 = nein, 1 = ja)
DEFAULT_VEBOSE=0
# Check auf einen remoten Backupfad wird nicht vorgenommen (0 = nein, 1 = ja)
DEFAULT_SKIPLOCALCHECK=0
# Blocksize von dd
DEFAULT_DD_BLOCKSIZE=1MB
# Weitere Parameter für dd
DEFAULT_DD_PARMS=""
# Hardlinks werden für rsync benutzt (0 = nein, 1 = ja)
DEFAULT_HARDLINKS=1
# Excludeliste für das benutzte Backuprogramm
DEFAULT_EXCLUDE_LIST=""
# Notifizierung soll stattfinden wenn eine neue Scriptversion verfügbar ist (0 = nein, 1 = ja)
DEFAULT_NOTIFY_UPDATE=1
# Aufzurufende Erweiterungen
DEFAULT_EXTENSIONS=""
# Sprache der Meldungen (DE oder EN)
DEFAULT_LANGUAGE=""
===

pi@raspberrypi ~ $ ls -la
-rw-r--r-- 1 pi pi 1976 Sep 23 22:22 .raspiBackup.conf

Gemountet ist die USB-Platte so:
pi@raspberrypi ~ $ mount
/dev/sda1 on /media/pi-ext type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

Danke für's helfen!
#488 usr240681 2015-09-24 07:51
zitiere framp:
Moin usr240681,

Deine Konfig sieht aber ziemlich leer aus :-* . Vielleicht benutzt Du einfach einen nopaste Service und postest hier den LInk. Dann hast Du nicht das Problem mit den kurzen Zeilen.

Cu framp


Ich hatte in meinem Post eine spitze Klammer drin. Das verträgt das Forum anscheinend nicht. Ich poste die Konfig noch mal.
#487 framp 2015-09-23 22:37
Moin usr240681,

Deine Konfig sieht aber ziemlich leer aus :-* . Vielleicht benutzt Du einfach einen nopaste Service und postest hier den LInk. Dann hast Du nicht das Problem mit den kurzen Zeilen.

Cu framp
#486 framp 2015-09-23 22:31
Moin Mario,

es wird eben nur genau eine externe Partition gesichert. Wenn Du /dev/sda3 auf /dev/sda1 kopierst und dann löschst hast Du nur noch eine root Partition die dann auch vom Script gesichert wird :-)

Zu Deiner zweiten Frage: Klar - nfs ist die beste Wahl. So mache ich es auch (Habe auch eine Raspi als Backupserver für die anderen Raspis :lol: )

Cu framp
#485 usr240681 2015-09-23 22:31
Hallo,

danke für die schnelle Antwort.

Meine Konfig ist die hier:
===%
#484 Mario 2015-09-23 22:17
Hey danke,

beide Tipps sind gut, der zweite ist aber nicht ganz so einfach ;-)
Meine Rootpartition liegt auf der SSD unter /dev/sda1 und wird durch Dein Skript auch gesichert. /home/seafile ist aber eine eigene Partition auf der gleichen SDD unter /dev/sda3.

Das mit dem Wrapperskript muss ich mir anschauen oder ich probiere mal ein bissel mit rsnapshot rum.

Noch ne Frage: Ich habe hier noch 2 Pis, beide nur mit Karte. Würde beide gern mit rsync und Deinem Skript auf den Backup-Pi sichern, an dem neben besagter SSD auch eine normale USB-Platte fürs Backup hängt.

Was ist die beste Methode, um die beiden anderen remote zu sichern? NFS?

Danke nochmal!
#483 framp 2015-09-23 22:09
Moin Mario,

die Aufgabe des Backupscripts ist die SD-Karte zu sichern. Externe gemountete Partitionen werden nicht mitgesichert. Eine Ausnahme ist es, wenn die Rootpartition ausgelagert wurde auf eine externe Platte.

D.h. Dein Anwendungsfall wird so leider nicht unterstützt :sad:

1) Du kannst aber das Wrapperscript benutzen und nach dem erfolgten Backup der SD Karte Deine /home/user mit tar oder rsync sichern. Der Restore würde dann die SD Karte wiederherstellen und die /home/user müßtest Du dann noch zusätzlich programmatisch restoren.

2) Eine andere Alternative wäre dass Du das gesamte Rootfilesystem zusätzlich zu /home/user auf die SSD bringst. Wie schon oben geschrieben wird ein externes root Filesystem gesichert und auch wieder restored von dem Script.

Bei (1) musst Du Programmieren
Bei (2) musst Du Deine Rootpartition von der SD Karte auf die SSD kopieren und die cmd.txt anpassen. Dabei kann Dir diese Beschreibung bzw das Tool helfen.

Ich hoffe es ist bei den beiden Lösungsmöglichkeiten eine für Dich mögliche dabei.

Cu framp
#482 Mario 2015-09-23 21:31
Moin,

super Skript und 1a Support. Ich habe das Ganze jetzt mal bei mir in Betrieb genommen und dabei allerdings eins übersehen. Ich habe eine SSD unter /home/user gemountet, die wird natürlich nicht mitgesichert - ich hatte das irgendwie nicht auf dem Schirm.

Hast Du dafür eine Idee?

Danke!
#481 framp 2015-09-23 18:32
Moin usr240681,

anbei meine Antworten:

1) Ja, denn es ist Konvention in Linux dass Benutzerkonfigurationen mit dem Punkt anfangen damit sie im Normalfall nicht angzeigt werden und Systemkonfigurationen keinen Punkt haben.

2) Danke fuer den Hinweis. Ich loesche die zweite Zeile.

3) Ich habe keinen Parser für die Konfig geschrieben, der Fehler entdecken und berichten würde. Wäre viel zu aufwändig. Deshalb muss die Konfig der bash Syntax entsprechen. Ausserdem müssen die Namen der Definitionen auf der linken Seite exakt so eingegeben werden. Du bekommst einen Syntaxfehler von bash weil irgendwas nicht ganz korrekt in der Konfig ist.

Mein Vorschlag: Poste mal den Inhalt Deiner Konfig (u.U. etwas anonymisiert :-) ) und ich sehe ihn mir auf Fehler an.

Cu framp
#480 usr240681 2015-09-23 17:36
Hallo,

ich habe mir wie oben beschrieben das Script auf meinem PI installiert (Installationsanleitung, Punkt 2).

Ich habe mir auch eine *.conf-Datei angelegt.
Frage 1) Ist es bewußt so gehalten dass die eine .raspiBackup.conf heißt, die andere nur raspiBackup.conf (also ohne Punkt vor dem Dateinamen)? -> /usr/local/etc/raspiBackup.conf oder ~/.raspiBackup.conf

Frage 2) Oben in der Beispiel-Konfig gibt es 2 mal die Zeile
DEFAULT_RESTORE_DEVICE=""

Frage 3) Wenn ich das Script dann zum Testen aufrufe:
pi@raspberrypi ~ $ sh /usr/local/bin/raspiBackup.sh -F
bekomme ich 2 Fehler:
/usr/local/bin/raspiBackup.sh: 70 [[: not found
/usr/local/bin/raspiBackup.sh: 88 Bad substitution

In meiner raspiBackup.sh steht die Version "0.5.15.7"

Danke für die Hilfe.
#479 Nea 2015-09-22 08:57
Super habe es nun auch hin bekommen, vielen Dank für dein tut und den Hinweis das die Antwort im Chat steht.
#478 framp 2015-09-22 06:49
Moin Nea,

mit sendEmail kenne ich mich nicht aus. Ich habe den Support dafuer vor laengerer Zeit auf Nachfrage von einem Interessenten eingebaut. Es gab da eine Diskussion die Du in den Kommentaren finden wirst.
Vielleicht liest ja jemand mit der sich mit sendEmail auskennt und kann Dir Tipps geben. Ansonsten musst Du im Netz oder in Linuxforen suchen bzw fragen.

Cu framp
#477 Nea 2015-09-21 22:48
Danke für die schnelle Antwort,
ich verwende sendEmail. Der Parameter -F ist wirklich sehr nützlich :-).. hmmm.
OK weißt Du zufällig wo die config von sendEmail liegt.

Vielen lieben Dank
#476 framp 2015-09-21 19:03
Moin Nea,

Du musst lokal einen eMailClient konfiguriert haben. Den Typ gibst Du mit -s mit. Bei mail bzw exim4 und ssmtp wird alles wie z.B. die smtp Server Adresse in der eMailClientConfig konfiguriert. Bei sendEmail sind noch ein paar zuseatzliche Parameter notwendig und die müssen mit -E übergeben werden. Noch der Hinweis dass der Parameter -F sehr nützlich ist um die eMailFunktion schnell zu testen :-)

Cu framp
#475 Nea 2015-09-21 14:07
Hallo, ein super Tut. Danke.
Eine Frage habe ich aber trotzdem:
wo wird der smtp-server eingetragen? Bei mir wäre das smtp.1und1.de. Trage ich das unter smtp-server ein, dann bekomme ich Fehlermeldungen. Mit dem Parameter -E wird dieser als erstes geschrieben und dann alle zusätzlichen Parameter in "" ?
Vielen Dank
#474 framp 2015-09-07 21:34
Moin Michael,

freut mich dass es Dir hilft. Es erforderte und erfordert zwar immer noch Aufwand das eigentlich nur für mich geschriebene Script auch für die Community nutzbar zu machen - aber es freut dann doch auch wenn ich positives Feedback bekomme :-)

Cu framp
#473 Michael 2015-09-07 21:15
Hallo "framp"

vielen Dank für dieses Klasse Script! Es funktioniert super und hat mir etwas Arbeit erspart :-)

Beste Grüße Michael
#472 framp 2015-09-03 15:35
Moin vito01,

das ist natürlich ärgerlich und tut mir leid. Allerdings finde ich mehrere Stellen, wo diese Einschränkung beschrieben wird:

1) In der Zusammenfassung: Eine zweiter Backupmodus, der partitionsorientierter Backupmodus, sichert alle bzw eine bestimmte Anzahl von Partitionen der SD Karte. Damit kann somit eine NOOBS SD Karte sowie Images mit mehr als zwei Partitionen gesichert werden
2) In der Funktionsübersicht: Der partitionsorientierte Backupmodus sichert eine beliebige Anzahl von Partitionen der SD Karte und kann somit NOOBs Images sichern
3) Beschreibung des Parameters P: Dieser Modus muss bei NOOBS Images gewählt werden und wenn mehr als zwei Partitionen auf der SD Karte sind.

und vor allem die Beschreibung von partitionsorientiertem und normalem Backup im separaten Kapitel
'Vergleich partitionsorientierter Backup und normaler Backup' dazu.

Da aber schon häufiger nachgefragt wurde, mehrere Partitionen mit rsync sichern zu können ist diese Funktionalität in der Entwicklung und wird in der nächsten Scriptversion 0.6 zur Verfügung stehen.

Details dazu auf der folgenden Seite: .

Der aktueller Stand der Entwicklung kann hier nachgelesen werden.

Cu framp
#471 vito01 2015-09-03 14:23
Hab viel Zeit investiert und alles gelesen,
starte das Script -rsync und bekomme

RBK0013E: Es existieren mehr als zwei Partitionen, die nur mit dem Backuptype DD oder DDZ gesichert werden können

Schade das dies nicht im Text beschrieben war.

:sad:
#470 framp 2015-08-30 10:32
Moin Robert,

Du kämpfst gerade mit Linux und weniger mit dem Script :-)

Du hast offensichtlich die Config Datei unter Windows erstellt. Das gibt aber Probleme da unter Windows am Zeilenende ein Zeichen steht, welches Linux nicht mag (CR). Du solltest jetzt folgendes machen:

1) sudo apt-get install dos2unix
2) sudo dos2unix /usr/local/etc/raspiBackup.conf

Danach sollte es funktionieren ;-)

Cu framp
#469 Robert 2015-08-30 09:47
Danke für deine Mühe. Es will einfach nicht klappen. Nun kommt:
/usr/local/etc/raspiBackup.conf: Zeile 4: $'\r': Kommando nicht gefunden.
#468 framp 2015-08-29 22:53
Moin Robert,

das bestätigt meine Annahme. Aber die Config Datei wird immer benutzt wenn es /usr/local/etc/raspiBackup.conf gibt oder ~/.raspiBackup.conf

Die Namen der Variablen auf der rechten Seite von = müssen aber exakt stimmen. Wenn Du z.B.
DEFAULT_BACKUP_PATH="/mySpecialBackupPath"

stehen hast wird immer noch /backup benutzt da es

DEFAULT_BACKUPPATH="/mySpecialBackupPath"

heissen muss.

In der nächsten Version werde ich einbauen dass auch eine Meldung erscheint wenn eine Konfig Datei gelesen wurde.

Cu framp
#467 Robert 2015-08-29 22:31
So ich nochmal. Der Fehler ist weg. Aber nur wenn ich keine conf Datei nehme.
Die wird auch irgendwie nicht gefunden, da bei Aufruf script kommt /backup nicht gefunden oder so ähnlich.
#466 framp 2015-08-29 12:13
@Robert,

der Logoutputparameter -L ist ungültig. Wenn Du den beim Aufruf mitgibst wird geprüft ob er korrekt ist (Darf nur 1,2 oder 3 sein). Leider nicht in der Konfigdatei.

Wenn Du also in der Konfigdatei die Zeile
DEFAULT_LOG_OUTPUT=1
mit einem falschen Wert gesetzt hast (z.B.
DEFAULT_LOG_OUTPUT=
oder
DEFAULT_LOG_OUTPUT="/home/framp")
bekommst Du genau den Fehler.

Ich werde in der nächsten Version diesen Parameter auch von der Konfigdatei prüfen um diesen Fehler zu verhindern.

Cu framp
#465 framp 2015-08-28 22:25
Moin Robert,

das sollte natürlich nicht passieren. Teile doch mal bitte mit wie Du das Script mit welchen Parametern aufrufst und wenn Du eine eigene Config erstellt hast zeige auch den Inhalt davon. Die eMail solltest Du aber maskieren :-*

Cu framp
#464 Robert 2015-08-28 20:40
Hallo, ich bekomme immer den Fehler invalid log destination Zeile 633. Das wiederholt sich in Endlosschleife. Mehr macht das Script nicht
#463 framp 2015-08-22 00:09
@Wilfried,

ich habe jetzt mal die letzten 8 Wochen mit dem Plugin mir die Memoryauslastung meine Raspis vor und nach dem Backup reporten lassen.

Ich kann kein Memoryleak erkennen. Es kommt eben wirklich darauf an wie gut Linux gerade drauf ist und Speicher zum cachen benutzt.

Cu framp
#462 framp 2015-08-16 14:27
Moin Christian,

vielen Dank für Dein Feedback.

Beim Testen habe ich dummerweise nicht auf den eMailText geachtet und deshalb ist mir das durch die Lappen gegangen :oops: . Ist aber schon gefixed. Ich schicke Dir eine geänderte Version per eMail zu. Bitte testen und wenn es OK ist merge ich die Änderung in die nächste Version.

Zu /mnt und /media: Da verstehe ich Dein Problem nicht ganz: Da sowieso nur die SD Karte gesichert wird und nichts externes (durch den Parameter one-filesystem bei tar bzw -x bei rsync) wird auch wenn /mnt und /media nicht excluded wird alles was dort gemountet ist nicht mitgesichert. Deshalb sollte da eigentlich keine Änderung notwendig bei Dir gewesen sein.

Cu framp
#461 Christian 2015-08-16 11:39
Hi framp,

das neue Update hat leider einen Bug, der Betreff wird leider (weiterhin) nicht an die Umgebungssprache angepasst, der Inhalt wird analog dem vorherigen Workaround deutsch, der Betreff leider nicht.

Dass /mnt und /media nicht mehr excluded werden, ist eine interessante Änderung, sollte vielleicht noch mal klar hervorgehoben werden. Bisher war mein /mnt der gesamte Backupspeicher eingemounted, excluded wird jedoch nur der Backuppfad, habe das nun ändern müssen auf den tatsächlichen Ordner, den ich einmounte.

Grüße,
Christian
+1 #460 framp 2015-08-15 19:43
Moin bcutter,

nein. Nur wenn die neue SD Karte größer ist und der neue Space genutzt werden soll oder ein Firmwareupdate vorgenommen wurde ist das nötig.

Cu framp
#459 bcutter 2015-08-15 19:38
Hi,

kurze Frage: Wenn ich den Datenträger meines Pi wechsle (konkret: die SD-Karte image-basiert mit Win32 Disk Imager unter Windows auf eine gleich große eines anderen Herstellers überspiele), sollte ich mir dann Gedanken um das Backup machen?

Konkret: Macht es Sinn, raspiBackup zu zwingen (z.B. durch schlichtes Umbenennen/Löschen), die .IMG, .MBR und .SFDISK neu zu erstellen?

Bin mir nicht sicher ob - 1:1-Kopie hin oder her - nicht doch irgendetwas an der neuen SD-Karte anders sein könnte.
#458 framp 2015-08-13 23:59
Sorry Matthias,

das geht leider doch nicht mit dem Script :cry: . Es ist zwar möglich die weitere TB Partition zu sichern - aber beim Restore wird alles auf die SD Karte geschrieben und ich glaube nicht das Du eine TB SD Karte hast :-)

Die einzige Lösung die ich sehe ist, dass Du das Wrapperscript benutzt um die SD Karte zu sichern und zusaetzlich Deine TB Platte per tar darin sicherst. D.h. aber dass Du ein wenig Scripten musst.

Eine externe Partition wird nur korrekt gesichert und restored wenn sich darauf das root Filesystem befindet.

Cu framp
#457 framp 2015-08-13 23:12
Klar kann man das. Allerdings ist das momentan nicht vorgesehen im Script :-*

So langsam wird es knapp mit den Parametern, mit denen man das Script steuern kann ...

Ich baue die Funktion die nächsten Tage ein und schicke Dir eine neue Version per email zum Testen ;-)
#456 Matthias 2015-08-13 23:10
Man möge mir die Fehler verzeihen, die Autokorrektur hat ihren eigenen Kopf.
#455 Matthias 2015-08-13 23:06
aaaahhhhh

Parameters -u, hatte ich übersehen. /var ist eine 2TB platte die an den banana Pi via sata abgeklemmt ist. natürlich sollen die Daten mit gesichert werden. kann man das irgendwie bewerkstelligen, da laut Beschreibung ja alle externen gerät die nicht in root gemutet sind (wie die speicherkarge) nicht gesichert werden.
#454 framp 2015-08-13 22:48
Moin Matthias,

danke für Dein Feedback. Dumm dass es per ftp nicht bei Dir hinzubekommen ist.

Das /var nicht gesichert wird ist nicht korrekt. Es gibt zwar ein paar Verzeichnisse, die immer nicht gesichert werden (Siehe Beschreibung des Parameters -u) aber /var gehört definitiv nicht dazu. Bislang wurde diesbezüglch kein Problem gemeldet.

Lass bitte Deinen Backup mit den zusätzlichen Parametern -m 1 -l 1 durchlaufen und schicke mir die Logdatei zur Analyse zu (email auf der Kontaktseite)

Cu framp
#453 Matthias 2015-08-13 22:42
so, update meinerseits.
leider habe ich das backup nicht via ftp hin bekommen. mein dns-323 wollte weder via ftp, noch via nfs plugin mit dem server kommunizieren.
da ich noch ein paar teile gefunden habe, habe ich mit kurzerhand aus einem e350 board und ein paar platten ein nas mit 14TB zusammengebastelt (immer gut wenn man was rumfliegen hat). auf dem system läuft nun Debian 8 Jesse und die Kommunikation via nfs funktioniert. das backup funktioniert auch, aber es werden nicht alle ordnerinhalte gespeichert. ich kann nicht sagen ob das gewollt ist, oder ein bug. wichtig für mich wäre zB der Inhalt von dem Ordner /var/, da dort zB Weisheiten liegen und auch systemwichtige Dateien, die bei einer Wiederherstellung nötig wären.
+1 #452 framp 2015-08-05 20:28
Eben habe ich eine neue Version 0.5.15.17uploaded.

Sie beinhaltet:

Aufgelaufenen kleine Bugfixes und Erweiterungen:

1) Erweiterung: Wenn eine neue Version existiert wird in der eMail ein Link auf die Versionshistorie angezeigt um schnelleres Nachsehen nach den Änderungen/Neuerungen zu ermöglichen

2) Bugfix: Wenn der Hostname Bindestriche enthält funktioniert der Restore nicht

3) Erweiterung: Es wird geprüft, ob Schreibzugriff auf den Backuppath (-p Parameter) besteht und sonst eine Fehlermeldung geschrieben

4) Erweiterung: /mnt und /media werden beim Sichern nicht mehr ausgenommen

5) Erweiterung: Es können bis zu 365 Backups aufgehoben werden (Parameter -k)

6) Erweiterung: Es kann mit -G die Sprache der Scriptmeldungen eingestellt werden, so dass sie anders sein kann als die eingestellte Standardsprache auf der Raspi was die Standardsprache für Meldungen ist

7) Bugfix: Beim -t rsync und -L 2 wird kein Logfile erstellt

8) Erweiterung: Die Extensions erhalten als ersten Parameter den Returncode des Backupprozesses

Das Script updated sich selbst wenn es mit dem Parameter -U aufgerufen wird.
#451 framp 2015-08-05 19:39
Nee, sind noch alle Beine dran :D . Wird sowieso Zeit mal alle aufgelaufenen Bugs fixes und Erweiterungen verfügbar zu machen :-)
#450 beMoD 2015-08-05 18:58
Für mich brauchst Du Dir da kein Bein ausreissen. Ich habs nicht eilig :zzz
#449 framp 2015-08-04 21:49
Habe aus Versehen meinen vorherigen Post gelöscht :cry:

Deshalb reposte ich ihn hier noch mal damit die History bestehen bleibt.

Moin beMoD,

bei mir funktioniert 2. Das Log wird dann nach

/backup/obelix/obelix-tar-backup-20150804-200438.tar.raspiBackup.log

kopiert. Hast Du bei Deinem -p Parameter (bei mir /backup) mal genauer nachgesehen?

Zu dem Limit von 52 bei -k - da sieht man dass das Script eben eigentlich nur für mich gedacht war. Ich mache pro Woche ein Backup und hebe 12 Versionen auf. Für mich sind 52 - also 1 Jahr - das mögliche Maximum.

Für mich ist ein tägliches Backup und das ein halbe Jahr etwas übetrieben. Aber Du wirst Deine Gründe dafür haben.

In der nächsten Version wird es 365 sein - also immer noch ein Jahr - aber dann täglich. Dann brauchst Du das Script nicht mehr zu ändern.

Cu framp

PS: @beMoD - da liegt wirklich ein Bug vor mit -L2 und -t rsync. Ist schon gefixed - nur muss der Regressiontest noch durchlaufen bis ich die neue Version publishe. Das dauert aber noch etwas ...
#448 framp 2015-08-04 21:04
Hm ... das koennte sein dass es am -t rsync liegt. Ich sehe mir das noch mal diesbezueglich genauer an.

Bin gerade dabei mal die aufgelaufenen kleinen Änderungen zusammenzusammeln und in einer neuen Version zu publizieren. Dein -k Fix ist dann drin - und dann wohl auch der Fix mit -L2 und -t rsync :-)
#447 beMoD 2015-08-04 21:00
Hi framp,

der Grund für das tägliche Backup ist, dass ich mir gerne das System zerfrickel und ich das täglich zurückrollen können möchte. Eine Woche ist mir zu lange. Ein halbes Jahr war eher ein Beispiel. Ich glaub aufgefallen ist mir das bei einem Test mit 3 Monaten. Danke für die Änderung :-)

Zum Log: Ich habs grade nochmal ausprobiert: http://pastebin.com/wePENizB

Grüße,
beMoD
#446 beMoD 2015-08-03 23:11
Hiho,

erstmal danke für das tolle Tool und auch den Support den Du hier leistest.

Bei mir funktioniert aber der Parameter -L nicht korrekt. Gebe ich 2 als Wert an, so wird bei mir garkein Log geschrieben. 0 und 1 als Wert funktionieren fehlerfrei. 3 hab ich noch nicht ausprobiert. Ist nichts kritisches, wollte ich aber mal erwähnt haben.

Ausserdem würde ich gerne täglich sichern, und die Backups ca. ein halbes Jahr vorhalten. Für -k ist das Maximum allerdings 52. Ich habe das jetzt erstmal händisch im Script auf 150 geändert, das wird aber ein eventuelles Update des Scripts wieder kaputt machen. Hat das einen bestimmten Grund die maximale Anzahl von Backups auf 52 zu begrenzen?

Grüße,
beMoD
#445 framp 2015-08-02 20:42
Kurzer Update für die Mitleser:

Es gibt Schreibprobleme bei Matthias auf den Backupspace. Da er kein nfs benutzen kann benutzt er ftp und das funktioniert bislang nicht so ganz.

Mein Vorschlag war curlftps zu benutzen. Allerdings weiss ich nicht wie gut da die Performance ist. Vielleicht berichtet Matthias ja hier noch kurz wenn er es mit ftp geschafft hat und vor allen Dingen wie :-*

Da es solche Fälle schon öfter gab werde ich ins Script vor dem Backup noch einen Test aufnehmen ob Dateien geschrieben werden können und eine entsprechende Fehlermeldung ausgeben.
#444 framp 2015-08-01 22:59
Moin Matthias,

das sieht in der Tat nicht gut aus.

Um das Problem zu analysieren benötige ich weitere Infromationen und ein vollständigen Log. Bitte rufe das Script zusätzlich mit den folgenden Parametern Code:-l 1 -m 1 -v auf und schicke mir das Log per email zu. (eMail Adresse findes Du auf der Kontakt Seite)

Cu framp
#443 Matthias 2015-08-01 22:51
Hallo

Ich bekomme das Programm nicht zum laufen. Es ist ein Banana Pi, der Ordner Backup ist von einem NAS eingebunden und auch beschreibbar.
Ich bekomme diesen Fehler:
--- RBK0009I: Banana-Server: raspiBackup.sh V0.5.15 um Sa 1. Aug 22:38:33 CEST 2015 gestartet
--- RBK0081I: Backup vom Typ tgz wird in /backup/Banana-Server/Banana-Server-tgz-backup-20150801-223833.tgz erstellt
--- RBK0082I: Backup der Bootpartition in /backup/Banana-Server/Banana-Server-backup.img existiert schon
....
Backuperstellung vom Typ tgz läuft. Das wird etwas dauern
--- RBK0010I: Banana-Server: raspiBackup.sh V0.5.15 um Sa 1. Aug 22:38:34 CEST 2015 beendet
??? RBK0005E: Backup fehlerhaft in Schritt main mit RC 141 beendet. Weitere Informationen finden sich im Logfile /var/log/raspiBackup/Banana-Server.log
??? RBK0043E: Unvollständiges Backup /backup/Banana-Server/Banana-Server-tgz-backup-20150801-223833.tgz wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
??? RBK0005E: Backup fehlerhaft in Schritt main mit RC 141 beendet. Weitere Informationen finden sich im Logfile /var/log/raspiBackup/Banana-Server.log

im Log steht:
....
--- RBK0084I: Backup des Masterbootrecords in /backup/Banana-Server/Banana-Server-backup.mbr existiert schon
20150801-223834: MSG --- RBK0085I: Backuperstellung vom Typ tgz läuft. Das wird etwas dauern
tar: Entferne führende „/“ von Elementnamen
tar (child): /backup/Banana-Server/Banana-Server-tgz-backup-20150801-223833.tgz: Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden
tar (child): Error is not recoverable: exiting now
20150801-223834: MSG --- RBK0010I: Banana-Server: raspiBackup.sh V0.5.15 um Sa 1. Aug 22:38:34 CEST 2015 beendet
Invocation parms: '-p /backup -A -m 1 -t tgz -k 4 -e foo@bar.com'
20150801-223834: MSG ??? RBK0005E: Backup fehlerhaft in Schritt main mit RC 141 beendet. Weitere Informationen finden sich im Logfile /var/log/raspiBackup/Banana-Server.log
20150801-223834: MSG ??? RBK0043E: Unvollständiges Backup /backup/Banana-Server/Banana-Server-tgz-backup-20150801-223833.tgz wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
mail: Invalid header: /var/log/raspiBackup/Banana-Server.log
#442 framp 2015-07-31 18:27
Moin TheNoob,

keine Ahnung warum Du es so machst. Das ist so falsch. In dem Installationsteil wird beschrieben dass in der Crontab
Zitat:
/usr/local/bin/raspiBackup.sh -p /backup -t tar -k 4 -e moo@foobar.com
stehen soll. Wenn Du es als Benutzer aufrufen willst musst Du
Code:sudo /usr/local/bin/raspiBackup.sh -p /backup -t tar -k 4 -e moo@foobar.com benutzen. Im Aufrufparameterteil sind alle weiteren Parameter im Detail beschrieben.

Cu framp
#441 TheNoob 2015-07-31 12:32
Danke für die Antwort!
Ich habe jetzt versucht, denn Crontab manuell zu starten (mit sudo sh -x und dann dem Crontab)
Das Ergebnis sieht so aus - ich vermute, das sollte anders aussehen(?)

+ VERSION=0.5.15
+ MYSELF=raspiBackup.sh
+ MYNAME=raspiBackup
+ [[ -e /bin/egrep ]]
/usr/local/bin/raspiBackup.sh: 70: /usr/local/bin/raspiBackup.sh: [[: not found
+ date +%Y%m%d-%H%M%S
+ DATE=20150731-101903
+ hostname
+ HOSTNAME=raspberrypi
+ NL=$\n
+ DEPLOYMENT_HOSTS=root@raspifix root@raspberrypi root@raspiap root@raspibmc pi@ seafile
+ GIT_DATE=: 2015-05-26 15:51:00 +0200$
/usr/local/bin/raspiBackup.sh: 88: /usr/local/bin/raspiBackup.sh: Bad substitution
+1 #440 framp 2015-07-29 14:04
Moin TheNoob,

im Kapitel ueber die Standardaufrufparameter steht
Zitat:
Es besteht die Möglichkeit die Standardparameter in /usr/local/etc/raspiBackup.conf oder ~/.raspiBackup.conf zu konfigurieren und zu ändern.
D.h. Du musst Deine Datei nur raspiBackup.conf bzw .raspiBackup.conf nennen und sie in das entsprechende Verzeichnis kopieren. Dann wird sie automatisch gefunden und benutzt. Es ist keine Aenderung im Aufruf des Scripts in der crontab notwendig.

Cu framp
#439 TheNoob 2015-07-29 00:33
Hey!
Danke für diese großartige Idee + Umsetzung.
Leider stehe ich gerade etwas auf dem Schlauch. Ich habe jetzt die Config erstellt und angepasst und weiß nicht weiter ...
1. Wird die Config "automatisch" gefunden oder muss ich das in der SH-Datei irgendwie vermerken?
2. Ich vermute, dass sich der Crontab-Eintrag ändert, wenn die Config vorhanden ist? Wenn ja, wie?

Über Hilfe freue ich mich! :)
#438 framp 2015-07-25 19:12
Fein. Freut mich dass es funktioniert.

Du bist bislang der Erste, der ausser mir eine Extension geschrieben hat und jetzt feststellt, dass noch etwas fehlt: Das Weiterreichen des Returnwertes des Scripts and die Postextension.
Das einzubauen ist fix gemacht. In der nächsten Version wird es verfügbar sein.

Wenn Du bis dahin nicht warten kannst musst Du die folgenden Zeilen ändern:
Zeile 505:
Code:executeShellCommand ". $extensionFileName $2"
Zeile 1609:
Code:callExtensions $POST_BACKUP_EXTENSION $rc.

Dann bekommt das Postbackup Script den rc als Parameter $1 überreicht.

Cu framp
#437 bcutter 2015-07-25 18:53
Super, scheint zu funktionieren (lt. Ausgabe von -F)! E-Mail und Push Notification kamen an.

Danke für deine Hilfe und weiter so hier, ich wüsste echt nicht was ich ohne RaspiBackup tun würde :)

Mit der Extension muss ich mal sehen, momentan wird die Notification einfach immer abgesetzt. Liesse sich noch der Backup-Zustand (erfolgreich/nicht erfolgreich) des RaspiBackup.sh innerhalb der Extension abgreifen, wäre über eine simple Fallunterscheidung die Extension auch gleich mehr wert (zumindest die post-Variante, beim pre liegt ja noch kein success/error vor). Aber mir genügt es momentan so - simple but working.
+1 #436 framp 2015-07-25 18:38
Bist ja fix mit der Extension :-)
BTW: Solltest Du weitere Fragen zu Extensions haben lass uns bitte auf der Extensionseite weitere Informationen austauschen 8)

Zu Deinen Fragen:
1) Nein, es wird kein Fehler reportet. Es wird eine Warnung im Logfile geschrieben, dass das pre oder post Script nicht gefunden wurde.
2) Genau dafür gibt es den Parameter -F
3) Das habe ich nicht getestet, aber ich habe mir eben den Code angesehen und es sollte funktionieren.

Cu framp
#435 bcutter 2015-07-25 18:30
Frage 3 (zum Namensschema): Wird mit _ (Unterstrich) separiert oder darf die Erweiterung selbst auch einen enthalten? Also z.B. "raspiBackup_PushingBox_NotifyBackup_post.sh", Aufruf via N-Parameter "PushingBox_NotifyBackup"
#434 bcutter 2015-07-25 18:29
Perfekt, soweit so klar.

Frage 1: Muss es denn ein pre- und ein post-Skript geben? Was passiert wenn nicht?

Frage 2: Habe bereits eine Post-Erweiterung erstellt. Wie kann ich die Funktion mit finalem Aufruf von raspiBackup.sh (mit allen Paremetern) testen? Habe keinen Parameter zum simulieren gefunden und kann nicht so lange warten, wie das Backup dauern würde :)

Zur Aufklärung: Die Erweiterung setzt nur eine cURL-Message bei PushingBox.com ab. Dort ist ein Szenario "Backup durchgeführt" hinterlegt, welches Aktionen wie Mail-Versand oder Push Notification an Smartphone durchführt. Hab keinen Mailserver zum Laufen bekommen und bin sonst auch sehr angetan von dem Dienst.
Die Erweiterung ist daher ein Ein-Zeiler und wäre natürlich mit der Community teilbar :)
+1 #433 framp 2015-07-25 18:16
zitiere bcutter:
Nachtrag: Habe gerade auf die v0.5.15 aktualisiert und die Erweiterungen entdeckt. Klingt genau wonach ich suche.

Erweiterungen sind eigentlich dafür gedacht um kleine Erweiterungen des Scripts der Allgemeinheit zur Verfügung zu stellen. So wie ich es verstehe ist Dein Anwendungsfall sehr individuell für Dich. Also würde ich ein Script nehmen.
Zitat:
Frage also: Wie erkennt das Backup-Skript die Erweiterung? Konnte im Quellcode keine Referenz entdecken, man gibt beim Aufruf ja nur > -N "temp mem" < an um beide Erweiterungen zu nutzen.
Ja, die Erweiterung muss dann nur einem Namesschema gehorchen. Z.b. raspiBackup_cut_pre.sh und raspiBackup_cut_post.sh und mit dem Parameter -N "cut".
Aber wie gesagt denke ich das eine Erweiterung in Deinem Falle eher nicht geeignet ist.

Cu framp
#432 framp 2015-07-25 18:08
Moin bcutter,

eigentlich soll das Wrapperscript eine StartHilfe sein für ein eigenes Script wenn man wie Du noch irgendwas vor oder nachm dem Backupablauf codieren will, denn es enthält ja schon mal gewisse Logik zum Mounten/Unmounten. Wenn Du diese nicht brauchst kannst natürlich auch Dein eigenes Script schreiben.

Deine 2te Anforderung verstehe ich leider nicht. Was meinst Du mit 'Stelle bleibt erhalten' ?

Cu framp
#431 bcutter 2015-07-25 18:07
Nachtrag: Habe gerade auf die v0.5.15 aktualisiert und die Erweiterungen entdeckt. Klingt genau wonach ich suche.

Frage also: Wie erkennt das Backup-Skript die Erweiterung? Konnte im Quellcode keine Referenz entdecken, man gibt beim Aufruf ja nur > -N "temp mem" < an um beide Erweiterungen zu nutzen.

Klappt das, wenn ich meine eigene Erweiterung (nur post relevant) erstelle und beim Aufruf als Parameter via Dateiname referenziere?
#430 bcutter 2015-07-25 17:26
Hi,

ich würde gerne nach einem erfolgreichen Backup einen CURL-Befehl absetzen. Anforderungen:
- Backup-Skript läuft unbehelligt weiter
- Stelle bleibt idealerweise erhalten, wenn eine neue Version des Backup-Skriptes heruntergeladen wird.

Nutze ich dazu am besten das BackupWrapper-Skript? Oder ich baue mir mein eigenes Backup-Skript, welches zuerst RaspiBackup.sh aufruft, abarbeitet und danach meinen CURL-Befehl absetzt.

Was meint der Profi?
#429 framp 2015-07-12 17:41
Rene hat auf den englischsprachigen Seite in einem Kommentar berichtet (http://www.linux-tips-and-tricks.de/en/backup/#comment-885), dass das Script auch auf einer Banana Pi funktioniert.
#428 framp 2015-07-07 16:17
Moin Thrusty,

da brauchst Du nix Neues zu schreiben. raspiBackup sichert automatisch ein externes Rootfilesystem sofern Du tar oder rsync Backup benutzt :-* (Siehe Beschreibung von Parameter -t)

Zu Deiner cron Meldung: Sofern Dein Programm keine Ausgabe schreibt muss auch nix per eMail verschickt werden und es faellt nicht auf wenn kein MTA vorhanden ist. Die uebrigbleibende cron Meldung logged nur dass eben das Script backup.sh aufgerufen wird.

Cu framp
#427 Thrusty 2015-07-07 15:36
Moin Framp, ich habe raspian auf einer xternen HDD, nur das Booten läuft über die SD. Und ich möchte ein komplettes Backup der HDD auf mein NAS machen. Hatte versucht das über ein Scrip per Cron regelmäßig machen zu lassen.
#!/bin/bash
#
dd if=/dev/sda 2> /dev/null | sshpass -p XXXXXXX ssh admin@192.168.178.35 "cat > ../i-data/0faecd45/admin/raspberry/image_$(date +'%Y-%m-%d').img"
Diese Version hatte ich zuletzt versucht. Da kommt der MTA Fehler nicht mehr. Aber folgender ist immer noch da:
Jul 7 12:16:01 raspberrypi /USR/SBIN/CRON[8513]: (root) CMD ( /usr/local/bin/backup.sh)
#426 framp 2015-07-07 13:56
Moin Thrusty,

mir ist nicht ganz klar was Du da machst. Auch ist mir nicht klar wie die Verbindung von Deinem Script zu raspiBackup ist :sad:

Aber unabhaengig davon kommt der Fehler davon, dass der Cron die Ausgaben der Scripts, die gestartet werden, per eMail versucht zuzustellen. Wenn Du keinen MTA (MessageTransferAgent) konfiguriert bzw installiert hast kommt diese Fehlermeldung.

Cu framp
#425 Thrusty 2015-07-07 10:58
Hallo zusammen, ich habe mir mit Hilfe dieser Seiten ein kleines Script gebastellt und möchte es über Root Crontab laufen lassen. Ein starten von Hand im Terminal funktioniert.
Dieser Befehl soll gestartet werden:

dd if=/dev/sda 2> /dev/null | sshpass -p XXXXXXX ssh admin@192.168.178.35 "cat > ../i-data/0faecd45/admin/raspberry/image_$(date +'%Y-%m-%d').img"

Der Start über Cron bringt mir folgenden Fehler im syslog:
Jul 7 01:40:01 raspberrypi /USR/SBIN/CRON[29792]: (root) CMD ( /usr/local/bin/backup2.sh)
Jul 7 01:40:11 raspberrypi /USR/SBIN/CRON[29791]: (CRON) info (No MTA installed, discarding output)

Kommt der MTA- Fehler von dem @ im Code? Gibt es eine andere Schreibweise um den User den NAS einzutragen?
#424 framp 2015-06-27 16:47
Moritz,

ich habe auf der Noobs Seite darum gebeten einen Kommentar zu hinterlassen, wenn man Betatester sein möchte. Solltest Du Interesse haben hinterlasse dort bitte einen kurzen Kommentar.

Cu framp
#423 framp 2015-06-27 16:37
Moin Moritz,

wie ich schon an verschiedenen Stellen geschrieben habe bin ich dabei das Script zu erweitern, so dass > 2 Partitionen, speziell auch NOOBs Images mit tar und rsync gesichert werden können.
Das dauert aber seine Zeit, da das eine andere Backuplogik ist und diese parallel zu der existierenden Logik, die auch weiterhin funktionieren soll, ins Script eingebaut werden muss. Der Backup funktioniert schon soweit - aber der restore ist noch nicht fertig codiert.
Danach muss noch alles getestet werden ob die alte BackupFunktion noch OK ist und auch die neue Funktion OK ist.
Speziell das Testen ist sehr zeitaufwändig. Wenn Du mir beim Testen helfen willst kann ich Dir gerne eine Betaversion des Scripts zukommen lassen.

Cu framp
#422 Moritz 2015-06-27 14:59
Hey framp,

nachdem nun raspibackup mit dd bei mir seit einigen Wochen problemlos mit drei Partitionen läuft, würde ich gerne den Speicherplatzbedarf des Backups gebändigt bekommen. Wäre es mögich, auch den Backuptyp rsync mit drei Partitionen zu betreiben zu können?
#421 framp 2015-06-13 23:30
Moin Willy,

bei mir läuft einmal pro Woche ein Backup. Bislang habe ich 2 Resultate und das reicht nicht um irgendwelche Aussagen vorzunehmen. Ich sammle weiter die Ergebnisse.

Vielleicht benutzt Du auch mal die Extensions bei Dir um die Werte zu verfolgen.

Cu framp
#420 Wilfried Bauer 2015-06-13 23:22
zitiere framp:
Moin Wilfried,

das sieht tatsächlich merkwürdig aus. Ich werde das mal bei mir beobachten. In der neuesten Version kann man ja Extensions einsetzen und eine der Beispielsextension ruft free auf. Die laufen bei mir. Es passt also gerade perfekt.

Cu framp

Hi framp,
gibts dazu schon neue Erkenntnisse?

Gruß
Willy
#419 framp 2015-06-08 21:13
Moin Christian,

das ist auch ein Notbehelf - ohne Code zu ändern - aber kein Bug denn eigentlich ist das nicht unterstützt ;-) . Ich werde aber in der nächsten Version drauf achten dass man die Sprache fest vorgeben kann.

Cu framp
#418 Christian 2015-06-08 21:06
Moin,

mach ich, vermutlich da es ein angepasstes Image für das Smarthome ist und primär einen anderen Zweck verfolgt.

Einen kleinen Bug habe ich entdeckt: Der Inhalt ist nun in deutsch, vielen Dank, das Betreff ist weiter englisch. ;-)

Grüße,
Christian
#417 framp 2015-06-08 20:02
Moin Christian,

da scheint irgendwas nich korrekt installiert zu sein bei Dir. Ich würde mal in diesem http://www.forum-raspberrypi.de Forum suchen und bei Suchmisserfolg Dein Problem schildern.

Cu framp
#416 Christian 2015-06-07 23:02
Moin moin,

ups, leider aber auch weiterhin kein Erfolg:

root@smarthome:/usr/smarthome# /opt/vc/bin/vcgencmd measure_temp
/opt/vc/bin/vcgencmd: error while loading shared libraries: libvcos.so: cannot open shared object file: No such file or directory

Grüße,
Christian
#415 framp 2015-06-07 19:08
Moin Christian,

da ist ein Typo :-*

/opt/vc/bin/vcgencmd measure_temp

Cu framp
#414 Christian 2015-06-07 18:52
Moin moin,

dann versuche ich mal mein Glück mit der Sprache. Bezüglich der Temperatur, der Parameter stimmt, die Speicherangaben werden ja auch ausgegeben, nur die Temperatur ist leer, da ist einfach nur ein - nach dem einleitenden Text zur Temperaturausgabe. Ich habe aber wohl nun auch durch Deine Hilfe die Ursache:

root@smarthome:/usr/smarthome# /opt/vc/bin/vcg encmd measure_temp
-su: /opt/vc/bin/vcg: No such file or directory

Wie kommt man an den Skript? Was für Abhängigkeiten hat dieser ggf.?

Mit freundlichen Grüßen,
Christian Heutger
#413 framp 2015-06-07 12:54
Moin Christian,

das Mounten kann jeder so vornehmen wie er will. Das Wrapperscript ist ja nur ein Beispiel und kann bzw soll natürlich auch beliebig angepasst werden.

Mit einem Trick kannst Du die gewünschte Sprache auswählen. Du musst
1) die Sprache installiert haben . Check mit locale -a
bzw dann de_DE.UTF-8 installieren mit raspi-config
2) Den Aufruf von raspiBackup.sh wie folgt vornehmen
export DESIRED_LANGUAGE="DE"; raspiBackup.sh
Der help Text wird dabei nicht geändert, aber Du bist ja wohl an den Laufzeitmeldungen interessiert :-)

Warum die temp nicht kommt kann ich so nicht sagen. Stimmt der Parameter -N ? Ist in der Meldung das Feld mit der Temperatur leer? Teste mal was Du mit
/opt/vc/bin/vcgencmd measure_temp
erhältst.

Cu framp
#412 Christian 2015-06-07 12:02
Hi,

habe die Seite geliked. ;-) Super Arbeit! Auch Danke für die Antworten gestern, ich denke aber, mit dem Timecapsule-System und dem Skript timecapsule-handler müsste ich zu viel ändern, so dass der Wrapper keinen Sinn für mich macht, ich bleibe dann bei meinem "eigenen".

Ich habe noch zwei Fragen:

1. Ich habe einen Raspberry basierend auf Raspbian und einen zweiten basierend auf dem SmartHome/SmartVisu-Projekt. Letzterer scheint das Local auf English zu stehen, daher meldet er alles in Englisch. Kann ich den Skript irgendwie überreden (ohne das Local umzustellen), deutsch zu verwenden?

2. Ich habe nun mem und temp eingebaut, auf dem Raspberrry bekomme ich dazu dann nun auch Infos, auf dem SmartHome nur zum Speicher. Woran könnte das liegen? An der Local vielleicht?

Mit freundlichen Grüßen,
Christian Heutger
#411 framp 2015-06-06 22:45
Heute habe ich eine Facebookgruppe RaspiBackup erstellt.

https://www.facebook.com/pages/RaspiBackup/1390788211249738
Dort werde ich aktuelle Aktionen und Neuerungen um das Script raspiBackup publizieren.

Wer Facebook benutzt und auf dem Laufenden bleiben will kann gerne der Gruppe beitreten.

Wer das Script nützlich findet kann auch gerne die Gruppe liken :-)
#410 framp 2015-06-06 16:13
Moin Christian,
am Ende steht 200 OK - damit wurde die Datei runtergeladen. ich vermute es gab da einen kurzzeitigen Performanceengpass bei meinem Provider. ich denke es funktioniert jetzt wieder.

Zu Deine mount Frage: Jetzt habe ich verstanden was Dein Problem ist :lol: nfs Mounts werden eigentlich immer in der /etc/fstab definiert und dann braucht man zum Mount nur den lokalen Mountpunkt anzugeben.

Cu framp
#409 Christian 2015-06-06 15:59
Ich erhalte:

root@raspberry ~ # wget http://www.linux-tips-and-tricks.de/raspiBackup.version
--2015-06-06 15:57:00-- http://www.linux-tips-and-tricks.de/raspiBackup.version
Auflösen des Hostnamen »www.linux-tips-and-tricks.de (www.linux-tips-and-tricks.de)«... 78.46.156.195
Verbindungsaufbau zu www.linux-tips-and-tricks.de (www.linux-tips-and-tricks.de)|78.46.156.195|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 301 Moved Permanently
Platz: http://www.linux-tips-and-tricks.de/de/downloads/raspibackup-version/download[folge]
--2015-06-06 15:57:05-- http://www.linux-tips-and-tricks.de/de/downloads/raspibackup-version/download
Wiederverwendung der bestehenden Verbindung zu www.linux-tips-and-tricks.de:80.
HTTP-Anforderung gesendet, warte auf Antwort... 301 Moved Permanently
Platz: http://www.linux-tips-and-tricks.de/de/downloads/raspibackup-version/download/[folge]
--2015-06-06 15:57:05-- http://www.linux-tips-and-tricks.de/de/downloads/raspibackup-version/download/
Wiederverwendung der bestehenden Verbindung zu www.linux-tips-and-tricks.de:80.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 7 [text/plain]
In »»raspiBackup.version«« speichern.

100%[======================================>] 7 --.-K/s in 0s

2015-06-06 15:57:05 (188 KB/s) - »»raspiBackup.version«« gespeichert [7/7]

root@raspberry ~ # cat raspiBackup.version
0.5.15
root@raspberry ~ # rm raspiBackup.version


OK, verstehe, das kannte ich noch nicht. OK, ich verstehe nun das unmount aber das mount verstehe ich weiter nicht, ich dachte immer, das braucht zwei Parameter mount /wohin /was aber das /was fehlt?
#408 framp 2015-06-06 15:37
Moin Christian,

zu Deinen Fragen zum Wrapperscript:

In den folgenden Zeilen definierst Du den Mountpoint und Backuppfad:

BACKUP_MOUNT_POINT="/remote/backup" # ===> adapt to your environment
BACKUP_PATH="$BACKUP_MOUNT_POINT/myraspberries" # ===> adapt to your environment

Die Zeile
trapWithArg cleanup SIGINT SIGTERM EXIT

aktiviert Code, der ausgeführt wird, wenn das Script normal oder abnormal beendet wird und dann wird folgender Code aufgerufen:

if (( ! $WAS_MOUNTED )); then
echo "--- Unmounting $BACKUP_MOUNT_POINT"
umount $BACKUP_MOUNT_POINT

Ich hoffe Dir damit geholfen zu haben den Code zu verstehen :-)

Cu framp
#407 framp 2015-06-06 15:33
Moin Christian,

bei mir klappt der Update. Führe mal den wget

wget http://www.linux-tips-and-tricks.de/raspiBackup.version

auf der Konsole aus. Du bekommst da sicherlich eine Fehlermeldung die im Script unterdrueckt wird.

Cu framp
#406 Christian 2015-06-06 15:27
Addendum: Ich bin auch verwirrt bezüglich des Backupwrappers, ich erkenne, wo gemounted wird, wobei mir unklar ist, wie der mount funktioniert, da ja die Angabe fehlt, was gemounted werden soll. Vor allem ist mir aber unklar, wie das unmount bei nicht bereits gemountetem Backupverzeichnis stattfindet, da nach dem Kommentar gar kein Code mehr steht. Erledigt der Backupskript das selbst?
#405 framp 2015-06-06 15:25
Moin Christian.

Danke fuer den Hinweis. Ich sehe mir das mal an.

Cu framp
#404 Christian 2015-06-06 15:21
Hallo,

irgendwie funktioniert bei mir das updaten nicht mehr. Ich erhalte egal auf welchem Raspberry:

root@smarthome:~# /usr/local/bin/raspiBackup.sh -U
!!! RBK0074E: Failed to update raspiBackup.sh

root@smarthome:~# cat raspiBackup.log
20150606-131942: DBG >> updateScript
20150606-131942: DBG >> isNewVersionAvailable
20150606-131942: DBG -- Downloading /tmp/raspiBackup.sh~
20150606-131945: DBG -- 0.0 0.0 0.0 2
20150606-131945: DBG
#403 framp 2015-05-30 21:17
Moin Wilfried,

das sieht tatsächlich merkwürdig aus. Ich werde das mal bei mir beobachten. In der neuesten Version kann man ja Extensions einsetzen und eine der Beispielsextension ruft free auf. Die laufen bei mir. Es passt also gerade perfekt.

Cu framp
#402 Wilfried Bauer 2015-05-30 21:06
zitiere framp:
Moin WiIfried,

benutze mal 'free'. Details dazu auf dieser Seite: http://www.linuxatemyram.com/.

Cu framp

Moin,

gesagt getan - sieht aber letztlich ähnlich aus:

pi@raspberrypi ~ $ free -m
total used free shared buffers cached
Mem: 435 201 233 0 18 89
-/+ buffers/cache: 93 341
Swap: 0 0 0
pi@raspberrypi ~ $
pi@raspberrypi ~ $
pi@raspberrypi ~ $ free -m
total used free shared buffers cached
Mem: 435 415 19 0 54 119
-/+ buffers/cache: 242 193
Swap: 0 0 0
pi@raspberrypi ~ $
#401 framp 2015-05-30 10:23
Moin WiIfried,

benutze mal 'free'. Details dazu auf dieser Seite: http://www.linuxatemyram.com/.

Cu framp
#400 Wilfried Bauer 2015-05-30 10:02
zitiere framp:
Moin Wilfried,

wie hast Du die Memoryauslastung gemessen (Welches Tool) ?

Cu framp

Sorry für die späte Antwort.
Drauf gekommen bin ich durch den Systemmonitor von FHEM. Der beruht intern aus vmstat. Ich habe jetzt einfach mal 2 vmstat Ergebnisse erstellt. Dazwischen lag nur das Backup. Die Abnahme des freien Speichers ist deutlich sichtbar.

pi@raspberrypi ~ $ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 238736 19268 90044 0 0 444 9 6786 344 25 14 58 3
pi@raspberrypi ~ $
pi@raspberrypi ~ $ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 32604 55672 115044 0 0 128 3 8616 1564 9 42 48 1
pi@raspberrypi ~ $
#399 framp 2015-05-28 16:17
Moin Markus,

das sieht merkwürdig aus. Zur Problemanalyse brauche ich das Log welches beim Restore erstellt wird (Parameter -l 1 benutzen). Dann schicke mir das per eMail (Siehe Kontakt Webseite) zu und ich sehe mir das mal an.

Cu framp
#398 Markus 2015-05-28 16:07
Hi Framp,

ich habe mir mit Netinstall ein Rasbian minimal Image erstellt. Für eine rsync Backup musste ich mir rsync und parted nachinstallieren. Nun habe ich bei einem Restore das Problem das immer diese Fehlermeldung erscheint

###
fsck fied with exit status 4
failed (code 4).
[....] An automatic file system check (fsck) of the root filesystem failed. A manual fsck must be performed, then the system restarted. The fsck should be performed in maintenance mode with the root filesystem mounted in read-on
[FAILde. ... failed!
[warn] The root filesystem is currently mounted in read-only mode. A maintenence shell will now be started. After performing system maintenance, pleass CONTROL-D to terminate the maintenance shell and restart the system. ... (warning).
###

Der Fehler wird für sda1, also meinen USB Stick ausgegeben. Defekt ist der Stick nicht, den wenn ich ein Restore von einem offiziellen Rasbian erstelle funktioniert dieser. Muss ich irgendwelche Softwarevoraussetzungen erfüllen, damit dein Script sauber läuft, oder an was könnte das liegen?

Danke und Grüsse
#397 framp 2015-05-28 10:17
Moin Moritz,

bin schon dran das Script zu erweitern. Allerdings ist das eine größere Änderung die etwas Zeit benötigt.

Ich schicke Dir dann eine Betaversion der neuen Version zu und es wäre nett wenn Du es dann bei Dir ausprobieren würdest.

Cu framp
#396 Moritz 2015-05-28 09:26
Hallo framp,

habe ich so gemacht (dd), und warte dann, bis es auch mit tar funktioniert! Danke für deine Mühe!
#395 framp 2015-05-26 08:59
Moin Moritz,

vielen Dank für den Test. Ich haette gedacht dass das geht. Das muss ich mir mal genauer ansehen.

Wie ich ja schon unten geschrieben habe kannst Du momentan mit dem Script Deine 3 Partitionen nur mit einem dd Backup sichern und wiederherstellen. D.h. Du hast jetzt die 2 Optionen:

1) dd Backup benutzen
2) Warten bis ich das Script erweitert habe

Cu framp
#394 Moritz 2015-05-25 23:20
Ich habe das Skript jetzt mal mit dem auskommentierten Bereich gestartet und ein tar - Backup erstellt.

Das Skript lief erfolgreich durch, sicherte jedoch nur die ersten beiden Partitionen, die /srv erscheint als leerer Ordner.
#393 Moritz 2015-05-24 16:40
zitiere framp:
Moin Moritz,

das sieht gut aus. Dieser Check auf Noobs ist zu ungenau. Er prüft nur auf mehr als 2 Partitionen. Deine Partitionierung ist aber OK. D.h es gibt jetzt 2 Wege:
1) Du kommentierst die folgenden Zeilen im Script einfach aus (ein # an den Anfang der Zeilen schreiben)

if [[ $(fdisk -l /dev/mmcblk0 | grep "/dev/mmcblk0p" | wc -l) -gt 2 ]]; then
writeToConsole $MSG_LEVEL_MINIMAL $MSG_MULTIPLE_PARTITIONS_FOUND
exit 127
fi
2) Du wartest bis ich die Abfrage im Script auf Noobs spezifischer gemacht habe. Das wird sicherlich die nächsten Tage passieren.

Wenn Du Dich fuer 1 entscheidest möchte ich Dich bitten mir Feedback zu geben ob es dann funktioniert, denn ich müßte erst eine SD Karte mit 3 Partitionen aufsetzen um das zu testen. Wenn ich das richtig sehe sollte es für alle 3 Backuparten ohne Änderung funktionieren. Wenn Du es dann also auch für alle 3 Typen testen würdest würdest Du mir einen grossen Gefallen tun :-)

Cu framp


Vielen Dank für die Hilfe, ich teste das heute mal und gebe dir danach Bescheid!
#392 framp 2015-05-24 16:17
Moin Moritz,

leider funktioniert das doch nicht so einfach wie ich dachte :oops:

Der dd Backup und restore wird funktionieren da nur die gesamte SD Karte betrachtet wird.

Aber beim tar und rsync Backup gibt es Probleme. Momentan werden beim Restore immer nur die ersten 2 Partitionen restored. Der Backup wird zwar funktionieren - aber beim Restore wird die dritte Partition nicht angelegt werden und die Daten der dritten Partition auf die zweite Partition restored werden.

Ich sehe mir das mal genauer an ob ich das ohne grosse Änderungen hinbekomme.

Cu framp
#391 framp 2015-05-24 14:58
Moin Moritz,

das sieht gut aus. Dieser Check auf Noobs ist zu ungenau. Er prüft nur auf mehr als 2 Partitionen. Deine Partitionierung ist aber OK. D.h es gibt jetzt 2 Wege:
1) Du kommentierst die folgenden Zeilen im Script einfach aus (ein # an den Anfang der Zeilen schreiben)

if [[ $(fdisk -l /dev/mmcblk0 | grep "/dev/mmcblk0p" | wc -l) -gt 2 ]]; then
writeToConsole $MSG_LEVEL_MINIMAL $MSG_MULTIPLE_PARTITIONS_FOUND
exit 127
fi
2) Du wartest bis ich die Abfrage im Script auf Noobs spezifischer gemacht habe. Das wird sicherlich die nächsten Tage passieren.

Wenn Du Dich fuer 1 entscheidest möchte ich Dich bitten mir Feedback zu geben ob es dann funktioniert, denn ich müßte erst eine SD Karte mit 3 Partitionen aufsetzen um das zu testen. Wenn ich das richtig sehe sollte es für alle 3 Backuparten ohne Änderung funktionieren. Wenn Du es dann also auch für alle 3 Typen testen würdest würdest Du mir einen grossen Gefallen tun :-)

Cu framp
#390 Moritz 2015-05-24 14:31
Mist, zu schnell geklickt, sorry für das Chaos...

df -h sagt:

Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
rootfs 12G 5,2G 6,0G 47% /
/dev/root 12G 5,2G 6,0G 47% /
devtmpfs 484M 0 484M 0% /dev
tmpfs 98M 264K 98M 1% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 195M 0 195M 0% /run/shm
/dev/mmcblk0p1 56M 19M 37M 34% /boot
/dev/mmcblk0p3 18G 3,8G 13G 24% /srv
//192.168.2.2/NetBackup 2,7T 1,4T 1,4T 49% /media/NetBackup
#389 Moritz 2015-05-24 14:30
zitiere framp:
Moin Moritz,

poste doch bitte mal die gesamte Ausgabe von fdisk -l sowie von df -h. Da das kein NOOBs system ist denke ich ich kann da was für Dich im Script einbauen.

Cu framp


Vielen Dank für deine Antwort, da waren wir wohl gleich schnell ;), die Ausgabe hier nochmal:

fdisk -l sagt bei mir:

/dev/mmcblk0p1
/dev/mmcblk0p2
/dev/mmcblk0p3
#388 framp 2015-05-24 14:26
Moin Moritz,

poste doch bitte mal die gesamte Ausgabe von fdisk -l sowie von df -h. Da das kein NOOBs system ist denke ich ich kann da was für Dich im Script einbauen.

Cu framp
#387 Moritz 2015-05-24 13:51
Hallo nochmal, ich habe jetzt mal alle Kommentare durchsucht und das Problem gab es schon einmal und du hattest nach der Ausgabe von fdisk -l gefragt.

fdisk -l sagt bei mir:

/dev/mmcblk0p1
/dev/mmcblk0p2
/dev/mmcblk0p3

Kann ich evtl. die dritte Parition irgendwo selbst in dein Skript einpflegen?
#386 Moritz 2015-05-24 12:49
Hallo framp, ich habe dein Skript heute ausprobieren wollen, es scheitert jedoch daran, dass ich mehr als zwei Partitionen nutze, nämlich /boot, /, und /srv...wie kann ich das PProblem lösen? (Fehler rbk0013e)

Vielen Dank und schöne Pfingsten!
#385 framp 2015-05-20 23:48
Moin zYloriC,

es gibt ein undokumentiertes Aufrufflag -c. Damit wird der Test umgangen. Aber ich bin mir nicht sicher ob das Dein Problem löst. Hast Du mal geprüft ob Du Dein Nas unter dem Backuppfad gemounted hast? Was liefert denn die Ausgabe von 'mount' und wie sind Deine Aufrufparameter?
Ist auf Deiner SD Karte genügend Platz für das Backup? Auch macht es keinen Sinn das Backup auf der SD Karte abzulegen - denn das Backup ist futsch wenn die SD Karte ihren Geist aufgibt.

Zu Deiner zweiten Frage: Ich benutze nfs - aber samba/cifs funktioniert auch sehr gut. Wenn Du den Backup über Nacht laufen lässt sollte es nicht auf jede Millisekunde drauf ankommen :-)

Cu framp
#384 zYloriC 2015-05-20 23:37
Danke framp für den Hinweis!!

In einer früheren Version hat es mal geklappt... Da habe ich dann die Backups per Cron auf ein NAS geschoben.
Ist es möglich, das Speichern auf die SD zu forcieren und die Prüfung zu umgehen?

Falls nicht, was ist der performanteste Zugriff vom rPi auf ein NAS. Samba, NFS, CIFS ? Was empfehlt ihr?
Habt ihr ein Tutorial an der Hand? Danke!
#383 framp 2015-05-20 23:09
Moin zYloriC,

das Script prüft ob Dein Backuppfad ein externes Device ist. Es macht ja keinen Sinn ein Backup auf die SD Karte zu schreiben.

Prüfe mal mit mount ob Du wirklich unter dem Backuppfad -p etwas gemounted hast. Der Fehlermeldung nach nicht :-*

Cu framp
#382 zYloriC 2015-05-20 23:00
Hallo zusammen,
ich bekomme die Fehlermeldung "??? RBK0027E: No external device mounted on /backup"
an mehreren Raspberries. Ich komme nicht weiter.

Habt ihr einen Tipp. Es klappt auch nicht, wenn ich alle Parameter des Aufrufs weglasse und das Skript mit den Defaults starte. Habt ihr eine Idee?

Vielen Dank, zYloriC
#381 framp 2015-05-13 22:12
Die Idee von Raspi habe ich mal aufgegriffen und die nächste Version wird zwei Extensionpoints haben, die es erlauben vor und nach dem Backupvorgang eigenen bash Code einzubinden und z.B. CPU Temperaturen ermitteln und sie auf der Konsole wie auch per email zu berichten.

Wer das schon vor der nächsten Version ausprobieren möchte muss sich kurz melden und ich schicke dann das geänderte Script sowie zwei BeispielextensionScripts, die die CPU temperatur melden, per email.
#380 framp 2015-05-12 18:12
Nein, selbständig findet kein Update bei einer neuen Version statt. Du musst das Script schon explizit mit dem Parameter -U aufrufen.
#379 Raspi 2015-05-12 18:10
Nur eine wichtige Frage:
updatet sich das Script selbstständig und überschreibt meine Änderungen?
#378 framp 2015-05-12 18:05
Moin Raspi,

zitiere Raspi:
...Ein "echo 3 > /proc/sys/vm/drop_caches" nach dem Backup löst das Problem.

Das ist kein Problem sondern beabsichtigtes Verhalten bei Linux um die Performance zu steigern. In dem Moment wo eine Appplication Speicher braucht wird der Cache sofort für diese freigegeben. Siehe auch http://www.linuxatemyram.com/ ;-)

Vielen Dank für Deine Codeerweiterung. Ist ein nettes Feature. Ich könnte Extensionpoints ins Script einbauen wo jeder eigene Extensions wie z.B. Deine, einhängen kann. Sollte wirklich Interesse daran bestehen kann ich ja mal in einer ruhigen Zeit darüber nachdenken und es implementieren.

Cu framp
#377 Raspi 2015-05-12 16:40
Noch eine Nachricht:
das mit dem Speicherverbrauch ist mir auch aufgefallen.
Ich habe den Pi 2 und 1GB Speicher (effektiv 974MB).

Vor dem Backup sind rund 800MB RAM frei, danach etwa 50.

Ein "echo 3 > /proc/sys/vm/drop_caches" nach dem Backup löst das Problem.
#376 Raspi 2015-05-12 16:09
Ich habe dein Script bei mir auf dem Rechner um wenige Zeilen erweitert, sodass mir CPU-Temperatur vor und nach dem Update in der Konsole aus- und in der E-Mail mitgegeben werden. Vielleicht kannst du es ja übernehmen:

# Die folgende Funktion steht unter "DEFAULT_NOTIFY_UPDATE=1"
function getCPUTemp() {
local temp=$(/opt/vc/bin/vcgencmd measure_temp)
echo "CPU temperature - $(date): $(echo $temp | cut -d '=' -f 2)"
}

# Folgendes steht in sendEmail() über "case $EMAIL_PROGRAM in"
content="$content\n$(getCPUTemp)"

# Und Folgendes steht in "sendEmail()" ganz unten nach "logExit sendEmail"
echo $(getCPUTemp)

# Folgendes steht in "backup()"
echo $(getCPUTemp)
echo -e "$(getCPUTemp)\n" >> $LOG_MAIL_FILE
#375 framp 2015-05-10 12:10
Moin Wilfried,

wie hast Du die Memoryauslastung gemessen (Welches Tool) ?

Cu framp
#374 Wilfried Bauer 2015-05-10 09:23
Hi,
ich stelle in meinem Datenlogging immer wieder fest, dass nach dem Backup die Memory-Auslastung des Raspi dramatisch gestiegen ist: kurz vor dem Backup 120MB, kurz danach 260MB. Das bleibt dann auch so hoch. Ist das ein Bug, oder wie kann ich dem abhelfen? Einen automatischen Reboot nach dem Backup würde ich höchstens als peinliche Notlösung nehmen, wenn es sonst nichts "richtiges" gibt.
Das Backup mache ich mit rsync per Cronjob.
Gruß
Willy
#373 framp 2015-05-09 12:46
Interessant wie so die unterschiedlichen Interessen sind. Der Request Nr 2 http://www.linux-tips-and-tricks.de/de/verbesserungsvorschlaege/ war gerade das Script etwas gesprächiger zu machen. Bei -m 0 werden nur ein paar Infomeldungen wie Script started und stopped und saemtliche Fehler berichtet. Ich könnte jetzt -m 1 als -m 2 sowie -m1 zu -m2 umstellen und -m 0 einführen, wo wirklich nur noch Fehlermeldungen geschrieben werden. Da das aber eine inkompatible Änderung ist werde ich aber keine Änderung vornehmen.
#372 Raspi 2015-05-09 11:22
Oder eben, damit es nicht ganz so gefährlich ist:
LOG_OUTUP_ONERROR=X
(Nur bei Fehlern loggen)

Jetzt weiß ich natürlich nicht, ob du die Logs erst im Speicher zusammenbastelst und dann speicherst oder ob du on-the-fly, bei jedem logItem, speicherst.
+1 #371 framp 2015-05-08 20:18
Du möchtest also kein Log haben. Finde ich etwas gefährlich, denn dann kann man nicht nachsehen warum der letzte Backup schief ging. LOG_OUTPUT_VARLOG sollte wenigstens gewählt werden.
Aber ich nehme das mal auf meine ToDo Liste.
#370 Raspi 2015-05-08 20:10
Ich glaube es wäre auch nützlich, wenn man im nächsten Update von offizieller Seite bei
---
LOG_OUTPUT_SYSLOG=0
LOG_OUTPUT_VARLOG=1
LOG_OUTPUT_BACKUPLOC=2
---
auch "LOG_OUTPUT_NONE=X"

einfügen würde.

Insofern es das schon gibt, scheine ich es übersehen zu haben.
#369 framp 2015-05-08 19:46
Moin Raspi,

nicht ärgern :-) . Du bist schon der Zweite der über diese Tuedelchen gestolpert ist. Ich sehe mir das mal an und baue im Script was ein dass sowas als falsche Eingabe erkannt und berichtet wird.

Cu framp
#368 Raspi 2015-05-08 19:43
Das darf nicht wahr sein. Ich habe zu 99% alles richtig gemacht und nur die "Tüdelchen" vergessen -.-


Danke!
+1 #367 framp 2015-05-08 19:32
Moin Raspi,

es fehlen die Tuedelchen " am Anfang und Ende des Parameters -E :-)

Also -E "-f xyz@hotmail.de -s smtp-mail.outlo ok.com:587 -xu xyz@hotmail.de -xp password"

Cu framp
#366 Raspi 2015-05-08 19:28
Folgendermaßen rufe ich es auf:

/usr/local/bin/raspiBackup.sh -p /media/hdd1/__RaspBerry_Pi_2_Backup/ -t tar -k 4 -e xyz@hotmail.de -E -f xyz@hotmail.de -s smtp-mail.outlook.com:587 -xu xyz@hotmail.de -xp password
#365 framp 2015-05-08 19:02
Moin Raspi,

wie Markus schon schrieb - im Kommentar #339 und aufwärts steht wie es geht. Auch findest Du bei der Beschreibung des Parameters -E das exakte Format und die Parameter für sendEMail. Diese Parameter entweder per -E mitgeben oder die DEFAULT_EMAIL_PARMS entsprechend setzen.

Wenn Du es nicht hinbekommst schreibe doch mal exakt per Copy und Paste welche Parameter Du bei -E bzw DEFAULT_EMAIL_PARMS angibst.

Cu framp
#364 Raspi 2015-05-08 18:19
Selbst wenn ich die DEFAULT_EMAIL_PARMS ändere passiert absolut nichts.

Schau dir mal meinen Kommentar #358 an.
#363 Markus 2015-05-08 17:08
Lies mal ab Kommentar 339 aufwärts, da sollte deine Frage beantwortet werden ;-)
#362 Raspi 2015-05-08 16:33
Ich habe vergessen etwas hinzuzufügen:

hiermit rufe ich mein Script auf:
/media/doBackup.sh

In doBackup.sh ist das hier:
/usr/local/bin/raspiBackup.sh -p /media/hdd1/__RaspBerry_Pi_2_Backup/ -t tar -k 4

Das funktioniert alles.

Aber wenn ich
-e xyz@hotmail.de
dran hänge, wird nichts verschickt.

Und damit alleine kann ich aber Mails schicken:
sendEmail -f xyz@hotmail.de -t xyz@hotmail.de -u "Backup" -m "Device xxx has sucessfully created a backup" -s smtp-mail.outlook.com:587 -xu xyz@hotmail.de -xp password
#361 Raspi 2015-05-08 16:10
Was genau muss man denn angeben, damit auch endlich mal eine Mail gesendet wird?
Mein "sendEmail" ist korrekt konfiguriert, aber das Script denkt nicht daran eine Mail zu verschicken.

Kann jemand evtl einen kompletten Befehl hier posten mit den Paremetern -xu, -xp und smtp?

(Falls ihr meine Mail sehr, nicht wundern: ist eine Spam-Mail)
#360 slor 2015-04-29 08:07
Disk /dev/nand: 7.2 GiB, 7700742144 bytes, 15040512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbe67cfb1

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 312581807 312579760 149.1G 83 Linux
#359 framp 2015-04-28 18:00
@Christian: Ist eine gute Idee das mal zu testen. Wenn es Probleme gibt oder Du Fragen hast melde Dich hier. Wäre doch gut wenn das Script auch auf anderen Systemen als der Pi einsetzbar wäre ;-)

@slor: Sollte prinzipiell kein Problem sein. Dazu muss ich aber wissen wie die Partitionen heissen. Poste doch mal bitte die Ausgabe von 'fdisk -l'. Dann kann ich ja mal fuer Dich einen spezielle Version erstellen ;-)

Generell bin ich durchaus bereit das Script anzupassen und zu erweitern fuer andere HW, sofern sich der Aufwand im Rahmen haelt. Allerdings kann ich nichts testen, da mir die HW fehlt. D.h. Ihr müßtet bereit sein für mich zu testen und mir Fehler berichten und Logs zuschicken.

Eina Anmerkung noch: Die erste Partition sollte sich so gut wie nie ändern, denn die wird vom Script nur einmal gesichert. Sollte das doch der Fall sein müßte ich das noch erweitern. Da das aber etwas größerer Aufwand ist würde ich das nur machen wenn das Script ansonsten auf der anderen HW läuft. Zum Testen ist es ja erst einmal unwichtig das auch die erste Partition immer gesichert wird.

Cu framp
#358 slor 2015-04-28 13:51
Hm, das hat mein Cubie natürlich nicht.
Hab Nand und ne SSD.
Könnte man das im Script als Variable einbauen? Bzw erst mal mit einem schalter abfragen und dann in eine Variable übernehmen?
#357 Christian 2015-04-28 13:41
Hallo,

ich werde es die Tage mit Odroid XU-3 mal testen, aber hier heißen die Partitionen tatsächlich genauso. Ich könnte mir aber vorstellen, dass das Partitionsschema so bei den meisten Einplatinencomputern lauten wird (viele sind ja auch an Raspberry angelehnt), soweit SD- oder MMC-Karten zum Einsatz kommen (beim XU-3 nutze ich MMC) und die gleichen Werkzeug wie PiBaker zur Erstellung der SD-Karten-Images verwendet werden (können).

Grüße,
Christian
#356 framp 2015-04-28 11:45
Moin slor,

es muessen 2 Partitionen

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 15564799 7720960 83 Linux

existieren die genau den Namen haben muessen. Die Groess ist egal.

Dann sollte es eigentlich funktionieren.

Cu framp
#355 slor 2015-04-28 10:23
Danke erst mal für diesen umfangreichen Artikel!
Kann man das Script auch auf anderen Einplatinen Rechnern z.b. Cubietruck laufen lassen? Oder ist das spezifisch an den Raspi angepasst?
#354 framp 2015-04-20 21:33
Moin bcutter,

wie bei den Aufrufparametern beschrieben ist werden das Programm mail, ssmtp und sendEMail unterstützt. Bei letzterem muss man noch weitere Parameter per -E angeben.
Ich selbst benutze exim4 welches das Program mail beinhaltet. Auch andere eMailprogramme wie Postfix oder sendmail beinhalten mail - sind aber sehr mächtig und nicht einfach zu konfigurieren.
Im Normalfall reicht ssmtp zu installieren und zu konfigurieren und ist wohl auch am einfachsten zu konfigurieren.
sendEMail ist auch verbreitet und Support dafür habe ich dann auf Nachfrage eingebaut. Allerdings ist dann noch was zusätzlich bei -E zu definieren.

Such Dir eine Alternative aus und befrage die Suchmaschine Deines Vertrauens zu den Details :-)

Cu framp
#353 bcutter 2015-04-20 21:20
Andere Frage:
Ich hatte bisher noch nie eine Mail erhalten, eMail ist beim Aufruf mit angegeben als Parameter. Woran liegt das, was fehlt meinem Pi? Ich vermute ich muss noch einen Mailserver angeben/installieren und mit Parameter "-E" die Details wie Host, Loginname, Port und Passwort mitgeben oder?
#352 bcutter 2015-04-20 21:14
Also mein Problem hat sich dank framp in wenigen Minuten geklärt: Der Cronjob war bei mir falsch. Der job wurde jede Minute zur ausgewählten Stunde gestartet, das hat den Pi überfordert. Danke für die astreine schnelle Hilfe und natürlich für das klasse Skript an sich!
#351 framp 2015-04-19 20:01
Moin bcutter,

das ist sehr merkwürdig. Man sieht sehr deutlich dass jede Minute ein tar Backup erstellt wurde. Allerdings sind das keine 5GB. Ich könnte mir vorstellen, dass Deine Crondefinition nicht korrekt ist. Oder dass Du aus irgendeinem Grunde das Backupscript rekursiv aufrufst.

Poste doch mal Deine Crondefinitionen und wie Du das Script aufrufst - ich meine - benutzt Du z.B. das Wrapperscript und wie sehen die Aufrufparameter aus bzw das Konfig File.

Cu framp
#350 bcutter 2015-04-19 19:39
Hi,

nachdem mein Pi heute planmäßig per Cron um 16 Uhr raspiBackup gestartet hat, war er gegen 16:29 Uhr tot - also heruntergefahren/außer Betrieb/nicht mal mehr pingbar.

Das raspiBackup.log habe ich, sagt aber wenig aus. Anscheinend wurde immer wieder versucht, das tar-Backup zu schreiben; in der Tat liegen im Backup-Zielverzeichnis auch diverse "angebrochene" TAR-Files (volle Größe sollten knapp 5 GB sein), Foto siehe http://bit.ly/1zy79Hq.

Was ist hier passiert? Ich hatte dein Skript mit großer Begeisterung letzte Woche aufgesetzt und 2x manuell erfolgreich ausgeführt (den cron manuell gestartet). Kann es mir nicht erklären, hoffe du hast eine Idee.

- Lag es an laufenden Diensten?
- Wird die zu bevorratende Anzahl von Backups nicht eingehalten?
- Info: Nutze V0.5.14.8
#349 Franzens 2015-04-04 14:27
ja stimmt - hier gabs nur meinen eigenen Text
Danke nochmals

Franzens
#348 framp 2015-04-04 11:08
Moin Franzens,

vielen Dank für den Test. Ich werde das noch dokumentieren. Allerdings ist mir eben noch aufgefallen, dass Du auch -m in -E drin hast. Das solltest Du auch noch rausnehmen, da das Script Dir sonst keinen entsprechenden Mailinhalt schicken kann ;-)

Cu framp
#347 Franzens 2015-04-04 11:00
Guten Morgen,

habs nochmal getestet mit folgendem Aufruf in der raspiBackup.conf:
# Weitere Parameter für eMailProgramme
DEFAULT_EMAIL_PARMS="-f absender.mail@absenderdomain -m Inhalt -s smtp-server:587 -xu Username -xp Password"

als Ergebnis bekam ich via sendEmail nach Abschluss des Backups eine Mail an die unter
# Benachrichtigungsemaladresse angegebene Mailadresse mit dem Betreff "name_des_raspis: Backup erfolgreich beendet"

Danke für die schnelle Hilfe!

Franzens
#346 framp 2015-04-03 22:24
zitiere Franzens:
...vermutlich müsste es sogar funktionieren wenn auf die Angaben unter
# Benachrichtigungsemaladresse und
# mailprogram

verzichtet wird
Das Mailprogramm muss definitiv angegeben werden. -u und -t werden automatisch auch gesetzt vom Script. Wenn Du die Parameter in -E mitgibst erhält sendEmail die Parameter zweimal. Wenn es trotzdem funktioniert ist sendEmail offensichtlich so tolerant und akzeptiert die Parameter mehrere Male. Ich empfehle aber sie aus -E herauszunehmen, denn ansonsten kann speziell der Betreff in der eMail nicht richtig vom Script gesetzt werden.

Wenn Du bitte noch mal testen könntest ohne -u und -t in -E und das Ergebnis hier mitteilen würdest - dann werde ich die Doc beim Parameter -E noch für sendEmail anpassen.

Cu framp
#345 Franzens 2015-04-03 22:02
Danke für die schnelle Antwort - habs umgehend getestet: so funktioniert der Aufruf in der raspiBackup.Conf:

# Weitere Parameter für eMailProgramme
DEFAULT_EMAIL_PARMS="-f absender.mail@absenderdomain -t empfänger@empfängerdomain -u Betreff -m Inhalt -s smtp-server:587 -xu Username -xp Password"

vermutlich müsste es sogar funktionieren wenn auf die Angaben unter
# Benachrichtigungsemaladresse und
# mailprogram

verzichtet wird
#344 framp 2015-04-03 17:51
Moin Franzens,

zu 1) Ja das reicht wenn Du es in der Befehlszeile ohne Parameter aufrufst und alles funktioniert. Nur muss natürlich der Aufruf des Scripts wie im Beispiel oben den ganzen Pfad für das Script benutzen. Alle anderen Parameter werden dann aus der Konfig gelesen.
zu 2) Ich benutze sendEmail nicht. Aber in einem Kommentar http://www.linux-tips-and-tricks.de/de/raspibackup/#comment-392 hat ein Scriptbenutzer geschrieben wie es aufzurufen ist. Dort musst Du nur Deine individuellen Werte anpassen.

Cu framp
#343 Franzens 2015-04-03 16:49
Klasse Lösung. Habe auch fast alles zum Laufen gebracht - zunächst also erst mal Danke für Deine Arbeit.
2 Fragen tauchten allerdings noch auf:
1.) Da ich die raspiBackup.conf nutze müsste doch der Aufruf in der crontab ohne weitere Parameter funktionieren - zumnindest reicht der Aufruf in der Konsole mit raspiBackup.sh zu einem sauberen Backup?
2.) ich nutze SendEmail und bekomme nach dem Backup statt einem Mail immer einen Fehler, wonach scheinbar Absenderdaten fehlen. sendEmail funktioniert so aber. Kann es an den weiteren EMail-parms liegen - und wenn, was muss da rein wenn ich web.de nutze?

Danke
#342 Friesen 2015-03-13 22:54
zitiere framp:
Nein, denn Du musst das Script ja immer als root aufrufen. Dann ist kein sudo mehr notwendig.

Das dache ich mir auch gerade. Danke, Backup ist gerade am laufen. Danke für die schnelle Antwort. Du bist klasse!
#341 framp 2015-03-13 22:49
Nein, denn Du musst das Script ja immer als root aufrufen. Dann ist kein sudo mehr notwendig.
#340 Friesen 2015-03-13 22:47
zitiere framp:
Moin Friesen,

anstatt
"/etc/init.d/nginx stop";"/home/seafile/seafile-server-latest/seahub.sh stop";"/home/seafile/seafile-server-latest/seafile.sh stop";"/etc/init.d/php5-fpm stop"

nimm mal

"/etc/init.d/nginx stop;/home/seafile/seafile-server-latest/seahub.sh stop;/home/seafile/seafile-server-latest/seafile.sh stop;/etc/ini t.d/php5-fpm stop"

;-)

Du musst nur alle Befehle insgesamt einmal in Tueddelchen schreiben ...

Cu framp

muss ich sudo vor jedem Befehl stellen?
Danke
#339 framp 2015-03-13 22:35
Moin Friesen,

anstatt
"/etc/init.d/nginx stop";"/home/seafile/seafile-server-latest/seahub.sh stop";"/home/seafile/seafile-server-latest/seafile.sh stop";"/etc/init.d/php5-fpm stop"

nimm mal

"/etc/init.d/nginx stop;/home/seafile/seafile-server-latest/seahub.sh stop;/home/seafile/seafile-server-latest/seafile.sh stop;/etc/ini t.d/php5-fpm stop"

;-)

Du musst nur alle Befehle insgesamt einmal in Tueddelchen schreiben ...

Cu framp
#338 Friesen 2015-03-13 22:29
Hallo Zusammen,
ich versuche gerade dieses tolles Script noch einwenig auszureizen. Bevor das Backup startet sollten alle relevante Dienste gestoppt werden. Im Script habe ich die Stelle dafür gefunden und folgenderweise ausgeführt:
# commands to stop services before backup separated by ;
DEFAULT_STOPSERVICES="/etc/init.d/nginx stop";"/home/seafile/seafile-server-latest/seahub.sh stop";"/home/seafile/seafile-server-latest/seafile.sh stop";"/etc/init.d/php5-fpm stop"

Anschließend sollen die Dienste wieder starten.
# commands to start services after backup separated by ;
DEFAULT_STARTSERVICES="/etc/init.d/nginx start";"/home/seafile/seafile-server-latest/seahub.sh start-fastcgi";"/home/seafile/seafile-server-latest/seafile.sh start";"/etc/init.d/php5-fpm start"

Beim beenden der Dienste bekomme ich schon Fehler: Datei oder Verzeichnis nicht gefunden.

Daher meine Frage, wie sollen die Einträge für das Stoppen bzw. Starten der Dienste aussehen?
Danke
#337 framp 2015-03-01 19:04
Moin Christian,

nein, Du machst alles richtig. In der 0.5.12 ist da noch ein Bug :oops: (-> http://www.linux-tips-and-tricks.de/de/versionshistorie/). Du musst den aktuellen Stand noch einmal manuell runterladen. Dann sollte es aber zukünftig funktionieren :roll:

Cu framp
#336 Christian 2015-03-01 18:57
Hallo,

was mache ich beim updaten falsch? Ich habe -U aufgerufen, aber es wird nur das alte Skript weggesichert und kein neues dazu gespeichert. Was wird hier eigentlich genau ausgeführt?

root@raspberry ~ # raspiBackup.sh -U
mv: Aufruf von stat für „raspiBackup.sh~“ nicht möglich: Datei oder Verzeichnis nicht gefunden
chown: Zugriff auf „/usr/local/bin/raspiBackup.sh“ nicht möglich: Datei oder Verzeichnis nicht gefunden
chmod: Zugriff auf „/usr/local/bin/raspiBackup.sh“ nicht möglich: Datei oder Verzeichnis nicht gefunden
--- RBK0072I: /usr/local/bin/raspiBackup.sh von Version 0.5.12 durch die aktuelle Version 0.5.14.2 ersetzt. Die vorherige Verion wurde als /usr/local/bin/raspiBackup.sh.old gesichert

Mit freundlichen Grüßen,
Christian Heutger
#335 ron 2015-02-23 14:24
Hi Framp...
...habe dein Script manuell zum laufen gebracht :-) es lag in der Tat an dem falsch gemounteten Netzlaufwerk... danke nochmal für die Unterstützung und für das coole Tool! ;-)
#334 framp 2015-02-22 21:24
Die neueste Version 0.5.11 macht jeden darauf aufmerksam, wenn es eine aktuellere Scriptversion gibt. Auch muss nun -z angegeben werden um zip bei tar und dd zu benutzen. Die alten Backuptypen werden aber noch unterstützt. Ist aber nicht dokumentiert :-*
#333 framp 2015-02-21 22:21
Moin ron,

sorry - ich habe eben Deinen Post aus Versehen gelöscht :-(. Ich zitiere ihn hier noch mal:

zitiere ron:

Hi Framp...
... soweit ich weiß ist da nix gemounted. Das Script legt auch das neue Verzeichniss (_backup) zusammen mit einem Unterverzeichniss (RonRaspberian) an. Die Rechte für das Verzeichniss sind rwxr-xr-x ...vllt.hilft dir das weiter


Damit man nicht aus Versehen sein Backup auf die SD Karte 'sichert' prüft das Script, ob die Sicherung auf einem externes Device erstellt wird. Wenn nicht, wird diese Fehlermeldung geschrieben.

Poste doch mal Deine Aufrufparameter des Scripts sowie die Ausgabe von mount.

Cu framp
#332 Framp 2015-02-21 19:27
Moin ron,

es müssen exakt 2 Partitionen existieren. Die Fehlermeldung ist nicht ganz korrekt :oops: muss ich fixen. Aber Du hast ja selbst das Problem isoliert. Die zweite Meldung sagt, dass Dein Backuppfad auf kein externes Laufwerk zeigt. Hast Du unter /backup was gemounted ?

Cu framp
#331 Framp 2015-02-21 19:19
Moin Wilfried,

Das Windowstool heißt Win32DiskImiger. Du kannst aber auch ein raspbian auf Deiner Pi auf einer weiteren SD starten und damit dann Dein Backup unter Linux auf Deine Backup SD auf einen Cardreader zurückspielen.

Cu framp
#330 ron 2015-02-21 17:32
hi framp...

...danke für die schnelle Antwort! Ich habe die Swap Partition erfolgreich mit gparted gelöscht und wo ich schon dabei war gleich die alte Raspbian Partition mitentsorgt. Dummerweise bekam ich dann beim ausführen des Scriptes die Fehlermeldung "Keine Datenpartition mmcblk0p1 gefunden" obwohl mmcblk0p1 als root partition noch vorhanden war. Nachdem ich dann aus dem unallocated discspace eine neue Partition erstellt hatte (mmcblk0p2) bekam ich die Fehlermeldung "Keine Platte an /backup verbunden" vllt. hast du noch einen weiteren Tip für mich :roll:
#329 Wilfried Bauer 2015-02-21 17:00
Hi,
ich lese im Text "Das dd Backup kann man auch mit Windows zurückspielen." Leider finde ich nirgends, wie ich das anstelle.

Mein einziger Linuxrechner ist der Raspi. Wenn dessen SD-Karte kaputt ist muss ich per Windows das DD-Backup auf die neue Karte zurück kopieren - wie schaffe ich das?
#328 framp 2015-02-21 16:30
Moin ron,

man legt zwar normalerweise bei Linux eine separate Partition für swap an - aber bei der Pi sollte man keine Swappartition benutzen bzw das swapping sogar explizit ausschalten, denn dadurch wird die Pi ungemein langsam wenn sie wirklich swapspace braucht. Auch tut das der SD Karte nicht gut.

So wie ich verstehe brauchst Du auch die 2te und 3te Partition nicht, da Du alles auf den USB Stick verschoben hast. Zum Booten wird aber natürlich immer noch die erste Partition auf der SD Karte benötigt.

Die einfachste Lösung ist, Du löschst einfach die dritte swap Partition auf der SD Karte mit fdisk.

Cu framp
#327 ron 2015-02-21 16:21
Hallöchen ich hätte da mal ein Problem wobei ihr mir hoffentlich behilflich sein könnt :roll: ...ich habe Raspbian auf einem pi2 laufen, installiert ist es auf einem USB Stick (/dev/sda2) auf dem Stick befindet sich außerdem noch eine Partition(/dev/sda1) welche unter media/boot warum auch immer eingehangen ist. Auf der SD Karte habe ich 3 Partitionen (/dev/mmcblk0p1) = /boot (/dev/mmcblk0p2) =alte Raspian Installation (wird nicht benötigt) und (/dev/mmcblk0p3) = Partition auf welcher swap als Datei genutzt wird. Leider bekomme ich mit der config das Script nicht zum laufen. Mein Versuch das Script ohne crontab laufen zu lassen wird mit "Mehr als zwei Partitionen mmcblk0p gefunden (Wird vielleicht NOOBS benutzt?" quitiert. Ich gehe mal davon aus das das Script irgendwie modifiziert werden müsste damit es die richtigen Partitionen sichert. Da ich allerdings absoluter Linux Neuling bin :oops: weiß ich nicht wo oder was ich da ändern sollte. Vielleicht habt ihr ja eine Idee :-)
#326 norne 2015-02-18 18:11
Daumen hoch! Wirklich feine Arbeit und Doku. Vielen Dank für Deine Mühen. Ich hab so etwas gesucht und es bei dir gefunden. Vielen Dank noch mal.
#325 framp 2015-02-18 11:56
Heute bin ich endlich mal dazu gekommen Eure Änderungs- und Verbesserungsvorschäge der letzten Zeit zu sammeln -> http://www.linux-tips-and-tricks.de/de/raspberry/431-raspibackup-sh-verbesserungs-und-aenderungsvorschlaege. Sollte ich was vergessen haben bitte darauf hinweisen und ich nehme das Fehlende noch in der Liste mit auf.
#324 framp 2015-02-18 10:47
Moin Wilfried,

/var/cache ist nicht angeraten zu excluden denn es kann dann Probleme beim restoreten System geben. Swapping sollte auf einer Pi nicht enabled sein und dann gibt es diese Datei auch nicht. Falls Du sie doch hast bin ich mir nicht sicher ob sie wieder automatich beim Booten angelegt wird. Das müßte man mal testen.

Cu framp
#323 Wilfried Bauer 2015-02-17 22:23
Habe grade mal das erste erfolgreiche Backup (rsync) gecheckt. Wäre evtl.

DEFAULT_EXCLUDE_LIST="--exclude=/var/swap --exclude=/var/cache/*"

sinnvoll, um das Backup zu verkleinern?
#322 framp 2015-02-17 17:40
Moin Wilfried,

Deinen zweiten identischen Post, den Du versehentlich erstellt hat, werde ich löschen :-)

Zu Deiner Frage: Bei mir sieht er z.B. in der Configdatei wie folgt aus:

DEFAULT_EXCLUDE_LIST="--exclude=/backup/* --exclude=/rsnapshot/* --exclude=/www-data*/*"

Alternativ kannst Du den Text dann mit -u "......" beim Aufruf mitgeben.

Cu framp
#321 Wilfried Bauer 2015-02-17 17:30
Super Tool !!!
Kleine Frage noch zu
"-u Erweiterung der Excludeliste beim Backup um bestimmte Verzeichnisse beim Backup zu ignorieren. Achtung: Die Parameter müssen der jeweiligen Syntax des Backuptools gehorchen."

Wäre dann z.B.
-u /backup/*

der richtige Parameter? Mit
-u /backup (ohne /* dahinter)

hatte es jedenfalls nicht geklappt.
#320 Wilfried Bauer 2015-02-17 17:28
Super Tool !!!

Kleine Frage noch zu
"-u Erweiterung der Excludeliste beim Backup um bestimmte Verzeichnisse beim Backup zu ignorieren. Achtung: Die Parameter müssen der jeweiligen Syntax des Backuptools gehorchen."

Wäre der richtige Parameter für rsync dann z.B.
-u /backup/* ?

Mit -u /backup (ohne /* dahinter) hatte es jedenfalls nicht geklappt.
#319 Kevin 2015-02-12 08:58
Alles klar, danke für die Rückmeldung. Danke, dass du es auf die ToDo-Liste setzt! :)
zitiere framp:
Moin Kevin,

ich verstehe dass diese Meldung irritierend ist. Wie Du schon schreibst, ist der restore erfolgreich. Das scheint ein Problem mit fdisk zu sein dass gpt nicht unterstützt ist.
Da der restore -wie Du ja auch festgestellt hast - OK ist - habe ich da bislang nicht weiter reingesehen. Gerade gestern hat meine SD Karte meines LAN Servers seinen Geist aufgegeben und der restore vom Wochenende funktioniert wieder perfekt. Auch heute habe ich eine Pi restored da die rpm Änderungen durch die Pi2 ein anderes System inoperable gemacht haben. Nach dem restore der Wochensicherung funktioniert wieder alles.

Kurzum:

Wichtig ist zu testen dass der restore auf einer anderen SD funtioniert. Das habe ich schon diverse Male durchexzerziert bzw getestet und funktioniert. Ich denke die Meldung kannst Du ignorieren.

Aber ich nehme das mal mit und untersuche das wie man diese Meldung beseitigen kann. Da ich gerade ziemlich viel um die Ohren habe wird das wohl noch etwas dauern. Aber wie gesagt: Wenn Dein restore wieder funktioniert brauchst Du Dir keine Sorgen zu machen :-)

Cu framp
#318 framp 2015-02-11 23:10
Moin Kevin,

ich verstehe dass diese Meldung irritierend ist. Wie Du schon schreibst, ist der restore erfolgreich. Das scheint ein Problem mit fdisk zu sein dass gpt nicht unterstützt ist.
Da der restore -wie Du ja auch festgestellt hast - OK ist - habe ich da bislang nicht weiter reingesehen. Gerade gestern hat meine SD Karte meines LAN Servers seinen Geist aufgegeben und der restore vom Wochenende funktioniert wieder perfekt. Auch heute habe ich eine Pi restored da die rpm Änderungen durch die Pi2 ein anderes System inoperable gemacht haben. Nach dem restore der Wochensicherung funktioniert wieder alles.

Kurzum:

Wichtig ist zu testen dass der restore auf einer anderen SD funtioniert. Das habe ich schon diverse Male durchexzerziert bzw getestet und funktioniert. Ich denke die Meldung kannst Du ignorieren.

Aber ich nehme das mal mit und untersuche das wie man diese Meldung beseitigen kann. Da ich gerade ziemlich viel um die Ohren habe wird das wohl noch etwas dauern. Aber wie gesagt: Wenn Dein restore wieder funktioniert brauchst Du Dir keine Sorgen zu machen :-)

Cu framp
#317 Kevin 2015-02-11 22:35
Hallo,

ich habe mir einen Raspberry Pi 2 zugelegt. Da ich das System (SD-Karte) neu aufgesetzt habe, will ich auch dein klasse Backup-Skript wieder nutzen.
Ich habe das Skript einmal direkt zum testen aufgerufen - nicht über Cron.
Ich bekomme dann folgende Meldung ausgespuckt:
"WARNING: GPT (GUID Partition Table) detected on '/dev/mmcblk0'! The util fdisk doesn't support GPT. Use GNU Parted."
Der Backupprozess läuft aber dennoch korrekt durch. Das Image scheint auch korrekt zu sein und der Raspberry startet auch mit dem zurückgespielten Image von einer anderen SD-Karten problemlos.
Muss ich die Meldung beachten?
Ich habe einmal GPartet installiert - die Meldung kommt weiterhin.
#316 framp 2015-02-08 19:29
Lass uns mal offline kommunizieren und die Subscriber nicht länger nerven
#315 Christian 2015-02-08 19:26
Hallo,

lol, ich meinte nicht das Update, ich meinte eine "Einsicht", welche Version(snummer/release/...) gerade aktuell ist. ;-)

Mit freundlichen Grüßen,
Christian Heutger
#314 framp 2015-02-08 19:11
Moin Christian,

die aktuelle Version bekommst Du wenn Du den -U Parameter des Scripts benutzt :-)

Cu framp

loool ... Recaptcha will gerade moin als Eingabestring
#313 Christian 2015-02-08 19:05
Moin moin,

vielen Dank für das Feedback. Gibt es denn bereits eine Möglichkeit, die aktuelle Version einzusehen? Bzw. wie kann man das CVS einsehen?

Und gerne, bin sehr begeistert von dem Skript.

Mit freundlichen Grüßen,
Christian Heutger
#312 framp 2015-02-08 17:58
Moin Christian,

zu meiner Schande muss ich gestehen, dass das logging tatsächlich nicht auszuschalten war :oops: Es fehlten ein paar Abfragen im Code. Die aktuelle Version schreibt wirklich keine debug Zeilen mehr bei -l 0.

Ja, ich habe Meldungen über den Fortschritt des Backups rausgenommen. Dazu gehört auch das Timing. Das kann man ja direkt über die Start und Endemeldung und deren Zeit herausfinden. Mir persönlich genügt das - aber ich werde bei -m 1 in der nächsten Version wieder gesprächiger sein.

Bislang habe ich immer das cvs Changelog gepostet. Aber die Kommentare sind sicherlich eher was für mich. Ich nehme den Punkt mit und überlege mir wie ich Änderungen besser für die Scriptbenutzer dokumentieren kann.

tgz ist bei den Parametern für -t beschrieben. Aber es ist sicherlich ein valider Punkt mal die gesamte Info auf dieser Seite zu updaten.

Historisch bedingt wird das zip über den -t Typ gesteuert. Nachdem dann zuerst die Forderung nach ddz kam, dann auch die Forderung nach tgz kam war dieses am einfachsten einzubauen. Ein Parameter -z bedeutet mehr Änderungsaufwand. Ich behalte das mal im Hinterkopf und werde das in einer zukünftigen Version einbauen.

Danke für Dein konstruktives Feedback.

Cu framp
#311 Christian 2015-02-08 17:10
Moin moin,

ok, würde erfordern, die Dokumentation zu aktualisieren, die Konfiguration oben wie auch das Beispiel im Skript sieht noch weitere Loglevel vor. Bisher waren hier Ausführzeiten dokumentiert wie auch sich bei Sicherung ändernde Dateien, entfernte trailing slashes usw., das hätte mir gereicht. ;-) In den Meldungen war der Anfang der Ausführung dokumentiert wie auch die einzelnen Schritte, Sicherung des Bootimages (oder auch nicht und warum), der Partitionstabelle und des Master Boot Records, Beginn des "eigentlichen" Backups und Ende desselben. Derzeit sind die Meldungen etwas wortkarg, ich hatte vorher auch die Konfigurationsdatei ohne MSG-Setting (hab mich hier an der Dokumentation im Skript orientiert), danach mit 1, konnte aber keine Änderung feststellen.

Mailen erledige ich derzeit (zusätzlich) für den Wrapper via Cron, durchaus würden mir auch reine Meldungen reichen, die ich mir so maile, persönlich bin ich durchaus ein Freund von zusammenhängenden Funktionen (also auch Mail, vgl. bspw. apticron), durchaus übertreiben es manche Linuxdienste wie systemd damit.

Das ist durchaus richtig, ich finde die Weiterentwicklungen aber Klasse und monitore daher auch diese Website über Änderungen (wobei ein Changelog besser wäre, als das aus den Kommentaren "zu fischen"), sicherlich wäre ein Autoupdate gefährlich, daher meine Rückfrage und die Rotationen bei Update (als möglichen Workaround). Fehler im Skript bekommt man ja durchaus durch die Mails mit.

Die Konfigurationsbeispiele hatten bisher tgz mit behandelt, inzwischen finde ich tgz nur noch in der Vergleichstabelle. Wer es nicht kennt, kommt nicht mehr darauf, dass es eine mögliche Option ist. Im Hinblick auf die optimierten Parameter wäre ein genereller ZIP-Parameter eine gute Idee, mit dem man (egal welche (passende/sinnvolle) Funktion) ZIP aktiviert, also bspw. für DD, TAR.

Mit freundlichen Grüßen,
Christian Heutger
#310 framp 2015-02-08 16:39
Moin Christian,

ein langer Kommentar von Dir - aber ist gut sich hier zu melden wenn man Dinge hat die einem Aufgefallen sind.

Das ganze System mit dem Debug und den Meldungen habe ich vereinfacht. Es gibt nur entweder debug (-l 1) oder eben nicht (-l 0). Ausserdem gibt es Standardmeldungen (-m 0) bzw erweiterte Meldungen zum Fortschritt (-m 1). genaugenommen braucht man die Parameter für -l und -m nicht mehr denn es ist ja nur noch ein anschalten und keine Alternativwahl.

Man braucht die Parameter nur wenn man Fehler sucht. Ansonsten interessiert nur ob alles OK war oder nicht. Wenn wichtige Meldungen fehlen bei -m 1 lasse mich wissen welche wichtig sind und ich baue sie ein.

Die Funktion des Scripts ist, ein Backup zu erstellen. Alles Andere sollte in einem Wrapperscript vorgenommen werden. Das ist die Linuxphilosophie: Jedes Programm soll genau das tun wofür es gedacht ist. Alle weitere Funktion sollen andere Programm vornehmen, die dazu geschrieben wurden (z.B. lftp, ). Eigentlich gehört auch der eMailKram dazu. Aber da das etwas kniffelig ist habe ich die Funktion mit ins Script eingebaut.

Ich rate dringend davon ab die Updatefunktion per cron automatisch laufen zu lassen. Ich kann nicht garantieren, dass eine neue Version immer fehlerfrei ist - was leider schon vorgekommen ist :oops: denn dann funktioniert der Backup nach dem Update nicht mehr. Die Updatefunktion ist nur dazu gedacht, mal eben schnell einen Fix, den ich nach einem Fehlerbericht erstellt habe, zu holen. Nachdem man den aktuellen Stand des Scripts erfolgreich getestet hat würde ich keinen Update des Scripts mehr vornehmen und 'Never touch a running script' befolgen. Ausser es gibt neue Funktionen die man dringend haben möchte oder es gibt einen Fix für einen Fehler, den man gefunden und reported hat. Danach sollte man dann auch wieder testen, dass der Backup OK ist. Nichts ist so ärgerlich als wenn man im Backupfall feststellt, dass das Backup nicht zu gebrauchen ist :sigh:

Ich werde Deine Anregung bzgl Backupversionen des Script beim Update in einer nächsten Version aufnehmen.

Was meinst Du mit 'tgz ist hier bspw. fast überall als Auswahl entfallen'?

Cu framp
#309 Christian 2015-02-08 11:23
Hallo,

ich habe von NOOBS auf ein eigenes System mit Raspberry "geupdated". Ich kann inzwischen von NOOBS sogar nur abraten, denn bspw. mit Wechsel auf Raspberry Pi 2 gab es direkt Probleme, man hätte auch NOOBS updaten müssen, was nicht geht.

However, ich habe bei der Gelegenheit auch den Skript upgedated und habe nun drei Fragen:

Die Logs laufen nicht mehr wie vorher, ich habe nun viel zu viel Debuginformationen darin, steht auch DBG davor, auch Nachrichten werden mit MSG angezeigt. Ich habe aber weder Verbose noch Debugging an. Log Level hatte ich erst 3, dann wieder 1, kein Unterschied jedoch. Wie kann ich das zurückstellen?

Die Messages in der Mail hingegen sind gegenüber vorher massiv weniger als vorher, da gab es vorher Infos zu den IMG und MBR Dateien sowie zu Zeiten, alles entfallen. Dabei habe ich (fehlt in obiger Beispielkonfiguration) den Messagelevel auf 1 gestellt. Kein Unterschied jedoch. Wie kann ich das zurückstellen?

An sich würde mir inzwischen ein informativer Output in der Ausführung reichen, da ich sowieso den gesamten Cronjon (ähnlich dem Wrapper, aber bei mir anders) mir per Mail schicken lasse (2>&1).

Alternativ wäre eine Einbeziehung von lftp genial, ich nutze das als nachgelagerten Skript upload.sh nach dem Backup und synce so mein Backup lokal noch mal in die Cloud.

Eine Frage hätte ich noch, und zwar wenn ich den Updateparameter angebe und das mit crone, mache ich das als extra cron oder würde dann bspw. geupdated UND anschließend gebackuped? Aus Sicherheitsgründen würde ich alte Skripte immer als .old aber auch in Rotation .old.1, .2 usw. sichern lassen. Natürlich müsste die Config dann stets alte Optionen berücksichtigen, tgz ist hier bspw. fast überall als Auswahl entfallen. Update sollte auch ein Configparameter werden, an sich ist es besser, das alles über die Config zu steuern.

Es ist uns bleibt ein Superskript, vielen Dank für den ganzen Aufwand.

Mit freundlichen Grüßen,
Christian Heutger
+1 #308 framp 2015-01-18 21:34
Es wurde gewünscht, dass sich das Script selbst updaten kann. Das ist jetzt möglich mit dem Parameter -U: Sofern eine alte Version lokal vorliegt wird die bisherige Version in raspiBackup.sh.old umbenannt und durch die neueste Version ersetzt.
#307 framp 2015-01-10 22:14
Da es vermehrt Anfragen und Probleme mit einer Synology als Backupserver gibt und ich keine Synology besitze und bei Problemen damit nicht helfen kann, habe ich die folgende Webseite erstellt: http://www.linux-tips-and-tricks.de/de/raspberry/427-raspibackup-sh-und-benutzung-von-synology-als-backupspace/ . Es wäre nett, wenn jeder, der eine Synology besitzt und mit dem Script erfolgreich benutzt, dort mit Rat und Tat beiseite steht. Ein kurzer Kommentar sorgt dafür, dass man immer über neue Kommentare informiert wird.
#306 Markus 2015-01-10 22:14
Hallo mal wieder,

also framp und ich sind immer noch an der rsync Problematik zwischen den Pis und dem Synology NAS.

Das Seltsame ist, dass wenn ich die rsync Aufrufe, so wie sie im Log enthalten sind in der Shell ausführe, dann geht es und rsync ackuped die Daten, erstellt hard links usw. Aber wenn ich es über das Script ausführe, dann ist das Verzeichnis entweder leer und das Backup ist nach 1s fertig oder es wird ein komplett neues Backup mit x GB erstellt... Framp hat sein Script nochmal Tests unterzogen aber konnte kein Problem feststellen und meinte ich soll noch mal hier anfragen, da es wohl auch einige User gibt, die ein Synology NAS haben und zunächst Probleme hatten. Sollte also jemand mit nem Synology NAS mitlesen... dann bitte kurz melden! Danke!
#305 Markus 2015-01-10 19:31
Hi framp,

Ich hoffe es geht dir soweit gut. Wollte dir nur sagen das ich ebschönenehentlich mit dem Smartphone im Kommentar #302 auf den negativen Daumen gedrückt habe. Falls möglich kannst du das wieder
auf 0 stellen und diesen Kommentar bitte nicht veröffentlichen :-) Danke und schönen Abend noch.

Grüsse
Markus
#304 framp 2015-01-09 20:52
Moin Kevin,

denke daran, dass vor einer Sicherung eines laufenden Systems soweit wie möglich alle aktiven Dienste wie samba, nfs, xbmc, mysql, apache usw beendet werden sollten. Dazu gibt es zwei Parameter im Script -a und -o bzw das Wrapperscript, was ich oben bereitgestellt habe.

Beim DD Backup wird die gesamte SD Karte gesichert. Da gibt es keine Excludeliste. Bei tar und rsync sieht die Standardexcludeliste wir folgt aus:

--exclude=$BACKUPPATH_PARAMETER \
--exclude=/proc/* \
--exclude=/lost+found/* \
--exclude=/sys/* \
--exclude=/mnt/* \
--exclude=/media/* \
--exclude=/dev/* \
--exclude=/tmp/* \
--exclude=/boot/* \
--exclude=/run/* \

CU framp
#303 Kevin 2015-01-09 20:44
zitiere framp:
Moin Kevin,

nein, bei einem dd Backup brauchst Du nichts zu excluden, denn es wird nur die SD Karte gesichert.

Solltest Du ein tar oder rsync Backup anfertigen wollen ist auch nichts besonderes notwendig da /mnt immer excluded wird. Hättest Du aber einen anderen Mountpoint wie z.B. /backup benutzt dann ist die Anwendung des Parameters -u wirklich wie von Dir vermutet notwendig.

CU framp


Wow! Danke für die schnelle Antwort!
Ich plane das Backup (testweise) auf eine andere SD-Karte zurückzuspielen und dann eine 1:1-Kopie des System zu haben, die direkt lauffähig ist. Ist das realistisch?
Was (welche Verzeichnisse) wird denn noch automatisch excluded?
#302 framp 2015-01-09 20:17
Moin Kevin,

nein, bei einem dd Backup brauchst Du nichts zu excluden, denn es wird nur die SD Karte gesichert.

Solltest Du ein tar oder rsync Backup anfertigen wollen ist auch nichts besonderes notwendig da /mnt immer excluded wird. Hättest Du aber einen anderen Mountpoint wie z.B. /backup benutzt dann ist die Anwendung des Parameters -u wirklich wie von Dir vermutet notwendig.

CU framp
#301 Kevin 2015-01-09 20:08
zitiere Kevin:
...Ich habe die Befürchtung, sonst würde das Stick auf den Stick selbst gesichert werden.
Wenn ja, wie genau mache ich das? Einfach per "-" /mnt/data"?


Ich meinte natürlich folgenden Teil des Befehls zum Excluden:
-u /mnt/data
#300 Kevin 2015-01-09 20:00
Hallo zusammen,

das Skript sieht sehr vielversprechend aus - sowas suche ich schon länger!
Eine Verständnisfrage habe ich aber noch:
Ich habe einen USB-Stick an meinem RPi als zusätzlichen Speicherplatz hängen. Dieser Stick ist natürlich unter einem Mountpoint (/mnt/data) ansprechbar.
Nun möchte ich ein ddz-Backup mit Hilfe des Skripts auf den Stick machen. Muss ich den USB-Stick (bzw. dessen Mountpoint) excluden? Ich habe die Befürchtung, sonst würde das Stick auf den Stick selbst gesichert werden.
Wenn ja, wie genau mache ich das? Einfach per "-" /mnt/data"?
#299 framp 2015-01-09 14:13
Vielen Dank Markus für den Report des Typos, der sich leider am 19.9.2014 eingeschlichen hat. Offensichtlich wird der xbmc Backup nicht so häufig benutzt, dass der Typo erst jetzt von Dir bemerkt wurde. Da ich schon lange kein XBMC mehr habe und deshalb nicht testen kann fiel mir der Fehler auch nicht auf :oops:

Er ist jetzt in der neuesten Version gefixed.
+1 #298 Markus 2015-01-09 08:22
Schon mal zu dem "XBMC Backup Problem:

Zeile 1019 muss lauten:
cmd="tar -cpz$verbose --one-file-system -f $BACKUPTARGET_FILE \

In der jetzigen Version hat sich ein zweites $ vor dem _FILE eingeschlichen, welches von der Shell nicht expandiert wird --> Leerer String und daher kommt es zu dem "File not found" Fehler, weil der nächste Parameter mit dem "--exclude=..." als Filename angesehen wird.

CU Markus
#297 framp 2015-01-08 22:48
Der sendEmail Fix von Kurt ist nun eingebaut.

Noch einmal vielen Dank an Kurt und an alle anderen (speziell auch an Markus bei seiner Hilfe und Tests, externe root Verzeichnisse zu unterstützen), die mittlerweile geholfen haben, das Backupscript in seiner Funktionalität zu erweitern und Bugs zu eliminieren.
+1 #296 Markus 2015-01-08 22:06
Hallo Kurt,

auch von meiner Seite "Danke". Damit wäre das EMail-Problem schon mal gelöst :lol:

VG
Markus
+1 #295 framp 2015-01-08 22:02
Moin Kurt,

vielen Dank für Deinen sehr hilfreichen Kommentar.

Über die Feiertage habe ich das Script so umgebaut, dass es in der Lage ist, Meldungen in beliebigen Sprachen zu schreiben, abhängig von der Locale, die auf der Pi eingestellt ist. Bislang sind Meldungen in English als Fallback und Deutsch möglich. Wer Lust und Laune hat mir zu helfen eine andere Sprache zu enablen sollte sich bei mir melden.

Dabei musste ich Messageidentifier einführen (RBKSxxx) und die --- haben offensichtlich bei den eMails ein Problem eingeführt was mir beim Testen nicht aufgefallen ist :cry:

Deinen Fix für das Problem werde ich in den Code einpflegen. Vielen Dank für den Fix Kurt. :thumbsup:

Cu framp
+1 #294 Kurt 2015-01-08 21:39
Hallo framp, hallo Markus,

auch von meiner Seite herzlichen Dank für die sehr interessante Lösung.
Heute habe ich sie auch einmal eingesetzt im Zusammenhang mit einer USB-Platte.

Bei SendEmail hatte ich auch so meine Probleme und die habe ich wie folgt gelöst:

den Aufruf von raspiBackup.sh habe ich in eine raspiBackup.run gepackt. Dabei sieht der Aufruf wie folgt aus:
/usr/local/bin/raspiBackup.sh -p /media/usbplatte -t tar -k 3 -s sendEmail -e meineEmail@provider.de -E '-f meineEmail@provider.de -s mail.gmx.net -xu meinUserAccount -xp MeinPasswort -o tls=yes'

Wichtig dabei ist, dass die übergebenen Parameter für -f, -s usw. in einfache Hochkommata eingeschlossen werden.

Weiterhin habe ich noch eine Änderung im Script raspiBackup.sh vorgenommen:

sendEmail) "$EMAIL_PROGRAM" $EMAIL_PARMS -u "$2" $attach -t "$EMAIL" -m "'$content'"

Der Unterschied zu originalen Zeile besteht darin, dass $content nicht wie vorher "$content", sonder "'$content'", also zusätzliche einfache Hochkommata eingeschlossen ist. Dies ist notwendig, da ansonsten die in der Message vorkommenen --- Ra usw. von sendEmail als Paramter interpretiert werden. So wie bei framp zu sehen.
Leider sind dann die einfachen Hochkommata auch in der Email enthalten.

Dies kann man beseitigen indem man die Message per Pipe dem sendEmail zukommen lässt, also

sendEmail) echo "$content" | "$EMAIL_PROGRAM" $EMAIL_PARMS -u "$2" $attach -t "$EMAIL"

Jetzt ist die Email sauber.

Ich hoffe, ich konnnte helfen.

VG
Kurt
#293 Markus 2015-01-08 21:35
Danke, mach ich. Backupjob läuft schon!
#292 framp 2015-01-08 21:15
Moin Markus,

offensichtlich gibt es verschiedene Probleme mit dem backup Script, die ich so nicht lösen kann:

1) xmbcBackup
2) Mail send

Ich benötige einfach weitere Informationen um Dir helfen zu können :roll: . Lass das Script mit den Parametern -m 1 -l 1 laufen und schicke mir das detailierte DebugLog an meine eMail, die Du im Kontaktbereich findest. Ich kontaktiere Dich dann offline.

Cu framp
#291 Markus 2015-01-08 20:56
Hallo,

mein ursprünglicher Post war leider zu lange, daher wurde der Rest abgeschnitten. Das der NFS-Share nicht korrekt angelegt wäre ist nicht das Problem. Ich habe das Script in der gleichen Konfiguration auf einem 2. Pi laufen (dort nach /nas/storage/pi_backups/fhem) backupen und dort geht alles wunderbar!
Die Schreibrechte passen und auch der Share kann erfolgreich gemountet werden. Trotzdem verhält sich das Script auf dem xbmc Pi anders.
Seit neuestem hängt das Script auch, wenn ich es einfach nur mittels "-h" aufrufe (keinerlei Ausgabe nach stdout) um mir die Parameter anzuzeigen...
Noch eine andere Idee?

Ich habe auch auf beiden Pis die "sendemail" Perl-Module installiert. Wenn ich dann die entsprechenden Aufrufe in raspibackup.sh einhänge kommt:

--- RBK0017I: Backup finished successfully
Jan 08 13:03:38 fhem sendEmail[5266]: Error: "--- RBK0009I: fhem: raspiBackup.sh 0.5.8.1 started at Thu Jan 8 09:14:01 CET ..., --- RBK0049W: Some files were changed or vanished during backup. RC: 23 - ignoring change, --- RBK0010I: fhem: raspiBackup.sh 0.5.8.1 stopped at Thu Jan 8 13:03:35 CET ..., --- RBK0017I: Backup finished successfully, " is not a recognized option!

sendEmail-1.56 by Brandon Zehm

Synopsis: sendEmail -f ADDRESS [options]
(Und dann die Usage von sendemail)

Any ideas?
(Wie man in dem Auszug sieht funktioniert also das Script auf dem anderen Pi)

VG
Markus
#290 framp 2015-01-08 18:01
Moin Markus(#286 und #286),

wie der andere Markus in Kommentar #287 beschrieben hat, liegt das Problem wohl darin, dass Deine NAS irgendwie nicht an der Pi gemounted ist. Folge mal seinen Ratschlägen und mounte die NAS erst einmal erfolgreich.

Cu framp
#289 Markus 2015-01-08 16:26
Hallo Markus,

ich verstehe das laut deinen Ausgeben so, der Mountpoint /nas/storage existiert (/nas/storage is a mountpoint) alles was danach kommt aber nicht (/nas/storage/pi_backups is not a mountpoint). Ich würde um alle möglichen Fehler erst einmal auszuschliessen wie folgt vorgehen:

0) Share auf der NAS anlegen = /volume1/pi_backups
1) Mountpoint auf dem Pi erstellen = /nas/storage/pi_backups
2) NAS Share via NFS3 in den zuvor erstellten Mountpoint einhängen
3) Einen entsprechenden Eintrag in deiner fstab machen =
192.168.xxx.xxx:/volume1/pi_backups /nas/storage/pi_backups nfs rw,nfsvers=3 0 0
4) Pi mal neu starten und schauen ob dein Share korrekt eingehängt wurde.

Nun kannst du noch deine Berchtigungen auf das Share prüfen. Navigiere dich hierzu auf dem Pi zu deinem Mountpoint und erstelle dir z. B. mit touch eine leere Datei, also in /nas/storage/pi_backups.

Wenn das alles funktioniert kannst du ab jetzt das Wrapper Script ins Spiel bringen. Ich hoffe das hilft dir ;-)

Grüsse
Markus
#288 Markus 2015-01-08 10:34
Mist, der letzte Text war wohl zu lang...
Kann es sein, dass der Share vlt. in dem Moment wo er loslegen will schon wieder entmountet wurde? Das würde erklären, warum er sagt "File not found", da die Verzeichnisse ja nur existieren, wenn es gemountet wurde...
#287 Markus 2015-01-08 08:38
Hallo,

zunächst mal: Super Arbeit, nach genau sowas habe ich gesucht!

Ich habe im Moment noch 2 kleine Probleme mit dem Script:

Backup erfolgt via NFS mount auf ein Synology-NAS.
Gemountet wird es via:
synology:/volume1/storage /nas/storage nfs noauto,nolock,soft,nfsvers=3,rsize=8192,wsize=8192,timeo=14,intr 0 0

a)
Auf dem 1. Pi (XBMC) möchte ich ein "XBMC" Backup erstellen. Hierbei kommt es zu folgendem Fehler:

root@raspbmc:/home/pi# /usr/local/bin/raspiBackupWrapper.sh
--- Mounting /nas/storage
/nas/storage/pi_backups/xbmc is not a mountpoint
/nas/storage/pi_backups is not a mountpoint
/nas/storage is a mountpoint
--- RBK0009I: raspbmc: raspiBackup.sh 0.5.8.1 started at Thu Jan 8 08:31:41 CET ...
tar: Removing leading `/' from member names
tar (child): --exclude=/nas/storage/pi_backups/xbmc: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
--- RBK0010I: raspbmc: raspiBackup.sh 0.5.8.1 stopped at Thu Jan 8 08:31:42 CET ...
??? RBK0005E: Backup failed in task bootPartitionBackup with RC 141. See logfile /var/log/raspiBackup/raspbmc.log for details
??? RBK0043E: Removing incomplete backup /nas/storage/pi_backups/xbmc/raspbmc/raspbmc-xbmc-backup-20150108-083139.tgz
--- Unmounting /nas/storage

Das Logfile sagt leider nicht mehr als genau dieses, an der entsprechenden Stelle:

"20150108-083142: DBG -- Finished boot partition backup...
20150108-083142: DBG
#286 framp 2015-01-02 19:12
@Thomas:

Mir ist gerade eingefallen, dass ich vor längerer Zeit mal einen undokumentierten Parameter -5 eingebaut habe. Da hatte auch jemand nach NOOBS Support gefragt. Das ganze ist quick and dirty und ungetestet von mir und es funktioniert auch nur für den tar und rsync Backup. dd Backup funktioniert nicht. Ausserdem musst Du den Restore manuell vornehmen. Die Restorefunktion des Scripts unterstützt kein Noobs.

Sollte sich eine größere Menge von Interessenten finden die ein Backup unter NOOBS mit dem Script erstellen wollen und entsprechenden Testaufwand bereit sind zu leisten, würde ich vielleicht den Support für NOOBs beim Backup und Restore einbauen. Du bist Nummer 2 - und das ist einfach zu wenig.

Cu framp
#285 framp 2015-01-02 13:57
Moin Thomas,

ziemlich am Anfang der Seite habe ich geschrieben, dass NOOBS nicht unterstütz wird :-) Bei mir laufen alle Pis mit einem raspbian bzw raspbmc und hat nur zwei Partitionen. Da NOOBS ein anderes Partitionslayout hat funktioniert der Backup mit dem Script leider nicht.

CU framp
#284 Thomas 2015-01-02 13:28
Hallo und vielen Dank für deine sicherlich recht große Mühe.

Gerne würde ich dein Script einsetzen, allerdings kommt bei mir nach folgendem Befehl:
pi@raspberrypi /usr/local/bin $ sudo /usr/local/bin/raspiBackup.sh

Immer folgende Meldung:
??? RBK0013E: Mehr als zwei Partitionen mmcblk0p gefunden (Wird vielleicht NOOBS benutzt?)

Ja ich nutzte NOOBS, und wie mache ich jetzt weiter?

Danke für deine Unterstützung!

Gruß

Thomas
#283 framp 2014-12-30 11:34
Moin Bernd,

es besteht keine Möglichkeit die Dateiattribute von Linux zu NTFS 1:1 abzubilden. D.h. immer wenn man Dateien von Linux nach NTFS kopiert gehen Informationen verloren (Dateizugriffsberechtigungen) und können nicht wieder hergestellt werden. Mit rsync kann man von Linux zu NTFS kopieren und mit Deiner angeführten Option wird ein weiterer Unterschied zwischen Linux FS und NTFS sichtbar - kann aber mit dem Flag behoben werden. Es dient dazu zu erkennen, ob sich eine Datei geändert hat (Änderungsdatum und Dateigröße).

Wenn Du nur Deine Benutzerdaten sichern willst kannst Du rsync in Deinem Falle benutzen.

Um ein Backup zu erstellen, welches durch einen Restore wieder den Originalzustand herstellt, ist ein rsync auf NTFS deshalb nicht geeignet und man geht dann den Weg über ein tar Backup, denn da werden alle Linuxdateiattribute in der Sicherungsdatei mitgespeichert und können auch wieder 1:1 auf ein Linux Dateisystem restored werden.

Cu framp
#282 Bernd 2014-12-30 10:03
Hallo,
dachte ich mir schon, dass es mit den Dateirechten zusammenhängen könnte.

Zu rysnc habe ich den Parameter '--modify-windows=1' gefunden:
--modify-window=1: this is ESSENTIAL. Basically in windows filesystems time is kept in even numbers (or some such problem). This command tells rsync to ignore filechanges that are only 1 second in difference from the original. It is almost impossible that you will create a file, sync it, and in ONE second make a change and want to sync it again. So it is safe to use this option and it means that rsync will not back up everything every time simply because of a one second change.

Nur wie baue ich dies in das Skript ein?

mfg Bernd
#281 framp 2014-12-30 09:36
Moin Bernd,

die Mächtigkeit von rsync liegt darin, dass es Hardlinks benutzt. Dadurch werden vollständige Backupverzeichnisse erstellt - aber nur die geänderten Daten wirklich neu kopiert und man kann man platzsparend mehrere Backups vorhalten und die Backupzeit ist minimiert. rsync benötigt dazu ein EXT3/EXT4 Dateisystem was linuxspezifisch ist.

D.h.ich sehe für Dich folgende Möglichkeiten:

1) Benutzung des undokumentierten Aufrufflags -K. Dadurch werden keine Hardlinks von rsync benutzt. Das bedeutet dann aber auch dass jedesmal ein vollständiger Backup mit dem entsprechenden Platz erstellt wird.

2) Erstellen eines Backupvolumes welches EXT3/EXT4 formatiert ist

3) Erstellen eine tar Backups.

Ich hoffe es findet sich darunter eine für Dich befriedigende Option :-)

CU framp
#280 Markus 2014-12-29 22:43
Hi Bernd,

da ich meine Backups auf ein Linux Filesystem speichere, bin ich mir nicht sicher, aber ich könnte mir vorstellen das es zwischen rsync und ntfs zu Berechtigungsproblemen kommen kann. Ich würde mal versuchen dein Backupshare für ntfs, also z. B. mit ntfs-3g zu mounten. Wie das geht kannst du z. B. hier nachlesen http://wiki.ubuntuusers.de/Windows-Partitionen_einbinden/NTFS-3G

Mehr fällt mir gerade nicht ein, ausser eben das Filesystem deiner Festplatte linuxfreundlich zu formatieren. Viel Erfolg ;-)
#279 Bernd 2014-12-29 20:58
Hallo,
dank an framp und Markus.
soweit verstanden.

dd-Backup funktioniert und wird auf einer ntfs-Partition abgelegt
bei rsync erhalte diese Fehlermeldung: '??? Filesystem of rsync directory /mnt/usbPlatte/Raspi/Backups has to be either'
auch hier soll das Backup auf ein ntfs-Dateisystem abgelegt werden?

mfg Bernd
#278 Markus 2014-12-29 18:46
Hallo Bernd,

1) Das Script sollte unter /usr/local/bin mit dem Namen raspiBackup.sh abgelegt und mit sudo chmod 755 ausführbar gemacht werden. Dann kannst du das Script von überall per sudo ausführen.

2) Config Datei unter /usr/local/etc/raspiBackup.conf ablegen und den Abschnitt in raspiBackup.conf leer lassen.

3) Wenn du zukünftig mit rsync sicherst, leg auch dein erstes Backup mit rsync an. Wenn du einfach nur mal eine Vollsicherung haben möchtes verwende dd ;-)

Grüsse
#277 framp 2014-12-29 18:32
Moin Bernd,
zitiere Bernd:

1. wie kann/muss ich das Backup-Skript aufrufen, wenn 'Boot' auf der SD-Karte liegt und die Daten auf einer Datenpartition (sda1) ?
Da musst Du nix besonderes machen. Da alles ausser /boot auf der externen Platte liegt wird das implizit erkannt.
Zitat:
2. wie kann/muss ich die .config Datei einbinden ?
Die Frage verstehe ich nicht. Du musst nur alle Konfig Daten in Konfig Datei schreiben.
Zitat:
3. erst ein DD-Backup starten, dann weitere rsync-Backups ?
Der rsync Backup sichert auch die boot Partition. D.h. mit all den Informationen ist ein Restore wieder möglich. Du kannst aber auch vorher ein dd Backup anlegen. Das ist dann ein zweites Backup. Es hängt also ganz von Deiner Backupstrategie ab welche Backups Du erstellen willst.
Denke daran, dass bei einer externen Platte das Backup auch entsprechend gross werden kann :roll:

Cu framp
#276 Bernd 2014-12-29 18:04
Hallo framp,
nachdem ich die Datenpartition lt.Deinem 'raspiSD2USB.sh' -Skript angelegt habe möchte ich nun auch das 'raspiBackup.sh'-Skript anwenden.
Dazu, für mein Verständnis:
1. wie kann/muss ich das Backup-Skript aufrufen, wenn 'Boot' auf der SD-Karte liegt und die Daten auf einer Datenpartition (sda1) ?
2. wie kann/muss ich die .config Datei einbinden ?
3. erst ein DD-Backup starten, dann weitere rsync-Backups ?

Danke für die Hilfen.
Vorab ein gesundes Neues Jahr

mfg Bernd
#275 framp 2014-12-16 19:44
Wie von Reytifuu angeregt habe ich mal zusammengeschrieben wie man verschiedene externe Datenquellen per ftp, ssh, nfs, smb und webdav auf einer Pi einbinden kann -> http://www.linux-tips-and-tricks.de/de/raspberry/423-wie-kann-man-von-der-raspberry-pi-auf-externe-daten-zugreifen/
#274 framp 2014-12-14 13:18
Moin Reytifuu,

den Backuppfad kannst Du wie oben beschrieben ist auf 3 verschiedene Arten definieren:

1) -p Parameter beim Aufruf
2) Den Parameter DEFAULT_BACKUPPATH in /usr/local/etc/raspiBackup.conf definieren
3) Den Parameter aus 2 kann man auch in ~/.raspiBackup.conf ablegen.

Als Backuppfad kann alles angegeben werden, was auf der Pi gemounted ist. Wenn Du z.B. unter /mynas Deine capsule gemounted hast als Sambalaufwerk kannst Du /mynas/mybackup als Backupfad angeben, sofern auf der capsule dann der Pfad mybackup existiert.

Ist eine gute Idee vielleicht mal Beispiele zu geben, wie man das Backupdevice (smb, nfs, webdav, sshfs usw) alles so mounten kann. Werde ich die Tage mal in Angriff nehmen.

Cu framp
#273 Reytifuu 2014-12-14 12:49
Hallo,
Und vielen Dank für deine Arbeit. Ich habe jetzt auch lange lange dran gesessen, bis alles so war wie ich es wollte. Ich habe noch nie so oft sd karten formatiert ;-) da kam mir dein backup script sehr gelegen.

Jetzt meine noob Frage. Den Pfad, wo die Backups gesichert werden soll, lege ich in der raspiBackup.sh in der config sektion fest, oder?
Jetzt möchte ich das ganze auf einer art nas, also auf einer time capsule ablegen, gebe ich dann einfach den smb pfad zu dem ordner ein? Könntest du ein Bsp. geben wie der komplette pfad aussehen müsste? Vielen Dank im Voraus!
#272 framp 2014-12-03 19:38
Moin Eric,

entweder mit den normalen Linuxmitteln, dem tar Befehl
tar -xf
oder dem Script selbst. Wie das geht ist oben bei den Aufrufparametern beschrieben.

Cu framp
#271 Eric 2014-12-03 14:41
Wie kann ich eine tar wiederherstellen???
#270 Eric 2014-12-03 14:25
Kurze Frage wäre noch, wie man das System mit der .tar Datei weiderherstellen kann?!

Grüße
#269 framp 2014-11-18 22:26
Bei mir läuft alles ohne Probleme. Vermutlich gibt es bei Dir irgendeinen Spezialfall. Lass uns das offline klären.
#268 Rene 2014-11-18 21:09
VERSION="0.5.7.9d"
#267 framp 2014-11-18 21:01
Moin Rene,

das ist dumm. Ich brauche aber die genaue Versionsnummer von Dir um die Ursache zu finden.

Cu framp
#266 Rene 2014-11-18 20:57
Bekam mit der neuesten Version heute beim rsync Backup ein:

./raspiBackup.sh: line 949: ((: ! : syntax error: operand expected (error token is "! ")

Backup ansich wurde mit "successful" benndet
#265 framp 2014-11-13 20:39
:oops: Du hast doch Recht.

Ich habe echt das Problem das ich keine Regressiontestsuite habe :sigh: Wenn ich diese erstelle muss ich aber mindestens nochmal denselben Aufwand reinstecken den ich schon für das Script selbst benötigte.

Vielleicht finde ich zwischen den Jahren dazu Zeit.
#264 framp 2014-11-13 20:25
Moin Michael,

nein. Wir können das aber gerne im irc Channel diskutieren. Den Link schicke ich Dir per eMail.

Cu framp
#263 Michael 2014-11-13 20:14
Ich glaube, Du musst auch noch in Zeile 326
'LOG_FILE=$BACKUPTARGET_DIR.$MYNAME.log'
in
'LOG_FILE=$BACKUPTARGET_FILE.$MYNAME.log'
ändern.
Sonst wird die Log-Datei mit konstantem Namen im darüberliegenden Verzeichnis erstellt.
#262 framp 2014-11-13 19:51
Moin Michael,

danke für den Hinweis. In der Zeile 319 fehlte leider ein $ Zeichen :oops:

Anstatt
BACKUPTARGET_DIR="$BACKUPTARGET_ROOT"
stand da
BACKUPTARGET_DIR="BACKUPTARGET_ROOT"

und deshalb hat er das Log immer in die Datei
BACKUPTARGET_ROOT.raspiBackup.log
geschrieben.

Ist jetzt gefixed :-)
#261 Michael 2014-11-13 18:48
Hallo Framp, jetzt scheint sich aber ein neues Problem eingeschlichen zu haben: Ich habe in der Config-Datei DEFAULT_LOG_OUTPUT=2 gesetzt. Wenn ich das Skript ausführe, bekomme ich gar keine Log-Datei mehr. Der Log Output auf der Kommandozeile fängt so an:

DEBUG LOG_OUTPUT: 2
INFO Using logfile BACKUPTARGET_ROOT.raspiBackup.log
DEBUG Removing maillog file ../raspiBackup.maillog
INFO raspiBackup.sh 0.5.7.9 (Rev 1.68 - 2014/11/09 16:54:27)
DEBUG Invocationparameters:
DEBUG Options:
DEBUG BACKUPPATH=/mnt/fritz.box/Kingston-DTMicro-01/SrvBackup
DEBUG KEEPBACKUPS=2
DEBUG BACKUPTYPE=ddz

Ich habe den Eindruck, in 'setupEnvironment()' wird der Pfad der Logdatei nicht richtig gesetzt. Da ist wahrscheinlich BACKUPTARGET_ROOT noch nicht gesetzt.

Ab dann wird es mir zu kompliziert…


Ciao, Michael
#260 framp 2014-11-09 16:48
Habe eben den von Michael gemeldeten Bug gefixed. Habe es auch so implementiert wie von ihm vorgeschlagen - geht am einfachsten :roll:
Ausserdem gibt es nun die Möglichkeit -L 3 anzugeben, d.h. das log wird ins aktuelle Verzeichnis geschrieben.
#259 framp 2014-11-09 12:40
Moin Michael,

vielen Dank für den Hinweis auf den Fehler und auch für die Lösung als Code :-) . Eigentlich spricht nix dagegen den Fehler so wie Du vorschlägst zu lösen. Aber ich versuche mal ob ich einen regex finde, der alles mit einem Mal filtert.

Cu framp
#258 Michael 2014-11-09 12:12
Hallo Framp, Martin, ich kann bestätigen, dass das Problem mit PATH im Cron-Job mit dem ersten Fix nicht gelöst war. Heute nacht werde ich feststellen, ob es bei mir mit der aktuellen Version gelöst ist :-)

Ich habe aber auch noch ein anderes Problem gehabt: Dabei muss ich vorausschicken, dass ich die Log-Datei in dasselbe Verzeichnis wie die Backup-Datei konfiguriert habe, was sicher nicht völlig abwegig ist. Bei einer Einstellung von KEEPBACKUPS=1 wurde die neu erstellte Backup-Datei jedesmal gleich nach Erstellung wieder gelöscht. Ursache ist folgende Zeile:
'pushd $BACKUPPATH 1>/dev/null; ls -d *-$BACKUPTYPE-* | head -n -$KEEPBACKUPS | xargs -I {} rm -rf$verbose "{}" 2>/dev/null ; popd > /dev/null'
in der Funktion 'backup()'. 'ls -d *-$BACKUPTYPE-*' spricht sowohl auf den Namen der Backup-Datei als auch auf den Namen der Log-Datei an, sodass die Zählung im Vergleich mit KEEP_BACKUPS nicht mehr stimmt. Ich habe das korrigiert, indem ich in diese Zeile noch den Filter 'grep -v ".*.raspiBackup.log"' eingefügt ("eingepipet") habe:
'pushd $BACKUPPATH 1>/dev/null; ls -d *-$BACKUPTYPE-* | grep -v ".*.raspiBackup.log" | head -n -$KEEPBACKUPS | xargs -I {} rm -rf$verbose "{}" 2>/dev/null ; popd > /dev/null'.
Konsequenter wäre wahrscheinlich eine genauere (positive) Filterung des Namens der Backup-Datei in 'ls -d xxxx', aber das habe ich mir dann nicht (für alle möglichen Backup-typen) zugetraut.

Framp, vielleicht willst Du diesen zusätzlichen Filter noch mit in den Code aufnehmen, oder gleich eine bessere Lösung mit 'ls -d xxxx' implementieren.

Ciao, Michael
#257 deMattin 2014-11-02 19:37
Skript-mod für Testaufruf: check
Pfadübergabe an console-Environment: check
"Härtetest" (mit console-Aufruf): check
Pfadübergabe an cron-Environment: check
"Härtetest" (mit cron-Aufruf): check
Testcron ohne mod und verbose: check
Logfiles: check
delete "Trash-Files": check
Alles auf "produktiv" gesetzt: check
Start des Produktiv-Scrips per cron: check und Backup läuft.
That's it!
Alles bestens. :-)

Danke und Gruß,
Martin
#256 framp 2014-11-02 18:43
zitiere deMattin:
...Aber ich mache ja immer den "Härtetest" ...
Ich muss gestehen, dass ich die Änderungen an der PATH Sache nicht mit einer Contab teste. Es ist nicht kritisch und ein Setzen des Pfades in dre CRON Tab löst das Problem ja. Deshalb ist Dein Härtetest sehr hilfreich :thumbsup:
Zitat:
Du solltest die PATH-Routine wirklich ganz oben ,,, einbauen,
Done :-)
Zitat:
...Hat das einen Grund, dass du den Standardpfad "/usr/local/sbin" nicht mit aufgenommen hast oder hast du den nur vergessen?...
Schlichtweg vergessen :oops: Ist aber jetzt auch drin.

Vielen Dank für Deine Tests und Hinweise auf die kleinen Fehler. Bist auch im CVS changelog dankend erwähnt :-)
#255 deMattin 2014-11-02 18:27
Hi,
erstmal vorweg: schöne Umsetzung, die du da aus meiner holprigen Erweiterung gebastelt hast.
Die Idee mit der Regexp hatte ich auch, habe es aber nicht hinbekommen (egrep kannte ich nicht).
Deine Routine an sich funktioniert auch bestens.

Aber ich mache ja immer den "Härtetest" mit PATH="" im cron-environment und in dem Fall macht die Position, an der du die Routine eingesetzt hast, Probleme.
Fehler (Auszug):
Code:
/usr/local/bin/raspiBackupTest.sh: Zeile 55: date: Datei oder Verzeichnis nicht gefunden
/usr/local/bin/raspiBackupTest.sh: Zeile 56: hostname: Datei oder Verzeichnis nicht gefunden
/usr/local/bin/raspiBackupTest.sh: Zeile 97: sort: Datei oder Verzeichnis nicht gefunden
/usr/local/bin/raspiBackupTest.sh: Zeile 103: tty: Datei oder Verzeichnis nicht gefunden
??? Unknown BACKUPTYPE ddz
raspiBackupTest.sh 0.5.7.5b (Rev 1.60 - 2014/11/02 15:41:13)
usage: raspiBackupTest.sh parms
-General parms-
-A append logfile to eMail (default: yes)
...

und Abbruch/Exit des Scripts!

Du solltest die PATH-Routine wirklich ganz oben (also bei Zeile 49) oder zumindest vor der "DATE"-Definition einbauen, damit es auch mit einem leeren cron-PATH funktioniert!

Und dann noch eine Kleinigkeit:
Hat das einen Grund, dass du den Standardpfad "/usr/local/sbin" nicht mit aufgenommen hast oder hast du den nur vergessen?
Ist zwar hier nicht wirklich wichtig, weil da keine relevanten Befehle liegen (ist das der Grund?), aber so wäre der Codeteil relativ universell.

Gruß und danke,
Martin
#254 framp 2014-11-02 16:45
Moin Martin,

vielen Dank für die detailierte Analyse, Fehlersuche und Deinen Lösungsvorschlag.
Ich habe den Code jetzt an den Anfang des Scripts gemoved und ein klein wenig den regex von grep korrigiert :-)

Cu framp
#253 deMattin 2014-11-02 16:20
So viel getestet und noch was am Schluss übersehen:

In meiner Variante wird ja auch "grep" benutzt.
Das wird ja auch nur über einen Pfad gefunden!

Also müsste das im script absolut aufgerufen werden:
/bin/grep
Somit:
## Check and set PATH for cron - Start
# PATHES=":/usr/b in: :/usr/sbin: :/bin: :/sbin: :/usr/local/bin : :/usr/local/sbin:"
# PATHtemp=$(echo $PATH)
# for p in $PATHES; do
# if ! echo $PATHtemp | /bin/grep $p 2>&1 1>/dev/null; then
# t=${p%:}
# t=${t#:}
# PATHtemp="$t:$PATHtemp"
# fi
# done
# PATH="$PATHtemp"
# # set # if active, reports PATH in cronlog or mail
## Check and set PATH for Cron - End

Gruß,
Martin
#252 deMattin 2014-11-02 15:27
Alternativ könnte man natürlich das Ganze umgehen, indem man:
1. den PATH im sudo-cron setzt, oder
2. im Script alle Pfade absolut setzt, oder
3. den erforderlichen Pfad im Script zentral direkt am Anfang (also direkt 2te Zeile, damit es auffällt) einfach setzt mit:
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

Aber wo wir jetzt so weit sind und das "Problem" eingekreist wurde ... ;)

Gruß,
Martin
#251 deMattin 2014-11-02 15:25
Ich habe es herausgefunden mit dem PATH und cron.
Meine PATH unter cron:
PATH=/usr/bin:/bin

1. deine Funktion erkennt keinen Unterschied zwischen /sbin und /usr/sbin wenn nach /sbin gesucht wird.
Wird also nach /sbin gesucht und /usr/sbin ist bereits definiert, dann wird /sbin nicht hinzugefügt, da es in /usr/sbin enthalten ist und somit gefunden wird.
Und genau das passiert mit deiner Reihenfolge der PATHES-Angaben für /sbin, da /usr/sbin zuerste definiert wird und /sbin eben nicht mehr.
Somit wird fdisk in /sbin weiterhin nicht gefunden.

Die Reihenfolge der Pfade in PATHES ist wichtig:
Zeile 339 somit:
PATHES="/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/bin"

Dann funktioniert das Script mit MEINEM default-cron-PATH, ABER:

2. Die Definition/Prüfung in der function kommt eigentlich zu spät - da werden einige Befehle schon ausgeführt, die eventuell nicht gefunden werden KÖNNTEN.
Ich habe es getestet mit PATH="" in der cron-Umgebung
Der Check müsste also ganz an den Anfang des Scripts.
Dann kann man den zwar nicht mehr mit deiner Debug-Funktion loggen, aber man könnte in deiner environment-function ja einfach nur den PATH für debugging ausgeben lassen.

3. Es bleibt das unter 1. beschriebene Problem bei deiner PATH-Prüfroutine, wenn ein bestehender cron-Pfad per default ungünstig definiert ist.
Mit folgender Erweiterung direkt am Skriptanfang (also Zeile 50) umgeht man das Problem.
In Zeile 53 ist der 1. Befehl, der einen Pfad braucht (date)!
In meiner Erweiterung ist die Reihenfolge egal - jeder einzelne Pfad muss nur von ":" umrahmt werden.
Den "Nachteil", dass die erste und letzte Pfadangabe der originalen cron-PATH eventuell zur Laufzeit gedoppelt werden, stört sicher nicht:

## Check and set PATH for cron - Start
# PATHES=":/usr/bin: :/usr/sbin: :/bin: :/sbin: :/usr/local/bin: :/usr/local/sbin:"
# PATHtemp=$(echo $PATH)
# for p in $PATHES; do
# if ! echo $PATHtemp | grep $p 2>&1 1>/dev/null; then
# t=${p%:}
# t=${t#:}
# PATHtemp="$t:$PATHtemp"
# fi
# done
# PATH="$PATHtemp"
# # set # if active, reports PATH in cronlog or mail
## Check and set PATH for Cron - End

Bei Tests ist es wichtig, das Script wirklich von cron bzw. in der cron-Umgebung aufrufen zu lassen und nicht aus einem Terminal!

Gruß,
Martin
#250 framp 2014-11-01 21:31
Moin Thomas,

Danke für Deine weiteren Tips das Script effektiv zu benutzen.
Interessant ist Dein Ansatz, jeweils mal ein dd backup und dann ein tar Backup zu erstellen. Mir reicht aber ein rsync Backup.
Eine Beschreibung wie man manuell restored ist sehr nützlich. Das Script kann natürlich die Backups auch restoren aber es ist immer gut auch einen Fallback zu haben.

Cu framp
#249 Thomas Wenzlaff 2014-11-01 20:36
Hallo,

danke für das Script. Es läuft super. Habe ein paar Ergänzungen hier aufgeschrieben:

http://blog.wenzlaff.de/?p=4486

Gruß
Thomas
#248 deMattin 2014-11-01 19:59
Komme nicht weiter!
Meine Idee, wie ich die cron-Consolenausgabe live mitverfolgen kann, funktioniert nicht.
Ich wollte die Ausgabe auf > /dev/pts/0 (ist bei mir immer die erste Remote-Console) umleiten, aber das funktioniert nicht. Wäre schon schön, wenn man das komplette Debug-log als Mailanhang bekommen könnte. ;)
Egal ...

Kann es sein, dass der Aufruf des Backup-Befehls mit "eval" bei Aufruf über Cron die PATH-Angabe wieder zerstört?
Deine PATH-Erweiterung sollte wohl bei direkter Konsolenaufruf so funktionieren, aber bei Cron ist irgendwie alles anders ...

Hast du eine Idee, wie man der Sache auf den Grund gehen könnte?

Dann noch eine Sache mit dem neuen(?) Parameter "Hardlinks".
1. Um die 1000er Zeilen herum ist der zweimal definiert (als Variable und fest als 1)
2. Was passiert, wenn man auf NTFS-FS sein Backup macht mit der default-Einstellung bei Hardlinks=1?
Kann das Probleme geben?
Wenn ich dein script hier richtig verstehe, wird das abgefangen und führt zu einer Fehlermeldung bei rsync-Backup und das Backup wird nicht ausgeführt.
Das sollte dann in der (Fehler-)Meldung eventuell stehen, dass man Hardlinks=0 einstellen muss bei NTFS.

Gruß,
Martin
#247 deMattin 2014-11-01 17:35
Das Script rufe ich sowieso mit komplettem Pfad auf.
Ich meine die PATH-Variable, weil er bei mir auch fdisk nicht findet, wie vorher beschrieben.
Die (gemailte) Fehlermeldung mit deinem aktuellem Skript Ver 0.5.7.5a:

/usr/local/bin/raspiBackup.sh: Zeile 852: fdisk: Kommando nicht gefunden.
/usr/local/bin/raspiBackup.sh: Zeile 879: fdisk: Kommando nicht gefunden.
??? No boot partition mmcblk0p1 found

Füge ich in:
# sudo contab -e
die PATH-Zeile:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ein, funktioniert der Ablauf des Skript.

Bei mir läuft gerade ein Backup.
Ich denke aber, ich habe eine Möglichkeit gefunden, die Debug-Meldungen auch bei Aufruf durch cron direkt auf die Remote-Console zu bringen.
Werde das mal dann gleich testen und wenn es klappt, sehe ich im Debug-Modus hoffentlich die Ausgabe deiner eingebauten PATH-Erweiterung - dann weiß man vielleicht mehr.

Rufe ich das cron-script über Webmin auf, läuft es übrigens genauso wie bei direktem Aufruf in der Console über sudo.

Es ist vermutlich zwar sowieso keine schlechte Idee, die PATH-Variable im sudo-cron zu definieren (ist ja auch bei vielen Distros wohl standard), aber mich interessiert ja auch, warum deine Modifikation nicht läuft.

Gruß,
Martin
#246 framp 2014-11-01 17:14
zitiere deMattin:
...also bei mir funktioniert der Cron-Aufruf von ddz auch nur, wenn ich in der sudo-Crontab den Pfad mit übergebe....
Meinst Du den Aufruf von raspiBackup.sh? Also /usr/local/bin/raspiBackup.sh .... Oder meinst Du dass Du den PATH in der crontab definieren musst?
#245 deMattin 2014-11-01 16:06
Hi,

also bei mir funktioniert der Cron-Aufruf von ddz auch nur, wenn ich in der sudo-Crontab den Pfad mit übergebe.
Auch die aktuelle Version des Scripts behebt das (bei mir) nicht.
Debugging fällt mir etwas schwer, weil ich die cron-Consolenausgabe ja nicht sehen kann.

Übrigens habe ich auch eine normale Raspbian-Konfiguration.
Allerdings habe ich default user "pi" umbenannt, falls das relevant sein könnte.

Gruß,
Martin
+1 #244 framp 2014-10-29 19:52
Moin Richard,

mit -p gibst Du an wo das Backup abgelegt werden soll. Das muss ein Pfad sein, an dem Dein Backupmedium vorher gemounted wurde. Das kann alles Mögliche sein, wie Cloudspace per webdav, nfs, samba, sshfs, USB Stick usw. Das ist ein generelles Prinzip unter Linux um maximale Variabilität des IOs zu ermöglichen und Programme davon unabhängig zu machen. Es gibt verschiedene Möglichkeiten das zu realisieren: Es gibt Leute, die benutzen die Parameter -a und -o zum mounten und unmounten des Backupspaces. Ich empfehle entweder den Space immer automatisch beim Booten zu mounten per fstab oder ein kleines Wrapperscript zu schreiben, welches vor und nach dem Aufruf von raspiBackup.sh den jeweiligen Mount bzw unmount ausführt.

Cu framp
#243 Richard 2014-10-29 09:40
Sehr cooles script! Genau das was ich suche, um meine Pis auf meiner Synology Diskstation zu sichern.

Ich habe allerdings ein paar Schwierigkeiten den Aufruf richtig hinzubekommen. Ich möchte als backup type "rsync" verwenden und bin mir nicht sicher wo ich die parameter ,,, angeben soll. Oder entfällt das alles, weil ich den externen Pfad erst lokal mounten muss (das käme mir allerdings etwas umständlich vor)? Für rsync habe ich leider keine Beispiele gefunden, oder habe ich da etwas übersehen?

Gruß Richard
#242 Michael 2014-10-28 09:39
Hallo Framp,

nach meinem Verständnis habe ich ein Standard-Raspbian (Stand September 2014), mit allen Aktualisierungen. Trotzdem muss bei mir wohl irgendetwas anders sein, sonst wären ja noch mehr Leute in das Problem gelaufen. Lt. crontab-Doku kann man sich aber ohnehin nicht darauf verlassen, dass in der cron-Umgebung der PATH so gesetz ist, wie auf der Kommandozeile. Insofern ist Dein aktueller Fix sicher sinnvoll.

Danke für Deine wertvolle Arbeit!

Ciao, Michael
#241 framp 2014-10-27 20:37
... die beiden eben gemeldeten Probleme sind in der aktuellen Version gefixed. :-)
#240 framp 2014-10-27 20:04
Moin Michael,

danke für die Hinweise. Ich sehe mir das mal an. Start/Stop hat mal funktioniert - ich habe aber da was geändert :-* . Ich habe keine Regressiontestumgebung um alle Optionen nach jeder Änderung zu testen :cry: Der zweite Punkt macht bei mir auf meiner Pi mit raspbian kein Problem, denn dort ist der PATH Standard in der crontab. Vermutlich benutzt Du ein anderes OS. Deshalb ist der Hinweis sehr wertvoll.

CU framp
#239 Michael 2014-10-27 19:44
Hier meine Erfahrungen mit dem Skript:

START- und STOPSERVICES funktionieren nicht, wenn mehr als ein Kommando pro Variable (mit Strichpunkten getrennt) aufgerufen werden soll.
Abhilfe:
Starten und Stoppen von Hilfsskripts, die dann die einzelnen Dienste starten und stoppen (wie schon bei 288GTO).

Nach dem Eintrag in die crontab wird 'fdisk' nicht gefunden.
Abhilfe:
PATH-Environmentvariable mit in die crontab schreiben (siehe z. B. http://stackoverflow.com/questions/10129381/crontab-path-and-user).


Ansonsten:
Gratulation! Das Skript ist eine große Hilfe für mich.
#238 framp 2014-10-26 20:22
Moin Michael,

Du hast Recht dass das Lesen keinen Einfluss auf die Lebensdauer der SD Karte hat. Belastung ist hier nicht negativ gemeint. Es heisst einfach dass bei dd die ganze SD Karte gelesen wird, bei tar nur die vorhandenen Daten und bei rsync nur die sich geänderten Daten. Also READs(DD) > READs(tar) > READs(rsync). Ich muss mir mal was überlegen wie ich das anders formulieren kann.

Danke für den Hinweis.

Cu framp
#237 Michael 2014-10-26 13:15
Hallo, was bedeutet 'hohe Belastung der SD-Karte' bei dd/ddz? Geht das auf die Lebensdauer der Karte? Es wird doch nur gelesen, was nach meinem Verständnis unkritisch sein sollte.

Ciao, Michael
#236 framp 2014-10-23 19:41
Die Vorschläge von Martin sind nun aufgenommen. Es gibt jetzt in der neuesten Version des Scripts die Parameter -b und -D um das dd weiter zu parametrisieren.
+1 #235 framp 2014-10-19 11:08
Moin Martin,

zitiere Martin:
... Könntest du dir Vorstellen, die Blocksize für DD als optionalen Parameter anzubieten?
...Und die Erweiterung des DD-Befehls um "conv=notrunc,noerror,sync" gefällt dir nicht?...
Die Blocksize kann ich noch mit aufnehmen. Sollte kein Problem sein. Auch werde ich wie beim eMail mit -E einen Parameter für weitere optionale Parameter bei dd einbauen.

Cu framp.
#234 Martin 2014-10-19 01:48
Hi framp,
habe gerade das aktualisierte Script runter geladen.
Bei den Config-Beispielen fehlt noch das ddz:

# type of backup: dd, ddz, tar, xbmc or rsync
DEFAULT_BACKUPTYPE="dd"

Danke für die schnelle Umsetzung!
----
Könntest du dir Vorstellen, die Blocksize für DD als optionalen Parameter anzubieten?
Ich habe gerade einen Test mit DD und Kompression durch und die Blocksize ist da eigentlich VÖLLIG egal, weil gzip das so lahm macht.
Sogar mit bs=256 Bytes ist es nur unwesentlich langsamer.
Alles nur um die 1MB/s(!)

Und die Erweiterung des DD-Befehls um "conv=notrunc,noerror,sync" gefällt dir nicht?

Kann ich mir zwar locker alles selber anpassen, aber dann müsste ich das bei jedem deiner Updates wieder machen ... ;)

Gruß und gute Nacht,
Martin
(aka deMattin)
#233 Martin 2014-10-19 01:23
framp, du hast mich mit shell-scripting angefixt. ;)
Ich habe das Testscript etwas (deutlich) optimiert und die Konfiguration vereinfacht, so dass es recht einfach nutzbar ist.
Danke für das Erhöhen des Zeichenlimits hier beim posten, aber es reicht jetzt nicht mehr (Skript hat über 4000 Zeichen). ;)
--------
# Skript zum Testen der optimalen Blocksize für dd-Backup.
# ver=0.5
#
# Aufruf mit sudo bzw. als root erforderlich für Feature "Caches leeren"
#
# Features:
# - für RPi oder beliebige andere Linux-Systeme
# - Lesetest und wahlweise auch Schreibtest in beliebigen Pfaden
# - Auch Test der Auswirkung durch gzip-Kompression
# - Gültigkeit der Pfade und Schreibrechte werden geprüft
# - Blockgrößen von 256 Bytes bis 8 MBytes werden getestet.
# - Cache-flush zur Vermeidung von Caching
# - Testdatei mir Random-Werten oder 0-Werten wählbar
# Hinweise:
# - Lesedatei auf Pi bzw. Linux-System wird immer erzeugt
# - Schreibdatei auf Backuplaufwerk wird nur beim Schreibtest generiert
# - Schreibpfad sollte auf externem Datenträger oder Server/NAS liegen!
# - Testdateien werden am Ende wieder gelöscht.
# - Erzeugung der Testdatei mir Random-Werten dauert viel(!) länger als mit
# 0-Werten (beim RPi ca 1,5MB/s gegenüber 14MB/s mit 0-Werten), sollte aber
# realistischere Ergebnisse liefern bei Verwendung der gzip-Kompression
# und ist daher wohl nur bei Test mit gzip-Kompression auch erforderlich.
# - Lesedatei_in_MB sollte ein ganzzahliges Vielfaches jeder einzelnen, zu
# testenden Blockgrößen sein (da jeweils Verdopplung also Vielfaches von 8)
# - Bei Einsatz unter OS X müssen im Code zumindest die bs angepasst werden
# z.B. 1M 2M ... ändern in 1m 2m ... (habe ich irgendwo gelesen)
# Ob der Rest bei OS X funktioniert? Keine Ahnung ... ;)
# (c) 2014 deMattin - free for all!
# inspired by framp with his raspiBackup-Skript
# on http://www.linux-tips-and-tricks.de/raspiBackup

--------
Mal sehen, vielleicht mache bzw. veröffentliche ich noch mehr.
Man bastelt sich ja so einiges zusammen im Laufe der Zeit - wobei das eigentlich mein erstes shell-script ist.
Ich hoffe, es ist kein gröberer Fehler mehr drin.
Zum Download (erstmal nur eine schnell zusammen genagelte, sehr provisorische Seite):

http://www.k64.eu/linux-tools/
#232 framp 2014-10-18 23:33
zitiere Martin:
...Hier fehlt ein Forum - die Begrenzung auf etwas mehr als 900 Zeichen ist für kurze Kommentare ok, aber für sowas hier schon echt nervig ...
Ich habe das Limit jetzt auf 2500 erhöht.
Ein Forum werde ich hier nicht einrichten, denn das ist einfach zu viel Aufwand. Als Forum kann ich aber das Raspberry Pi Forum -> http://www.forum-raspberrypi.de/ empfehlen. Dort findet man mich auch :-)
#231 framp 2014-10-18 23:22
In der aktuellen Version wird nun der Backuptype ddz unterstützt. Die Option -z gibt es nicht mehr. Dafür muss jetzt der Backuptyp -t ddz angegeben werden.

Vielen Dank Martin für diese Anregung !
#230 framp 2014-10-18 17:17
Moin Martin,

vielen Dank für Deine Analyseergebnisse und das Script. Vielleicht wollen ja noch andere ihre Ergebnisse mit dem Script posten.
Ich bin kein Fan von dd. Ich benutze bei mir rsync - Backup geht i.d.R. schnell und die Pi wird nicht gross belastet. Aber den Kommentaren nach scheinen doch viele dd zu benutzen. Deshalb werde ich auch die Änderung mit ddz wie von Dir angeregt vornehmen.

Cu framp
#229 Martin 2014-10-18 16:38
test.sh z.B. in /tmp/ erzeugen und Rechte 0755 geben.
Skript mit sudo /tmp/test.sh aufrufen.
sudo erforderlich wegen der clear-cache Funktion.
Ohne die ist der Test durch caching verfälscht!
Skript ist so für reinen Lesetest des erzeugten Testfiles von SD-Karte "eingestellt".
Größe der Testdatei sollte bei allen bs glatte Teiler durch die bs ergeben!

Andere Ergebnisse bei anderen SD-Karten wären interessant.
Ich nutze 16GB SanDisk Ultra SDHC1 im System.

--------
#!/bin/bash
#
clear
echo "Testdatei 304MiB erzeugen"
dd if=/dev/zero of=/tmp/infile bs=1M count=304
#
for bs in 256 512 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 8M

do
sync
echo 3 > /proc/sys/vm/drop_caches
echo "Teste block size = $bs"
dd if=/tmp/infile of=/dev/null bs=$bs
# dd if=/tmp/infile of=/backup/outfile bs=$bs
echo ""
done
rm /tmp/infile
#rm /backup/outfile
#228 Martin 2014-10-18 16:23
Die Tests sind relativ gut reproduzierbar, bei kleinen Abweichungen je Testdurchlauf wegen der anderen, parallelen Jobs des Pi.
Ergebnisse meiner Speedtests:
Testdatei 304MiB
- Nur Lesen:
256 14,7 MB/s
512 18,0 MB/s
ab 1k 18,2-18,3 MB/s
- Mit Schreiben auf cifs-Server:
256 4,1 MB/s
512 4,9 MB/s
1k 5,8 MB/s
2k 6,2 MB/s
4k 6,2 MB/s
8k 6,5 MB/s
16k 4,9 MB/s
32k 5,7 MB/s
64k 6,6 MB/s
128k 6,6 MB/s
256k 6,7 MB/s
512k 6,7 MB/s
1M 5,3 MB/s
2M 6,6 MB/s
4M 6,5 MB/s
8M 6,6 MB/s

Hier fehlt ein Forum - die Begrenzung auf etwas mehr als 900 Zeichen ist für kurze Kommentare ok, aber für sowas hier schon echt nervig ...
Mal sehen, ob ich mein Testskript im nächste Posting unterbringe - viel Beschreibung ist jedenfalls nicht drin.
Aber es sollte nachvollziehbar sein - auch wie man zwischen Test mit Schreiben auf sein Backup-Medium umschaltet und individuell anpasst.
#227 Martin 2014-10-18 16:13
Habe gerade mal Blocksize-Tests gemacht:
Ergebnis: reine Lesegeschwindigkeit steigt ab 512 Bytes(!) nicht mehr an (bei mir ca. 18 MByte/s).
Wenn man auch auf die Schreiboperation auf meinen cifs-Netzwerkspeicher berücksichtigt, sieht es minimal anders aus (bei mir ca. 5,9-6,7 MByte/s ab 1k Bytes)
Erste Maximum aber auch hier schon bei ca. 8k.

Da eine hohe Blocksize Nachteile (mehr Datenverlust) im Fehlerfall hat, sollte die vielleicht doch von 1MB auf 512 Bytes (also default) oder wenigstens 2k zurück gesetzt werden.
Ist ja schließlich ein BACKUP!

Bei Festplattencopy sieht das anders aus - aber beim Pi mit SD-Karte greift der Speedtipp mit großen Blöcken bei dd offensichtlich nicht.

Testergebnisse beim Pi bei hoher Belastung sind recht schwierig, wenn es sich um einen fertig konfigurierten Pi mit parallelen Jobs handelt.

Meine Ergebnisse und Testskript poste ich im nächsten Beitrag - dann kann jeder selber testen.
#226 Martin 2014-10-18 13:57
Danke.
Das macht das wohl noch transparenter im Skript.

Macht es nicht Sinn, den DD-Befehl bei Backup und Restore zu erweitern?
dd if=/dev/mmcblk0 bs=1MB conv=notrunc,noerror,sync

Mir erscheint es sinnvoller, bei Lesefehlern den lesbaren Bereich bestmöglich zu kopieren, als das Backup komplett abzubrechen, was ohne diese Parameter passiert.
In so einem Fall wäre zwar auch eine kleinere Blocksize günstiger, wenn auch noch langsamer.

Wobei bei mir das unkomprimierte Backup deutlich (4x) schneller geht als das komprimierte.
- komprimiertes DD:
15931539456 Bytes (16 GB) kopiert, 9842,59 s, 1,6 MB/s
- unkomprimiertes DD:
15931539456 Bytes (16 GB) kopiert, 2650,19 s, 6,0 MB/s
Erstaunlich, wie schwachbrüstig der RPi bei der Komprimierung ist - bei einemr load von 4!
Bei der Komprimierung schreibt er immer nur ca. 10 MB gefolgt von einer mehsekündigen Schreib-Pause, in der wohl die neuen Daten komprimiert werden.
#225 framp 2014-10-18 11:54
Moin Martin,

das ist ein guter Vorschlag. Das Zippen des DDs hatte ich damals relativ schnell eingebaut mit dem -z Flag. Deinen Vorschlag nehme ich auf und lasse den DD Zip einen neuen Backuptype werden (ddz) mit einer eigenen Extension (img.gz).

Cu framp
#224 Martin 2014-10-18 10:44
Das Backup-Skript klappt soweit gut bei mir.
Ich benutze das gz-gepackte DD-Backup.
Das Image wird allerdings gleich benannt wie ein unkomprimiertes.
Es ist nun kein Problem, Zeile 509 zu ändern:
dd if=/dev/mmcblk0 bs=1MB | gzip > $BACKUPTARGET_FILE.gz

Allerdings ist die Lösung nicht so gut, weil damit das u.a. Löschen der alten Backups nicht mehr funktioniert.
Und überall mit neuen IF-Abfragen auf Kompression abzufragen, wo es nötig ist, ist ja auch eher unschön.

Das müsste doch geschickter an einer Stelle gehen, z.B. in der Zeile 91 bei:
declare -A FILE_EXTENSION= ...
Aber dafür reichen meine Fähigkeiten nicht. ;)

Kannst du das vielleicht einbauen?
Also ".img.gz" als Extension bei gz-gepackten dd-Images.

Danke und Gruß,
Martin
#223 framp 2014-10-12 19:15
Moin 288GTO,
zitiere 288GTO:
...Mit dem Stoppen und Starten der verschiedenen Dienste vor und nach dem Backup hatte ich ein wenig Probleme, dieses habe ich nun in ein separates, kleines Shellscript ausgelagert, welches ich über deine START- und STOPSERVICES Variablen aufrufe, funktioniert einwandfrei.
Die -a und -o Parameter sind auch nur in einfachen Fällen zu benutzen. So wie Du es mit einem separaten Script machst ist eine gute Alternative. Die andere ist, dass Du ein Script schreibst, welches das Backupscript aufruft und darin alle administrativen Dinge vor und nach dem Aufruf des Scripts erledigt. Hängt alles davon ab wie gut man sich mit Scripts auskennt :roll:

Cu framp
#222 framp 2014-10-12 19:02
@PiBorg,

Du hast eine eMail von mir :-)

cu framp
#221 PiBorg 2014-10-12 11:37
Hey Framp,

vielen Dank für deine fixe Anpassung. Habe soeben ein neues rsync Backup mit deiner aktuellen Skript Version durchgeführt. Funktioniert soweit. Allerdings funktionieren folgebackups, auch nach einem Neustart nicht. Im Debug-Modus bekomme ich folgende Meldungen zurück (gekürzt wegen begrenzter Zeicheneingabe im Kommentarfeld):

###Start
INFO Backup created with return code: 12
INFO Backup finished
DEBUG >> backup
DEBUG cleanup
DEBUG >> cleanupBackup
DEBUG Got trap EXIT
??? Error occured with rc=12
ERROR Error occured with rc 12
###Ende

Kannst du dir das bitte nochmal ansehen, da scheint noch ein Fehler vorhanden zu sein. Vielen Dank.

Grüsse
#220 288GTO 2014-10-12 00:21
Hi framp!

zitiere framp:
Auch dass Du gleich die Zeilennummer reportet hast...

Selbstverständlich, wenn ich's eh schon für mich selbst gefixt habe.
zitiere framp:
Übrigends interessant dass das Script auch auf Odroid läuft. Welches OS nutzt Du?

Auf meinem Odroid U3 läuft Ubuntu 14.04 "headless" (ohne Grafik, ich arbeite nur über SSH damit):
Linux 3.8.13.28 #1 SMP PREEMPT Mon Sep 22 22:40:41 UTC 2014 armv7l armv7l armv7l GNU/Linux

Ich bin derzeit gerade beim Aufsetzen/Konfigurieren deines Scripts (ich verwende DD, komprimiert), habe das erstellte Image jedoch noch nicht getestet - das Erstellen läuft zumindest schon mal einwandfrei.
Mit dem Stoppen und Starten der verschiedenen Dienste vor und nach dem Backup hatte ich ein wenig Probleme, dieses habe ich nun in ein separates, kleines Shellscript ausgelagert, welches ich über deine START- und STOPSERVICES Variablen aufrufe, funktioniert einwandfrei.
#219 framp 2014-10-12 00:20
Moin Martin,

danke für den Hinweis. Ist jetzt gefixed. Da bin ich wohl mit den bbBBackups etwas durcheinandergekommen :lol:

Cu framp
#218 Martin 2014-10-11 23:39
Kleiner "Bug" in den cron examples im Skript - da ist überall ein "b" zu viel reingerutscht.:
... /usr/local/bin/raspbiBackup.sh ...
muss heißen:
... /usr/local/bin/raspiBackup.sh ...

Danke für das Skript und Gruß,
Martin
#217 framp 2014-10-11 19:09
Moin 288GTO,

vielen Dank für den Hinweis. Auch dass Du gleich die Zeilennummer reportet hast so dass ich nur noch den Code updaten musste und neu uploaden. Ist leider noch ein kleiner Fehler der durch die letzte größere Änderung reingerutscht ist :oops:

Übrigends interessant dass das Script auch auf Odroid läuft. Welches OS nutzt Du?

Cu framp
#216 288GTO 2014-10-11 16:41
Hi framp!

Ich verwende dein tolles Raspi-Backup-Script schon lange, und heute habe ich wieder mal auf die aktuelle Version upgedated.
(Ich verwende es nun auch für meinen Odroid U3.)

Mir scheint, dass in Zeile 509 (von Version 0.5.5.2a) ein "$" zuviel reingerutscht ist...

$BACKUPTARGET$_FILE

müsste

$BACKUPTARGET_FILE

lauten - dann klappt's bei mir auch mit dem komprimierten dd Backup. ;-)

Vielen Dank für dein tolles Script!
#215 Sergej 2014-10-10 00:17
zitiere framp:
@Sergej

Danke für Deinen Hinweis und Deine Hilfe den Fehler zu finden. Die größere Umstellung letztens hat leider auch bei sendEMail einen Bug erzeugt und mit Deiner Hilfe ist das jetzt in der neuesten Version gefixed :roll:


Der Mann ist unglaublich!
Das jemand sich so viel Zeit nimmt, um nach einem Problem für einen zu schauen ist erstaunlich.

Vielen Dank! :-)
Gruß Sergej
#214 framp 2014-10-10 00:08
@Sergej

Danke für Deinen Hinweis und Deine Hilfe den Fehler zu finden. Die größere Umstellung letztens hat leider auch bei sendEMail einen Bug erzeugt und mit Deiner Hilfe ist das jetzt in der neuesten Version gefixed :roll:
#213 framp 2014-10-09 23:11
@Sergej,

das kein Kontakt per irc möglich war - schicke mir mal das Log was Du bekommst mit -l 2 an meine eMail (Siehe Kontakt Seite).

Cu framp
#212 framp 2014-10-09 21:54
@PiBorg

Vielen Dank für Deinen aufmerksamen Test. Leider hat sich nach einer größeren Codeänderung ein Bug in das Script eingeschlichen, so dass Hardlinks bei rsync leider nicht mehr benutzt wurden :oops:

Das habe ich jetzt korrigiert und eine neue Version des Scripts uploaded.

Sorry for the inconvenience :cry:

Cu framp
#211 Sergej 2014-10-09 21:05
@frodo,

Genauso wie du den Commandlinebefehl geschrieben hast kann ich problemlos Emails senden. Wenn ich allerdings die Befehle nach -E "..." einfüge kommt der Fehler: Oct 09 19:01:18 raspberrypi sendEmail[8320]: Error: "-f email@hotmail.de -s smtp-mail.outlook.com:587 -xu email@hotmail.de -xp passwort" is not a recognized option!

Dank vielmals für deine Hilfe,
Gruß
Sergej
#210 framp 2014-10-09 20:46
Moin Sergej,

das ist dumm.

Als ich den Support für sendEmail eingebaut habe (ich benutze es selbst nicht) hat mir Dorf damals geschrieben, er würde mit folgendem Befehl eine eMail schicken können.

Comandlinebefehl sollte wie folgt aussehen:
sendEmail -f absender@absenderdomain.de -t empfaenger1@empfaengerdomain.de -u Betreffszeile -m Inhalt -s smtp-server -xu username -xp passwort

Kannst Du mir mal den Befehl posten mit dem Du so eine eMail versenden kannst?

Cu framp
#209 Sergej 2014-10-09 20:42
@framp Danke für den Tipp. Funktioniert leider Trotzdem nicht :cry: . Das ist ganz komisch, es ist ganz egal was ich hinter -E in den Anführungszeichen angebe, es kommt immer der Fehler "is not a recognized option!"
#208 framp 2014-10-09 19:11
@Sergej: Die Fehlermeldung kommt vom sendEmail. Das kennt den Parameter -t eMail nicht - aleso weglassen. Die eMailAddresse with dem Script mit -e ja schon mitgegeben :-)

@PiBorg: Das muss ich mir genauer ansehen. Bitte etwas Geduld :roll:
#207 Sergej 2014-10-09 11:37
Kann mir wer helfen ich bekomm es nicht hin die email mit sendEmail abzuschicken. Er sagt mir immer "is not a recognized option!". Mein Ausführparameter sieht so aus: sudo /usr/local/bin/raspiBackup.sh -p /media/hdd1/Backup -t tar -l 1 -L 2 -s sendEmail -E "-f Meineemail@hotmail.de -t Meineemail@hotmail.de -s smtp-mail.outlook.com:587 -xu MeinBenutzername -xp Meinpasswort" -e Meineemail@hotmail.de
#206 PiBorg 2014-10-08 23:02
Hoi Framp,

Ich habe den vorgeschlagenen Thread soben gelesen und bin leider noch mehr verwirrt als davor.

Beispiel: Das erste Bakup war 2GB gross. Zischenzeitliche haben sich 500MB neue Daten angesammelt. Das zweite Backup ist nun 500MB gross. Dadurch sind die Folgebackups ja auch schneller, Ist doch so korrekt, oder?

Bei mir ist das zweite Backup nun aber 2,5GB gross. Ich denke es wird bei mir einfach nur ein komplett neues Backup, so wie das erste Backup erstellt.

Liege ich damit richtig oder habe ich einen Denkfehler? Wenn ich richtig liege, wo kann ich ansetzen das wirklich nur die neuen Daten gesichert werden?

Danke und Gruss
#205 Framp 2014-10-08 17:49
Moin PiBorg,

Es wird immer ein Backupverzeichnis beim rsync backup erzeugt. Aber nur neue Daten kopiert. Ich habe das mit den Hardlinks mal hier http://www.forum-raspberrypi.de/Thread-raspbian-praktische-verwendung-von-hardlinks-bei-backups?highlight=Inode beschrieben. Lies es Dir bitte durch und ich hoffe dann ist Deine Frage beantwortet. Ansonsten melde Dich noch mal.

Cu framp
#204 PiBorg 2014-10-08 14:57
Hallo framp,

ich habe mir nun auf meinem NAS ein Backup-Share angelagt und dieses in Rasbian eingebunden. Nun habe ich das Skript unter /usr/local/bin abgelegt und ausführbar gemacht. Die Standard Parameter werden durch die /usr/local/etc/raspiBackup.conf überschrieben (so sollte es sein). Das manuelle Ausführen und Sichern auf dem Share funktioniert soweit.

Frage: Das Skript führe ich derzeit manuell aus und habe bei DEFAULT_KEEPBACKUPS=3 und bei
DEFAULT_BACKUPTYPE="rsync" angegeben.

Nun habe ich nach dem ersten Backup, testweise einfach ein Skript angelegt und erneut das Backup manuell aufgerufen. Erwartet hätte ich das nur das neu angelegte Skript gesichert wird, stattdessen wird jedoch ein komplett neues Backup erstellt.

Kann es sein das die Keepbackups-Funktion nur funktioniert wenn ich das Backup über Cron ausführen lasse? Was kann ich tun um das auch manuell zum Laufen zu bekommen?

Danke und Grüsse
#203 framp 2014-09-29 21:45
Moin Kalle,

ich benutze sendEMail nicht. Aber Dorf hatte damals nach sendEMail support gefragt was ich eingebaut haben und in Comment No #17 -> http://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself#comment-78 genau beschrieben welche Parameter er mitgeben musste.

Einfach mal dort nachlesen :-)

Cu framp
#202 Kalle 2014-09-29 21:39
Wie gebe ich die Parameter an, wenn eine Mail mit sendEmail geschickt werden soll ?

... -s sendEmail -e xxx@xxx.xx -E

Danke und Gruß
Kalle
#201 framp 2014-09-23 21:41
Moin HaDe,

Du hattest den Fehler

Meldet (Fehler?) 3, 8 und 2, ebenso syntaxfehler pipe-Zeichen sei unexpected ?

berichtet. Dazu benötige ich das debug Log was Du mit den Parametern -l 2 und -L 1 erzeugst in /var/log/raspiBackup. Kannst Du mir das bitte an meine Kontakt eMail schicken zwecks Analyse?

Cu framp
#200 HaDe 2014-09-22 23:22
sudo ./usr/local/bin/raspiBackup.sh -p /backup -t tar -k 4 -l 2

INFO raspiBackup.sh 0.5.5.1 (Rev 1.44 - 2014/09/19 17:53:43)
DEBUG Invocationparameters: -p /backup -t tar -k 4 -l 2
DEBUG > doit
DEBUG Startingdirectory: /
--- raspberrypi: raspiBackup.sh 0.5.5.1 started at Mo 22. Sep 22:47:52 CEST 2014 ...
DEBUG >> doitBackup
DEBUG NOS: 0 - EXCLUDE_DD: 0
/dev/mmcblk0p1 8192 3009765 1500787 e W95 FAT16 (LBA)
/dev/mmcblk0p2 3014656 15349759 6167552 85 Linux extended
?? More than two partitions mmcblk0p found (Using NOOBS ?)
#199 HaDe 2014-09-22 23:18
Hallo framp,

gerade sehe ich mit Freude, dass Du auf meine Email reagiert hast.
Noobs ist (noch) auf der sd, bei Betrieb mit größerer sd wäre es (so glaube ich) zum Expandieren des gesamten, möglichen Arbeitsbereiches nützlich?
Vielleicht teste ich auch die anderen Betriebsystemvarianten, möchte aber zum Anfang NUR eine 1:1 Kopie meiner eigerichteten SD-Karte hergestellt sehen. Mit dd ging das nur auf 16 GB, weil sich die Ziel-SD minimal kleiner als das 8 GB-Original herausstellte. Jetzt könnte ich noch hunderte von 8 GB-Karten probieren ?
Dein Script habe ich jetzt mit dem Aufruf "l 2" erweitert, ein Protokoll ist erzeugt:
Das hatte ich hier reinkopiert, die mir zur Verfügung gestellten Zeichen reichten nicht aus, als gibt es noch eine Email.
Gruß und danke für die Geduld HaDe
#198 framp 2014-09-22 12:44
Hallo DaHe,

solche Fehler sollte es nicht geben. Bitte lasse das Script mit den zusaetzlichen Parametern -l 2 (kleines L) und -L 1 noch einmal laufen und schicke mir die Logdatei aus /var/log/raspiBackup an meine eMail (Siehe KontaktSeite). Ich sehe mir das dann an und werde das Problem fixen.

Zu Deiner Frage mit mehreren Partitionen: Benutzt Du noobs? Willst Du nur Deine Daten sichern oder alles incl der Bootpartition?

Cu framp
#197 HaDe 2014-09-22 12:32
Hallo und guten Tag,

raspiBackup.sh hatte ich mir runtergeladen und installiert, weil ich mit rpi-clone.sh nicht klar kam. Meldet (Fehler?) 3, 8 und 2, ebenso syntaxfehler pipe-Zeichen sei unexpected ?

Damit kann ich nichts anfangen, weil linux-Neuling.

Schade dass raspiBackup.sh, weil es mehr als 2 Partitionen findet (using Noobs?), zur Sicherung meiner bisher recht erfolgreich eingerichteten 8 GB-micro-SD (Raspi B+) dann doch nicht geeignet ist ?

Gesichert hatte ich per dd, nach mehreren Versuchen auf einem Linux-Fremdrechner und Einsatz einer 16 GB SD.

Leider möchte ich nicht bei jeder Neusicherung immer größere Kartenkapazitäten nutzen müssen.

Läßt sich das Script anpassen oder muss ich Noobs entfernen und wie mache ich das ?

Danke und beste Grüße
#196 framp 2014-09-16 23:18
Mayki hat weiter unten Probleme berichtet, die mittlerweile offline gelöst wurden.
Anbei eine kurze Zusammenfassung der Probleme und deren Lösung:

1) Der tar Backup hat einen RC 2 gemeldet. Das lag daran, dass der Mount des externen Backup Devices unter /backup nicht funktionierte und das Backup auf die SD Karte geschrieben wurde, bis die Karte voll war und tar abbrach. Ich werde in eine zukünftigen Version des Scripts einen Test einbauen, der prüft, ob unter dem Backupverzeichnis ein mount auf ein externes Device existiert um sowas zu verhindern.

2) Das tar Backup hat einen RC 1 gemeldet. Das lag daran, dass nicht alle aktiven Services auf der Pi gestoppt wurden und tar bemerkte, dass sich gesicherte Dateien in der Zwischenzeit geändert haben. Nachdem diese Services auch vor dem Backup gestoppt wurden lief der Backup durch.
#195 Jakob Berr 2014-09-15 21:33
Super, vielen Dank für den Tip! Das ist genau das, wonach ich gesucht habe.
#194 framp 2014-09-15 20:22
Moin Jakob,

wie schon oben geschrieben wird NOOBS nicht unterstützt.

Aber so wie ich verstehe willst Du nur Deine SSD sichern. Das Sichern der Boot Partition sowie des Partitionslayouts der SD Karte, was raspiBackup.sh erledigt, benötigst Du nicht.
Dann würde ich einfach rsnapshot -> http://www.rsnapshot.org/ benutzen. Das benutzt auch Hardlinks wie raspiBackup.sh und ermöglicht BackupVersionen auf Tages-, Wochen- und Monatsbasis zu erstellen und vorzuhalten.
#193 Jakob Berr 2014-09-15 12:48
Hallo Framp! Erstmal vielen Dank dafür, dass Du dieses Script zur Verfügung stellst. Ich habe eben versucht, es auf meiner Pi laufen zu lassen, habe aber leider folgende Fehlermeldung bekommen:

--- raspberrypi: raspiBackup.sh 0.5.4.1 started at Mo 15. Sep 12:42:24 CEST 2014 ...
/dev/mmcblk0p1 133 1935359 967613+ c W95 FAT32 (LBA)
??? No data partition mmcblk0p2 found

Meine Pi läuft nicht mehr mit der Original SD-Karte, auf der NOOBS war - ich habe die System Disk (mmcblk0p6) ausgelagert auf ein externes Laufwerk und lediglich die BOOT Partition (mmcblk0p5) auf eine SD-Karte gespielt - diese startet jetzt die PI, während sich alles andere auf dem SSD abspielt. Ein zweites SSD mit gleicher Kapazität ist als sdb1 unter /backup gemounted. Dort würde ich gerne das erste SDD via rsync sichern. Hast Du einen Tipp für mich, wo ich das Script ändern müsste, damit das klappt? Vielen Dank!
#192 framp 2014-09-10 20:01
Die Fehlermeldung ist deutlich. Das Log kann nicht geschrieben werden. Merkwürdig ist, dass es mit dem tar Backup ging.
#191 Christoph Göpfrich 2014-09-09 22:06
Na super, mit tar ging es aber bei dd Backup bekomm ich folgende Meldung:

??? Error occured with rc=EXIT
tee: /var/log/raspiBackup/raspberrypi.log: Read-only file system
??? Backup failed. See logfile /var/log/raspiBackup/raspberrypi.log for details
/usr/local/bin/raspiBackup.sh: line 376: /bin/rm: No such file or directory
#190 framp 2014-09-09 21:58
In der Beschreibung für die Parameter steht
-s email Program welches benutzt wird {mail|sendEmail|ssmtp} (Default: mail)

D.h. also Du musst postfix oder sendmail die das Program mail beinhalten oder sendEMail oder ssmtp installieren.
#189 Christoph Göpfrich 2014-09-09 21:47
Ich benutze kein NOOBS. Habe direkt das Raspbian drauf. Habs nun in putty eingegeben und da funktioniert es, allerdings nur ohne den Email Parameter. Was muss ich denn für ein Email Programm installieren damit er mir eine Status Meldung sendet?
#188 framp 2014-09-09 21:43
Moin Christoph,

wenn Du diese Fehlermeldung bekommst existiert eine der zwei Partitionen der SD Karte nicht. Vermutlich hast Du ein NOOBS. Das ist aber nicht von dem Script supported.

Cu framp
#187 Christoph Göpfrich 2014-09-09 21:24
Könntest du mich vielleicht per Email kontaktieren?
#186 Christoph Göpfrich 2014-09-09 21:21
Hey framp,

in der log Datei sagt er "??? No boot partition mmcblk0p1 found"

Was heist das und wie kann man es beheben?
#185 framp 2014-09-08 16:46
Du kannst es ja mal probieren ob es bei Dir funktioniert und in dem Beitrag zum Restore in einem Kommentar Deine Erfahrung mitteilen - ob positiv oder negativ :-)
#184 Masque 2014-09-08 16:43
ok, danke für den Hinweis. Ich muss zugeben, dass ich nicht alle Kommentar durchgesehen habe.
Das händische Restore würde ich mir prinzipiell zwar zutrauen, aber man muss das Rad ja nicht immer neu erfinden wenn es schon Erfahrungen gibt. Ich such mal nach dem Kommentar. Besten Dank schon mal.
Gruß Masque
#183 framp 2014-09-08 16:27
Moin Masque,

wenn Du Dir alle Beiträge, die ich zur Raspberry auf dieser Seite erstellt habe, durchsiehst, wirst Du einen Beitrag finden, wo beschrieben ist wie man auch einen Restore mit dem Script vornehmen kann :-)
Diese Funktion benutzt jeder aber auf eigene Gefahr denn mangels Hardware und Zeit wurde die Restore Funktion nicht ausgiebig getestet. Bei mir mit meiner Hardware klappt es aber.
Im Zweifelsfall muss man den Restore händisch vornehmen und die Tools, mit denen das Backup erstellt wurde (dd, tar, rsync) benutzen um die Backups zu restoren.
Ich nehme Deinen Kommentar als Anregung und werde auf dieser Seite demnächst mal beschreiben, wie man händisch die Backups wieder restoren kann.

Cu framp
#182 Masque 2014-09-08 14:42
Hallo,
erstmal herzlichen Dank für das umfangreiche Script und die ausführliche Doku.
Ich backupe meinen Raspi per tar. Das klappt auch wunder bar.
Gibt es auch eine Anleitung wie man am besten ein Restore durchführt für den Fall, dass es die SD Karte komplett zerstört hat ?
#181 framp 2014-09-08 13:10
Moin Christoph,

es ist so schwer zu sagen warum es nicht funktioniert hat. So wie ich es verstehe hast Du den Backup per Cron angestossen. Hast Du vorher probiert ob Du es in der Befehlszeile aufrufen kannst und es funktioniert? Falls es da Probleme gibt kannst Du in /var/log/raspiBackup nach Fehlermeldungen sehen. Der zusätzliche Aufrufparameter -l 2 (kleines L) wird ein noch genaueres Log erstellen.
Sollte der manuelle Aufruf des Scripts funktionieren liegt der Fehler irgendwo im Aufruf in der /etc/contab. Vielleicht postest Du mal die Zeile wenn es daran liegt.

Cu framp
#180 Christoph Göpfrich 2014-09-08 12:38
Hey,

habe alles so eingerichtet wie bei dir in der Anleitung beschrieben, und habe meinen NAS gemountet um dort die Backups zu speichern. Allerdings hat er gestern Abend kein Backup erstellt? Hab ich was falsch gemacht?
#179 Mayki 2014-09-07 21:39
Vielen Dank für Ihre Bereitschaft ... :oops:
#178 framp 2014-09-07 21:19
Moin Mayki,

gib bitte Deine eMailAdresse bei Deinem nächsten Post an. Die kann nur ich lesen und ich werden DIch dann offline kontaktieren um Dein Problem anzugehen.

Cu framp
#177 Mayki 2014-09-07 20:55
Ich habe alles nach Anleitung, aber konnte es nicht tun.
raspiBackup.sh 0.5.4.1 (Rev 1.43 - 2014/08/24 07:27:46)
Invocationparameters: -p /backup -t tar -k 4 -o service xbmc stop -a service xbmc start
--- raspbmc: raspiBackup.sh 0.5.4.1 started at Sun Sep 7 20:47:54 CEST 2014 ...
/dev/mmcblk0p1 4096 147455 71680 c W95 FAT32 (LBA)
/dev/mmcblk0p2 151552 3842047 1845248 83 Linux
--- Stopping services ...
xbmc stop/waiting
--- Starting services...
xbmc start/running, process 4679
--- raspbmc: raspiBackup.sh 0.5.4.1 finished at Sun Sep 7 20:50:38 CEST 2014 ...
??? Error occured with rc=2
Invocation parms: '-p /backup -t tar -k 4 -o service xbmc stop -a service xbmc start'
??? Backup failed. See logfile /var/log/raspiBackup/raspbmc.log for details
#176 framp 2014-09-07 17:28
Moin Mayki,

nfs://192.168.0 .101/volume1/Backup funktioniert so nicht. Die NAS muss erst gemounted werden.
Folgende Vorgehensweise:
1) Nachsehen unter welchem Namen die Platte per nfs exportiert wird.
showmount -e 192.168.0.101
2) Vermutlich kommt /volume1/Backup als Antwort zurück.
3) sudo mkdir -p /backup
4) sudo mount 192.168.0.101:/volume1/Backup /backup
5) Aufruf des Backups mit
sudo raspiBackup.sh -p /backup -t tar -k 4 -o "service xbmc stop" -a "service xbmc start"
Wenn dann alles funktioniert den nfs Mount in die /etc/fstab eintragen und in die crontab folgendes schreiben:
15 19 * * 0 /usr/local/bin/raspiBackup.sh -p /backup -t tar -k 4 -o "service xbmc stop" -a "service xbmc start"

Cu framp

PS: Wenn Du willst kannst Du auch Deine Fragen in English stellen. Dann bitte aber auf der englischen Seite (oben links die USA Flagge clicken :-) )
#175 Mayki 2014-09-07 13:07
Hallo, Hilfe bei der Setup-Backup brauche ich, weiß ich nicht genau, wie sie sollten Befehle aus? Ich will zurück bis zu einem Ordner auf dem NAS Synology. Er will mich nicht um zu arbeiten ..
15 19 * * 0 usr/local/bin/raspiBackup.sh -p nfs://192.168.0.101/volume1/Backup -t tar -k 4 -o "service xbmc stop" -a "service xbmc start"
#174 framp 2014-09-05 20:28
Moin Padde,

ich werde Dich offline kontaktieren um rauszufinden was Du genau willst. Mal sehen was sich da machen lässt :roll:

Cu framp
#173 Padde 2014-09-05 20:25
Ich wäre tatsächlich an den unüblichen, jeweils separaten Logs interessiert :)
Ist das möglich?
#172 framp 2014-09-03 21:09
Moin Padde,

verstehe ich es richtig, dass Du gerne für jeden Backuplauf das jeweilige log parallel sichern willst?

Das ist eigentlich in der Linuxwelt unüblich. Ich könnte aber z.B. das Log nich wieder überschreiben bei einem Luaf sondern alle Logs hintereinander kopieren. Dann muss man allerdings selbst dafür Sorge trage, dass die Logdatei nicht zu gross wird

cu framp
#171 Padde 2014-09-02 19:03
Hallo,

super Anleitung, vielen Dank dafür!!

Eine Frage: Wie bringe ich dem sh bei, dass er alte log-Dateien nicht löscht? Ich hätte es gerne wie folgt:

backup01.tar
backup01.log
backup02.tar
backup02.log

Die Ausgabe der log-Dateien auf Netzlaufwerk sowie den korrekten Dateinamen habe ich bereits hinbekommen. Nur leider wird immer die alte log-Datei (im Beispiel wäre das "Backup01.log") gelöscht...

Danke im Voraus.

Gruß
Padde
#170 Padde 2014-09-02 13:42
Hallo framp,

bei mir erstellt das Backup keinen Unterordner mit dem Hostnamen. Das stört mich aber auch nicht.

Was ich gerne hätte: Unterordner, welche aus Datum und Uhrzeit bestehen, z.B. "20140902134000".

Alte Backups sollten natürlich dennoch gelöscht werden. Also muss dann der Unterordner des zu löschenden Backups gelöscht werden.

Wie bekommen wir das hin? 8)
#169 Christian 2014-08-26 19:47
Perfekter Skript und toller Kontakt, bin absolut begeistert. Vielen lieben Dank auch für die Anpassungen. :-)

Ein paar Tipps aus meinen Erfahrungen:

In Verbindung mit einer Time Capsule empfehle ich den timecapsule-handler-Skript, um vorher selbige einzuhängen und anschließend wieder auszuhängen (sollte wie auch die Sicherung an sich über einen Skript angestoßen werden).

Leider lässt diese kein rsync zu, daher empfehle ich tar zu verwenden, braucht nur 1/3 der Zeit von tgz.

Zum Mailen empfehle ich ssmtp und mpack. Ist sehr einfach einzurichten, wenn man keinen "echten" Mailserver auf dem Raspberry braucht oder will.
#168 framp 2014-08-24 11:39
@Patrick,
lass uns offline per eMail Dein Problem lösen., Ich habe Dir eine eMail an Deine in Deinem ersten Beitrag mitgeteilten eMail geschrieben :-)
#167 Patrick 2014-08-24 10:10
zitiere framp:
Moin Patrick,
ich habe mir erlaubt Deine eMail Adresse in Deinem Posting zu maskieren. Du bekommst wohl so schon genuegend Spam ;-)
Schlecht zu sagen was da krumm ist. Benutze mal den Parameter -l 2 (kleines L) und sieh dann in /var/log/raspibackup/HOSTNAME/raspibackup.log nach was da so drin steht. Das Script schreibt dann sehr viele Infos was es so tut.

Es passiert anscheinenden nichts...auch der weiserer läuft nach angeblichem start einfach weiter.
#166 Patrick 2014-08-24 10:09
zitiere framp:
Moin Patrick,
ich habe mir erlaubt Deine eMail Adresse in Deinem Posting zu maskieren. Du bekommst wohl so schon genuegend Spam ;-)
Schlecht zu sagen was da krumm ist. Benutze mal den Parameter -l 2 (kleines L) und sieh dann in /var/log/raspibackup/HOSTNAME/raspibackup.log nach was da so drin steht. Das Script schreibt dann sehr viele Infos was es so tut.

Es wird unter dem angegebenen Pfad kein log geschrieben...ich finde nur bei /var/log/raspiBackup eine file raspberrypi2.log geschrieben, das ist aber ein älteres log, als ich das Backup script manuell gestartet hatte.
#165 framp 2014-08-24 09:21
Moin Patrick,
ich habe mir erlaubt Deine eMail Adresse in Deinem Posting zu maskieren. Du bekommst wohl so schon genuegend Spam ;-)
Schlecht zu sagen was da krumm ist. Benutze mal den Parameter -l 2 (kleines L) und sieh dann in /var/log/raspibackup/HOSTNAME/raspibackup.log nach was da so drin steht. Das Script schreibt dann sehr viele Infos was es so tut.
#164 Patrick 2014-08-24 09:10
:cry: Moin, ich versuche Dein Skript zu nutzen. Wenn ich en Aufruf sudo raspiBackup.sh -p /media/backup -A -t tar -k 4 -e patrick@ABCDEF.ch -o 'service apache2 stop' -a 'service apache2 start' mache funktioniert alles bestens und das Backup wird erfolgreich angelegt. Wenn ich das ganze aber mit sudo crontab -e und mit 00 * * * * /usr/local/bin/raspiBackup.sh -p /media/backup -A -t tar -k 4 -e patrick@ABCDEF.ch -o 'service apache2 stop' -a 'service apache2 start' -b / eintrage wird der job anscheinend nicht ausgeführt. Nach 9 Minuten sehe ich mit grep CRON /var/log/syslog nur (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)

Was muss ich ändern?

Gruß
Patrick
#163 framp 2014-08-22 20:52
Hinweis: Die neue Version unterstütz nun auch reine tar Backups, d.h. die Backups sind nicht compressed. Wer compressed tars weiterhin haben möchte muss als type jetzt tgz und nicht tar angeben.
#162 framp 2014-08-13 20:26
Moin Alex,

freut mich, dass das Script Dir hilft bzw geholfen hat. Nett mal eine Successstory zu lesen. Gab bislang noch keine hier.

Wenn Du gerne was spenden willst gehe bitte auf http://www.ein-herz-fuer-kinder.de/. Dort bekommst Du auch eine Spendenbescheinigung ;-)

CU framp
#161 Alex 2014-08-13 01:10
Moin,

vielen Dank für das Maintainen dieses Scriptes! Ich nutze es jetzt schon einige Monate(Jahre?) und es hat mir grade mein System gerettet! Danke!
Wie und wo kann man Dir denn was zurückgeben?
Flatter vielleicht? Oder Paypal, Überweisung? ;)
Schönen Gruß, Alex
#160 framp 2014-08-10 21:20
Da es leider immer noch Spamkommentare trotz recaptcha gibt werden ab sofort Kommentare erst nach einer Kontrolle auf Spam veröffentlicht. I.d.R. wird das innerhalb eines Tages passieren.
#159 ecke_82 2014-06-26 06:47
Danke für die Antwort.

werde es über die dd + rsync variante lösen.
#158 framp 2014-06-25 21:04
Habe mal in der Codelibrary nachgesehen wann ich es auskommentiert habe: Bei der Erweiterung, dass verschiedene Backuptypen eines Servers in einem Verzeichnis gesichert werden können.

Hintergund ist, dass das nur ein Backup der xbmc Config Dateien ist. Zum restore muss man also immer erst ein neues frisches xbmc per dd aufsetzen und dann das Backup der Configs restoren. Ich denke es ist besser dann ein rsync Backup zu benutzen.

Wenn Du diese Funktion aber wieder gerne im Script haben möchtest kann ich sie wieder enablen. Da ich kein xmbc mehr habe müsstest Du es aber testen.
#157 ecke_82 2014-06-25 03:42
Hallo,
Das Script klingt richtig interessant.
Habe mir VERSION="0.5.2.7a" mal angesehen.
Sind die XMBC Backupfunktionen mit Absicht auskommentiert?

Ich nutze 3 Pi's. 2xRaspian & 1xRasbbmc.
Würde also die Funktion gerne nutzen.
#156 framp 2014-06-21 22:41
Moin Marko,

war die Tage im Urlaub und konnt deswegen nicht Dein Posting bearbeiten.

Vielen Dank für Deinen Hinweis. Leider verstehe ich nicht was Du warum geändert hast. Kannst Du bitte mal die alte und die neue Zeile sowie die Zeilennummer im Script (Version 0.5.2.7a) posten?

Cu framp
#155 Marko 2014-06-09 15:16
Ich vervende sendEmail. Raspibackup.sh macht das Backup, aber kann nicht (mehr) Email schicken.
RaspiBackup generiert den Befehl für sendEmail mit dem -m Aufrufparameter:
-m '--- raspbmc: raspiBackup.sh 0.5.2.7a started at Mon Jun 9 09:08:00 CEST 2014 ...'
SendEmail kann nicht "-" in dem Aufrufparameter richtig interpretieren und antwortet mit
"Jun 09 10:31:29 raspbmc sendEmail[11644 ]: Error: "--- raspbmc: raspiBackup.sh 0.5.2.7a started at Mon Jun 9 09:08:00 CEST 2014 ..." is not a recognized option!"

Wenn man in sendEmail -m "---" mit zB. "***" ersetzt, bekommt man funktionierenden Befehl.
Ich habe in raspiBackup.sh alle Zeilen mit echo gesucht und "---" mit "***" ersetzt. Jetzt bin ich (wieder) per Email benachrichtigt wie es mit dem Backup ist.
#154 framp 2014-06-01 16:19
Danke für den Hinweis Axel. Ist schon korrigiert. Durch die Umstellung der Webseite auf Mehrsprachigkeit sind leider ein paar Links gebrochen worden.
#153 Axel 2014-06-01 16:11
Hallo,

Dein Downloadlink im Text passt nicht.
Korrekt wäre
wget http://www.linux-tips-and-tricks.de/de/downloads/raspibackup-sh/download -O raspiBackup.sh

Mal bei Gelegenheit ändern.

Gruß Axel
#152 framp 2014-05-13 21:34
Moin Krassor,
da /media ein Standardmountpoint bei der Pi ist wird der implizit im Script excluded. Ausserdem wird immer der jeweilige Backuppath excluded, d.h. auch wenn Du den mountpoint /backup benutzen würdest wird der nicht gesichert. Anbei die Liste der ausgenommen PfadeCode: --exclude=$BACKUPPATH \ --exclude=/proc/* \ --exclude=/lost+found/* \ --exclude=/sys/* \ --exclude=/mnt/* \ --exclude=/media/* \ --exclude=/dev/* \ --exclude=/tmp/* \ --exclude=/boot/* \ --exclude=/run/* \ --exclude=/mnt/*
#151 Krassor 2014-05-13 21:28
Hallo :)
hab ne externe Platte unter /media/ eingebunden.
Wenn ich das dd-backup mit -b / durchführe, backuppt er mir dann nicht ebenso alle Festplatten, die unter /media/ eingebunden sind?
#150 georg 2014-05-05 14:28
Perfekt! Vielen Dank :-)
#149 framp 2014-05-02 15:31
@Balou: Die neue Version 0.5.2.7a kann jetzt alle Backuptypen in einem Verzeichnis ablegen :-)
#148 framp 2014-05-01 19:42
Moin tom,

es ist Option a. Wenn es aber vieles ist was zu starten/stoppen ist würde ich das aber in ein Bash Script auslagern (z.B. raspiBackupStartStop.sh und im Script werden alle Services gestartet bzw gestoppt und in der Variablen steht nur DEFAULT_STOPSERVICES="raspiBackupStartStop.sh stop" bzw DEFAULT_STARTSER VICES="raspiBackupStartStop.sh start")
#147 tom 2014-05-01 19:30
Hi framp,
danke für den Hinweis. Ich habe keine weiteren .conf Dateien . Im script habe ich jetzt alle Mail relevanten Parameter auf NULL "" gesetzt.

Das Script scheint jetzt nachdem ich die Service stoppen / starten auch noch geleert habe zu laufen. Wenn ich das richtig verstehe ist die Konfig für mehrere Services wie folgt:

Option a) DEFAULT_STOPSERVICES="Service1;Service2;Service3" oder
Option b) DEFAULT_STOPSERVICES="Service1";"Service2";"Service3"
#146 framp 2014-05-01 16:14
Moin tom,

Du hast offensichtlich alle Parameter in /usr/local/etc/raspiBackup.conf definiert. Leider werden die Parameter per debug noch nicht getraced :sad: Aber ich bin mir sicher Du hast da irgendwas für DEFAULT_EMAIL definiert. Denn ansonsten wird da kein Check nach einem installierten Mailserver vorgenommen.

Sieh da noch mal nach bzw poste ansonsten mal den Inhalt.

CU framp
#145 framp 2014-05-01 16:09
Für neue Funktionsanfragen zum Script habe ich eben diese Seite erstellt.

@tom: Solange Du kein -e im Aufruf mitgibst wird keine eMail geschrieben. Welchen Fehler bekommst Du denn?
#144 tom 2014-05-01 15:28
beim Aufruf des Scriptes erhielt ich diesen Fehler:

raspiBackup.sh 0.5.2.6 (Rev 1.33 - 2014/04/12 17:38:07)
Invocationparameters: -l 2
DEBUG: Options: -l 2
DEBUG: Startingdirectory: /usr/local/bin
--- raspberrypi: raspiBackup.sh 0.5.2.6 started at Mi 30. Apr 12:48:35 CEST 2014 ...
??? Mail program not installed to send emails
DEBUG: Got trap EXIT
??? Error occured with rc=EXIT
DEBUG: Error occured with rc EXIT
Invocation parms: '-l 2'
DEBUG: Removing incomplete backup /mnt/backup/archive/raspimage/
Assertion failed in line 243
#143 framp 2014-05-01 13:51
Wenn Du nach raspibackup auf dieser Webseite suchst (oben rechts) wirst Du fündig ;-)
#142 jens 2014-05-01 11:33
Hallo,

also das mit dem ssh stelle ich mir so vor, man kann ja bei rsync ein ssh login machen auf einen anderen server, ich glaube die parameter sind -e "/usr/bin/ssh -p 22 -l benutzername"
Das könnte man eventuell irgendwie über die config als zusätzliche Parameter übergeben?
Dann müßte man noch das Kennwort eingeben, oder man hat die ssh keys auf den jeweiligen Rechnern abgespeichert, dann gehts ohne Kennworteingabe (für die automatische Sicherung unerlässlich)

Der Restore müßte per Hand doch einfach bei tar mit
tar xvpfz backup.tgz -C /
eingespielt werden? Oder wie ist es richtig?
Ich bin glaub ich gerad zu blöden, deinen Disclaimer zu finden ....Bzw, die Seite wo Du das Restore beschreibst...

Gruß
Jens
#141 framp 2014-04-30 19:48
zitiere tom:
... Ich habe das Problem das ich keinen Mailserver auf dem raspi installieren möchte - und das script deswegen abbricht.
Das sollte eigentlich nicht sein. Das Script sollte auch ohne eMail Senden durchlaufen. Ich sehe mir das mal an und fixe das.
#140 framp 2014-04-30 19:45
Moin Jens,

zum Restore: Mit Absicht habe ich keinen Link hier in dem Beitrag gesetzt, denn der Restore ist mangels Zeit und Hardware nicht gut getestet. Er funktioniert bei mir aber perfekt. Deshalb gibt es einen Disclaimer auf der Seite wo ich die Funktion beschreibe.

zum rsync und ssh: Ja, da hast Du Recht. Das Script ist historisch gewachsen von dd zu tar zu rsync. Bei den beiden ersten musst Du eine Platte gelinked haben. Deshalb ist das auch bei rsync eine Voraussetzung. Ich kann mir das aber mal gerne ansehen ob ich das irgendwie einbauen kann, wenn Du die Funktion unbedingt brauchst.
#139 jens 2014-04-30 13:53
... man könnte sich beim backup mit rsync auch über ssh auf der einer anderen Maschine einloggen, wo die Sicherung liegen soll. So muß dann gar kein Laufwerk am Raspberry pi gemountet werden.

Gruß
Jens
#138 jens 2014-04-30 13:43
Hallo ,
das script ist prima meine beiden raspberrys zu sichern. Ich habe in raspberry forum gelesen, das Du auch ein restore script geschrieben hast und du das auf Anfrage zu Verfügung stellst?
Gruß
Jens
#137 tom 2014-04-30 10:11
Hallo framp,

fantastisches Script um die Beere zu sichern. Ich habe das Problem das ich keinen Mailserver auf dem raspi installieren möchte - und das script deswegen abbricht. Wie kann man alternativ zu dem email versenden diese als Eventdateien ablegen, so daß das script durchläuft ?

Grüße,
Tom
#136 Balou 2014-04-25 16:24
Ich habe ein zweiten Cronjob eingerichtet und sichere in einem zweiten Verzeichnis. So habe ich ein Tar backup und ein DD Backup. Wenn mal nichts geht wird das image zurückgesichert und gut. Geht manchmal schneller als die Fehlersuche
Balou
#135 framp 2014-04-24 21:45
Moin Balou,

das ist eine interessante Frage. Das Script wurde nicht dafür geschrieben unterschiedliche Backuptypen zusammen in einem Verzeichnis zu haben. Ich habe da bei mir unterschiedliche Backupverzeichnisse benutzt. Der Code löscht immer das älteste Backup im Backupverzeichnis.
Eigentlich ist das eine nicht schlechte Idee das zu unterstützen. Dann kann man z.B. alle Monate ein DD Backup ziehen und ansonsten ein RSYNC Backup.

Ich werde mir das mal die nächsten Tage genauer ansehen und einbauen, dass man verschiedene Backuptypen sichern kann und immer der älteste Backup vom jeweiligen aktuellen Backup Typen gelöscht wird.
#134 Balou 2014-04-24 10:19
Ich setzte das Script seit einiger Zeit ein um meine beiden Pis zu sichern. Klappt soweit alles perfekt. Hat mir auch schon geholfen als ich Daten wieder zurückholen mußte. Ich sichere regelmäßig auf dem NAS und auf einen USB Stick. Beim spielen welche die beste Backup Variante für mich ist bin ich über folgendes gestolpert. Per Cronjob sichere ich mit folgenden Parametern /media/usb1/Backup/System -t tar -k 4 -e root -b /. Soweit alles okay. 4 Backup werden vorgehalten. Versehentlich habe ich mit /media/usb1/Backup/System -t dd -k 4 -e root -b / gesichert. Es wurde ein Backup erstellt und wieder gelöscht. Im Verzeichnis lagen die vorher gesicherten 4 Tar Backups. Sichere ich in einem leeren Verzeichnis ist alles okay. Sollte das Script nicht das älteste Backup löschen unabhängig von Art?
#133 framp 2014-04-18 10:10
Im Gegensatz zu einem DD Backup sind die TAR und RSYNC Backups keine vollstaendigen Imagebackups. Es muss immer das Partitionlayout, die Partitionstabelle und die Bootpartitiondaten erstellt bzw restored werden. Deshalb sichern TAR und RSYNC auch noch das PartitionLayout und die erste kleine Bootpartition, die /boot enthaelt. Beim Restore mit dem Script werden auf der SDKarte die Partitions neu angelegt, dann die erste Partition mit /boot restored und danach die gesicherten Daten von TAR bzw RSYNC.

Wenn Du manuell aus dem tar restoren willst musst Du erst das Partitionlayout incl Partitiontable sowie die Bootpartition erstellen.

/dev wird beim Booten des OS angelegt und muss deshalb nicht gesichert werden.
#132 Yannick 2014-04-18 09:47
Warum werden beim tar Backup alle möglichen wichtigen Verzeichnisse wie etwa /boot oder /dev vom Backup ausgeschlossen ? Damit ist ja klar, warum die SD-Karte nicht lauffähig ist im Pi nach einem restore.
#131 framp 2014-04-12 19:20
zitiere Yannick:
...Ich verstehe nur noch nicht ganz warum du die Variable "EMAIL_PARMS" nicht auch in der Configdatei erwähnst...

Die Parameter sind spaeter auf Nachfrage eingebaut worden um weitere eMailProgramme zu unterstuetzen. Da habe ich einfach vergessen den auch noch in die Config mit aufzunehmen. Wird in dern nächsten Version gefixed sein.
#130 Yannick 2014-04-12 00:24
Wahrscheinlich ist es auch korrupt. Erstelle ich z.b eine tar datei von /home/pi funktioniert das entpacken. Der Fehler trat ja bei ner log Datei auf. Dann habe ich mal in das Verzeichnis geschaut und die ganzen logs entdeck. Die sind riesig und doppelt und dreifach vorhanden. Läuft bei Dir logrotate oder etwas ähnliches ? Ich habe die überflüssigen Logs dann gelöscht und ein neues tar angefertig (700 MiB jetzt, vorher 865 MiB). Mit diesem neuen tar werde ich es morgen nochmal versuchen. Jetzt gehts erstmal ins Bett :zzz
#129 framp 2014-04-11 20:30
Hm ... das sieht mir so aus als wäre das tar File korrupt. Gab es einen Fehler beim Erstellen des Backups? Teste mal mit tar -tf backupFile ob Du dann den Inhalt des tars komplett sehen kannst.
#128 Yannick 2014-04-11 11:10
Nochmals Hallo,

das wiederherstellen aus der tar Datei hat leider nicht funktioniert. :-| Am Ende tritt ein Fehler auf (siehe Bild):
https://dl.dropboxusercontent.com/u/1684046/2014-04-11%2010.55.31.jpg

Unter dem Fehler kannst Du den Befehl sehen mit welchem ich versucht habe die Datei auf der SD Karte wiederherzustellen. Die Quelle ist dabei ein USB Stick. Das ganze lief unter Kubuntu auf einem Live-USB Stick
#127 Yannick 2014-04-11 09:13
Hallo framp,

das Problem lag woanders und ich konnte es selbst lösen nachdem ich deinen echt langen Code verstanden habe :lol: (kenne mich eigentlich nur ein bisschen mit python aus).
Mein USB Stick habe ich in /media/usbstick gemountet. Das geht bei tar natürlich nicht, weil man diesen Teil nicht sichert. Usbstick unter /backup gemountet und es geht.

Ich verstehe nur noch nicht ganz warum du die Variable "EMAIL_PARMS" nicht auch in der Configdatei erwähnst. Wenn man sich ne Mail via sendEmail schicken lassen will muss man sich doch am smtp Server anmelden oder?. Das ist das einzige was jetzt noch nicht ganz klappt.
Gleich werde ich versuchen meine Tar-Sicherung via Ubuntu-Live wiederherzustellen. :)
#126 framp 2014-04-10 20:04
Moin Yannik,

wie sieht den die Aufrufbefehlszeile genau aus? Ich denke da stimmt was nicht mit dem Argument fuer -a. Du kannst aber auch mal Deine Befehlszeile mit dem Parameter -l 2 (kleines L gefolgt von 2) erweitern und das Logfile zeigen.
#125 Yannick 2014-04-10 13:36
Hallo framp,

ich habe eben versucht ein tar-Backup zu erstellen. Leider ohne Erfolg. Im logfile stehen nur Fehler aus denen ich nicht schlau werde:

--- raspberrypi: raspiBackup.sh 0.5.2.5a started at Thu Apr 10 13:25:54 CEST 2014 ...
--- Stopping services ...
??? Error occured with rc=EXIT
??? Backup failed. See logfile /var/log/raspiBackup/raspberrypi.log for details

Gruß, Yannick
#124 framp 2014-03-28 22:41
Leider kann ich nicht anhand des Traces rausfinden warum es Probleme gibt. Rufe das Script noch mal mit dem zusaetzlichen Parameter -v auf und Poste das Ergebnis des Logs.
#123 Robert 2014-03-21 07:09
Hi Framp,

immer Easy ist nicht eilig.
#122 f amp 2014-03-21 02:49
Komme aber erst in D wieder dazu mich mit dem Log zu befassen :roll:
#121 Robert 2014-03-19 19:38
Hier das log
http://pastebin.com/6ZJLNeWs
#120 framp 2014-03-18 20:27
zitiere Tim:
Ich könnte mir vorstellen, dass 'framp' jetzt sagen würde (wenn er gerade nicht im Tokio'er ÖVNP steckt), dass Du mal dein Log-File (mit -l 2) zur Verfügung stellen sollst ;-)
Bin noch nicht in Tokyo - erst morgen :-* Aber genau das ist es was ich brauche um mal nachzusehen. Den Tracelog mit -l 2 (uns zwar auf pastebin.com)
#119 Tim 2014-03-18 20:04
Ich könnte mir vorstellen, dass 'framp' jetzt sagen würde (wenn er gerade nicht im Tokio'er ÖVNP steckt), dass Du mal dein Log-File (mit -l 2) zur Verfügung stellen sollst ;-)
#118 Robert 2014-03-18 19:11
Naja das ist ja grad mein Problem.
Das Ziel Laufwerk ist per NFS gemountet.
Da sind noch satte 500GB frei, wenn das nicht reicht!
Das komisch ist, wenn ich ein dd backup mache funktioniert alles, nur mit rsync nicht.
#117 Tim 2014-03-18 18:53
Hi Robert,

mein Aufruf steht in Kommentar #110..

Dein RSYNC-Prozess liefert wohl als Return Code (RC) Fehler 12. Das wäre ggf. eine volles Ziellaufwerk?

http://forum.ubuntuusers.de/topic/rsync-error-code/

Cheers,
Tim
#116 Robert 2014-03-18 17:04
Hi Tim,

kannst du mir deinen Rsync Aufruf posten.
Ich bekomme immer den folgenden Fehler
??? Error occured with rc 12
??? Backup failed. See logfile /var/log/raspiBackup/cardserver.log for details
#115 framp 2014-03-18 15:01
:lol: ... Du hast Glück dass ich gerade Urlaub habe und versuche rauszufinden, wie ich am besten vom Tokio FH nach Tokio City per ÖPNV komme. Das Problem mit dem Script ist dagegen peanuts :roll:
#114 Tim 2014-03-18 14:56
Wow, danke, funktioniert jetzt wieder fehlerfrei! Das ist ja fast Enterprise-level Support ;-)

sent 440602785 bytes received 188860 bytes 974125.18 bytes/sec
total size is 931025694 speedup is 2.11
INFO: Backup created with return code: 0
DEBUG: Deleting oldest directory in /backup/MonitorPi
DEBUG: Current directory: /root
INFO: Backup finished
--- MonitorPi: raspiBackup.sh 0.5.2.4 finished at Di 18. Mär 14:55:13 CET 2014 ...
DEBUG: Enddirectory: /root
INFO: Cleanup: 0
--- Backup finished successfully
#113 framp 2014-03-18 14:45
Das war zwar nocht nicht der detailierte Log den ich haben wollte - aber ich habe auch so rausgefunden was los ist :-)

Es kann bei rsync vorkommen, dass sich Dateien ändern oder verschwinden im Backuprozess. Letzteres ist bei mir bislang noch nicht vorgekommen. Es gibt jetzt eine neue Version 0.5.2.4 die diesen Fehler ignoriert.
#112 Tim 2014-03-18 14:32
Danke für das schnelle Feedback ;-)

Mit -l 2 bekomme ich via Mail und Log-File diese Informationen:

http://pastebin.com/9ZfsxeMf (Hier gibts sonst einen "Comment too long"-Fehler)

Auf dem Raspberry Pi läuft der Nagios-Fork "Icinga"; vermutlich legt der während der Laufzeit des Backups Dateien an, bzw. löscht sie wieder, und das führt zu dem Problem?

Dann müsste ich wohl entweder
- var/lib/icinga/spool/ irgendwie vom Backup ausschließen
- den Icinga-Dienst vor dem Backup stoppen und danach wieder starten

Danke für den Hinweis mit dem detaillierteren Logging ;-)
#111 framp 2014-03-18 14:04
Ist leider so schlecht zu sagen was da los ist. In /var/log/raspibackup muss eine Logdatei stehen. Sieh mal nach was Du dort findest. Alternativ das Script noch mit -l 2 (kleines L) aufrufen um den Debugmodus einzuschalten. Dann steht in dem Log File noch wesentlich mehr drin.
#110 Tim 2014-03-18 13:14
Habe das neue Skript per rsync getestet, funktioniert einwandfrei (Backup auf /backup, welches ein per NFS gemountetes NAS-Laufwerk ist).
:-?
Der zweite Aufruf des Backups hat dann einen Fehler erzeugt, von dem ich nicht weiß, ob er relevant für die Konsistenz des Backups ist?

Irgendeine Idee dazu?

root@MonitorPi:~# ./raspiBackup.sh -p /backup -t rsync -k 4 -e mail@dummy.de -b / -A
--- MonitorPi: raspiBackup.sh 0.5.2.3a started at Di 18. Mär 13:07:57 CET 2014 ...
--- MonitorPi: raspiBackup.sh 0.5.2.3a finished at Di 18. Mär 13:12:05 CET 2014 ...
??? Error occured with rc 24
#109 framp 2014-03-14 22:06
Freut mich dass das Script Dir hilft. Was hat openssl mit dem Backup zu tun?
#108 Alex 2014-03-14 21:58
Hallo, habe rsync und tar ausprobiert. Alles läuft super wie beschrieben, ich sichere direkt auf eine NFS-mount. Vielen Dank für deine Leistung und Mühe!

Eine Frage jedoch: was ist eigentlich aus dem Verschlüsseln mittels openssl geworden?
#107 framp 2014-03-10 21:52
Eben habe ich einen dummen Bug im aktuellen Script gefixed :oops: . Durch den Bug wird eine Datei im Backupverzeichnis erstellt (...maillog), die dort nix zu suchen hat. Nachdem die Datei gelöscht wird und das aktuelle Script benutzt wird, werden wieder hard links benutzt für rsync Backups und somit Speicherplatz für die Backups reduziert.
#106 framp 2014-03-02 17:22
Eben habe ich einen weiteren Beitrag erstellt wo beschrieben ist wie man das Script auch zum Restore benutzen kann. Wer Lust hat und das Risiko liebt kann es ja auspro