Überblick

raspiBackup erstellt Backups vor Raspberry Pis. Das Script kann den erstellten Backup auch wieder restoren. Dabei werden auf der Ziel SD Karte neue Partitionen angelegt und dann mit dem entsprechenden Tool (dd, tar oder rsync) die Daten wieder restored. Das dd Backup kann man auch unter Windows restoren. Alle anderen Backuptypen benötigen eine Raspberry mit einem laufenden Raspbian oder ein anderes System, welches Linux als Betriebssystem hat. Ein manueller Restore der Daten mit den zuvor benutzten Backuptools dd, tar oder rsync ist natürlich auch möglich. Sollte ein externes Rootfilesystem gesichert worden sein wird es auch wieder auf ein externes Gerät zurückgespielt.

 

 

Funktionsübersicht

  • Einfacher Restore der Sicherung für Windows, Mac oder Linux Benutzer mit der Raspberry selbst
  • Meldungen in Deutsch und Englisch
  • Externes Rootfilesystem kann gesichert und restored werden wenn der normale Backupmodus und ein tar oder rsync backup benutzt wurde
  • Einsetzbar auch zum Klonen von einer Raspberry Pi
  • Einfacher Update des Scripts durch die aktuellste Version (-U Parameter)
  • Raspberry Pi kann sich selbst wiederherstellen
  • Manuelle Wiederherstellung eines Backups

 

Inhaltsverzeichnis

Aufrufsyntax und -optionen

Wiederherstellungsszenario für Windows- und Macbenutzer

Wiederherstellungsszenario für Linuxbenutzer

Beispielaufrufe

 

Aufrufsyntax und -optionen

 

Hinweis

Für den Restore sollte immer dasselbe Operatingsystem benutzt werden auf welchem das Backup erstellt wurde. Es gibt Inkompatibiliäten bei geänderten Tools und der Restore bricht dadurch ab. Momentan ist es sfdisk welches sich zwischen Wheezy und Jessie geändert hat.

raspiBackup muss als Benutzer root oder per sudo aufgerufen werden.

raspiBackup.sh Option1 Option2 Option3 ... [Backupverzeichnis bzw Backupdatei] 

Je nachdem ob das Quellsystem nur die SD Karte benutzt oder sein Rootfilesystem extern ausgelagert hat sind zwei verschiedene Aufrufe des Restores zu unterscheiden, die durch den Parameter -R gesteuert 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.

 


Parameter Funktion Standard
-C Beim Formatieren wird mit der Option -c bei mkfs.ext4 auf Bad Blocks geprüft. Hinweis: Die Restorezeit wird dadurch erhöht. Verfügbar ab V0.6.3.2 Aus
-d

Ausgabedevice (die SD Karte oder USB Stick). Beispiel: /dev/sda

Achtung: Dieses Device wird vollständig gelöscht und neu angelegt! Beim tar und rsync Backup wird automatisch die Größe der root Partition entsprechend verkleinert oder vergrößert wenn die SD Karte oder USB Stick eine andere Größe hat als die SD Karte des Backups.

Keiner
-R

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

Achtung: Diese Option nur benutzen wenn sowohl eine SD Karte als auch ein externes Rootfilesystem auf USB Stick benutzt wird. Sonst reicht die Option -d.

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

Hinweis: Diese Option steht nur zur Verfuegung wenn der normale Backupmodus benuzt wurde. Im partitionsorientierten Modus (Option -P) kann keine externe Rootpartition mitgesichert werden.

Keiner

--resizeRootFS

--noResizeRootFS

Ab Version 0.6.3.2:

Während der Wiederherstellung kann die Rootpartition auf die maximal verfügbare Größe der SD Karte oder der externen Partition ausgedehnt werden.

Ein
-0 Es wird kein neues Paritionslayout auf der SD Karte erstellt sondern das existierende benutzt. Details dazu siehe FAQ #6 Aus
-1 Das Partitionslayout wird auf der SD Karte erstellt so wie es auf der Original SD Karte existiert und dabei werden sämtliche Fehler die entdeckt werden - incl Fehler dass die Ziel SD Karte zu klein ist - ignoriert.  Siehe FAQ #6 für weitere Details.
Hinweis: Diese Option kann unerwartete Ergebnisse habenBenutze die Option nur wenn Du weisst was Du tust.
 Aus


 


 

Wiederherstellungsszenario für Windows- und Macbenutzer

Sofern eine DD Backup erstellt wurde kann das mit dem Windows32DiskImager restored werden. Alternativ kann jedes Backup mit der Pi wiederhergestellt werden. Soll ein TAR oder RSYNC Backup wiederhergestellt werden muss dieser alternative Weg beschritten werden. Die folgenden Schritte sind notwendig:

1) Ein raspbian auf der Raspberry starten

2) Die SD Karte auf die wiederhergestellt werden soll muss in einem SD Kartenlesen angeschlossen werden

3) Das Medium, welches das Backup enthält (z.B. eine Platte) muss angeschlossen und gemounted werden bzw ein Netzwerklaufwerk mit den Backupdaten muss gemounted werden

4) Falls die Rootpartition ausgelagert wurde muss eine weitere Platte angeschlossen werden, die die Rootpartition enthält, welche wiederhergestellt werden soll

Dabei wird üblicherweise die SD Karte /dev/sda, die Backuppartition /dev/sdbx und eine eventuelle Rootpartition /dev/sdcx. Wird ein Netzlaufwerk benutzt ist die Rootpartition dann üblicherweise /dev/sdbx

Die aktuelle Gerätebelegung kann anders sein und sollte immer mit

sudo parted -l 

überprüft werden um zu vermeiden dass andere Partitionen irrtümlicherweise überschrieben werden.

 

Wiederherstellungsszenario für Linuxbenutzer

Dieses sieht genauso aus wie das für Windows- und Macbenutzer. Im Unterschied braucht aber die Raspberry Pi nicht benutzt sondern wird die SD Karte mit dem SD Kartenleser an das Linuxsystem angeschlossen, die Backuppartition gemounted und eine Partition für ein eventuelles externes Rootfilesystem bereitgestellt.

 

Beispielaufrufe

Notwendige Hardware für den Restore:

1) Eine laufende Raspberry Pi mit einem laufenden raspbian oder einem anderen Linux Betriebssystem oder ein anderer Linux Rechner mit installiertem raspiBackup.

2) Einen angeschlossener SD Kartenleser und eingelegte neuer SD Karte

3) Ein angeschlossenes Backupdevice (per USB oder Netz)

4) Falls eine externe Rootpartition wiederherzustellen ist muss noch per USB eine weitere Platte oder SD Karte angeschlossen sein.

 

Restore auf eine SD Karte

  1. Das gesicherte System heisst im Beispielaufruf raspberrypi
  2. SD Karte die den Restore der Boot- und Rootpartition erhalten soll ist im Beispiel als sdf verfügbar. Achtung: Alle bestehenden Daten der SD Karte werden nach einer Sicherheitsabfrage von raspiBackup vor dem Restore gelöscht.
  3. Das zu restorende Backup ist unter /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/ verfügbar
  4. Hier ist beschrieben wie man den aktuellen Wert für -d herausfinden kann

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

 

Restore auf eine SD Karte und eine externe Partition

  1. Das gesicherte System heisst raspberrypi
  2. Es wurde auf /dev/sda eine entsprechend grosse Partition /dev/sda1 angelegt um den Restore aufzunehmen. Eine Formatierung ist nicht notwendig.
  3. Die SD Karte die den Restore der Bootpartition erhalten soll ist im Beispiel als sdf verfügbar. Achtung: Alle bestehenden Daten der SD Karte werden nach einer Sicherheitsabfrage von raspiBackup vor dem Restore gelöscht.
  4. Die externe Rootpartition auf der das Rootfilesystem restored werden soll liegt im Beispiel auf sda1. Achtung: Alle Daten der Partition /dev/sda1 werden nach einer Sicherheitsabfrage von raspiBackup vor dem Restore gelöscht.
  5. Das zu restorende Backup ist unter /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi/-rsync-backup-20141230-213032/ verfügbar
  6. Hier ist beschrieben wie man den aktuellen Wert für -d und -R herausfinden kann
sudo raspiBackup.sh -d /dev/sdf -R /dev/sda1 /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/ 

 

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

Auf demr raspberry muss man folgenden Befehl eingeben:

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

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

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

Nun sieht man dass die interne SD Karte /dev/mmcblk0 8GB gross ist, die neue externe SD Karte /dev/sda 16Gb gross ist und die externe Platte /dev/sdb auf die die Rootpartition gebracht werden soll ist 300GB gross und hat eine Partition /dev/sdb1.

Somit sind ist der Parameter für  -d /dev/sda (Externe SD Karte). Falls eine externe Rootpartition mitgesichert wurde ist noch -R /dev/sdb1 (Externe Rootpartition) notwendig. Die Parameter müssen natürlich den lokalen Gegebenheiten angepasst werden.

 

Hinweis

EIn Backup sollte regelmäßig getestet werden ob der Restore immer noch funktioniert und auch immer noch alle Daten beinhaltet. Nichts ist so frustrierend wenn man in dem Moment, wo man das Backup benötigt, feststellt, dass das Backup korrupt ist oder nicht alle Daten enthält. Ein Test ist bei der Raspberry recht einfach. Eine neue SD- Karte einlegen, das Backup restoren und von der neuen SD-Karte booten.

Falls aus irgendwelchen Gründen der Restore mit dem Script fehlschlägt kann man natürlich jederzeit die vom Script gesicherten Daten mit den Standard Linuxtools, die zum Backup genutzt wurden - dd, tar oder rsync - wieder restoren. Allerdings geht das dann nicht so bequem wie mit dem Script.
 

Kommentare   
#257 framp 2018-06-04 19:19
Für die Mitleser,

Markus hat ein raspiBackup Image welches per Stretch erzeugt wurde versucht mit einem Weezy zu restoren. Leider hat sich das sfdisk inzwischen inkompatibel zwischen Wheezy und Stretch geändert :cry:

D.h. es ist tunlichst angeraten ein backup auf der OS version zu restoren auf dem es erstellt wurde. Leider speichert raspiBackup beim backup nicht ab welches OS version benutzt wird und kann deshalb auch nicht auf diese Inkompatibilitaet in einer Meldung hinweisen :sigh:
#256 framp 2018-06-02 12:39
Moin Markus,

der SD Karte ist wohl zu heiss geworder. Oder hat der Blitz eingeschlagen? :-*

Bei den Ausgaben kann ich nicht sehen was die Ursache ist. Lsse den restore noch mal mit der Option Code:-l debug laufen und schicke mir das Debuglog zur Analyse zu. Meine eMail findest Du auf der Kontaktseite ;-)

PS: Du bist nicht der Erste dem das passiert. Und ich sach noch ... :roll:

Cu framp
#255 Markus 2018-06-02 12:06
Hier noch das Log aus der Log-Datei:

20180602-115736: MSG --- RBK0128I: Logdatei ist /home/pi/raspiBackup.log.
20180602-115736: MSG --- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
20180602-115739: MSG !!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht.
20180602-115739: MSG
20180602-115739: MSG !!! RBK0100W: Gerät /dev/sdb wird mit dem Backup beschrieben.
20180602-115740: MSG --- RBK0038I: Bist Du sicher? j/N
20180602-115742: MSG --- RBK0009I: raspberrypi3: raspiBackup.sh V0.6.3.2a (1015c57) um Sa 2. Jun 11:57:42 CEST 2018 gestartet.
20180602-115742: MSG --- RBK0097I: Partitioniere und formatiere /dev/sdb.
20180602-115742: MSG --- RBK0052I: Partition(en) werden auf /dev/sdb erstellt.
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 14772 cylinders, 64 heads, 32 sectors/track
Old situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 8192 93236 85045 c W95 FAT32 (LBA)
start: (c,h,s) expected (4,0,1) found (0,130,3)
end: (c,h,s) expected (45,33,21) found (5,204,60)
/dev/sdb2 94208 30253055 30158848 83 Linux
start: (c,h,s) expected (46,0,1) found (5,220,24)
end: (c,h,s) expected (1023,63,32) found (1023,254,63)
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty

sfdisk: unrecognized input: dos
20180602-115743: MSG
Usage: umount -h | -V
umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
umount [-d] [-f] [-r] [-n] [-v] special | node...
Usage: umount -h | -V
umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
umount [-d] [-f] [-r] [-n] [-v] special | node...
20180602-115743: MSG ??? RBK0077E: Restore wurde fehlerhaft mit RC 112 beendet. Siehe vorhergehende Fehlermeldungen.
#254 Markus 2018-06-02 12:05
Hallo,
ich habe beim Restore des Backups leider ein kleines Problem und komme nicht weiter... Ich weiß, es heißt erst das Backup testen, aber wie es der Teufel so will, ist das System erst abgeschmiert, bevor ich eine neue SD organisieren konnte... Also spiele ich das Backup auf die Karte auf, von dem es kommt. Folgende Aufrufe haben ich gemacht und dabei nachfolgeneden Output bekommen:

pi@raspberrypi ~ $ sudo fdisk -l | egrep "^Disk /|^/dev"
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 31116287 15496704 83 Linux
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
/dev/sda1 2048 1953521663 976759808 7 HPFS/NTFS/exFAT
Disk /dev/sdb: 15.5 GB, 15489564672 bytes
/dev/sdb1 8192 93236 42522+ c W95 FAT32 (LBA)
/dev/sdb2 94208 30253055 15079424 83 Linux
pi@raspberrypi ~ $ sudo raspiBackup.sh -m detailed -d /dev/sdb /mnt/fritzbox/Backup_RPi/RPi3/raspberrypi3/raspberrypi3-tgz-backup-20180523-192041/
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.3.2a (1015c57) um Sa 2. Jun 11:57:36 CEST 2018 gestartet.
--- RBK0128I: Logdatei ist /home/pi/raspiBackup.log.
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt.
!!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht.

!!! RBK0100W: Gerät /dev/sdb wird mit dem Backup beschrieben.
--- RBK0038I: Bist Du sicher? j/N j
--- RBK0009I: raspberrypi3: raspiBackup.sh V0.6.3.2a (1015c57) um Sa 2. Jun 11:57:42 CEST 2018 gestartet.
--- RBK0097I: Partitioniere und formatiere /dev/sdb.
--- RBK0052I: Partition(en) werden auf /dev/sdb erstellt.

??? RBK0077E: Restore wurde fehlerhaft mit RC 112 beendet. Siehe vorhergehende Fehlermeldungen.


Nur zur Info, an dem RPi, mit dem ich das Restore mache, hängt noch eine externe HD.

Kann mir hier jemand helfen?

Vielen Dank im Vorraus

Markus
#253 framp 2018-04-01 21:23
Moin Lscheff,

das klingt sehr merkwürdig. Hast Du beim Backup Fehlermeldungen bekommen? Ansonsten lass mal den Backup mit der Option -l debug durchlaufen und schicke mir das Log an meine eMail (-> Kontakt Seite):

Cu framp
#252 Lscheff 2018-04-01 20:42
ich nutze die aktuelle Version und bis aufgrund des dhcp Problems auf rsync umgestiegen.
Habe heute festgestellt bei einem restore dass keine img, mbr, sfdisk Dateien abgelegt wurden. daher auch kein Restore möglich.
ich habe eine neue Installation auf eine 128GB Karte gemacht und dann ca. 4 Probeläufe durchgeführt.
Wo ist mein Fehler?
#251 framp 2018-04-01 10:39
Moin MadTrinity,

freut mich dass der restore nun geklappt hat. ZU Deinem dhcp Problem: Das ist bekannt und wurde u.A. hier schon behandelt ;-)

Cu framp
#250 MadTrinity 2018-04-01 06:19
Hallo Leute,

Danke für eure Hilfe also madm4x mit deinem blkid konnte ich nichts anfangen.

Danke framp mit deinem post konnte ich das Backup erfolgreich zurückspielen ausser Dhcpd scheint alles zu funktionieren

Danke nochmal
Gruss
Mad
#249 framp 2018-03-31 21:28
Moin MadTrinity,

es gibt einen Unterschied zwischen /dev/sda und /dev/sda1: Ersteres ist ein Device/Gerät. Letzteres ist eine Partition.

madm4x hat es geschrieben: Du musst beim Restore ein Gerät angeben - also /dev/sda - keine Partition. Beim ersten Restoreversuch hast Du richtigerweise /dev/sda angegeben. Da war aber /dev/sda1 noch gemounted :sigh: Jetzt hast Du plötzlich ein /dev/sda1 genommen :cry:

Versuche es noch mal wieder mit /dev/sda :-)

Cu framp
#248 madm4x 2018-03-31 20:34
zitiere framp:

Lass mich wissen wenn das noch nicht ausreicht ;-)

Cu framp


Da er schreibt das Null Linuxkenntnisse vorhanden sind, wird das befürchte ich nicht ausreichen ;)

@Mad

bevor du das Backup wiederherstellst solltest du erstmal rausfinden auf welchem Laufwerksname deine neue SD liegt bzw. eingebunden ist. Am einfachste ist das denke ich mit dem Befehl "blkid" .. in der Ausgabe siehst du dann welches Device deine neue SD Karte hat.

Denn /dev/sda sollte oder ist in der Regel immer die Karte auf der sich das System befindet von dem Bootest und mit dem du gerade arbeitest. Und darauf sollte ja wohlkaum das Backup zurück gespielt werden. ;)

Die Neue SD Karte sollte daher eher /dev/sdb oder /dev/sdc lauten so das der Befehl dann raspiBackup.sh -d /dev/sdb oder sdc sein müsste. Und wenn du dir unsicher bist führst du als erstes "blkid" aus und schließt dann die neue SD Karte an. Anschließen führst du "blkid" nochmal aus und siehst welches Device neu hinzugekommen ist.

VG
#247 MadTrinity 2018-03-31 20:14
Hi framp,
danke für deine mühe, linux ist nicht meine Welt habe versucht damit was anzufangen leider ohne erfolg.

sudo parted -l
Model: Generic Mass-Storage (scsi)
Disk /dev/sda: 31,9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 4194kB 31,9GB 31,9GB primary fat32 lba


Model: SD SL32G (sd/mmc)
Disk /dev/mmcblk0: 31,9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 4194kB 70,3MB 66,1MB primary fat32 lba
2 70,3MB 31,9GB 31,8GB primary ext4

sudo mount | grep /dev/sda
/dev/sda1 on /media/pi/3363-6538 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

dann habe ich mal sudo umount /dev/sda1
und danach nochmal das zurückspielen ausprobiert

sudo raspiBackup.sh -d /dev/sda1 /media/NetBackup/raspberrypi/raspberrypi-tar-backup-20180315-051002/
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.3.1 (590ae9c) um Sa 31. Mär 20:10:47 CEST 2018 gestartet.
??? RBK0086E: Wiederherstellungsgerät darf keine Partition sein.
??? RBK0077E: Restore wurde fehlerhaft mit RC 107 beendet. Siehe vorhergehende Fehlermeldungen.

Was muss ich den jetzt machen habe eine neue SD Karte in den USB Adapter gesteckt da möchte ich gerne das Backup was auf der NAS liegt zurückspielen.

Was muss ich machen?

Gruß
Mad
#246 framp 2018-03-31 17:48
Moin Mad,

Deinen Kommentar habe ich zum Anlass genommen die Fehlermeldung RBK0154E hier zu dokumentieren. Lass mich wissen wenn das noch nicht ausreicht ;-)

Cu framp
#245 MadTrinity 2018-03-31 12:29
Hallo,
habe mir eine neue SD Karte geholt und wollte ein Backup auf die neue Karte zurückspielen.
Das Backup liegt auf meiner NAS, die neue SD Karte ist in einem Adapter am USB eingesteckt.

Blick da nicht so richtig durch
habe es so probiert

sudo raspiBackup.sh -d /dev/sda /media/NetBackup/raspberrypi/raspberrypi-tar-backup-20180315-051002/

bekomme aber eine Fehlermeldung
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.3.1 (590ae9c) um Sa 31. Mär 12:26:32 CEST 2018 gestartet.
??? RBK0154E: Ein Restore ist nicht möglich wenn eine Partition von /dev/sda gemounted ist.
??? RBK0077E: Restore wurde fehlerhaft mit RC 102 beendet. Siehe vorhergehende Fehlermeldungen.

Kann mir einer bitte schreiben wie ich das Backup jetzt auf die neue Karte bekomme. Es sind nahezunull Linux kentnisse vorhanden.

Vielen Dank vorab
Gruß
Mad
#244 framp 2018-03-24 12:43
Moin Kuppi,

Zitat:
Warum sollte ein Restore auf die gleiche SD-Karte funktionieren, wenn es von einem rsync Backup erfolgreich funktioniert und das System anschließend einwandfrei läuft?
Weil vielleicht andere Stellen auf der SD Karte benutzt werden und keine defekten dabei sind. Mir wurden schon ganz verueckte Fehler bercihtet durch defekte SD Karten. Ist aber nur eine Vermutung meinerseits.

Zitat:
Es treten Fehler auf das Hardware nicht korrekt eingebunden wird, zumeist wird das WLAN nicht eingebunden oder es gibt Schwierigkeiten mit dem Bluetooth. Zuletzt hat bei mir ein Restore von einem tar Archiv gebootet und bei Start von X hat sich das System aufgehangen.
Das könnte natuerlich auch ein Timingproblem beim Booten sein. Ich habe das Gefuehl dass das u.U. mit dem dhcp auch ein Timingproblem sein koennte. Ist aber auch nur eine Vermutung :roll:

Zitat:
Ja, ich benutze für meine Backups nun immer rsync und bestätige das klappt damit auch das Restore.
Ich benutze auch rsync und da laeuft alles ohne Probleme. Ehrlich gesagt finde ich von den drei Backupmethoden, dd, tar und rsync auch rsync das bester Verfahren. Es werden nicht immer alle Daten kopiert und man hat die BackupDaten nicht in einer Datei gepackt sondern gleich griffbereit. Dadurch kann man eben schnell mal einzelene Dateien manuell aus dem Backup zurueckholen wenn man merkt dass eine /etc Datei verhunzt wurde :-)
Zitat:
Ich bin mir nicht ganz sicher ob dass das Backup auch auf nicht Linux Filesysteme funktioniert.
Nein, es funktioniert nicht. rsync benoetigt ext3/4 da es nur da Hardlinks gibt.

Probleme mit tar gibt es immer wieder so dass ich manchmal ueberlegt habe tar ganz rauszunehmen aus raspiBackup. Aber es gibt auch viele Benutzer von tar die haben keine Probleme. Deshalb lasse ich es drin - auch wenn es immer wieder deshalb Problemberichte und Diskussionen gibt.

Cu framp
#243 Kuppi 2018-03-24 12:20
Hallo framp,
das es an einer defekten SD-Karte liegt schließe ich aus. Warum sollte ein Restore auf die gleiche SD-Karte funktionieren, wenn es von einem rsync Backup erfolgreich funktioniert und das System anschließend einwandfrei läuft?

Nein, es liegt nicht daran das keine IP Adresse bezogen wird. Es treten Fehler auf das Hardware nicht korrekt eingebunden wird, zumeist wird das WLAN nicht eingebunden oder es gibt Schwierigkeiten mit dem Bluetooth. Zuletzt hat bei mir ein Restore von einem tar Archiv gebootet und bei Start von X hat sich das System aufgehangen.

Ja, ich benutze für meine Backups nun immer rsync und bestätige das klappt damit auch das Restore. Ich bin mir nicht ganz sicher ob dass das Backup auch auf nicht Linux Filesysteme funktioniert, das teste ich noch mal aus. Aktuell verwende ich immer ein EXT4 Filesystem formatiertes Volume, dann kann man sicher sein das es auch funktioniert.

Gruß,
Kuppi...
#242 framp 2018-03-23 18:26
Moin Kuppi,

wenn Du beim tar Backup beim restorten System unterschiedliches Fehlerverhalten bekommst liegt es vermutlich an einer defekten SD Karte.

Wenn das Verhalten immer gleich ist und keine IP Adresse bezogen wird findest Du direkt unter Deinem kommentar jemanden der selbige Erfahrung gemacht. Dort habe ich auch Hinweise auf loegliche Lösungen genannt:

1) rsync benutzen
2) networkd und nicht dhcpcd benutzen

Auch ich habe dieses Verhalten be Restoretests mit raspiBackup bei Jessie und Stretch festgestellt und versucht eine Lösung zu finden - dann aber nach Tagen der Suche und des Testens aufgegeben :sad:

Cu framp
#241 Kuppi 2018-03-22 16:48
Die erstellten Backups lassen sich nur lauffähig wieder Restoren wenn der Backup Typ rsync ist. Das Backup läuft auch mit tar durch (unabhängig ob mit ZIP oder ohne Komprimierung), aber wenn ich das Backup auf ein Device Restore startet der Raspberry zwar aber läuft nicht richtig. Mal wird Hardware nicht korrekt erkannt, mal bleibt das System beim Bootvorgang irgenwo hängen, etc...etc...
Wiederhole ich den Vorgang mit identischer Hardware (also gleiches Device unter /backup gemountet) nur im Mode rsync und stelle das Restore wieder her, dann läuft alles. Ich vermute das es mit Links (symbolisch oder auch hard) zusammen hängt, bin aber nicht sicher. Auf jeden Fall bekomme ich ein lauffähiges Restore nur von einem rsync erstellten Backup wieder hergestellt, alles andere funktioniert nicht.

Jemand ähnliche Erfahrung oder einen Tipp für mich?

Danke und besten Gruß,
Kuppi...
#240 framp 2018-03-21 22:09
Moin Lscheff,

zitiere Lscheff:

1000 Dank. Hat prima funktioniert, zumindest sieht das nach den ersten Tests gut aus :D
:thumbsup:

zitiere Lscheff:

Kann man nicht ein Diff der dhcpcd5 Installation (Inhalte und Rechte) vorher/nachher machen?


Ich habe Tage spendiert um die Ursache rauszufinden und letztendlich aufgegeben :cry: Ja, kann man sicherlich. Ich habe wie gesagt irgendwann aufgegeben. Es scheint auch irgendwie mit Deinem Router bzw der dhcp Konfig zusammenzuhängen. Das tar bei Jessie ist neu und unterstuetzt weitere Attribute wie xattr. Es kann sein dass dass man damit das Problem loesen kann.

Man muss nur Zeit investieren :-*

Cu framp
#239 Lscheff 2018-03-21 21:40
Hi framp,

ja Jessie und tar backup.

1000 Dank. Hat prima funktioniert, zumindest sieht das nach den ersten Tests gut aus :D

Wenn die De- und Installation von dhcpcd5 erfolgreich war, dann liegt es doch sicher an fehlenden Dateien oder Rechten. mir ist aufgefallen, dass beim ersten Booten die Datei rc.local eine Fehlermeldung gezeigt hat. Kann man nicht ein Diff der dhcpcd5 Installation (Inhalte und Rechte) vorher/nachher machen?
#238 framp 2018-03-20 23:16
Moin Lscheff,

ich vermute mal dass Du ein tar Backup unter Jessie hastdenn nur da weiss ich von einem dhcp Problem beim Restore (Siehe hier) :roll:

Die einzige Möglichkeit die ich kenne erfordert
1) einen angeschlossenen Monitor
2) eine angeschlossene Tastatur
3) eine Kabelverbindung

Dann logon als pi und
Code:sudo dhcpcd eth0<br />sudo apt-get remove dhcpcd5<br />sudo apt-get install dhcpcd5<br />

Vermutlich geht es auch mit einer WLAN Verbindung aber dann muss wlan0 anstatt eth0 benutzt werden.

Cu framp
#237 Lscheff 2018-03-20 22:24
Hi framp,

Habe (glücklicherweise) ein Backup gemacht bevor meine SD Karte dahin ging. Jetzt habe ich das Problem mit dem dhcp nach dem restore. Kannst du mir bitte den workaround geben, damit mein raspi wieder arbeiten kann?
#236 framp 2018-03-01 20:07
Moin dgh,

dieses Szenario wurde nicht beruecksichtigt.

Ich sehe aber drei Moeglichkeiten für Dich:

1) Du probierst es einfach mal aus. Es gibt eine gewisse Wahrscheinlichkeit dass es funktioniert. Dann benutzt noch Du -l debug beim restore und schickst mir das Debuglog per email zu. Vielleicht kann ich es ja relativ schnell fixen.

2) Du definierst die zwei Partitionen (boot und root) auf der SSD und benutzt restore wobei Du auch eine SD Karte benutzt. Dann kopierst Du per DD die Bootpartition des Backups auf die SSD. Anschliessend updatest Du in /etc/fstab die uuid der Bootpartition und nimmst dabei die uuid der Rootpartition aus der fstab.

Cu framp
#235 dgh 2018-03-01 10:07
Hallo,

mein System bootet im Moment von SD und die root partition ist auf einer SSD.
Gesichert wurde immer mit der tar option.Es wurde auch ein image von der boot partition auf der sd erstellt.

Nun möchte ich so restoren (auf eine ssd oder auf eine sd), dass ich das ganze System (root & boot) wieder auf einem einzigen Medium habe.

Wie sieht dazu der restore Befehl aus ? Geht das überhaupt ?

Gruss
#234 framp 2018-02-10 18:43
Moin Matze,

so wie ich es sehe sollte ausser der Homematik SW nicht weiter gestoppt werden müssen.
Vielleicht liest ja auch ein Homematic Benutzer hier mit und kann Dir dazu seinen Kommentar abgeben. Oder Du fragst auch mal im Homematic SW Forum nach ob da jemand raspiBackup benutzt und was er stoppt.

Cu framp
#233 Matze 2018-02-10 18:13
Nabend,

welche Services muss ich vor dem Backup beenden? Könnt ihr mir einen Rat geben? Auf meinem Pi3 läuft die Homematic-Software. Bisher stoppe ich nur "cron".

pi@PiVccu:~ $ service --status-all
[ + ] alsa-utils
[ + ] avahi-daemon
[ + ] bluetooth
[ - ] console-setup.sh
[ + ] cron
[ + ] dbus
[ + ] dphys-swapfile
[ + ] fake-hwclock
[ - ] hwclock.sh
[ - ] keyboard-setup.sh
[ + ] kmod
[ + ] lxc
[ + ] lxc-net
[ + ] lxcfs
[ + ] networking
[ - ] nfs-common
[ - ] paxctld
[ - ] plymouth
[ - ] plymouth-log
[ + ] procps
[ + ] raspi-config
[ + ] rpcbind
[ - ] rsync
[ + ] rsyslog
[ + ] ssh
[ - ] sudo
[ + ] triggerhappy
[ + ] udev

Gruss Matze
#232 Matze 2018-02-08 10:01
Hi framp,

Dank deiner schnellen Hilfe funktionniert der Restore jetzt bei mir. Besten Dank.

Backup mit "rsync" habe ich mit Hilfe der "FAQ 17" überprüft, rsync funktioniert tatsächlich. Ich dachte es wird immer ein komplettes Backup erstellt, weil ich die Speichergröße von den einzelnen Backups verglichen habe, ist immer identisch.

Danke schön

Gruss
Matze
+1 #231 framp 2018-02-07 20:37
Moin Matze,

die Meldunge bekommst Du wenn Du fuer Option -d eine Partition angibst, also z.B. /dev/sda1. Du kannst nicht auf eine Partition restoren. Es muss eine ganze SD Karte sein wie z.B. /dev/sda.

Bist Du sicher dass rsync immer ein komplettes Backup erstellt? Siehe dazu FAQ 17

Cu framp
#230 Matze 2018-02-07 15:05
Hallo,

ich habe von meinem RaspberryPi3, auf dem Raspian Stretch läuft, erfolgreich ein "dd" und ein "tar" Backup erstellt. Bei "rsync" hatte ich Probleme, es wurde jedesmal ein komplettes Backup erstellt.
DIe Backups werden auf meiner Synology NAS abgelegt, das mounten des Laufwerks war kein Problem.
Nun wollte ich zum Test von meinem Laptop (LinuxMint) das Backup auf eine leere SD-Karte (steckt im externen Kartenleser) zurückschreiben.
Nun erscheint aber folgende Fehlermeldung: "RBK0086E Wiederherstellungsgerät darf keine Partition sein".
Wie bekomme ich das Problem gelöst?

Gruss
Matze
#229 framp 2018-01-22 21:26
Moin Georg,

ja - gestern Abend um 21:30 Uhr. Ich habe Dir eben die Mail noch einmal geschickt. Vielleicht siehst Du mal in Deinem Spamordner nach ;-)

Cu framp
#228 Georg 2018-01-22 20:47
Hi framp,

sorry - aber hast du mir die Datei schon geschickt? An EDIT framp: eMail gelöscht ...
#227 framp 2018-01-20 21:26
Moin Georg,

ja - es gibt einen Workaround: Den dhcpd neu zu installieren. Aber dazu brauchst Du eine direkte Verbindung zur Raspi. Auch muss das ohne Workarounds mit der IP funktionieren. Ich habe Dir die Beta zugeschickt ;-)

Cu framp
#226 Georg 2018-01-20 21:07
zitiere framp:
Moin Georg,

ich vermute Du hast ein Jessie oder Stretch gesichert. Da gibt es Probleme mit dhcpd. Entweder Du benutzt dd oder rsync Backup oder Du testest mit der aktuellen neuen Betaversion, bei der die neue tar Funktionalität von Jessie/Strech benutzt wird und wo es keine Probleme mit dhcp gibt. Wenn Du die nächste Betaversion ausprobieren willst lass mich wissen und ich schicke sie Dir zu.

Cu framp


Ja - gerne. Würde ich schon mal testen.
Gibt es keine Möglichkeit dhcpd irgendwie manuell wieder einzurichten?
#225 framp 2018-01-20 21:01
Moin Georg,

ich vermute Du hast ein Jessie oder Stretch gesichert. Da gibt es Probleme mit dhcpd. Entweder Du benutzt dd oder rsync Backup oder Du testest mit der aktuellen neuen Betaversion, bei der die neue tar Funktionalität von Jessie/Strech benutzt wird und wo es keine Probleme mit dhcp gibt. Wenn Du die nächste Betaversion ausprobieren willst lass mich wissen und ich schicke sie Dir zu.

Cu framp
#224 Georg 2018-01-20 20:49
Hallo framp,

vielen, herzlichen Dank für die schnelle Hilfe. Es hat geklappt! :lol:

Ein Problem habe ich noch - ich weiß das hier der richtige Ort ist. Ich habe die SD-Karte nun in einen Raspberry von dem NICHT das Backup ist. Dieser Raspberry bootet scheinbar normal, ich kann mich sogar mittels Login und PW einloggen.
Nur via SSH (ist aktiviert) und Browser (ein entsprechender Dienst läuft) komm ich nicht drauf. Laut "ip r" hat der Raspi gar kein keine IP-Adresse... Bei "netstate" ist auch alles leer...

Kann es sein, dass dies an dem unterschiedlichen Raspi liegt (= unterschiedliche MAC)?
#223 framp 2018-01-20 19:59
Moin madm4x,

raspiBackup restore sollte auf jedem normalen Linux funktionieren. Ich benutze raspiBackup auch immer auf meinem Linux System (Mint) um ein Backup zu restoren. Warum soll es dann nicht auf einer Syno funktionieren? Da läuft ja auch ein Linux. Testen kann ich es nicht da ich keine Syno habe. Aber ich bin zuversichtlich dass es funktioniert.

Cu framp
#222 madm4x 2018-01-20 19:52
zitiere Georg:
Nun wollte ich mal den Restore auf meiner Synology getest.

- raspibackup habe ich erfolgreich auf der Synology installiert
- eine SD-Karte in den SD-Schacht der NAS gesteckt


raspibackup auf einer Synology?
Hab ich was verpasst? ;)
+1 #221 framp 2018-01-20 18:56
Mojn Georg,

Du hast eine Partition von /dev/sdq noch gemounted. Da der Restore alles auf /dev/sdq überschreibt ist das eine Warnung und verhindert dass Du aus versehen eine falsche Partition plattmachst denn eine gemountete Partition ist normalerweise absichtlich gemounted weil sich Daten darauf befinden ;-)

Mit Code:mount kannst Du nachsehen was Du fuer eine Partition gemountet hast und wenn es wirklich die richtige ist sie mit Code:sudo umount /dev/sdq aushaengen. Dann wird raspiBackup nicht mehr meckern :lol:

Cu framp
#220 Georg 2018-01-20 18:10
Hallo,

ich habe ein Backup im tar-Format erstellt. Nun wollte ich mal den Restore auf meiner Synology getest. Leider ohne Erfolg.
- raspibackup habe ich erfolgreich auf der Synology installiert
- eine SD-Karte in den SD-Schacht der NAS gesteckt
- Befehl: sudo raspiBackup.sh -d /dev/sdq ioBroker-RasPi-tar-backup-20180115-012001
Fehlermeldung: Ein Restore ist nicht möglich wenn eine Partition von /dev/sdq gemounted ist.

Was mache ich falsch?
#219 madm4x 2018-01-06 14:18
Moin,

wahrscheinlich hab ich deswegen direkt von Anfang an mein System auf USB ausgelagert ;)

Freut mich ebenfalls das alles wieder läuft und die Tatsache das sowas an einer defekten SD liegen kann ist auf jeden Fall notiert ;)


VG
#218 Zwieback 2018-01-06 13:18
Moin framp,

Danke nochmals für Deien Hilfe.
Leider konnte ich mit "sudo e2fsck -c -c /dev/sdg2"
die SD-Karte nicht reparieren.
Selbst ein Formatieren mit gparted war erfolglos. Due Partitionen und Dateien wollen einfach nicht verschwinden. Hab jetzt also eine "SD-Rom" Karte :lol:
#217 framp 2018-01-06 13:11
Moin Zwieback,

Vielen Dank für Deinen Update. Freut mich dass es jetzt wie gewünscht funktioniert.
Tut mir leid dass mir nicht eher eingefallen ist dass sowas schonmal wegen einer defekten SD Karte berichtet wurde :-* . Ist jetzt das zweite Mal und zukünftig werde ich bestimmt dran denken. :-)

Cu framp
#216 Zwieback 2018-01-06 12:49
Moin, moin framp

Erfolgsmeldung: Dein Script und dd waren nicht Schuld!!!!!!
Hab heute mal bei "ALDIgutenGaben" zugeschlagen und mir zwei neue SD-Karten besorgt.
Das erste original RaspiBackup mit Win32DiskImager auf die neue SD Karte gezogen und siehe dar:

Alles läuft wie es laufen soll :-)
Login wird gespeichert und auch die erstellten Daten sind nach reboot wieder vorhanden!

Vielen Dank für Deine /Eure Hilfe
#215 framp 2018-01-05 20:41
Dann benutze aber die Optionen -c -c bei mkfs um explizit zu prüfen ob die SD karte OK ist ;-)
#214 Zwieback 2018-01-05 20:36
es wird immer verwunderlicher,

hab einmal mit Win32DiskImager ein frisches Stretch Image auf die SD Karte kopiert und mich doch sehr gewundert das ich genau das gleiche Verhalten mit dem gleichem letztem Login habe.
Mein Pi3 läuft mit einem kleinem Display an den GPIOs.
Dafür muss ich einige Anpassungen am frische System vornehmen.
Beim erstem Boot des frischen Images war das >Display aber bereits funktionstüchtig!!!
Gehe jetzt davon aus das die SD Karte defekt ist.

Werde mal meinen PC mit Linux starten und die komplette SD-Karte formatieren.
#213 framp 2018-01-05 19:21
In /var/log/syslog.

Aber Du koenntest recht haben. Ich erinnere mich jetzt an einen Fall dass bei einem raspiBackup Benutzer alle Aendernungen wieder weg waren sobald ein Reboot erfolgte weil die SD Karte einen weg hatte und der Superblock nicht geschrieben werden konnte. Im Superblock stehen alle Verweise auf Dateien und wenn da kein Update erfolgen kann bleibt der alte Inhalt stehen.

Teste doch mal mit einer anderen SD Karte bzw fuehre mal ein Code:e2fsck -c -c auf der SD Karte aus. ACHTUNG: Der Check dauert sehr lange !

Cu framp
+1 #212 Zwieback 2018-01-05 18:59
Moin framp,

mal in eine ganz andere Richtung gedacht!
Gibt es eine Log Datei für das Runterfahren des Pi?
Mir ist aufgefallen das beim starten des Pis ab und an ein "checkdisk" ausgeführt wird.
Werden unter Umständen alle Änderungen nicht abgespeichert weil der Pi nicht sauber herunter fährt.
Könnte es damit zu tun haben?
#211 madm4x 2018-01-04 21:36
zitiere framp:
Ich will mal die nächsten Tage ein dd Backup von Stretch erzeugen und ich hoffe ich kann Dein Problem reproduzieren.

Hast Du mal ein rsync Backup ausprobiert?

Cu framp


Kannst du dir eigentlich sparen ;)

Rsync unter Stretch läuft und dd kann ich gerne morgen oder am WE mal testen.

Ne Lösung oder Ursache ist mir allerdings auch noch nicht in den Sinn gekommen :(

@Zwieback
Hast du mal sämtliche Log Files durch geschaut?
Oder auch mal nachgeschaut ob und Journald was zu finden ist?


VG
#210 framp 2018-01-04 21:23
Dann nimm tar :-) . Dann brauchst Du nichts umzupartitionieren.
#209 Zwieback 2018-01-04 21:21
Moin framp,

für das rsync Backup muss ich erst mal meien hdd neu partitionieren um einen ext4 Partition zu erhalten. Die Platte läuft derzeitig als NTFS Partition.
#208 framp 2018-01-04 21:17
Moin Zwieback,

klar doch. Die Symptome sind so merkwuerdig dass ich natuerlich auch wissen will worin die Ursache liegt - auch wenn es nichts mit raspiBackup zu tun hat.

Dein mount Delta hat nichts damit zu tun. Ich will mal die nächsten Tage ein dd Backup von Stretch erzeugen und ich hoffe ich kann Dein Problem reproduzieren.

Hast Du mal ein rsync Backup ausprobiert?

Cu framp
#207 Zwieback 2018-01-04 21:06
Moin framp,

hoffe Du hilfst mir trotzdem weiter den Fehler zu finden!?

Hab mal die Ausgabe von "mount von beiden Systemen verglichen:

Bis auf eine Zeile sind alle anderen Zeilen gleich, teilweise aber in anderer Reihenfolge vorhanden.
Aber es gibt eine Zeiole da gibt es eien Unterschied.

Zitat:
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
in der lauffähigen Version steht "fd=30", in der anderen steht "fd=32"

Eine Idee ob das das Problem sein kann?
#206 framp 2018-01-04 12:11
Moin Zwieback,

dann kann ich jetzt ja wenigstens wieder ruhig schlafen denn das beweist dass raspiBackup nicht die Problemursache ist :-)

Dienste stoppen denke ich wird auch nicht die Ursache sein :sad:

Vielleicht vergleichst Du mal die Ausgabe von Code:mount bei beiden Szenarien. (Ist nur eine Idee).

Cu framp
#205 Zwieback 2018-01-04 10:43
Moin, moin framp,

hier mal eine Wasserstandsmeldung:
Auch das manuell angestoßende dd Image im laufendem Betrieb verhält sich gleich.
Werd heute abend nach der Arbeit mal ein dd Image anstoßen wo alle Dienste gestoppt werden.
Hab auch eine Kollegen gebeten das auf seinem Pi mal nachzustellen.
#204 Zwieback 2018-01-03 21:56
Moin moin framp,

das manuelle backup mitt dd läuft grad. dauert aber bei meiner 16GB SD auf die angeschlossenen Hdd ca. 1,5h.
Danach werd ich ein rsync Backup probieren und dann anschließend berichten.

Danke schon mal für die hilfreiche Unterstützung.
#203 framp 2018-01-03 21:28
Moin Zwieback,

vielen Dank fuer Deinen Test - auch wenn er nicht erfolgreich war :sad:

Ich sehe nun nur folgende Moeglichkeiten um vielleicht die Quelle des Uebels zu finden:

1) Ein reines DD Backup erstellen von der SD Karte und restoren. Damit wird bewiesen bzw ausgeschlossen dass es an raspiBackup liegt (ich habe mir den Code angesehen und da wird nur dd aufgerufen. Aber der Teufel ist ja bekanntlich ein Eichhoernchen :-x )
2) Mal ein tar oder rsync Backup ausprobieren. Darueber kann man sehen ob es am dd liegt.

Cu framp
#202 Zwieback 2018-01-03 19:56
Moin, moin

da bin ich wieder.

Leider hat das mit dem länger als eien Stunde laufen lassen vor dem reboot auch nicht geklappt. Nach dem reboot waren wieder alle Daten verschwunden und als letzter Login war auch wieder der 28.12 eingetragen.
#201 Zwieback 2018-01-02 21:17
Hallo framp,

nee noch nicht, kann ich aber gerne mal machen.
Werd mich dann morgen wieder melden . lass das System mit dem restortem Image dann mal über nacht laufen.
Stoße dann auch mal ein manuelles Image mit dd auf die hdd an.
Zitat:
sudo dd if=/dev/mmcblk0 of=/media/pi/backup/Pi3_dd.img
Bis später dann :-)
#200 framp 2018-01-02 20:57
Dumm. :sad:
Ich bin mir sicher dass der Hase da irgendwo im Pfeffer liegt...
Hast Du Dein restortes Image mal länger als 1 Stunde laufen lassen?
#199 Zwieback 2018-01-02 20:45
Hallo framp
das scheint es auch nicht gewesen zu sein :sad:

Code:pi@raspberrypi3:~ $ date Di 2. Jan 20:43:05 CET 2018 pi@raspberrypi3:~ $ sudo /etc/cron.hourly/fake-hwclock pi@raspberrypi3:~ $ date Di 2. Jan 20:43:22 CET 2018 <br />pi@raspberrypi3:~ $ sudo reboot login as: pi pi@192.168.178.64's password: <br />Linux raspberrypi3 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l <br />The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu Dec 28 18:31:08 2017 <br />pi@raspberrypi3:~ $ date Do 28. Dez 18:31:17 CET 2017 pi@raspberrypi3:~ $ date Do 28. Dez 18:31:21 CET 2017
#198 framp 2018-01-02 20:31
Es liegt an /etc/fake-hwclock.data. Im Backup befindet sich dort die Backupzeit und deshalb startet der Restore auch mit dieser alten Zeit. ntp setzt dann die Zeit aktuell nachdem eine Netzverbindung steht.

Da die Raspi keine RTC hat sichert ein cron Job -> /etc/cron.hourly/fake-hwclock die aktuelle Zeit jede Stunde. Wenn nun der Shutdown frueher vorgenommen wird bleibt die alte Backupzeit auf dem Image :sigh:

@Zwieback: Gib doch mal vor dem Shutdown folgendes ein:
Code:sudo /etc/cron.hourly/fake-hwclock
Dann wird das Image auch nicht mehr mit der alten Zeit starten :-)

raspiBackup setzt automatisch die Zeit auf die aktuelle Zeit beim Restore sofern ein tar oder rsync Backup vorliegt.
#197 madm4x 2018-01-02 20:09
zitiere Zwieback:

pi@raspberrypi3:~ $ last
pi pts/0 192.168.178.95 Tue Jan 2 19:31 still logged in
---------------
pi tty1 Thu Dec 28 18:31 gone - no logout
---------------
reboot system boot 4.9.59-v7+ Thu Jan 1 01:00 still running.


Ich hab zwar kein Plan von dem "Loggin system" oder der damit Verbundenen "User Verwaltung".

Aber auf den ersten Blick sieht es für mich so aus das du Aktuell mit "pi pts/0" eingeloggt bist und es laut System noch ein User "pi tty1" gibt der eingeloggt war von dem aber das logout fehlt.
Wie sich das auf dein Problem auswirkt kann ich nich sagen.... Ihr dürft mich auch gerne hauen wenn das rein gar nichts damit zu tun hat :D

Wie gesagt hab mich mit sowas bisher nie Beschäftigt ... nur fällt mir das auf den ersten Blick auf zumal das bei mir ähnlich aussieht:
Zitat:

root@kodi-stretch-rpi:~# last
root pts/0 192.XXX.XXX.XX Tue Jan 2 14:27 still logged in
pi tty7 :0 Mon Jan 1 09:31 gone - no logout

wtmp begins Mon Jan 1 08:00:11 2018
root bin ich aktuell über ssh und pi loggt sich automatisch ein über Pixel-Desktop.

Vielleicht kann framp da ja mehr zu sagen und/oder ins Detail gehen ;)


VG
#196 Zwieback 2018-01-02 20:04
hallo zusammen,

grad nochmals das system mit sudo reboot durchgestartet und mit putty wieder eingelogt. danach sofort ein date gemacht und siehe da das Datum war als, gleich darauf nochmal "date" und das Datum stimmt!?
Zitat:
pi@raspberrypi3:/home $ sudo reboot
login as: pi pi@192.168.178.64's
password:
Linux raspberrypi3 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
Last login: Thu Dec 28 18:31:09 2017
pi@raspberrypi3:~ $ date Do 28. Dez 18:31:29 CET 2017
pi@raspberrypi3:~ $ date Di 2. Jan 19:58:35 CET 2018
pi@raspberrypi3:~ $ last pi pts/0 192.168.178.95 Thu Dec 28 18:31 gone - no logout pi tty1 Thu Dec 28 18:31 gone - no logout
reboot system boot 4.9.59-v7+ Thu Jan 1 01:00 still running pi pts/0 192.168.178.75 Wed Dec 27 19:58 - 20:06 (00:07)
Das verhalten läast sich mit jedem "sudo reboot" reproduzieren!

Werd jetzt erst mal meine 16GB SD-Karte partitionieren damit ein Backp nicht immer so lange dauert.
#195 Zwieback 2018-01-02 19:45
hallo framp,
hallo madm4x, erst mal vielen Dank für eure Hilfe.

mit last wird mir der aktuelle Login korrekt angezeigt. Allerdings steht der nach einem "sudo reboot" nicht in der Liste und der aktuelle dadrüber.
Aufgefallen ist mir allerdings das mein Aufruf anders aussieht als bei Dir.

Zitat:
pi@raspberrypi3:~ $ ls -la /var/log/syslog -rw-r----- 1 root adm 936583 Jan 2 19:38 /var/log/syslog
Meine Antwort auf "last" sieht nach jedem reboot gleich aus:
Zitat:
pi@raspberrypi3:~ $ last pi pts/0 192.168.178.95 Tue Jan 2 19:31 still logged in pi tty1 Thu Dec 28 18:31 gone - no logout reboot system boot 4.9.59-v7+ Thu Jan 1 01:00 still running
Mein System scheint aber das richtige Datum und Uhrzeit zu haben
Zitat:
pi@raspberrypi3:~ $ date Di 2. Jan 19:43:44 CET 2018
Hab auch schon mit einem erneutem Backup ausprobiert aber da ist es das gleiche Verhalten.
#194 madm4x 2018-01-02 17:49
zitiere Zwieback:
Die Datei hatte nach einem Reboot aber wieder einen Zeitstempel vom 28.12.2017 und nicht wie vor dem Reboot einen Zeitstempel vom 01.01.2017


Nachtrag zu meinem Posting.
Ist mir gerade noch spontan eingefallen ;)

Welche Ausgabe bekommst du denn wenn du direkt nach dem Restore und dem ersten Boot "date" eingibst?
Und welche Ausgabe bekommst nach einem Reboot und der Eingabe von "date"???

VG
#193 madm4x 2018-01-02 17:44
Klink mich ma hier ein...

Mal abgesehen davon das ich mir dieses Verhalten auch nicht erklären kann und ich auch nicht wüsste wie man das "Nachstellen" könnte, stellt sich mir allerdings auch gerade die Frage ob das ein Phänomen durch raspiBackup, von dd oder durch Stretch selbst verursacht wird????

@Zwieback
hast du das ganze mal mittels rsync versucht?
oder auch mal manuell eine Kopie per dd versucht?


VG
#192 framp 2018-01-02 17:08
Moin Zwieback,

das ist sehr merkwuerdig. Die Loginversuche werden in /var/log/wtmp vermerkt.
Code:
ls -la /var/log/syslog
-rw------- 1 root root 13180 Jan 2 16:56 /var/log/syslog

Mit last kannst Du die Liste ansehen: Beispiel
Code:
last
framp pts/1 majestix Tue Jan 2 16:56 still logged in
framp pts/1 majestix Tue Jan 2 16:55 - 16:56 (00:01)
framp pts/1 majestix Tue Jan 2 13:14 - 13:15 (00:00)
framp pts/1 majestix Mon Jan 1 19:30 - 19:59 (00:28)


Kannst Du denn in /var/log/syslog Deine erneuten Logins sehen?

Ich muss gestehen, dass ich mir das Ganze nicht erklären kann - ausser Du schreibst irgendwo anders die neuen Daten hin. Deshalb komme ich auf fstmp. Allerdings sollte sich dann auch Dein Original so verhalten :kopfkratz:

Cu framp
#191 Zwieback 2018-01-02 16:40
Moin, moin,

nee, mir ist das aufgefallen beim ersten Login. Da steht doch immer der letzte Login Versuch drüber und der hatte nach jedem Reboot das gleiche Datum und die gleiche Uhrzeit.
Wenn ich die original SD KArte nehme dann ist das nicht so. Dann steht da immer eine aktuellere Zeit, nähmlich die vom letztem Login.

Aufgefallen war mir das weil ich bei meinem Hausautomationsprogramm IPSymcon immer wieder eine Setting Datei von dem Datum drin hatte an dem auch der letzte Login stattfand.
Der letzte Login war am 28.12.2017 auch wenn ich mich gestern am 01.01.2018 eingelogt habe. Die Setting datei von IPSymon wurde auch alle paare Minuten mit korrektem Zeitstempel abgelegt. Die Datei hatte nach einem Reboot aber wieder einen Zeitstempel vom 28.12.2017 und nicht wie vor dem Reboot einen Zeitstempel vom 01.01.2017

Ob ich ein tmpfs in der /etc/fstab nutze kann ich heute abend mal nachschauen.
#190 framp 2018-01-01 19:41
Moin Zwieback,

vielen Dank. Dir wuensche ich auch ein frohes Neues :-)

Verstehe ich richtig, dass jedesmal, wenn Du Dein Image, welches Du restored hast nach jedem reboot mit dem befehl last prüfst wer logged on war und keinen neuen logon siehst? Das ist merkwürdig und sollte nicht passieren. Die Logins werden in /var/log/wtmp recorded. Wenn sich die datei nicht aendert ist der Effekt zu erklären.
Kann es sein dass Du irgendwo ein tmpfs in Deiner /etc/fstab benutzt?

Du erwaehnst dass Aenderungen nach einem reboot weg waren. Welche Aenderungen waren es denn? Vielleicht laesst sich darueber rausfinden was die Ursache ist.

Cu framp
#189 Zwieback 2018-01-01 19:21
Hallo,

erst einmal ein fröhliches Neues Jahr.

Nun zu meinem Problem:
Ich habe mir ein Backup mittels raspibackup (dd) von meinem lauffähigem PI3 mit Stretch auf eine exteren HDD erstellt.
Das Backup hab ich dann mit Win32DiskImager auf eine andere SD Karte überspielt.
So weit so gut. Der Pi3 bootet dananch auch von der neuen SD Karte und es hat den Anschein das alles i.O. ist.
Aufgefallen ist mir dann aber das das letzte Login Datum nach einem reboot immer das gleiche ist. Eigendlich müsste sich diese dann ja aktuallisieren!!!
Aufgefallen ist mir das weil Änderungen die ich am wiederhergestelltem System vorgenommen habe (Änderungen in meinem Hausautomationsprogramm IPSYMCON) nach einem Reboot verschwunden sind.
Gibt es hierfür eine Erklärung oder einen Hinweis wo ich nach der Ursache für dieses Verhalten suchen kann!?

Mt besten Dank im Vorraus
Zwieback
#188 framp 2017-12-07 20:45
Moin Phil,

freut mich dass Du raspiBackup gut bei Dir einsetzen kannst :-)

Cu framp
#187 Phil 2017-12-07 20:38
Keine Frage sondern nur ein schnelles Lob - funktioniert tadellos. Ich habe folgendes Szenario:

Eine Home Assistant Installation auf einem schon älteren Raspberry Pi, welche ich per rsync auf ein Synology NAS sichere. Es gab anfangs Probleme mit einer stabilen Verbindung zum NAS, wo ich die etwas instabile WLAN Verbindung ursächlich verantwortlich machen konnte (LAN geht leider aufgrund baulicher Bedingungen nicht dauerhaft).

Inzwischen geht das Backup recht zuverlässig (mache per crontab eine tägliche Sicherung meines Raspberry) und auch der Test Restore auf eine andere SD Karte hat ohne Probleme funktioniert.

Dazu habe ich mir eine Ubuntu Linux VM in VMware Fusion installiert, dort vom Mac den SD Card Reader gemountet und dann über den von Dir beschriebenen Weg einen Komplett Restore gefahren. Nach dem Restore SD Card in den Raspberry - Boot - läuft...
#186 madm4x 2017-09-29 21:03
Moin,

hab mich ma kurz hier eingelesen.

1. Interessant wäre es wirklich zu Wissen ob du dein Netzwerk über DHCP laufen lässt oder nicht.

2. Wäre es von Vorteil wenn du mal den Inhalt von /etc/network/interfaces und von /etc/dhcpcd.conf hier posten würdest.

3. Mit welchem System oder Programm verbindest du dich den per SSH? Putty, WinSCP? (Falls das schon genannt wurde, sorry, wie gesagt habe nur kurz überlesen)

Für eine fehlerhafte oder gar keine Verbindung per ssh kann es ja mehrere Gründe geben. Die Hauptgründe die mir spontan einfallen und bei nem Backup/Restore passieren können sind:

-Gleicher Hostname auf mehreren Systemen, sowie gleiche Einträge unter /etc/hosts

-Eventuell IP schon vorhanden aufgrund von DHCP Lease

-Ungültiger ssh_key bzw, Keymanagement da dieser schon auf nem andere RPi genutzt wurde/wird.


Aber aus der Ferne schwer zu beurteilen.



VG
#185 framp 2017-09-29 20:50
Ich sehe folgende Wege wie Du Dein Problem lösen kannst:
1) Versuche ob Systemd-Network funktioniert
2) Benutze eine statische IP (bei einem Server wie z.B. FHEM auch anzuraten) Dann musst DU aber in Deinem DHCP Server diese IP blocken bzw eine IP nehmen, die nicht im DHCP Raum liegt
3) Schildere Dein Problem in einem Forum und hole Dir da Hilfe. Z.B. http://www.forum-raspberrypi.de/
4) Ein Benutzer von raspiBackup hat das Problem auch schon gehabt und eine Lösung gefunden, liest hier mit und postet seine Lösung

Waere nett wenn Du uns auf dem Laufenden halten würdest ob und welche Lösung Du gefunden hast damit zukünftig andere Raspi Benutzer mit demselben Problem gleich direkt auf die Lösung hingewiesen werden können ;-)

Cu framp
#184 framp 2017-09-29 20:48
Moin Hinrich,

freut mich dass Du doch das Backup erfolgreich starten konntest :-) Weniger freut mich dass es offensichtlich nur am Raspi, den Du backuped hast, funktioniert :sad: Das Backup sollte überall funktionieren, denn es kann ja auch mal sein dass nicht die SD Karte sondern der Raspi das Zeitliche segnet :-x

Es ist sehr gut und auch extrem wichtig dass Du der Ursache des Problems nachgegangen bist, denn ich wünsch keinem im Glauben ein gutes Backup zu haben im Ernstfall festzustellen, dass der restorete Backup nicht startet :cry:

Deiner Beschreibung nach bekommt Deine Raspi keine IP Adresse wenn Du den Restore auf einer anderer Raspi startest. Ich vermute Du benutzt DHCP und keine feste IP. Da kann es je nachdem welchen DHCP Server Du hast Probleme geben. Mit dem Wechsel von Wheezy auf Jessie wurde alles auf Systemd umgestellt und ich hatte bei meinen Teste für den Raspi3 Support auch Probleme mit Jessie und DHCP IP Adresse. Nachdem ich alles auf Systemd-Network umgestellt hatte funktionierte ein Start auch auf einer anderen Raspi. Ich habe dazu diese Anleitung genommen.
Bei mir läuft immer noch Wheezy und ich habe da keine Probleme.
#183 Hinrich 2017-09-28 22:44
Hallo framp,

danke für deine Antwort.

Erfreulicherweise habe ich es nun auf einem anderen Raspi hinbekommen. Das ist eigentlich das Live-System aber ich habe mir gedacht, dass man mit dem Sichern auf einen USB Stick eigentlich nichts kaputt machen kann :-)
Gesagt, getan: Die 16GB mit dem tgz Verfahren gesichert und auf eine andere 16GB Karte erfolgreich restored. Alles läuft 1 zu 1, also bestens!!

Mein Sportsgeist wollte aber verstehen, warum es auf der anderen Kiste nicht zu klappen scheint. Also habe ich deinen Rat befolgt und über HDMI einen Monitor angeschlossen. Und siehe da, der Bootvorgang ist erfolgreich, denn der Raspbian Desktop erscheint (ich habe nicht rumklicken können, weil keine Maus angeschlossen). Jetzt frage ich mich natürlich, warum ich über putty / ssh über die bekannte IP (bzw. Hostnamen) keine Konsole aufmachen kann. Auch fhem ist übers GUI nicht zu erreichen.
Die /etc/fstab sieht ziemlich jungfräulich aus.


pi@raspberrypi3:~ $ cat /etc/fstab
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
[\code]

Als nächstes werde ich mir eine weitere 32 GB SD Karte besorgen und weiter testen.

Viele Grüße,
Hinrich
#182 framp 2017-09-27 21:29
Moin Hinrich,

so wie ich es sehe ist alles gut gelaufen. Verkleinern heisst nur, dass die Rootpartition ursprünglich mal knapp 32 GB war und nun beim Restore auf knapp 16GB verkleinert wird. Wenn die 32 GB SD Karte sehr voll ist gibt das ein Problem. Dein kleines Raspbian passt aber auch auf eine 16GB SD Karte ohne Probleme. D.h. Dein Problem liegt nicht an der Verkleinerung.

Am besten wäre es wenn Du einen Bildschirm anschliessen koenntest. Dann wuerdest Du genau sehen warum Dein Raspbian nicht startet.

Ich vermute aber dass Du in Deiner /etc/fstab noch irgendwelche Partitionen ausser /boot und /root angegeben hast und deshalb startet Raspbian nicht.

Mein Restore meiner RaspiNAS kommt z.B. auch nicht hoch wenn ich nicht noch meiner externe USB Platte dran angeschlossen habe. Prüfe das mal. Ansonsten poste mal den Inhalt Deiner /etc/fstab ;-)

Cu framp
#181 Hinrich 2017-09-27 13:17
Code:
--- RBK0050I: Backup wird von /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808 zurückgespielt
--- RBK0051I: Master boot backup wird von /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/raspberrypi3-backup.mbr auf /dev/sda zurückgespielt
--- RBK0052I: Partition(en) werden auf /dev/sda erstellt
!!! RBK0004W: Zweite Partition wird von 28.90 GiB auf 14.77 GiB angepasst
--- RBK0053I: Erste Partition (Bootpartition) wird auf /dev/sda1 zurückgespielt
--- RBK0054I: Zweite Partition (Rootpartition) /dev/sda2 wird formatiert
--- RBK0055I: Zweite Partition (Rootpartition) /dev/sda2 wird zurückgespielt
--- RBK0076I: Restore erfolgreich beendet
#180 Hinrich 2017-09-27 13:16
Code:
pi@raspberrypi3:~ $ sudo /usr/local/bin/raspiBackup.sh -m detailed -d /dev/sda /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/
--- RBK0009I: raspberrypi3: raspiBackup.sh V0.6.2.2 (fc2f04a) um Mi 27. Sep 11:24:42 CEST 2017 gestartet
--- RBK0128I: Logdatei ist /home/pi/raspiBackup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
--- RBK0138I: Bootbackup /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/raspberrypi3-tar-backup-20170927-110808.tar wird benutzt
--- RBK0068I: Bootpartitionsdateien des Backups aus dem Verzeichnis /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808 die mit raspberrypi3-backup beginnen werden benutzt
!!! RBK0006W: Ziel /dev/sda mit 14.83 GiB ist kleiner als die Backupquelle mit 28.96 GiB. Die root Partition wird entsprechend verkleinert. HINWEIS: Der Restore kann fehlschlagen wenn sie zu klein wird
!!! RBK0065W: Gerät /dev/sda wird repartitioniert und die gesamten Daten werden gelöscht
--- RBK0067I: Momentane Partitionen auf /dev/sda:
Number Start End Size Type File system Flags
1 4,19MB 70,3MB 66,1MB primary fat16 lba
2 70,3MB 15932MB 15861MB primary ext4
!!! RBK0066W: Gerät /dev/sda wird überschrieben mit der gesicherten Boot- und Rootpartition
--- RBK0038I: Bist Du sicher? j/N
j
#179 Hinrich 2017-09-27 13:11
Code:
pi@raspberrypi3:~ $ sudo /usr/local/bin/raspiBackup.sh -a : -o : -m detailed /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d
--- RBK0009I: raspberrypi3: raspiBackup.sh V0.6.2.2 (fc2f04a) um Mi 27. Sep 11:08:09 CEST 2017 gestartet
--- RBK0128I: Logdatei ist /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/raspberrypi3-backup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
--- RBK0031I: Prüfe ob neue Version verfügbar ist
--- RBK0159I: Prüfe ob eine Beta Version verfügbar ist
--- RBK0151I: Backuppfad /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d wird benutzt
!!! RBK0157W: Keine Services sind zu stoppen
--- RBK0081I: Backup vom Typ tar wird in /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808 erstellt
--- RBK0036I: Partitionslayout wird gesichert
--- RBK0044I: Backup der Bootpartition wird in /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/raspberrypi3-backup.img erstellt
--- RBK0044I: Backup des Partitionlayouts wird in /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/raspberrypi3-backup.sfdisk erstellt
--- RBK0046I: Backup des Masterbootrecords wird in /media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/raspberrypi3-backup.mbr erstellt
--- RBK0158I: tar Backup "/media/pi/5b8b53b4-112a-4c7f-a616-2899b532174d/raspberrypi3/raspberrypi3-tar-backup-20170927-110808/raspberrypi3-tar-backup-20170927-110808.tar" wird erstellt
--- RBK0085I: Backuperstellung vom Typ tar gestartet. Bitte etwas Geduld
!!! RBK0156W: Keine Services sind zu starten
--- RBK0010I: raspberrypi3: raspiBackup.sh V0.6.2.2 (fc2f04a) um Mi 27. Sep 11:16:03 CEST 2017 beendet
--- RBK0017I: Backup erfolgreich beendet
#178 Hinrich 2017-09-27 12:55
Hallo zusammen,

erst einmal vielen Dank für das tolle Projekt und die viele Arbeit, die du (oder Ihr) reingesteckt habt und es anderen Nutzern zur Verfügung stellt!

Ich hatte mir schon lange vorgenommen, das Script zu installieren, um das Backup aber v.a. den Restore zu testen.
Nun bin ich endlich dazu gekommen.

Leider bislang nicht erfolgreich, d.h. das Ziel, den Raspi anschließend mit einer anderen SD Karte zu booten, habe ich bislang verfehlt.

Ich versuche, kurz zu beschreiben, was ich gemacht habe.

Ausgangslage:
Ein Raspberry Pi mit Raspbian zum Testen, also nichts wichtiges drauf.
SD Karte: SanDisk 32 GB.
Script installiert, alles erfolgreich.
USB Stick angeschlossen und mit ext4 formatiert.
Nun die entsprechenden Services gestoppt.
Dann das Backup mit dem Script (tar) auf den USB Stick gesichert, keine Fehlermeldungen.
Jetzt einen USB SD Kartenadapter mit einer SanDisk 16 GB SD Karte angeschlossen und den Restore hierauf vorgenommen, ebenfalls ohne Probleme / Fehlermeldungen.
Nur der Hinweis: "Die root Partition wird entsprechend verkleinert. HINWEIS: Der Restore kann fehlschlagen wenn sie zu klein wird"

Was bedeutet zu klein!?

Leider habe ich keine zweite SD Karte mit 32 GB.

Anschließend "poweroff" und Netzteil abgezogen.
Die Restore-SD-Karte (16GB) rein und Strom wieder dran. Die grüne LED blinkt bzw. flackert wie sie das meinem Dafürhalten beim normelen Bootvorgang machen muss.
Leider: Über putty bekomme ich keine ssh Verbindung mehr hin. Das ist für mich ein Indiz, das der Restore nicht funktioniert hat.

Warum klappt das trotz "Backup erfolgreich beendet" bzw. "Restore erfolgreich beendet" nicht?
Was mache ich falsch?

Für Hinweise / Ideen wäre ich echt dankbar!!

Kommandos bzw. Outputs im nächsten Beitrag.

Viele Grüße,
Hinrich
#177 Danmann 2017-09-18 07:25
Hi,

alles klar.

Ich werde mich mal evtl irgendwann da nochmals dran setzen. Habe den Pfad jetzt erst einmal ausserhalb von Seafile gelegt.
Vllt lasse ich es dabei. Vllt werde ich es noch mit tar anschlissend zippen versuchen. Sobald ich Zeit wieder habe.

Vielen Dank, auf jeden Fall!

LG,

Dan
#176 framp 2017-09-12 20:14
Moin Dan,

zitiere Danmann:
...Der Seafile-Cli ( Laptop), greift auf die Externe und laed u.a. die raspiBackups hoch.


D.h. Du sicherst die rsync Backups noch per Seafile? Dann wird immer alles gesichert da keine Hardlinks unterstützt werden. Ich vermute auch dass die Sicherung auf dem Seafile nicht OK sein wird, denn Softlinks werden vermutlich aufgelöst werden und dadurch auf verschiedene Kopie verweisen. Dass wird sicherlich kurzfristig gut gehen, aber wenn die verlinkten Dateien bei Updates geändert werden wirst Du Probleme bekommen.
Wenn Du unbeding diesen Weg gehen willst empfehle ich Dir die rsync Backups in ein tar zu packen und dieses zu sichern.

Cu framp
#175 Danmann 2017-09-12 00:02
Moin,

bei mir landen alle Backups auf die Externe - Festplatte, die direkt an den Pi angeschlossen ist.
Die Externe ist dann per Samba eingebunden auf meinem Laptop. Der Seafile-Cli ( Laptop), greift auf die Externe und laed u.a. die raspiBackups hoch.

Zitat:
Code: Failed to stat /home/Linux-Laptop/minibian/externe/backup/pi_client/OS/minibian/raspiBackup/minibian/minibian-rsync-backup-20170907-174306/usr/bin/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/vcgencmd: No such file or directory. Beim Backup oder Restore? Wenn es beim Backup ist ist irgendwas bei Deinem System krude :o
Die Fehlermeldung, habe ich bei den Logs vom Seafile-Cli ( Laptop), wenn ich die raspiBackups auf den Seaf-Server hochlade.
Das raspiBackup hat ja dann die rechte
drwxr-xr-x root:root
vllt liegt es daran? Obwohl, read ja vorhanden ist. Heisst read auch gleich kopieren der Daten moeglich? Muss ja eigentlich. Da das meiste ja Hochgeladen wird.

Zitat:
Zitat: Man kann ja den kompletten Backup nicht zippen, wegen diesen Hyperlinks. Vllt ist ein tar backup oder dd vllt eher ratsam? Ja, aber da sicherst Du immer alles. Was theoretisch funktionieren sollte ist das gesicherte rsync Backup zu taren und zippen und dann asynchron hochzuladen. Allerdings solltest Du das dann sehr gut testen.
Moechte auch eigentlich bei den rsync Backups bleiben. Sie laufen schnell durch und wenn mal eine kleinere SD da ist, dann muss ich den anderen Krempel nicht machen.

Werde mal gucken, ob ich die nachdem Backup nochmals zippe oder mir einen Seaf-Cli auf den Server packe. Dann ist es mir egal, wie lange das Dauert, wenn er den Pi dann nicht gerade in die Knie zwingen sollte, wegen den vielen Dateien.
Mal schauen.

LG,

Dan
#174 framp 2017-09-09 11:52
zitiere Danmann:
Moin,

Moine
Zitat:
Ich wuerde gerne meine rsync backups in die Cloud pummpen. Das funktioniert auch aber wie ich schon irgendwo hier erwaehnt habe, dauert das relativ lang.
Bei mir landen alle Backups auf einer lokalen Platte. Es ist sicherlich bei mir auch eine Ueberlegung wert sie dann asynchron - da es ja relative lange dauert - irgendwohin hochzuladen.

Jetzt sind mir bei den Seafile - Clienten ( LinuxDesktop) bei den Logs folgende Sachen aufgefallen. Z.B. Code:Failed to stat /home/Linux-Laptop/minibian/externe/backup/pi_client/OS/minibian/raspiBackup/minibian/minibian-rsync-backup-20170907-174306/usr/bin/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/vcgencmd: No such file or directory.
Beim Backup oder Restore? Wenn es beim Backup ist ist irgendwas bei Deinem System krude :o
Zitat:
Stellt sich die frage, ob der Restore noch klappt oder nicht, wenn ich ihn nicht direkt von der Externen machen sollte. Sprich den Backup vom Cloud z.B auf ne USB Stick packe.
Kommt drauf an wie und wohin Du Deine Backups hochlaedst.
Zitat:
Man kann ja den kompletten Backup nicht zippen, wegen diesen Hyperlinks. Vllt ist ein tar backup oder dd vllt eher ratsam?
Ja, aber da sicherst Du immer alles. Was theoretisch funktionieren sollte ist das gesicherte rsync Backup zu taren und zippen und dann asynchron hochzuladen. Allerdings solltest Du das dann sehr gut testen.
Zitat:
Wie machst du das eigentlich? Oder packst du deine Backups nicht in deine Cloud?
s.o.

Cu framp
#173 Danmann 2017-09-09 11:33
Moin again,

Wenn moeglich, pack dieses unter den Kommentar, den du noch nicht freigeschaltet hast. Von heute morgen, denke ich ... ne gestern Abend, muesste es sein!?

Habe mal ein Vergleich gemacht, was die Datei menge eines rsync Backup betrifft und ein library von Seafile, was ca 397GB betrifft, bei mir.

Ich habe eine library, bei meinem Seafile Server, wo all meine Fotos, Programme, Documents usw usf hochgeladen werden. Um genau zu sein, sind es genau 71300 files bei 360.7GB. Fast identische menge an files sind es bei einem 1.7 GB grosem rsync Backup. Sprich

78.282 Dateien, bei einer groesse von 1.7GB.

Das ist natuerlich ne menge Arbeit, fuer den Server/ Pi.
Denke, ich werde auf tar oder dd umswitchen. Sollte jetzt nur als Info fuer die Leute dienen, die evtl Seafile, Nextcloud oder aehnliches benutzen um deren Backup ueber die Cloud nochmals zu sichern.

Vllt gibt's ja in der richtung noch ein paar Hinweise.

Danke und einen schoenen Tag,

Dan
#172 Danmann 2017-09-09 04:43
Moin,

muss mal wieder stoeren :/

Ich weiss, das du Seafile benutzt bzw benutzt hast.

Ich wuerde gerne meine rsync backups in die Cloud pummpen. Das funktioniert auch aber wie ich schon irgendwo hier erwaehnt habe, dauert das relativ lang.

Jetzt sind mir bei den Seafile - Clienten ( LinuxDesktop) bei den Logs folgende Sachen aufgefallen. Z.B.
[09/09/17 14:33:10] repo-mgr.c(1432): Failed to stat /home/Linux-Laptop/minibian/externe/backup/pi_client/OS/minibian/raspiBackup/minibian/minibian-rsync-backup-20170907-174306/usr/bin/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/vcgencmd: No such file or directory.
Stellt sich die frage, ob der Restore noch klappt oder nicht, wenn ich ihn nicht direkt von der Externen machen sollte. Sprich den Backup vom Cloud z.B auf ne USB Stick packe.

Man kann ja den kompletten Backup nicht zippen, wegen diesen Hyperlinks ( muss mal gucken, was das ist).
Vllt ist ein tar backup oder dd vllt eher ratsam?

Wie machst du das eigentlich? Oder packst du deine Backups nicht in deine Cloud?

Danke dir schon mal,

Dan
#171 Danmann 2017-09-07 23:51
Hi,

ne, da bin ich mir Sicher, das du nichts geloescht hast :D Kein Problem. Computer halt. Klappt nie wie man es sich vorstellt ;)

Was mir aufgefallen ist, wenn ich mich per Handy ( SSH) eingeloggt habe, blieb er bei Key - Authentication stehen. Da scheint er ewig zu ueberlegen, was er denn jetzt machen soll.

Habe gestern auch gleich den restore durchgefuehrt ( ohne probleme) und die SD Karte fuer das Update von Jessie auf Stretch ausprobiert. VPN lief nicht mehr. Aber das ist eine andere Story..... Ist schon toll so ein Backup ;)

Danke dafuer!
#170 framp 2017-09-07 20:50
Moin Dan,

bewusst habe ich nichts gelöscht. Sorry :oops:

Dass offensichtlich das Stoppen des dbus das Problem verursacht ist merkwürdig. Auch weil der dbus soweit ich weiss primaer von UI Komponenten (kde, gnom) benutzt wird. Aber offensichtlich ist da auch irgendeine Systemkomponente betroffen. Ich wuerde jedenfalls den dbus nicht beenden. Er ist offensichtlich zu wichtig fuer Systemkomponenten.

Cu framp
#169 Danmann 2017-09-07 02:15
Ne, da muss irgendwas schief gegangen sein.

Der Link wurde einfach Kopiert. Habe da keine / extra mit eingefuegt ;)

Hatte zwei Kommentare geschickt. ( Der 2te ist auch da "2017-09-04 00:10")
Und beide waren natuerlich befuellt mit woertern ;D Besonders der erste, war voll davon ;) Der hatte unter anderem beschrieben, das nicht alle services wieder gestartet haben, nach cron. Zumindest, waren ein paar services nicht mehr in der Auflistung. Nach einem 2ten Durchlauf war es allerdings so wie es sein sollte. Also war das auch nicht das Problem.
Habe nur eine config. Wie schon erwaehnt, starte ich cron mit
* 05 * * 1 /usr/local/bin/raspiBackup.sh
Sonst keine weiteren Aufrufparameter. Denke das raspiBackup seinen job macht. Daran wird es nicht liegen.
Ich bleibe dabei, bei einem manuellen Aufruf und somit den vorhandene SSH-Verbindung, habe ich keine Probleme. Durch Cron besteht keine SSH-Verbindung. Da muss irgendwo der Knackpunkt sein, wenn services gestartet bzw gestoppt werden.

Mache gleich mal einen Test mit SSH-Verbindung und Cron.
------------------------------

Habe die Tests jetzt doch mal durchgefuehrt, bevor ich den Kommentar hier los geschickt habe.

Das liegt an dbus. Den service nicht mit rein nehmen und gut ist.
Verstehe nur nicht, warum es manuell keine Probleme gibt :o
Irgendwelche einwaende dies auf jeden Fall mit in die raspiBackup config mit rein zu nehmen?

LG,

Dan
#168 framp 2017-09-06 00:19
Moin Dan,

ich habe Deinen 'leeren' Kommentar gelöscht und Deinen Link Kommentar korrigiert - aber sonst sollte nichts von Dir verloren gegangen sein :-?

Sehr merkwürdig ist dass es beim manuellen Aufruf des Backups der Restore OK ist und beim cron Aufruf nicht :sigh:

Das sollte wirklich keinen Unterschied machen. Beide Male rufst Du ja raspiBackup als root auf. Oder hast Du da noch irgendwelche Konfigfiles in ~ oder . rumstehen so dass /usr/local/etc/raspiBackup.conf überschrieben wird oder benutzt Du andere Aufrufparameter für raspiBackup im cron als beim manuellen Aufruf? Mit der Option -m detailed schreibt Dir raspiBackup genau welche Konfigdateien benutzt werden.

Cu framp
#167 Danmann 2017-09-06 00:02
Hi,

Irgendwie ist hier was verloren gegangen. Hatte eigentlich 2 Nachrichten raus gehauen.... Egal ;D

Ja genau, funktioniert aber dauert ewig.
Es ist auch nur, wenn es per cron ausgefuehrt wird. Wenn ich es manuell mache, habe ich keine Probleme. Kann sein, das die SSH - Verbindung ja eh schon steht, das der das "Kapiert". Also auch, wenn ich eine neue Verbindung danach mache.

Ich benutze minibian und rsync.
Mit dhcp etc. kein plan. Nutze Static IP sowohl in minibian als auch vom Router. ( Router gibt fuer fast alle Geraete ne Static IP)
Was vllt sein kann, das PiHole da ein wenig rum muckt. Da alle Devices durch die pihole geschleust werden. Und der Router halt alle Geraete zum PiHole schickt bzw die DNS/ IP vom Pi benutzt.
Aber, wie schon erwaehnt, habe ich dieses Problem nicht, wenn ich das Backup manuell durchfuehre.

Muss anscheinend mal ein wenig ausprobieren und zB PiHole aus den stop/ start rausnehmen. Ist vllt eh besser. Da gibt's zu dem Zeitpunkt auch kein "Ausfall" was Internet betrifft. Oder aber per cron einen reboot durchfuehren lassen, nach dem Backup.
Keine Ahnung. Werde mal ein wenig testen.

LG,

Dan
#166 framp 2017-09-04 19:16
Vielen Dank fuer dne Link. Ich habe ihn eben korrigiert. Die url Syntax war nicht ganz korrekt :-)

Ist schon merkwuerdig mit dem ssh Login. Funktioniert es und dauert nur lange? Ich habe die Erfahrung gemacht, dass dass man bei Jessie am besten den Systemd.Networkd - speziell wenn man dhcp benutzt. - benutzt um die Netzwerkdinge zu konfigurieren und den alten dhcpd loescht. Der macht immer wieder Probleme.

Welches OS hast Du denn? Welchen Backuptyp machst Du?

Cu framp
#165 Uli2000 2017-09-04 19:15
Um einen Restore durchzuführen, stecke ich das Backup vom USB Stick (ext4) in mein Notebook wo ein virtuelles Ubuntu läuft (Parallels Software auf Mac OS). Jede andere virtuelle Linux Distribution auf anderer OS Plattform sollte auch gehen. Dann das Image auf Dropbox hochladen und mit originalem OS wieder downloaden und unter Windows mit windiskimager oder unter MacOS mit Apple Pi Baker wieder auf die SD-Karte schreiben. So kann man Schwierigkeiten umgehen, weil man ext4 nicht überall lesen oder schreiben kann.
#164 Danmann 2017-09-04 08:44
Jau, keine Ahnung, warum der das so ausspuckt.

Wie du schon geschrieben hattest.
https://softwarebakery.com//shrinking-images-on-linux

Weiter unten hatte ich eigentlich auch mehr geschrieben als nur nix ;D
#163 Danmann 2017-09-04 00:10
Habe es jetzt nochmal per cron getestet. Dieses mal sind alle Sachen wieder gestartet. Der SHH Login dauert trotzdem ewig. Toll, jetzt habe ich noch nicht einmal einen Hinweis, was es sein koennte :D

So jetzt aber weg hier.

Tuess

Dan
#162 MadM4x 2017-09-03 23:24
Der Link ist nich dead... Der Link hat nen / zuviel :P

https://softwarebakery.com/shrinking-images-on-linux
#161 framp 2017-09-03 23:00
Vielen Dank für eine weitere Lösungsmöglichkeit des blöden Problems.
Ps... Der Link ist leider dead :cry:
#160 Danmann 2017-09-03 22:54
Dazu habe ich hier eine schoene Anleitung zu.

Habe ich des oefteren schon ohne Probleme so gemacht ;)

PS: Da sind ja die Zitat etc buttons! Nice ;)

EDIT framp: Link korrigiert
#159 MadM4x 2017-09-03 20:21
Das Problem kenne ich nur zu gut ..
Und meistens merkt man es wenns zu Spät ist :(

Daher folgender Tipp von mir (so habe ich es mir angewöhnt)

Nach dem Installieren oder Schreiben eines frischen Systemimage direkt hingehen und gparted auf dem RPi installieren. Es sei denn du hast einen PC mit Linux zuhause, dann kannst du natürlich diesen nehmen ;)

Nach dem Installieren von gparted die Karte bzw. die zweite Partition um ca. 0.5GB bis 0.9GB verkleinern.

Also z.b:
8GB Karte auf 7.2-7.5GB
16GB Karte auf 15.2-15.5GB usw.

Is nicht die schönste Lösung aber in der Regel passen meine DD Images seitdem immer.


CU
#158 framp 2017-09-03 19:38
Moin Lars,

das hat damit zu tun dass eine 16GB SD Karte nicht exakt 16GB hat sondern immer geringe Abweichungen nach unten.

Beispielausgabe bei zwei meiner SD Karten:
Code:sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes

Code:sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 15.5 GB, 15548284928 bytes


D.h. Deine ZielSDKarte ist leider etwas zu klein und Du musst Dir eine größere besorgen. Alternativ kannst Du weniger per dd sichern. Wie das geht steht hier

Cu framp
#157 Lars 2017-09-03 19:13
Hallo Zusammen,
ich hab das Problem, das ich ein mit raspiBackup (dd) erstelltes Backup nicht mit win32Image wieder auf die SD Karte schreiben kann. Da bekomme ich von Win32Image die Meldung, das ich zu wenig speicher habe. Ich habe mit der Option Normaler Modus gesichert. auf der SD sind 2 Partitionen. Laut meinem Verständnis müßte er doch beide Partitionen gesichert haben und diese mit Win32Image auch wieder zurück schreiben. was mache ich falsch? Im Logh ist auch keine Fehlermeldung zu finden.

Mfg
Lars
#156 framp 2017-09-03 14:38
zitiere Danmann:
Wie kann man denn hier zitieren?:)
Deine Nachfrage hat mich dazu gebracht mal nach der Ursache des Verschwindens der Icons zu suchen - und ich habe sie auch wieder herzaubern koennen :-)
#155 framp 2017-09-03 13:23
Moin Dan,

Zitat:
Wie kann man denn hier zitieren?:)
Nachdem ich auf das neue reCaptcha umgestellt habe um die laestigen Spamkommentare loszuwerden sieht man nur noch die Smileys :sad: Vorher konnte man auch URL Links, Quotes usw per Click auswaehlen. Jetzt muss man explizit die Tags in der Antwort eingeben. Siehe dazu hier In der Liste fehlt quote als Tag was hier aber funktioniert.

Zitat:
Kann es sein, das bei
https://www.linux-tips-and-tricks.de/de/faq#a22
das 1 nicht richtig stimmt?
Jupp. Das ist ein Typo und habe ich eben korrigiert.

Zitat:
Kann man eigentlich das rsync backup anschliessend irgendwie zippen, also automatisch?
Nein. Bei rsync werden Hardlinks benutzt um die Grösse des Backup zu reduzieren. Das funktioniert aber nur bei nicht geänderten Dateien. Je nachdem wie gross Deine Aenderungen im Seafile sind kann das mehr oder weniger erfolgreich sein. Wenn Du Daten kompressen willst musst Du tar oder dd benutzen. Z.B. koenntest Du die Seafiledaten per tar in einem zweiten Schritt sichern. Dazu musst Du dann aber entsprechende Excludes beim rsync bzw tar Backup erstellen um den jeweiligen anderen Teil aus dem Backup herauszufiltern. Da musst Du aufpassen, da die Syntax beim tar anders ist als beim rsync :sad:

Cu framp
#154 Danmann 2017-09-03 13:02
Moin bei euch und ich sag schon mal gute Nacht.

Wie kann man denn hier zitieren?:)

Cool. Dann reicht ja
00 22 * * 0 /usr/local/bin/raspiBackup.sh
vollkommen aus.
Dann klopp ich mal all meine restlichen services noch da mit rein, dann sollte ja eigentlich alles gut sein.
Die Liste kannte ich natuerlich schon ;)

Vllt kann man ja noch in das Script einen Hinweis nach zB 20 Backups machen?! Das man mal wieder den restore checken sollte. Kann man sich natuerlich auch selber in Kalender eintragen aber warum nicht ;)

Meine SD Karte funktioniert noch einwandfrei. Muss an irgendwas anderes gelegen haben. Dachte, das es an der crontab liegen koennte. War das einzige restore/ backup, was per crontab durch ging was ich benutzt hatte. Werde mir mal eins fuer heute Nacht einstellen. Werde die dann nochmal checken. Ansonsten, keine Ahnung woran es lag. Ausser evtl. irgendwas am PC. Die config Einstellung war auf jeden Fall die gleich wie vorhin.

Kann es sein, das bei
https://www.linux-tips-and-tricks.de/de/faq#a22
das 1 nicht richtig stimmt? Oder ich kapiere das nicht richtig. Bei mir ist die config unter
/usr/local/etc/raspiBackup.conf
zu finden.

Kann man eigentlich das rsync backup anschliessend irgendwie zippen, also automatisch? Mir scheint der Upload von Seafile Ewigkeiten zu dauern, wegen den ganzen files. Sind ja eigentlich, zumindest bei mir, nur 1.7GB.
Habe da jetzt nur was fuer tar und dd gefunden.

Vielen Dank,

Dan
#153 MadM4x 2017-09-03 12:34
Hab zwar nur kurz Überflogen ;)

aber Bezüglich "crontab" wäre es Interessant zu Wissen was bzw wie du es genau Eingetragen hast. Also ob mit "nano /etc/crontab" oder mit "crontab -e" UND ob du darauf geachtet hast, das crontab mit ner Leerzeile wie # Anfängt und auch Ende.

Desweiteren wäre es vielleicht auch gut zu Wissen welches System auf deinem RPi läuft. (Wie gesagt hab hier nicht alles nachgelesen) denn bei manchen System muss im Cronjob der Befehl mit dem User root aufgerufen werden.

Also:
00 22 * * 0 root /usr/local/bin/raspiBackup.sh

Generell gilt aber wie framp schon erwähnte, wenn raspiBackup.sh über cron gestartet wird, wird auch die .conf genutzt wenn du nichts weiter mit angibst.

Habe bei mir auch alle nötigen/möglichen Angabe die "Default" sind wie zb die Service/Dienste in die raspiBackup.conf eingetragen. Daher reicht ein Aufruf von raspiBackup.sh in der Regel aus.

Vielleicht schaust du auch mal mit "systemctl | grep running" welche Dienste laufen bzw gestoppt werden müssten. Relevant sind aber so wie ich das Sehe wirklich nur die, die während nem Backup auf das System zugreifen und Dateien ändern könnten.
Allerdings bin ich noch ein N00b und beschäftig mich erst seit kurzem damit.


CU
#152 framp 2017-09-03 10:40
Moin Dan,

Zitat:
Restored SD rein und auch da keine erkennbaren Fehler oder sonstiges. Seafile etc alles lief einwandfrei.
So soll es auch sein :-)

Zitat:
Wenn ich jetzt zB bei crontab folgendes eintrage:
00 22 * * 0 /usr/local/bin/raspiBackup.sh
und sonst nix weiter. Greift es dann trotzdem auf meine raspibackup.conf? Oder sollte ich folgendes eintragen?!
00 22 * * 0 /usr/local/bin/raspiBackup.sh -a -o
Hier: https://www.linux-tips-and-tricks.de/de/faq#a22 habe ich beschrieben wie es mit den Konfigs funktioniert. Wenn Du dort DEFAULT_STARTSERVICES und DEFAULT_STOPSERVICES gesetzt hast brauchst Du in der crontab nichts mehr mit -a und -o definieren. Das ist nur notwendige wenn Du die Einstellungen der Konfig ueberschreiben willst.
Zitat:
Da koennte zuvor mein Problem gewesen sein. Das die crontab Variante nicht auf die config zugriff?
Nein
Zitat:
Oder aber das der restore ueber PC nicht vernuenftig durchlief.
Schwer zu sagen ohne ein Log von raspiBackup. Kann auch sein dass die SD Karte einen weg bekommen hat beim Restore, denn ein Restore belastet natuerlich die SD Karte schon :sad:
Zitat:
Sollte ich sowas wie file2ban, ddclient etc mit rein nehmen?
Hier: https://www.linux-tips-and-tricks.de/de/faq#a18 habe ich mal zusammengestellt wo ich denke das es Sinn macht die Services zu stoppen. fail2ban und ddclient brauchen meiner Meinung nach nicht gestoppt zu werden. Allerdings kann es auch nicht schaden ;-)

Cu framp
#151 Danmann 2017-09-03 06:10
Hi,

ich habe mir mal ne SD Karte und nen SD Reader besorgt.
Habe auch nochmals ein Backup gemacht und mit dem gleich ein restore durchgefuehrt.

Die SD Karte sind von 2 verschiedenen Hersteller. Einmal eine Sandisk und eine Toshiba. Die Toshiba ist auch kleiner, obwohl halt beide 8GB gross sind. Die root Partition wurde erfolgreich verkleinert. Alles lief ohne Probleme durch.
Restored SD rein und auch da keine erkennbaren Fehler oder sonstiges. Seafile etc alles lief einwandfrei.

Wenn ich jetzt zB bei crontab folgendes eintrage:
00 22 * * 0 /usr/local/bin/raspiBackup.sh
und sonst nix weiter. Greift es dann trotzdem auf meine raspibackup.conf? Oder sollte ich folgendes eintragen?!
00 22 * * 0 /usr/local/bin/raspiBackup.sh -a -o

Da koennte zuvor mein Problem gewesen sein. Das die crontab Variante nicht auf die config zugriff? Oder aber das der restore ueber PC nicht vernuenftig durchlief.

Dann waere eigentlich noch gut zu Wissen, was alles fuer services am besten gestoppt werden sollten. Habe mein server/ services die ich so installiert habe mit rein genommen. Jedoch ist mir nicht ganz bewusst, was eigentlich sonst noch alles so laeuft. Habe mal mit..
service --status-all
mir meine laufenden Sachen angeguckt.
Sollte ich sowas wie file2ban, ddclient etc mit rein nehmen?

Denke, das wars erst einmal.

LG,

Dan
#150 framp 2017-08-29 21:03
Nein, da hat sich nichts mehr geaendert. Wenn Du vielleicht den restore noch mal mit der Option -l 1 -L current laufen lassen und mir das Log zuschicken koenntest? Dann kann ich nachsehen was die Ursache fuer dieses Verhalten ist und das Problem fixen :-)
#149 Danmann 2017-08-29 20:44
Hi,

Hatte mir vorher schon ein paar Sachen zerschossen. Alles gut. So würde ich den test nicht durchführen ohne ein anderes Backup zu haben oder halt ne andere SD card.

Nehme an, du brauchst die log des restores?
Die Versionen sollten neu sein. RaspiBackup.sh wurde am pi am 27 drauf gepackt und beim Linux gestern. Wenn du in den letzten 8 Std bzw 4 Tagen kein neues Update raus gehauen haben solltest, sollten beide noch 2 date sein.

LG,

Dan
#148 framp 2017-08-29 19:38
Moin Danmann,

den Backup sollte man immer auf einer zweiten Karte testen :cry: Um die Ursache zu finden brauche ich das Log. Wenn Du es hast schicke es mir bitte zu (eMail auf der Kontaktseite). Ansonsten sollte der Restore auch auf einem Linuxsystem funktionieren. Es gab da aber vor nicht alzzu langer Zeit einen Fix dazu. Benutzt Du die aktuelle Version von waspiBackup?

Cu framp
#147 Danmann 2017-08-29 10:33
Hi,

du hattest recht! War eine gute Idee das Backup mal auszuprobieren! Hat naemlich gar nicht geklappt. :D

Habe mir dein scripinstall auf meinen Linux Mint installiert. Um dann das Backup zurueck zu Spielen. Folgende aussagen waren beim restore..

mount: special device /dev/mmcblk01 does not exist
cat: /tmp/boot/cmdline.txt: No such file or directory
cat: /tmp/boot/cmdline.txt: No such file or directory
umount: /tmp/boot: not mounted
--- RBK0076I: Restore erfolgreich beendet

Wenn ich jetzt die SD Card nutze bekomme ich sehr viele Fehlermeldungen angezeigt beim starten. Hauptsaechlich,...

Failed to start System Logging Service.
Das wird wahrscheinlich Nginx etc pp sein. Habe die natuerlich alle mit rein genommen. Wobei ich die nicht in der crontab habe. Weil ich dachte/ denke, das es in der config reichen sollte.
Habe gleucklicherweise einen Tag vorher ein Backup gemacht. Ein paar sachen muessen zwar wieder hier und da nach installiert werden aber kein Problem ;) .....
Glaube ich :D

Vllt haste ja eine Idee. Werde mir mal noch ne SD Karte holen, damit ich mal rum probieren kann.

Danke ;)
#146 framp 2017-08-21 20:40
@Mario,

sieh Dir mal die FAQ 16 an. Damit kannst Du das leidige Problem dass eine SD Karte etwas zu klein ist beim Restore vermeiden ;-)

Cu framp
#145 framp 2017-08-21 20:19
Hm ... benutze mal die Option -v beim restore.
#144 MadM4x 2017-08-21 20:17
@Mario,

bei dd sollte das gehen.
Öffne einfach ein zusätzliches Fenster und verbinde dich erneut per SSH.

Dann gibts du folgendes ein:
pkill -USR1 -x dd

Nach drücken/bestätigen mit Enter sollte in dem Fenster wo das Restore läuft angezeigt werden wieweit dd ist mit welcher Schreibgeschwindigkeit.

Wenn du beide Fenster offen lässt kannst du pkill Befehl so oft wiederholen wie du möchtest.

@framp

Gab/Gibts für rsync nicht die Möglichkeit das per -progress oder so ähnlich anzeigen zu lassen? Hatte mal irgendwas davon gelesen das man für rsync ne "Fortschritt-Anzeige" anzeigen lassen kann. Ob das aber korrekt war und aktuell auch noch geht habe nicht verfolgt. Müsste dann ja eh im Script geändert werden.

CU
#143 Mario 2017-08-21 20:14
Danke für die Rückmeldung.

Ich habe mal wieder das Problem, dass die neue SD-Karte etwas winziger als die alte ist, also funktioniert mein dd-Backup nicht.

Das rsync-Restore mit Repartionierung scheint nicht viel gemacht zu haben, ich habe zwei Stunden rödeln lassen, ps -efa hat allerdings keinen rsync-Prozess gezeigt.
#142 framp 2017-08-21 19:49
Moin Mario,

Ich muss Mal sehen ob ich da was einbauen kann. Bis dahin kannst Du die Option -v benutzen bei tar und rsync. Damit schreiben die Tools welche Dateien bearbeitet werden. Beim dd gibt es aber nichts :cry:

Du kannst aber auch in einem weiteren Fenster das Tool top benutzen um nachzusehen ob dd, tar oder rsync noch was tun.

Cu framp
#141 Mario 2017-08-21 17:44
Hi,

gibt es irgendeine Möglichkeit sich den Progress beim Restore anzuzeigen?

Nach 2h Stunden habe ich abgebrochen und weiß nicht mal, ob er was getan hat ;-)
#140 MadM4x 2017-08-04 21:25
Mittlerweile ...

Es gab irgendein Problem mit der SD Karte bzw. den Partition oder so, wo das Backup drauf sollte.
Hab nun leider die Log dazu nicht mehr :(

Auf jeden Fall musste ich der SD manuell erstmal ne Partition einrichten. Danach lief es dann ohne Probleme.
Keine Ahnung ob es beim Restore Probleme bezüglich der Partition oder der Partitionstabelle gab.

Falls mir der genaue Fehler nochmal in den Sinn kommt, schreibe ich dir kurz ne Email.
#139 framp 2017-08-04 19:21
Moin MadM4x,

das ist unschoen :cry: Leider kann ich ohne ein Debuglog nicht die Ursache finden :sad: Rufe bitte raspiBackup mit den zusaetzlichen Optionen -l debug -m detailed auf und schicke mir das Debuglog per eMail zu. Meine eMail findest Du auf der Kontaktseite ;-)

Cu framp
#138 framp 2017-08-04 19:09
Moin MadM4x,

am 15. Jan 2017, 16:09:02 Uhr habe ich diesen Test eingebaut der nur bei tar und rsync Sinn macht aber beim dd Backup wie Du schon schreibst unsinnig ist :oops: Am 8.4. wurde dieser Fehler mit der Version 0.6.2 published. Es scheint seitdem keiner mehr ein dd Backup restored zu haben oder noch aeltere Versionen zu benutzen. dd Backups werden auch seltener erstellt. Primaer von Windows Benutzern und die restoren mit win32diskimager.

Ich habe das eben gefixed und published.

Vielen Dank fuer den Hinweis auf den Bug.

Cu framp
#137 MadM4x 2017-08-04 18:11
Nachtrag:

Ein Restore vom rsync Backup klappt leider auch nicht, da bei/nach:

!!! RBK0018W: Ziel /dev/sdc mit 7.21 GiB ist größer als die Backupquelle mit 6.87 GiB. Die root Partition wird entsprechend vergrößert um den ganzen Platz zu benutzen
!!! RBK0065W: Gerät /dev/sdc wird repartitioniert und die gesamten Daten werden gelöscht

Nichts mehr passiert.
Ich habe sogar mal Testweise die SD-Karte aus dem USB Cardreader entfernt nur um zu sehen ob ich irgendeine Reaktion oder Fehlermeldung erhalte :D aber nichts passiert.

Ergänzend vielleicht noch hinzuzufügen.
Ausgeführt auf einem RPi3 mit aktuellem Raspbian Jessie und einem Transcend R9 CardReader.

Raspbian selbst Bootet von SD und das Root liegt auf nem USB Stick.
#136 MadM4x 2017-08-04 16:17
Ich habe mal ne Frage bezüglich verschiedener Backup Methoden.

In der Regel erstelle ich wenn mein RPi eine fertige Grundkonfig hat ein Image per dd die weiteren danach dann per rsync.

Daher habe ich nach dem dd Backup die raspiBackup.conf dementsprechend auch geändert.

Nun wollte ich gerade mein dd Backup für einen anderen RPi zurückspielen, erhalte aber nun die Meldung:

#raspiBackup.sh -d /dev/sdc

#ls: Zugriff auf /........./,,-200533.img/*.sfdisk nicht gefunden.
RBK0077E: Restore fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen. RC: 108

Is mir zwar klar das er die *.sfdisk nicht findet, ist ja auch nen dd Backup :D nur wie kann ich nun das Image zurückspielen?
Habs schon Versucht in der .conf wieder bei defaultbackup auf dd zu stellen aber dann erhalte ich die selbe Meldung.
#135 framp 2017-07-23 19:21
STB hat den Fix getestet und nun kann raspiBackup wieder auf einem Linux System benutzt werden um Sicherungen auf SD Karten zurückzuspielen :-)
#134 framp 2017-07-13 20:54
Moin STB,

Du hast einen kleinen Bug gefunden :oops: . Ich habe Dir eine Version mit einem Fix zugeschickt. Bitte verifizieren :-)

Cu framp
#133 STB 2017-07-13 12:38
Hi,

ich probiere gerade von meinem Linux-System das Restore des raspis durchzuführen.

Die SD-Card ist /dev/sdd, aber

raspiBackup.sh -l debug -d /dev/sdd /backup/pi/raspi1/raspi1-rsync-backup-20170711-083447/

liefert nur

??? RBK0155E: No bootdevice found

Muss ich jetzt vorher die SDCard partitionieren, die .sfdisk-Datei anpassen?

Gruß
Stephan
#132 framp 2017-07-01 19:34
Moin Gerald,

Zitat:
...Hätte vielleicht dazu sagen sollen: Ist eine NOOBS-Installation...
Eine NOOBS Installation hat sehr viele Eigenheiten so dass Standard Linux Tools versagen. Vermutlich wird es daran liegen.
Wichtig ist dass Du an Deine Daten rangekommen bist :-)

Vielen Dank auch für die detailierte Beschreibung wie Du es hinbekommen hast. Es gibt zwar eine beschränkte Anzahl von NOOBS Benutzern - aber ich kann mir vorstellen, dass durchaus noch weitere Benutzer dasselbe Problem bekommen und nach einer Lösung suchen.

Cu framp
#131 Gerald 2017-07-01 19:04
Hallo framp,

Supertipp mit kpartx - wieder was gelernt!
In meinem Fall aber leider selbige Fehlermeldung ("wrong fs type, bad option, bad superblock on /dev/mapper/loop0p2, missing codepage or helper program, or other error").
Hätte vielleicht dazu sagen sollen: Ist eine NOOBS-Installation (okay, war mein erster Raspberry, habe ich danach nicht mehr verwendet ...) - vermute, es hat mit dem NOOBS-Partition-Layout zu tun, wo in der zweiten "extended" Partition das eigentlich System eingepackt ist.

Habe übrigens mein Restoreproblem für den Moment gelöst: Ich habe mittlerweile die Hauptpartition unter Windows mounten können (mit OSFMount und Ext2Fsd), da ich durch Herumprobieren den nötigen Trick gefunden habe: Zunächst die Partition1 vom Image-File mit OSFMount gemountet -> File System n/a. Dann diese Partition mit "Save to image file" in ein anderes Imagefile geschrieben. Dieses File erneut gemountet - hatte wieder zwei Partitions, und nun die zweite gemountet - voila!

Danke und lG, Gerald

Mein Partition Layout:
Number Start End Size Type File system Flags
1 4194304B 858000383B 853806080B primary fat32 lba
2 859832320B 8035237887B 7175405568B extended
5 864026624B 926941183B 62914560B logical fat16 lba
6 931135488B 8035237887B 7104102400B logical ext4
3 8035237888B 8068792319B 33554432B primary ext4
#130 framp 2017-07-01 11:27
Moin Gerald,

ich mache alles unter Linux wie folgt:
Code:
sudo kpartx -a -v jessie-lite-dd-backup-20170701-111018.img
sudo mount /dev/mapper/loop0p2 /mnt

und am Ende
Code:
sudo kpartx -d jessie-lite-dd-backup-20170701-111018.img

Auf raspbian musst Du noch kpartx vorher per Code:sudo apt-get install kpartx installieren.

Cu framp
#129 Gerald 2017-07-01 00:33
Hallo framp,

ich habe aktuell Bedarf ein einzelnes File aus meinem dd-Backup rückzuspielen und versuche das Image-File dafür zu mounten. Ich schaffe es aber weder unter Windows noch unter Linux.

Mit Windows hätte ich die Tool OSFMount (um das Image File zu mounten) und Ext2Fsd (um das Ext4 Filesystem lesen zu können) verwendet. Leider erkennt OSFMount das Filesystem nicht.

Unter Linux habe ich versucht das Image wie folgt zu mounten (offset mit parted ausgelesen):
mount -o loop,ro,offset=859832320 *.img /mnt/test

Folgender Fehler:

mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error

Fällt dir dazu etwas ein, was ich noch tun könnte?

Danke schön und lG, Gerald
+1 #128 framp 2017-06-23 22:48
Moin e-raser,

ich habe Deine ganze Sache die letzten Tage genauer getestet und geprüft:

zu 1) Das war ein Bug. Bislang hat ihn niemand bemerkt weil immer sofort ntp das Datum korrigiert hat. Das ist in der aktuellen Version gefixed.
zu 2) Das konnte ich nicht reproduzieren

Ansonsten stellte ich fest dass ein Jessie Image, welches mit tar gesichert und restored wird keine IP bekommt. Also genau dass was Du erfahren hast. Bei Wheezy gibt es keine Probleme mit tar Backups. Das irre ist, dass ein Jessie Image welches per rsync gesichert und restored wird ohne Probleme eine IP bekommt :kopfkratz:

Ich werde das weiter untersuchen und hoffentlich die Ursache finden. :crossingfingers:

Cu framp
+1 #127 framp 2017-06-20 20:21
Moin e-raser,

freut mich dass Dein System wieder läuft :thumbsup:

Vielen Dank auch für den Update und die ausführlichen Infos. Ich habe heute morgen Deinen Kommentar gelesen und mir nach meiner Antwort vorgenommen die Ursache dieses Problems jetzt mal genauer zu analysieren. Ich bin wie Du im Forenbeitrag ja gesehen hast auch schon auf das Problem gestossen.

Zu Deinen weiteren Punkten die Du entdeckt hast:

1) Habe ich auch schon festgestellt. Eigentlich setzt raspiBackup die Raspi fake rtc auf das aktuelle Restoredatum. Bei Wheezy ist dann die Zeit OK. Ich muss mal prüfen was sich da bei Jessie geändert hat.
2) Sehr merkwürdig. Ich prüfe das mal bei einem restoreten Jessie.
3+4) Das sind beides Serverdienste. Wenn Du sie nicht -o vor dem Backup gestoppt hast kann ich mir vorstellen, dass das die Ursache ist

Zu Deinen Fragen:
a) 3 und 4 ist sehr wahrscheinlich. 1 und 2 hat sicherlich andere Ursachen
b) raspiBackup sichert alle Daten - ausser Verzeichnisse die wirklich nicht benötigt werden oder die Du mit weiteren Optionen excludest
c) siehe (a)

Cu framp
#126 e-raser 2017-06-20 19:37
@framp,

--> Lösung #1 zum dhcpcd-Problem hat geholfen. Habe das für mich auch so dokumentiert, für mögliche zukünftige raspiBackup-Restores sind also schonmal 3 Stunden Nerven und Zeit eingespart.

Allerdings hatte ich weitere Probleme nach dem Restore, welche ich nicht vorenthalten will - ggf. sind einige davon ja auch "irgendwie" (wie das dhcpcd-Problem) auf das Backup zurück zu führen (tar in meinem Fall):
1) Uhrzeit ist falsch --> klar, ntp synct sich via Netz, zurückzuführen auf das dhcpcd-Problem = gelöst
2) "ping adress-or-IP" nicht möglich, Fehler: "Ping: icmp open socket: Operation not permitted". Lösung gem. https://ubuntuforums.org/showthread.php?t=927709: "sudo chmod u+s /bin/ping" ! Auch sehr seltsam, vor dem Backup haben die Filerechte ja auch gepasst.
3) Webmin: Defekt (Anzeige/Fehler "Require proc/proc-lib.pl failed : Died at (eval 118) line 1." für die meisten Module). ==> Problem: In /proc darf man als User nicht schreiben --> Neuinstallation Webmin (auf alte Config aufbauend) nötig!, am einfachsten (sofern via Paketlisten installiert) via "sudo apt-get install --reinstall webmin"
4) VNC-/X-Sessions: einige Einstellungen (Erweiterungen) für die Taskleiste (= lxpanel) fehlten und mussten neu hinzugeklickt werden.

Sonst soweit nichts entdeckt. V. a. 3 ist ekelig (wenn auch 'leicht' zu fixen) und vermutlich auf "in Betrieb während raspiBackup läuft" zurück zu führen.

Abschliessende offene Frage:
Sind diese o. g. Probleme nach einem raspiBackup (tar)-Restore ggf. darauf zurückzuführen, dass
a) raspiBackup im laufenden Betrieb sichert
b) bestimmte Verzeichnisse nicht mitsichert
c) bestimmte Dateien sich während dem Backup ändern (ich die zugehörigen Dienste also vorher stoppen/nachher wieder starten sollte)?

Erstmal aber nochmal vielen Dank für deine Hilfe mit den Lösungsoptionen - hat mir einige Stunden gespart :-)
+1 #125 framp 2017-06-20 07:56
Moin e-raser.

Das ist natürlich sehr blöd :cry: Besonders weil es jetzt im Ernstfall auftritt. Hast Du keinen Restoretest gemacht wie ich es an verschiedenen Stellen empfehle?

Anyhow:

Folgende Lösungsmöglichkeiten sehe ich:

1) Starten des Backups mit einem angeschlossenen Monitor und Tastatur. Dann
Code:sudo ifup eth0
sudo dhcpcd eth0

Dann bekommt Deine Raspi wieder eine IP. Allerdings nur bis zum naechsten Restart :sad: Wenn Du nun den dhcpcd5 deinstallierst und wieder installierst ist das Problem behoben:
Code:sudo apt-get remove dhcpcd5
sudo apt-get install dhcpd5


2) Wiederaufnahme des Threads und vielleicht hat ja noch jemand aus der Community eine andere Idee

3) Vielleicht hat ja jemand der hier mitliest ein Jessie am laufen und die Lösung. Bei mir läuft kein Jessie.

4) Wie im verlinkten Beitrag gesagt auf networkd umstellen.

Ich druecke Dir die Daumen dass eine der Lösungsmöglichkeiten zum Erfolg führt.

Solltest Du irgendwie rausbekommen was die Ursache für dieses blöde Verhalten ist wäre es nett dieses hier mitzuteilen damit andere Benutzer von Jessie nicht auch in dieses Loch reinfallen.

Cu framp
#124 e-raser 2017-06-20 03:39
Hi framp,

ich musste nun zum ersten Mal den Ernstfall durchführen und ein Image restoren. Alles prima soweit, BIS auf eine gravierende Sache: Kein Netzwerk. Ist ein Raspbian Jessie und genau das Problem, welches du hier beschrieben hast:
http://www.forum-raspberrypi.de/Thread-raspbian-geklontes-jessie-image-bekommt-keine-netzwerkverbindung

Nur... was ist nun die akute Lösung für mich? An das Quellsystem (microSD tot...) komm ich nicht mehr ran um dhcpcd rauszuwerfen, ich kann nur noch das Zielsystem (also die wiederhergestellte Kopie) modifizieren.

Brauche hier DRINGEND Hilfe, das System ist schon viele Stunden offline und die Nachtschicht hat sich bisher leider nicht gelohnt... :-(
#123 framp 2017-05-12 19:23
Moin Chris,

wie man sieht ist es absolut wichtig zu testen ob alles funktioniert wenn man raspiBackup einsetzen moechte. Speziell da Du keine Raspi benutzt sondern eine Bananapi. Allerdings sollte es damit auch funktionieren.
Du hast mir ja schon das restore log zugechickt. So wie ich es sehe ist schon beim Backup was schief gelaufen.

Kannst Du bitte noch mal ein Backup erstellen und mir von dem Lauf das Log zuschicken?

Cu framp
#122 Chris 2017-05-12 10:51
Hallo framp,

ich wollte gerade ein Restore vom meinem erstellten Backup machen, um zu testen, ob dies auch im Notfall funktioniert.
Es ist ein tar-Backup, wo die root-Partition auf einer externen Platte liegt. Mein Befehl lautet:
raspiBackup.sh -d /dev/sdb -R /dev/sda3 /media/driveb/raspibackup/bananapi/bananapi-tar-backup-20170511-030001/

Nun bekomme ich aber leider eine Fehlermeldung:
--- RBK0009I: bananapi: raspiBackup.sh V0.6.2 (554d0d7) um Fri May 12 10:27:36 CEST 2017 gestartet
--- RBK0128I: Logdatei ist /root/raspiBackup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
--- RBK0138I: Bootbackup /media/driveb/raspibackup/bananapi/bananapi-tar-backup-20170511-030001/bananapi-tar-backup-20170511-030001.tar wird benutzt
--- RBK0068I: Bootpartitionsdateien des Backups aus dem Verzeichnis /media/driveb/raspibackup/bananapi/bananapi-tar-backup-20170511-030001 die mit bananapi-backup beginnen werden benutzt
!!! RBK0018W: Ziel /dev/sdb mit 15.06 GiB ist größer als die Backupquelle mit 14.16 GiB. Die root Partition wird entsprechend vergrößert um den ganzen Platz zu benutzen
!!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht
--- RBK0067I: Momentane Partitionen auf /dev/sdb:
Number Start End Size Type File system Flags
1 1.05MB 15213MB 15212MB primary ext4
--- RBK0146I: Keine Partitionstabelle auf /dev/sda gefunden
!!! RBK0069W: Bootpartition /dev/sdb1 wird formatiert und erhält die zurückgespielte Bootpartition
!!! RBK0070W: Rootpartition /dev/sda3 wird formatiert und erhält die zurückgespielte Rootpartition
--- RBK0038I: Bist Du sicher? j/N
j
--- RBK0050I: Backup wird von /media/driveb/raspibackup/bananapi/bananapi-tar-backup-20170511-030001 zurückgespielt
--- RBK0051I: Master boot backup wird von /media/driveb/raspibackup/bananapi/bananapi-tar-backup-20170511-030001/bananapi-backup.mbr auf /dev/sdb zurückgespielt
--- RBK0052I: Partition(en) werden auf /dev/sdb erstellt
!!! RBK0004W: Zweite Partition wird von 0 Bytes auf 915.09 MiB angepasst
??? RBK0111E: Fehler beim Erstellen der Partitionen.RC
??? RBK0077E: Restore fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen. RC: 112

Was mach ich falsch?

Gruß, Chris
#121 framp 2017-03-04 09:44
Moin Kurt,

Code:-l debug -m detailed -L current funktioniert. Ich habe darüber schon diverse Logs erstellen lassen und analysiert. Du musst mal den genauen Befehl (copy/paste) hier mitteilen.

Eigentlich funktioniert das Rückspielen auf eine kleinere SD Karte funktionieren. Aber nur wenn Du tar oder rsync benutzt hast. DD geht nicht. Ausser Du hast DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY benutzt und Deine Partition auf der 32GB Karte auf < 16 GB angelegt.

Sofern Du keinen DD Backup versuchst zu restoren kann ich Dir auch die aktuelle Betaversion V0.6.1.3b-4-beta3 zuschicken und Du testest die mal aus.

Cu framp
#120 Kurt 2017-03-03 11:19
Moin framp,

habe gerade erfolgreich einen restore eines backups einer 32GB Karte auf eine 32GB SD Karte gemacht. Das gleiche auf eine 16 GB Karte schlug fehl mit dem Fehler:

--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.1.3b um Fr 3. Mär 11:04:16 CET 2017 gestartet
??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=112
??? RBK0077E: Restore fehlerhaft bendet: Create partition error (RC 112).

In beiden Fällen habe ich folgenden Befehl verwendet (V 0.6.1.3b):
sudo raspiBackup.sh -d /dev/sdc /media/Back/raspberrypi/raspberrypi-rsync-backup-2017…

Ich wollte dann die zusätzlichen Optionen -l 1 -m 1 bzw. -l debug -m detailed -L verwenden, da kam aber der Fehler:
RBK0147E: 1 (bzw. debug) nicht gefunden.

In Deinem blog fand ich einen Hinweis vom 24.9.16 (Helmut) mit gleichem obigem Fehler, auf den Du auch geantwortet hattest.

Frage: ist ein restore auf eine kleinere SD Karte noch nicht möglich?

Danke.
Kurt
#119 framp 2017-01-05 10:09
Moin Saschko,

freut mich dass es nun funktioniert :thumbsup:.

Zugegebernermassen hatte ich auch solch eine Vermutung und haette das mit dem Log auch sehr schnell rausgefunden. Aber bevor ich hier lange Frage und Antwort spiele frage ich lieber immer gleich nach dem Log. Da steht die Wahrheit drin :lol:

Cu framp
#118 saschko 2017-01-05 10:04
Hallo framp,
vielen Dank für die schnelle Antwort!
Hab doch was falsch gemacht, aber den Fehler selbst gefunden.... Habe eine veraltete raspiBackup.sh verwendet. :cry: Nach Update auf die neueste funktioniert es :-)

Gruß saschko
#117 framp 2017-01-05 09:37
Moin Saschko,

Du machst nichts falsch. Die Optionen und Parameter sind richtig. Bitte füge die Optionen -l debug -m detailed -L current zu Deinem Aufruf dazu und schicke mir die erzeugte Logdatei per eMail zu. Du findest die eMail auf meiner Kontaktseite ;-)

Cu framp
#116 saschko 2017-01-05 00:20
Hallo,
ich versuche gerade ein Backup direkt auf einem Raspi wieder einzuspielen. Habe (1) ein neues raspbian auf dem raspi, (2) eine neue SD-Karte, auf die das Backup soll - entspricht dev/sdb und (3) einen USB-Stick mit einer root.Partition /dev/sda1
Im Verzeichnis "backup" habe ich mein NAS per NFS gemountet.

Immer, wenn ich nun
raspiBackup.sh -d /dev/sdb -R /sda1 /backup/daily/rpi/rpi-rsync-backup-20170103-033001/
eingebe, wird ein neues dd-Backup in /backup/rpi erstellt - dabei will ich eigentlich ein Restore starten. Was mache ich falsch?
#115 framp 2016-11-17 19:37
Super. Jetzt hoffe ich das sich die Banane und die Orange vertragen :D
#114 René 2016-11-17 18:55
Danke schön für das super Script. Der Restore hat offenbar geklappt. Jetzt muss ich nur noch den Orange Pi dazu überreden das Banana Pi Image zu schlucken :-)
#113 framp 2016-09-24 15:41
Moin Helmut,

sfdisk: end of partition 2 has impossible value for cylinders: 1021 (should be in 0-1020)

Das ist ein Zeichen dass die dynamische Anpassung der Rootpartition in Deinem Falle noch Probleme hat. Bei meinen Tests war alles OK aber es gibt offensichtlich noch Randbedingungen wo es nicht funktioniert :sad:

Bitte rufe den Restore mit den zusätzlichen Optionen -l 1 -m 1 auf und schicke mir das erstellte Log von raspiBackup zu. Meine eMail findest Du auf der Kontaktseite.

Wenn Du eine SD Karte nimmst die dieselbe Größe oder sogar größer ist als die Original SD Karte sollte der Restore funktionieren.

Cu framp
#112 Helmut 2016-09-24 09:44
Guten Morgen,

ich habe nun nach einigem Probieren erfolgreich rsync Backups erstellt und möcht das Restore verifizieren. Doch dies geht schief, weil sich fsdisk beim Erstellen der Partitionen beschwert. Ich bin absolut ratlos und wäre für Hilfe sehr dankbar. Im log steht dazu folgendes:

20160924-093355: MSG --- RBK0052I: Partition(en) werden auf /dev/sdb erstellt
20160924-093356: MSG !!! RBK0004W: Zweite Partition wird angepasst von 15456010240 bytes (14.39 GiB) zu 7881097216 bytes (7.33 GiB)
sfdisk: Checking that no-one is using this disk right now ...
sfdisk: OK
sfdisk: Warning: partition 1 does not end at a cylinder boundary
sfdisk: Warning: partition 2 does not start at a cylinder boundary
sfdisk: Warning: partition 2 does not end at a cylinder boundary
sfdisk: Warning: no primary partition is marked bootable (active)
This does not matter for LILO, but the DOS MBR will not boot this disk.
sfdisk: end of partition 2 has impossible value for cylinders: 1021 (should be in 0-1020)
sfdisk: I don't like these partitions - nothing changed.
(If you really want this, use the --force option.)
20160924-093356: MSG ??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=112
20160924-093356: MSG ??? RBK0077E: Restore fehlerhaft bendet: Create partition error (RC 112)

Vielen Dank im Voraus
Helmut
#111 framp 2016-08-10 19:48
Moin Creamware,

Du musst schon eine SD Karte mit der Bootpartition haben die schon bootfähig ist und damit booten, denn Du machst ja einen quasi manuellen Restore und benutzt dazu nicht raspiBackup.
Du musst aber darauf achten, dass deine restorte Rootpartition auf derselben Partitionsnummer restored wird und dann unter demselben DeviceNamen gemountet wird wie es in der /boot/cmdline.txt der SD Karte steht. Ansonsten wird nichts booten. Sofern Du nur ein Gerät am Raspi angeschlossen hast und nur eine Partition auf dem gerät hast ist das im Normalfall /dev/sda1. Ansonsten musst Du noch vor dem Booten die /boot/cmdline.txt entsprechend anpassen.

Cu framp
#110 Creamware 2016-08-10 19:26
Hallo,
Werde das heute mal testen. Muss ich dann den so erzeugten Stick noch irgendwie bootfähig machen ?
Denke nein,oder ? Weil er ja nur die Rootpartition enthält,oder ?
#109 framp 2016-08-09 22:47
Moin Creamware,

Du hast Dein Problem ziemlich ungenau beschrieben. Sonst haette ich Dir gleich richtig antworten koennen ;-)

Das kein Backup gefunden wird liegt vermutlich daran, dass Du nicht das gesamte Backupverzeichnis sondern nur das tar kopiert hast. Wenn Du test2 in raspi2-tar-backup-20160806-203002 umbenennst und /mnt/backup/raspi2-tar-backup-20160806-203002 angibst wird es vermutlich funktionieren.

Da Du aber keine zweite SD Karte hast bringt Dir das nichts.

Ja, Du kannst das tar irgendwo entpacken (Muss nur genug Platz sein) und dann hast Du Deine Rootverzeichnisse. Nur /boot wird leer sein. Die Daten stecken in der .img Datei. Aber so wie ich Dich verstehe brauchst Du die auch nicht.

Es war eine der wichtigsten Bedingung von mir an raspiBackup, dass man an die Backupdaten auch mit normalen Linuxbefehlen herankommt :-)

Cu framp
#108 Creamware 2016-08-09 22:06
Hallo Frame,
Habe das schon alles genau gelesen. Meine Problem ist aber folgendes. Wenn ich das Backup Verzecihnis angebe mit Deiner Syntax, dann kommt immer die Meldung das kein Bsckup gefunden wurde. Des Weiteren habe ich keinen Kartenleser, und auch keine zweite SD Card. Ich möchte nur den Backup der Root Partition, den ich auch als tar file habe, auf den /dev/Sdb Stick zurücksichern.
Oder könnte ich das far file einfach auf den Ersatzstick entpacken ??
#107 framp 2016-08-09 21:39
Moin Creamware,

eigentlich habe ich sehr deutlich geschrieben dass man nach dem ersten Backup den restore testen soll :-*

Anyhow: Auf der Seite zum Restore habe ich in einem Beispiel beschrieben wie der Befehl aussehen muss wenn man ein restore mit externer Rootpartition vornehmen will.
https://www.linux-tips-and-tricks.de/de/raspibackup-restore

Dort steht z.B. Zitat:
sudo raspiBackup.sh -d /dev/sdf -R /dev/sda1 /remote/raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/
Jetzt ist natürlich die Frage wie man rausbekommt welche Laufwerksbezeichnungen was ist. bei mir sieht es z.B. so aus bei 'sudo fdisk -l'

root@raspberrypi:~# fdisk -l

Disk /dev/mmcblk0: 8011 MB, 8011120640 bytes
...
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 15646719 7761920 83 Linux

Disk /dev/sda: 15.5 GB, 15548284928 bytes
...
Device Boot Start End Blocks Id System
/dev/sda1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/sda2 122880 30367743 15122432 83 Linux

Disk /dev/sdb: 300.1 GB, 300069052416 bytes
256 heads, 63 sectors/track, 36338 cylinders, total 586072368 sectors
...
Device Boot Start End Blocks Id System
/dev/sdb1 1 586072367 293036183+ ee GPT

Dort siehst Du and der Größe dass /deb/sdb1 die externe Rootpartition ist (300GB) und /dev/sda die externe SD Karte ist (15.5 GB). Die interne SD Karte ist mmcblk0. Also lautet bei mir der Befehl

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

wobei mein rsync Backup auf /raspifix/disks/backup/rsync/raspberrypi/raspberrypi-rsync-backup-20141230-213032/ liegt.

Du musst Deine Werte anpassen und dann wird es funktionieren. Ausserdem wirst Du vor dem Restore noch einmal die Ausgabe von fdisk -l sehen von den Geräten und kannst noch einmal checken ob alles OK ist.

Cu framp
#106 Creamware 2016-08-09 16:55
Hallo,
habe jetzt den ersten Notfall, wo ich ein Backup restoren müsste, und komme nicht weiter. Boote im Prinzip von SD, und root liegt auf einem Stick. Backup war tar, und liegt in einem Verzeichnis, das ich nun auf einem anderen Raspberry gemounted habe. habe den Stick auf den ich restoren will angesteckt, und der lautet auf dev/sdb. Wie kann ich nun das tar file auf den Stick restoren ??
Möchte ja auf diesem Raspberry nicht die SD Card überschreiben !
Folgender Befehl wurde versucht:
raspiBackup.sh -R /dev/sdb /mnt/backup/test2/raspi2-tar-backup-20160806-203002.tar

Danke...
#105 framp 2016-07-25 20:33
Moin Nelson,

vielen Dank für Deinen Kommentar und den Hinweis auf Deine Erweiterung.

Deinen Beitrag #102 hatte ich als Anlass genommen genau diese fehlende Funktion in die demnächst rauskommende neue Version 0.6.1.3 zu implementieren. Sie hat einen weiteren Parameter -j für den Restore, der die zweite Partition entsprechend verkleinert oder vergrößert :-) .

Ich habe Dir auch noch eine eMail mit weiteren Infos geschickt ;-)

Cu framp
#104 Nelson 2016-07-25 00:46
Danke für die Info. Ich konnte deinen Vorschlag direkt umsetzen und testen. Scheint gut zu funktionieren. Ich habe mal ein kleines Script geschrieben, was sich dem Problem annimmt. Für das Script habe ich 2 oder 3 Funktionen aus deinem Script übernommen. Ich hoffe das ist ok, wenn nicht, dann hast du ja meine E-Mail Adresse.

http://www.mehr4u.de/raspibackup-wiederherstellung-eines-backups.html
#103 framp 2016-07-13 19:31
Moin Nelson,

dieses Problem wird immer mal wieder berichtet und ich muss mir da auch mal was einfallen lassen :-* . Bis dahin gibt es zwei Möglichkeiten:

1) Du kaufst Dir eine größere SD Karte :lol:
2) Bei einem tar oder rsync Backup liest Du Dir https://www.linux-tips-and-tricks.de/de/raspibackup-restore#comment-1080 durch. Die Größe muss nicht halbiert werden wenn die SD Karte ziemlich voll ist. Es reicht auch sie etwas kleiner zu machen.
3) Bei einem dd Backup ist softwarebakery.com/shrinking-images-on-linux hier gut beschrieben wie Du das dd backup verkleinern kannst.
Du kannst es auch genau ausrechnen um wieviel Du die size verkleinern musst indem Du die Größendifferenz durch 512 teilst und noch 1 dazuzaehlst.

Cu framp
#102 Nelson 2016-07-13 07:39
Hallo,

erst mal ein Lob für deine tolle Arbeit. Super Script.
Jetzt zu meinem Problem. Ich habe das Backup mit rsync laufen lassen. Beim Wiederherstellen der SD-Karte kommt der Fehler, dass die neue Karte zu klein wäre. Das ist sie bestimmt auch, aber nur ein paar kb. gibt es im Script schon einen Parameter, der die Partition so wiederherstellt, dass er die Neue nur so groß macht wie nötig? Nach erfolgreichem Restore, könnte ich ja das rootFS manuell wieder expandieren.

Fehlermeldung:
root@backup-pi:~# raspiBackup.sh -d /dev/sda /media/nas/backup/rsync-wz/pi/pi-rsync-backup-20160710-231219
--- RBK0009I: backup-pi: raspiBackup.sh V0.6.1.2 um Tue 12 Jul 23:43:04 BST 2016 gestartet
--- RBK0128I: Logdatei ist /root/raspiBackup.log
--- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
??? RBK0105E: Die Ziel SD Karte ist zu klein. Minimum erforderlich: 32009355264 bytes - Verfügbar: 31674335232 bytes
#101 framp 2016-05-30 20:33
Moin Florian,

vielen Dank für die Info. Die --force Option alleine reicht auch. Die kannst Du bei raspiBackup mit -1 (Strich 1) einschalten.

Ich habe gerade ziemlich viel um die Ohren. Wenn es wieder ruhiger geworden ist sehe ich mir das noch mal genauer an. Bis dahin einfach die -1 Option benutzen.

Cu framp
#100 Florian 2016-05-29 23:03
osmc@osmc:~$ sudo umount /dev/sdb1
osmc@osmc:~$ sudo umount /dev/sdb2
osmc@osmc:~$ sudo sfdisk --force -uSL --no-reread /dev/sdb < /media/Movies3TB/Backup/rpi/osmc/osmc-backup-20160526-220001.sfdisk

Disk /dev/sdb: 1021 cylinders, 245 heads, 62 sectors/track
Old situation:
Units: sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 2048 499711 497664 c W95 FAT32 (LBA)
/dev/sdb2 501760 15523839 15022080 83 Linux
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty
New situation:
Units: sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 2048 499711 497664 c W95 FAT32 (LBA)
/dev/sdb2 501760 15523839 15022080 83 Linux
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty
sfdisk: Warning: partition 1 does not end at a cylinder boundary
sfdisk: Warning: partition 2 does not start at a cylinder boundary
sfdisk: Warning: partition 2 does not end at a cylinder boundary
sfdisk: Warning: no primary partition is marked bootable (active)
This does not matter for LILO, but the DOS MBR will not boot this disk.
sfdisk: end of partition 2 has impossible value for cylinders: 1021 (should be in 0-1020)
Successfully wrote the new partition table

Re-reading the partition table ...

sfdisk: If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
osmc@osmc:~$ echo $?
0
#99 Florian 2016-05-29 23:03
sfdisk --no-reread scheint die erhoffte Wirkung zu zeigen, aber nur in Zusammenhang mit --force. Hier beide Versionen:

osmc@osmc:~$ sudo umount /dev/sdb1
osmc@osmc:~$ sudo umount /dev/sdb2
osmc@osmc:~$ sudo sfdisk -uSL --no-reread /dev/sdb < /media/Movies3TB/Backup/rpi/osmc/osmc-backup-20160526-220001.sfdisk

Disk /dev/sdb: 1021 cylinders, 245 heads, 62 sectors/track
Old situation:
Units: sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 2048 499711 497664 c W95 FAT32 (LBA)
/dev/sdb2 501760 15523839 15022080 83 Linux
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty
New situation:
Units: sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 2048 499711 497664 c W95 FAT32 (LBA)
/dev/sdb2 501760 15523839 15022080 83 Linux
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty
sfdisk: Warning: partition 1 does not end at a cylinder boundary
sfdisk: Warning: partition 2 does not start at a cylinder boundary
sfdisk: Warning: partition 2 does not end at a cylinder boundary
sfdisk: Warning: no primary partition is marked bootable (active)
This does not matter for LILO, but the DOS MBR will not boot this disk.
sfdisk: end of partition 2 has impossible value for cylinders: 1021 (should be in 0-1020)
sfdisk: I don't like these partitions - nothing changed.
(If you really want this, use the --force option.)
osmc@osmc:~$ echo $?
1
#98 Florian 2016-05-29 19:13
zitiere framp:
Moin Florian,

ich kann Dir auch eine gepatchte Version von raspiBackup zuschicken wenn Du möchtest. Ich brauche einfach jemanden bei dem der Fehler auftritt und der Deinen Fixvorschlag testen kann :-)

Cu framp

Danke, ich habe den restore nun geschafft, indem ich das "exitError" (oder ähnlich) nach dem sfdisk Befehl auskommentiert habe. Die --no-reread Option habe ich selbst auch zu spät entdeckt ;)
Wenn ich heute noch Zeit habe, versuche ich den restore auf die alte SD-Karte mit --no-reread.

P.S.
Übrigens ein super Skript! Läuft jede Woche perfekt durch und hat viele schöne Details (Backup-Optionen, E-Mail, Kompression, gute Doku, ...). Danke für deine Arbeit!
#97 framp 2016-05-29 18:17
Moin Florian,

ich kann Dir auch eine gepatchte Version von raspiBackup zuschicken wenn Du möchtest. Ich brauche einfach jemanden bei dem der Fehler auftritt und der Deinen Fixvorschlag testen kann :-)

Cu framp
#96 framp 2016-05-29 15:29
Moin Florian,

vielen Dank für Deinen Kommentar. Es kommt immer mal wieder vor dass jemand über dieses Problem berichtet. Ich kann es aber bei mir nicht nachstellen. Deshalb gibt es die Option -1 die sfdisk mit -f aufruft.
Die Option --no-reread war bislang nicht auf meinem Radar. Vielleicht könntest Du raspiBackup in Zeile 2241
mal in

sfdisk $force --no-reread -uSL $RESTORE_DEVICE < $$.sfdisk &>>"$LOG_FILE"

ändern und testen ob der Fehler dann weg ist? Ich kann den Fehler leider bei mir nicht reproduzieren :sad:

Wenn es dann bei Dir klappt ändere ich raspiBackup entsprechend ab.

Cu framp
#95 Florian 2016-05-29 14:32
zitiere framp:
Moin Sebastian,

leider kann ich ohne ein Log das Problem nicht untersuchen. Bitte rufe den Restore mit raspiBackup auf und gibt die zusaetzlichen Parameter -l 1 -m 1 mit. Das erzeugte Log schicke mir bitte an meine eMail (Siehe Kontakt Link).

Cu framp

Ich denke, das Problem hängt damit zusammen, dass sfdisk die Partitionstabelle nicht neu lesen kann. Partprobe scheint allerdings zu klappen. Also evtl. sfdisk mit --no-reread aufrufen und nur partprobe machen lassen. Oder den Fehlerwert von sfdisk interpretieren und ein fallback auf partprobe machen.
#94 Florian 2016-05-29 14:03
zitiere Sebastian Thiem:

sfdisk: BLKRRPART: Das Gerät oder die Ressource ist belegt
sfdisk: The command to re-read the partition table failed.
Run partprobe(8), kpartx(8) or reboot your system now,
before using mkfs
sfdisk: If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
Re-reading the partition table ...
20160519-100326: MSG ??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=102
20160519-100327: MSG ??? RBK0077E: Restore fehlerhaft in Schritt main mit RC 102 beendet. Weitere Informationen finden sich im Logfile /home/pi/raspiBackup.log
####################LOG#######################

Ich hatte genau dasselbe Problem auch gerade:
Backup mit tar Option auf externer Platte gemacht. Restore direkt aus Raspberry Pi 3 (osmc läuft darauf). Restore wollte ich auf neue SD-Karte machen (64GB, angehängt über SD-Kartenleser per USB, /dev/sdb). Erstellt auch 4 Partitionen anstatt 2. Ein manuelles "sudo partprobe /dev/sdb" läuft durch - evtl. ein Timing-Problem?
Thx und Gruss,
Florian
#93 framp 2016-05-19 15:41
Moin Sebastian,

leider kann ich ohne ein Log das Problem nicht untersuchen. Bitte rufe den Restore mit raspiBackup auf und gibt die zusaetzlichen Parameter -l 1 -m 1 mit. Das erzeugte Log schicke mir bitte an meine eMail (Siehe Kontakt Link).

Cu framp
+1 #92 Sebastian Thiem 2016-05-19 10:10
Hi,

leider läuft bei mir der Restore nicht. Nutze das aktuellste Skript mit einem Pi 2 und Raspbian.

Das Backup lasse ich auf einen Stick unter /media/backup durchführen als TAR.
Den Restore möchte ich auf eine mSD per USB Adapter durchführen. Jedoch klappt das nicht. Siehe LOG
Jedenfalls ist /dev/sdb nicht eingehangen.
Interessant dabei ist, dass die SD ein sdb3 und 4 bekommt. Macht irgendwie keinen Sinn wenn die komplette Karte neu partinioniert werden soll.

Was läuft falsch?

Danke schon mal
####################LOG#######################
Device Boot Start End #sectors Id System
/dev/sdb1 8192 131071 122880 c W95 FAT32 (LBA)
start: (c,h,s) expected (4,0,1) found (0,130,3)
end: (c,h,s) expected (63,63,32) found (8,40,32)
/dev/sdb2 131072 62945279 62814208 83 Linux
start: (c,h,s) expected (64,0,1) found (0,0,1)
end: (c,h,s) expected (1023,63,32) found (479,3,16)
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty
New situation:
Units: sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdb1 8192 131071 122880 c W95 FAT32 (LBA)
/dev/sdb2 131072 62945279 62814208 83 Linux
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty
Successfully wrote the new partition table

sfdisk: BLKRRPART: Das Gerät oder die Ressource ist belegt
sfdisk: The command to re-read the partition table failed.
Run partprobe(8), kpartx(8) or reboot your system now,
before using mkfs
sfdisk: If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
Re-reading the partition table ...
20160519-100326: MSG ??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=102
20160519-100327: MSG ??? RBK0077E: Restore fehlerhaft in Schritt main mit RC 102 beendet. Weitere Informationen finden sich im Logfile /home/pi/raspiBackup.log
####################LOG#######################
#91 framp 2016-05-15 19:04
Moin Homer,

nach Deiner Meldung Deines Problems habe ich jetzt die Beschreibung angepasst. Ich achte zwar immer darauf, dass neuer Code auch mit alten Backups und Optionen läuft - aber die Beschreibung hatte ich so umgestellt, dass sie nur zur neuen Version 0.6.1.2 passt. My fault. Sorry :oops:

Cu framp
#90 Homer-S 2016-05-15 18:05
ahhhhhhhhh
Danke, nun beginnt es auch mit Fehlermeldugen aber dann läuft es komplett durch und zumindest lutet die Letzte Meldung "succesful" :)

Danke
#89 framp 2016-05-15 16:57
Sorry Homer,

mein Fehler :sad: . Es muss -r und nicht -p sein :oops:
(Siehe https://www.linux-tips-and-tricks.de/de/raspibackup-restore und Parameter -r). Auch musst Du nicht das tar entpacken.

Cu framp
#88 Homer-S 2016-05-15 16:28
Hallo, habs noch mal probiert, musste das tar aber entpacken:
root@partedmagic:~/Media/sdd2# raspiBackup.sh -v -m 1 -d /dev/sdb -R /dev/sdd1 -p /media/sdd2/raspberrybackup/raspberrypi/unzip/raspberrypi-tar-backup-20160424-230001
./raspiBackup.sh: line 1015: getent: command not found
./raspiBackup.sh: line 1015: getent: command not found
--- RBK0009I: partedmagic: raspiBackup.sh V0.6.1.1k started at Sun May 15 16:20:46 UTC 2016
--- RBK0128I: Using logfile /var/log/raspiBackup/partedmagic.log
fdisk: cannot open /dev/mmcblk0: No such file or directory
??? RBK0011E: No boot partition mmcblk0p1 found

WIE kann ich das fixen? Beim letzten mal hatte es genau auf diese Weise funktioniert?!
#87 framp 2016-05-15 16:18
Moin Homer,

-p vor dem Pfad. raspiBackup solltest Du auf einem raspbian auf der Raspi ausführen. Es geht natürlich auch auf einem anderen LInux - aber dann sollte alles notwendige Installiert sein :-)

Cu framp
#86 Homer-S 2016-05-15 16:09
OS, welches restored werden soll ist Raspian, auf dem ich es durchführe ist eine Live CD mit PartesMagic.

Das -p vor oder nach dem Pfad zum tar? Na ich teste es einfach

Danke
#85 framp 2016-05-15 14:18
Moin Homer,

die Fehlermeldung
./raspiBackup.sh: line 1015: getent: command not found
ist nicht gut :sad: . Das solltest Du fixen. Mir scheint Du hast kein raspbian installiert. Welches OS benutzt Du?

Ausserdem solltest Du -p /media/sdb2/raspberrybackup/raspberrypi/raspberrypi-tar-backup-20160424-230001.tar benutzen - also noch das -p einfügen. In der älteren Version die Du benutzt funktioniert es noch nicht so wie DU es aufrufst. Erst ab der Version 0.6.1.2.

Cu framp
#84 Homer-S 2016-05-15 13:25
Hallo mal wieder :)

es sollte mal wieder soweit sein, dass ich einen Restore mache. leider will er gerade nicht so wie ich das will.
Das ist das Kommando mit dem ich den Restore anschieben möchte. Die raspiBackup.sh befindet sich im selben Ordner wo ich das Kommando eingebe.

raspiBackup.sh -v -m 1 -d /dev/sdc -R /dev/sdb1 /media/sdb2/raspberrybackup/raspberrypi/raspberrypi-tar-backup-20160424-230001.tar
./raspiBackup.sh: line 1015: getent: command not found
./raspiBackup.sh: line 1015: getent: command not found
raspiBackup.sh 0.6.1.1k, 2015-12-29/22:16:12 - 393d9b7
usage: raspiBackup.sh parameters


!!! RBK0125W: Unused parameters "/media/sdb2/raspberrybackup/raspberrypi/raspberrypi-tar-backup-20160424-230001.tar" detected. There are quotes missing in parameter arguments

Welches Argument will er denn noch haben?

Danke
#83 framp 2016-05-01 12:12
Moin Georg,

das ist etwas umständlich wie Du es machen willst ;-) Du kannst es auch unter Windows machen:

Du kannst ganz normal eine Bootpartition mit dem Standardtool anlegen und mit FAT formatieren. (56MB). Danach kannst unter alle Daten aus der alten Bootpartition auf die neue Bootpartition kopieren.

Cu framp
#82 Georg 2016-05-01 11:21
Hi,

mein "offenes" Problem:
Ich habe eine Boot SD und eine Root USB. Die Boot SD ist 32gb. Brauche da aber eigentlich nur die Rootpartition. Nun möchte ich gerne diese Boot partition auf eine kleinere SD Karte bringen.... Diskimager o.ä. funktioniert da nicht.
Hatte gedacht es müsste doch möglich sein das auch mit Deinem Backup Tool zu machen. Eine Tar Sicherung habe ich. Nun müsste ich eigentlich nur die Boot Partition auf eine neue kleinere SD restoren. Nur finde ich nicht die richtigen Aufrufparameter.
Gruss Georg
#81 framp 2016-04-30 19:49
Moin Georg,

freut mich dass es doch noch geklappt hat :-) . Merkwürdig ist dass Du da so viel manuell machen musstest. Eigentlich sollte raspiBackup das alles erledigen. Eine defekte SD Karte auf die man restoren will kann aber schon ziemliche negative Seiteneffekte haben.

Ich nehme Dein Erlebnis zum Anlass eine Seite zu erstellen, wo ich speziell für den Restore auch auf eine USB Disk oder -Karte die einzelnen Schritte Step by Step beschreibe was man vor dem Restoreaufruf gemacht haben muss. Speziell die USB Platte bzw -karte muss schon in gewisser Weite vorbereitet sein, denn raspiBackup kann nicht einfach die ganze Platte formatieren :o

Zu Deinem noch offenen Problem: Das habe ich zugegebenermassen nicht verstanden :-*

Cu framp
#80 Georg 2016-04-30 17:17
Hi,
schlussendlich ja.Die SD Karte und die Platte machte Schwierigkeiten. Erst nachdem ich sie einmal frisch mit Fat32 in Windows formatiert hatte, lief es.
Auch die USB Disk hatte ich im Raspberry ersteinmal formatiert / partitioniert und mit einem ext4 Dateisystem versehen. Nach dem Restore war dann noch ein fsck notwendig.
Ich hatte das vor einem Jahr schon einmal gemacht, aber ohne diese Schwierigkeiten... Wahrscheinlich hab ich zuviel rumgebastelt-:)
Auf jeden Fall bin ich froh, dass Du dieses Programm geschrieben hast. Ist wirklich sehr gut. Nochmal danke dafür.
Jetzt muss ich nur noch versuchen die 32gb Boot SD auf
eine 2gb zu bringen...Mal sehen opb das dasmit auch irgendwie geht. Muss ja nur die Boot Partition drauf.
Vielleicht nehme ich den gleichen Befehl wie beim restore und hänge anstelle der Original USB nur eine alte Schrottplatte dran damit die Aufrufsyntax für den restore passt.
Gruss Georg
#79 framp 2016-04-27 22:49
Moin Georg,

wie sieht es aus? Hast Du Dein Backup nun wieder restoren können?

Cu framp
#78 framp 2016-04-26 19:10
Moin Georg,

wie mir scheint hast Du nicht wie von mir dringend geraten wird mal den Restore getestet :sad:

Die SD Karte muss nicht vorbereitet werden. Die wird vollständig neu aufgesetzt. Die USB Partition darf nicht das ganze Gerät (/dev/sda) sein, sondern muss eine Partition (/dev/sda1) sein. Damit kannst Du dann z.B. mehrere Partitionen als externes Rootfilesystem für verschiedene SD Karten benutzen. Die Partition wird dann formatiert und damit alle exisierenden Daten zerstört. Also aufpassen dass die richtige Partition ausgewählt wird beim Restore.

Cu framp
#77 Georg 2016-04-26 10:09
Hi,
kurzer Nachtrag...
Wie müsste ich die SD Karte und die USB Disk vorbereiten um den restore erfolgreich auszuführen ? Formatieren und/oder Partition anlegen und/oder löschen oder oder etc.? Wie gesagt, bin leider kein Linux Fachmann.
Gruss Georgf
#76 Georg 2016-04-26 10:00
Hi,
danke für Deine schnelle Antwort. Hab gar nicht auf die (1) hinter dem Gerät geachtet....in der Hektik.
Gestern Nacht habe ich dann nocheinmal restored. Jetzt habe ich aber das Problem, dass er auf der USB Disk keine Partition findet. Die Daten sind aber da. Fsck habe ich bereits gemacht, aber der sagt die Platte ist in Ordnung (clean).
Was komisch ist...auf der SD ist als rootfile partition in der cmdline.txt als rootfile "/dev/sda1" angegeben. Auf der USB Disk heisst die aber "sda" vor & nach dem restore. Da sollte doch auch "sda1" stehen ? Muss ich die vor dem restoren so benennen ?
Ich bin leider nicht der Linux Fachmann, aber was ich gesehen habe, dass im Standard bein Backup einige Directories ausgeschlossen sind. Bei einigen kann ich das verstehen (tmp, backup etc.), bei anderen frage ich mich ob das so funktionieren kann. z.b. "sys" wird nicht gesichert. Kann das System nach dem Restore dann überhaupt laufen?
Danke für Deine Hilfe schon mal vorab.
Gruss Georg
#75 framp 2016-04-25 20:17
Moin Georg,

bist Du Dir sicher dass beides nach dem Stromausfall korrupt ist? Normalerweise hilft schon ein fsck auf die root Partition - sprich Deinen USB Stick.

Zu Deinem Fehler: Die Meldung sagt ja dass Du keine Parition als Ziel angeben darfst. Du hast die Partition /dev/sdd1 genommen. Es muss aber das Gerät /dev/sdd sein ;-)

Dann sollte der Restore funktionieren.

Cu framp
#74 Georg 2016-04-25 20:05
Ich habe auf einem raspberry die root partition ausgelagert auf eine usb disk. Gestern, nach einem Stromausfall, war nun die SD Karte und die Usb Disk nicht mehr lesbar/brauchbar. Ich dachte, ok, du hast ja eine aktuelle Sicherung (mit raspiBackup regelmäßig einmal am Tag eine tar - Sicherung) Aber.....
Möchte ich mit "raspiBackup.sh -d /dev/sdd1 -R /dev/sda1 /home/pi/backups/raspberry_old/Raspbmc/old/raspbmc-tar-backup-20160421-200003.tar" die Karfte und die USB Disk an einem Ersatz Raspi wiederherstellen, kommt immer die Meldung:
"??? RBK0086E: Wiederherstellungsgerät darf keine Partition sein". Ich komme hier nicht weiter, brauche aber die Daten...
(sd Karte und usb disk wurden mit fdisk auf dem raspi formatiert) Weder mit noch ohne Partition ist diese Fehlermeldung weg zu bekommen
Gruss Georg
#73 Homer 2016-04-15 20:49
Getestet ja, aber vor einer guten Zeit, als noch alles auf der SD-Karte drauf war UND ich noch eine Ersatzkarte im Schrank hatte ...
#72 framp 2016-04-15 13:00
Moin Homer-S,

verstehe ich das richtig dass Du den Restore noch nie getestet hast und jetzt den Ernstfall hattest, wo Du das Backup zum ersten Mal restored hast?

Ich empfehle auf der Webseite in rot Zitat:
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 immer wieder vor Zeit zu Zeit den ganzen Restoreprozess durchexerzieren und testen ob die erstellten Backups OK sind und sich ein System damit funktionsfähig restaurieren läßt.
:-)

Cu framp
#71 Homer-S 2016-04-15 11:33
DANKE! Es/Er/Sie läuft wieder ...

Ich werde den crontab Eintrag auf jeden Tag abändern!

Nochmals Danke für diene Hilfe und Geduld!
#70 Homer-S 2016-04-14 21:04
Ok nach dem unmount der sd karte lief es wieder los
Und es rattern die Dateien durch

Daumen drücken, nicht nur für die Deutsche Mannschaft heute
:)
#69 framp 2016-04-14 20:48
Moin Homer-S,

... das sollte so nicht sein :sigh:

Hast Du keine weitere Fehlermeldung bekommen? Benutze doch zum restore mal noch den Parameter -m 1 damit Du mehr Meldungen bekommst sowie den Parameter -v.

Cu framp
#68 Homer-S 2016-04-14 20:44
Nach 30 min habe ich versucht die Maus zu bewegen, aber nichts ging mehr. Nach dem Neustart bekomme ich eine Fehlermeldung mit dem gleichen Kommando
Error occurred with rc=102
#67 framp 2016-04-14 20:29
Moin Homer-S,

Rom wurde auch nicht an einem Tage erbaut :-) Also etwas geduld. Du kannst aber auch noch den Parameter -v beim restore benutzen. Dann siehst Du welche Dateien gerade restored werden.

Cu framp
#66 Homer-S 2016-04-14 20:20
Guten Abend,
Ich restore gerade und warte schon >10 Min

Es zeigt immer
Restoring backup from ....tar

Kommt da noch was oder brauch ich nur Geduld?

Danke
#65 framp 2016-04-13 21:47
Moin Homer,

zitiere Homer:
raspiBackup konnte ich auch nicht installieren, da das Lifesystem kein Internet hat.

Man kann es auch manuell auf einem rechner mit Internetverbindung runterladen (raspiBackup.sh und raspiBackup.conf) und dann auf die SD kopieren. Wie das geht habe ich www.linux-tips-and-tricks.de/de/raspibackup/#installation unter Schritt 3 beschrieben.
Zitat:
Deshalb dachte ich mir, Ich versuche es mal so:
SD Karte mit neuem Image bespielt.
aus der tar Datei, die Dateien entpackt und auf auf die externe root Partition kopiert mit überschreiben.
fstab geändert und die cmdline geändert.
...
Kann das was ich gemacht habe, überhaupt funktionieren?
Nein, Dabei entsteht ein ungesunder Mischmasch. Auch ist nicht gewährleistet dass Deine Bootpartition zu Deinem Backup passt.

Ich empfehle Dir raspiBackup manuell zu installieren und damit den restore vorzunehmen.

Cu framp
#64 Homer 2016-04-13 20:31
Hallo framp,
meine Motivation hält sich leider extrem in Grenzen, deshalb habe ich es heute erst versucht. Mein LifeLinux kann leider das Backup nicht restoren. raspiBackup konnte ich auch nicht installieren, da das Lifesystem kein Internet hat. Deshalb dachte ich mir, ich versuche es mal so:
SD Karte mit neuem Image bespielt.
aus der tar Datei, die Dateien entpackt und auf auf die externe root Partition kopiert mit überschreiben.
fstab geändert und die cmdline geändert.

Der Pi startet auch wieder und startet auch installierte Software, wie z.B. RP-Monitor. Aber schon im (wie nennt man das eigentlich) boot Ablauf kommt ein Fehler, dass mysql nicht gestartet werden kann...

Kann das was ich gemacht habe, überhaupt funktionieren?
#63 framp 2016-04-09 23:12
Moin Homer,

was spricht dagegen einfach den Backup zu restoren? Das wäre der einfachste Weg.

Du könntest z.B. aber auch eine neue SD Karte mit dem Backup versehen und die wichtigen Daten von der aktuellen SD Karte zurückspielen. Das setzt aber voraus dass Du weisst wo die wichtigen Daten liegen.

Ansonsten würde ich in einem RaspberryForum (z.B. www.forum-raspberrypi.de/ (Deutsch) oder www.raspberrypi.org/forums/ (English) ) mein Problem schildern und um Hilfe fragen.

Cu framp
#62 Homer 2016-04-09 22:44
Danke für die schnelle Antwort, aber das stellt sich für meine rudimentären Linux Kenntnisse schon als zu schwierig dar ...
#61 framp 2016-04-09 21:42
Moin Homer,

prinzipiell geht das. Es hängt allerdings vom Backup was Du erstellt hast ab - dd, tar oder rsync. Und Du musst SEHR GENAU wissen welche Verzeichnisse alle von mysql benutzt werden. Dazu musst Du das dd oder tar Backup entpacken dass Du die Verzeichnisse Schritt für Schritt zurückspielen kannst.

Ich würde aber an Deiner Stelle lieber versuchen das Problem zu beheben. Ich habe z.B. die Fehlermeldung genommen und einer Suchmaschine vorgeworfen und z.B. stackoverflow.com/questions/11990708/error-cant-connect-to-local-mysql-server-through-socket-var-run-mysqld-mysq gefunden, der mir sehr vielversprechend aussieht.

Wenn es wirklich nicht klappt ist die sicherste Methode noch das gesamte Backup zu restoren.

Cu framp
#60 Homer 2016-04-09 21:35
Hallo und guten Abend, kann man aus dem Backup auch "nur" mysql wieder zurück installieren? ich hatte von gestern auf heute beim aufrufen der Pydio homepage plötzlich diese Fehlermeldung:
DibiDriverException: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (11)
#59 framp 2016-03-26 16:44
Moin Mark,

beim Restore wird alles was gesichert wurde, wieder restored damit Du alle möglichen Speichermedien neu haben kannst. Dieses ist in Deinem Falle die Bootpartition auf SD sowie die Rootpartition auf USB.

Aus Deiner Frage lese ich heraus, dass es Dir eigentlich nur ums Rootbackup geht. Aber sollte Deine SD Karte ihren Geist aufgegeben haben nützt Dir dieses wenig :o

Aber Du hast natürlich Recht: Die Wahrscheinlichkeit, dass dieses passiert ist um Größenordnungen geringer als bei der Rootpartition, denn sie wird beim Booten nur gelesen und 'nutzt' sich somit nur bei einem Firmwareupdate ab.

Cu framp
#58 Mark 2016-03-26 16:19
Hallo,

ich habe ein (Verständnis)problem beim zurück sichern.
Das eigentliche System des Raspi liegt auf einem USB Stick, die SD wird nur zum booten genutzt.

Beim Rücksichern muss ich jedoch -d und -R angeben, sollte nicht -R reichen?

Oder ist das in beiden Fällen /dev/sda1???


Gruß Mark
#57 framp 2016-03-19 16:29
Moin Balou,

dann war das wohl ein intermittierender Fehler, den das Backupprogramm tar bekommen hat. Die SD Karte hat da vermutlich irgendein Problem gehabt. Lässt sich leider nicht mehr nachvollziehen :sad:

CU framp
#56 Balou 2016-03-19 15:01
framp,
Aktuell läuft alles ohne Probleme. Ich konnte den Fehler "Ein Fehler ist aufgetreten mit Rückgabewert=109"
abgebrochen." nicht wieder nachstellen. Ob zwischenzeitliches formtieren der Karte das erstmal beseitigt hat weiß ich nicht. H2testw hat jedenfalls nichts
nichts gefunden.
#55 Balou 2016-03-14 11:56
framp
Zwischenstand bis jetzt. Restore Versuche aus Tar Backup.
Mit Karte ca 3 Monate alt kein Problem, mit Karte neu frisch ausgepackt, kein Problem.
ein IMG Image auf die Karte mit der ich die Probleme hatte, kein Problem. Karte ist ca 4 Monate alt.
Alles Sandisk Ultra 16GB

Ich probiere die Tage noch mal das tar Backup und Restore.
#54 framp 2016-03-12 20:27
Moin Balou,

dieser intermittierende I/O Fehler weist auf Probleme mit der SD Karte auf die Du restorest hin.

Versuche mal den Restore auf eine andere und möglichst neue SD Karte.

Cu framp
#53 Balou 2016-03-12 20:14
framp,

jetzt ist das Restore nach zwei mal mit Fehler ohne Fehler durchgelaufen. Im alten Log habe noch das gelesen:
tar: ./overlays: Funktion mkdir fehlgeschlagen: Eingabe-/Ausgabefehler
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler
#52 framp 2016-03-12 18:47
Moin Balou,

guter Punkt. Ich sollte mal die RCs dokumentieren :-* .

109 bedeutet dass das Backupprogram, also in Deinem Falle tar, einen Fehler beim Restore bekommen hat. Den exakten RC vom tar schreibt die Meldung leider nicht. Das werde ich in der neuen Version ändern.

Du kannst aber in das Log reinsehen. Dort siehst Du den genauen tar Befehl der aufgerufen wird und dort folgt dann anschliessend ein Logeintrag 'Result xyz' wobei xyz der Returnwert von tar ist. Dann musst Du nachsehen was der RC beim tar bedeutet. Es kann auch helfen noch den Aufrufparameter -v zu benutzen. Dann wird die gesamte Ausgabe von tar gelogged was auch weiterhelfen kann den tar Fehler einzugrenzen.

Cu framp
#51 Balou 2016-03-12 18:28
Hi,

Mit ist gerade ein Restore mit
"Ein Fehler ist aufgetreten mit Rückgabewert=109"
abgebrochen.
Was soll mir der Fehler sagen?
Übrigens tar Backup
#50 framp 2016-02-10 17:30
Moin Frank,

in der Tat: Das ist ein Bug :oops: . Du bist der Erste der ein Restore eines gezippten dd Backups probiert hat. Ich muss gestehen , dass ich nur immer den dd Restore getestet habe :sad:

Der Fix ist ja einfach: Einfach den Text if= löschen. In der nächsten Version ist der Fix drin.

Vielen Dank für den Hinweis und die Problemanalyse.

Cu framp
#49 Frank Z. 2016-02-10 00:57
Hallo Framp!

Erstmal besten Dank für das nützliche Skript!

Ich glaube, ich habe einen Bug gefunden. Ich versuche, ein gezipptes dd Image zu restoren. Das Skript erkennt korrekt, dass das Image gepackt ist ("*.img.gz"), übergibt aber einen falschen Parameter (if=), der für reines dd gedacht wäre, an gzip:

20160210-004814: MSG !!! RBK0066W: Device /dev/sde will be overwritten with the saved boot and root partition
20160210-004814: MSG --- RBK0038I: Are you sure? y/N
20160210-004818: DBG >> restore
20160210-004818: DBG -- TRAP cleanup SIGINT SIGTERM EXIT
20160210-004818: MSG --- RBK0050I: Restoring backup from /backuppath/orion-ddz-backup-20160209-235331.img.gz
20160210-004818: DBG -- gunzip -c if="/backuppath/orion-ddz-backup-20160209-235331.img.gz" | dd of=/dev/sde bs=1MB
gzip: if=/backuppath/orion-ddz-backup-20160209-235331.img.gz: No such file or directory
0+0 records in
0+0 records out

Hoffe geholfen zu haben! ;)

Viele Grüße,
Frank
#48 framp 2016-01-14 10:40
Moin Wolle,

normalerweise sollte dieser Fehler nicht auftreten. Bitte versuche den Restore noch einmal mit den Parametern -l 1 -m 1 und schicke mir bitte das Log an meine eMailadresse (Siehe Kontaktseite).

Die force option kann man einschalten mit dem undokumentierten Parameter -1 (Eins). Das Restore sollte dann funktionieren. Du solltest dann aber genau pruefen ob das Restore Image funktioniert.

Cu framp
#47 Wolle 2016-01-13 23:06
Hallo framp
das restore meines tar backup klappt nicht.
sfdisk meldet einen Fehler (siehe Logausschnitt).
Kann man die --force Option über einen Parameter einschalten oder hast Du noch eine bessere Idee?
Danke für das prima Script und die Hilfe.
Wolle

sfdisk: Checking that no-one is using this disk right now ...
sfdisk: OK
sfdisk: Warning: partition 1 does not end at a cylinder boundary
sfdisk: Warning: partition 2 does not start at a cylinder boundary
sfdisk: Warning: partition 2 does not end at a cylinder boundary
sfdisk: end of partition 2 has impossible value for cylinders: 1023 (should be in 0-1022)
sfdisk: I don't like these partitions - nothing changed.
(If you really want this, use the --force option.)
#46 framp 2016-01-10 13:36
Moin Marcus,

freut mich dass es geklappt hat. Deine Anregnung diese Funktionalität in raspiBackup aufzunehmen wurde schon öfter geäußert. Momentan liegt mein primärer Fokus darauf ein Regressionpaket für raspiBackup zusammenzustellen, so dass Fehler bedingt durch Änderungen oder Erweiterungen im Script sofort erkannt werden und nicht publiziert werden.

Danach sehe ich mir mal an wie man Änderungen in dem Partitionslayout für den Restore vornehmen kann. Eine gut Idee habe ich momentan noch nicht. Ich möchte soweit wie möglich Linuxstandardtools dafür benutzen. Mal sehen was mir einfällt.

Cu framp
#45 Marcus 2016-01-09 14:59
PS:

Sehr schön wäre natürlich, wenn das Script mit einem Schalter beim Restore die Größe des Devices automatisch erkennen würde und die größte Partition entsprechend anpassen würde. Man könnte so auch ganz leicht das System von kleinen auf große SD-Karten und umgekehrt "umtopfen", ohne selbst rechnen zu müssen.
#44 Marcus 2016-01-09 14:54
Hallo Framp,

tolles Script - Backup und Restore (Tar-Modus) auf eine Time Capsule funktionieren einwandfrei! Vielen Dank auch für den Tipp #36 und #40 zum Verkleinern der Partitionen, hat nach etwas Rechnerei 1a funktioniert, auch bei einer komplexeren Partitionstabelle.

Noch einmal vielen Dank für ein so tolles Backup-Script.

Viele Grüße,
Marcus
#43 framp 2016-01-03 10:17
Moin Achim,

die -X Option ist schon lange nicht mehr notwendig. Aber ich habe gesehen, dass sie noch in den Beispielaufrufen benutzt wurde. Das habe ich gerade korrigiert. Danke für den Hinweis.

Zu Deinem zweiten Punkt: raspiBackup macht eine exakte Kopie und erfordert deshalb auch dass die Partitionen der Quell SD Karte auf die Ziel SD Karte passen. Es gibt aber einen Trick, wie man die Größe manuell ändern kann. Siehe dazu den Beitrag #36 und #40.
Ich werde diese Funktionalität auch irgendwann einbauen.

Cu framp
#42 Achim 2016-01-03 07:17
Moin - Gute Arbeit,

ist die -X Option in deinem Beispiel richtig? Bei mir gibts deswegen eine Fehlermeldung, wenn ich -X weg lasse gehts.
Leider bekomme ich auch beim tar-backup die Fehlermeldung, dass meine Ziel- Karte (ein paar) Bytes zu klein ist. Habe eigentlich das tar-Backup genommen um auf eine kleinere Karten zurückzuschreiben.

Gruss,
Achim
#41 framp 2015-12-30 14:46
Moin Raspi-Newbie,

vielen Dank für die Bestätigung dass dieses Verfahren funktioniert um einen Restore auf eine kleinere SD Karte hinzubekommen.

Zitat:
@framp: Es wäre natürlich klasse, wenn die Funktion irgendwann Einzug in das Skript findet.

Das erfordert größere Änderungen, die bislang nicht geplant sind. raspiBackup war ja ursprünglich nur für mich gedacht und der Funktionsumfang ist mittlerweile weit über meine Ansprüche hinausgewachsen.
Für diese Funktion müssen mehr Metadaten beim Backup erfasst werden, denn die Funktion macht ja nur Sinn wenn für das Backup noch genügend Platz auf der SD Karte übrig bleibt nach dem Restore.

Ich könnte mir aber vorstellen ein weiteres Script zu erstellen welches das Verkleinern der Konfigdateien vornimmt. Wann ich dazu komme weiss ich nicht. Aber ich habe dieses im Hinterkopf :-)

Cu framp

PS: Ich nehme Deinen Kommentar als Anlass diesen manuellen Workaround auf der Webseite zu beschreiben so dass jeder zukünftig mit dieser manuellen Methode einen Restore auf eine kleiner SD Karte vornehmen kann.
#40 Raspi-Newbie 2015-12-30 11:32
Hallo zusammen,

ich hatte vorhin auch das gleiche Problem wie strawmeas.
Die neue SD-Karte ist offenbar um 20971520 Bytes zu klein.

??? RBK0105E: Die Ziel SD Karte ist zu klein. Minimum erforderlich: 7969177600 bytes - Verfügbar: 7948206080 bytes
??? RBK0015E: Ein Fehler ist aufgetreten mit Rückgabewert=102

Nun habe ich den Rat von framp befolgt und die Datei .fdisk des Backups angepasst:

Vorher:
/dev/mmcblk0p2 : start= 122880, size= 15441920, Id=83

Nachher:
/dev/mmcblk0p2 : start= 122880, size= 15000000, Id=83

Und, siehe da, es klappt! Der Pi bootet auf der neuen SD-Karte und macht was er soll.

@framp: Es wäre natürlich klasse, wenn die Funktion irgendwann Einzug in das Skript findet.

Guten Rutsch!
#39 framp 2015-11-27 18:35
Moin Robin Woodo,

jetzt habe ich mir Dein Problembericht noch mal genauer angesehen und habe auch ohne Log den Fehler gefunden. Du rufst das Script mit dem Parameter -p auf - der hat aber beim restore nichts zu suchen ;-) Lass den Parameter weg und dann sollte alles wie gewünscht klappen.

Cu framp
#38 framp 2015-11-26 23:07
Moin Robin Woodo,

Deine Parameter sehen eigentlich OK aus. Rufe bitte den Restore mit den zusätzlichen Parametern -l 1 -L 3 -v -m 1 auf und schicke mir das Log an die auf der Kontaktseite genannten eMail. Ich sehe mir das dann mal an.

Cu framo
#37 RobinWoodo 2015-11-26 22:41
Hi, ich habe ebenfalls ein Backup meiner NOOB Installation als .tar angelegt. Beim Restore habe ich nun ein paar Probleme.
Die SD-Karte auf die das Backup aufgespielt werden soll ist laut "sudo parted -l" als "/dev/sdd" bekannt. Den Restore versuche ich über folgenden Befehl "sudo /usr/local/bin/raspiBackup.sh -p -d /dev/sdd -r /PFAD" durchzuführen.
Leider bekomme ich hierbei immer den Fehler "??? RBK0031E: Backuppfad -d exisitert nicht". Was mache ich falsch? Vielen Dank für deine Hilfe!
#36 framp 2015-11-26 19:04
Moin strewmeas,

der partitionsorientierte Restore legt alles wieder so an wie es auf dem Backup war. Allerdings verstehe ich was Du vorhast und es ist auch ein valides Einsatzszenario vom Backupscript. Vielleicht baue ich es irgendwann mal ein, dass man die Größe der Partition beim Restore angeben kann. Nachdem ich jetzt aber ziemlich lange am partitionsorientierten Modus gearbeitet habe werde ich erst mal keine größere Änderungen aufnehmen.

Du kannst aber folgendes machen:

1) Die Datei .fdisk des Backups irgendwo sichern und dann darin den Wert der bytes mit
Disk /dev/sda: 128.0 GB, 128035676160 bytes
ändern und die Zahl der Bytes der QuellPartition halbieren in 64017838080
2) Die Datei .sfdisk des Backups irgendwo sichern und dann darin den Wert von size=
/dev/mmcblk0p2 : start= 122880, size= 7618560, Id=83
halbieren in 3809280

Der Lösungsansatz ist ungetestet. Er sollte aber eigentlich funktionieren.

Lass uns wissen ob es so funktioniert.

Cu framp
#35 strawmeas 2015-11-26 08:45
Hallo,

folgendes Problem: Ich habe ein partitions-orientiertes tar-Backup meiner SD-Karte erstellt, die zwar 16GB groß ist, aber deren Root-Partition nur 7,5 GB beträgt. Dieses Backup wollte ich auf eine via USB angeschlossene 8-GB-Karte wiederherstellen, bekomme hier aber die Meldung
"RBK0105E: Die Ziel SD Karte ist zu klein" Was mache ich falsch?

Gruß
strawmeas
#34 heeelga 2015-11-09 12:57
Moin framp,

vielen Dank noch einmal für den großartigen Support! Mit deiner neuen Version klappt alles wie gewollt.
Zusammengefasst habe ich dein Script installiert, dann die .sh Datei mit der neueren Version durch Copy/Paste ersetzt und kann nun den Restore mit -Y automatisiert anlaufen lassen.
Ich habe darüber hinaus keine Probleme feststellen können :).

Grüße,
heeelga
#33 framp 2015-10-22 17:16
Moin heeelga,

-y ist undokumentiert und wird von mir benutzt um das Script eben schnell auf meinen Raspis zu installieren.

In der kommenden version 0.6, die auch NOOBS Images unterstuetzt, habe ich den Parameter -Y eingefuehrt, weil es mich auch beim Testen genervt hat immer mit yes zu antworten.

Er ist aber nicht ganz ungefaehrlich - Du kannst Dir damit u.U. eine Partition zerschiessen :o

Wenn Du willst rolle ich den Parameter -Y in den aktuellen Stand rein und schicke Dir das neue Script. Du bist dann natuerlich auch der Tester ob der cherry-pick OK ist 8)

Cu framp
#32 heeelga 2015-10-22 15:18
Hi Framp,

vielen Dank für den ausführlichen Artikel und das geniale Backupscript. Ich hatte es vorher mal mit der OneLiner DD Backup Methode probiert aber da hat das zurücksichern des Images nie geklappt.

Eine Frage hätte ich zum Restore, keine Ahnung ob das möglich ist. Gibt es einen Parameter den man beim Restore auf eine SD Karte mitgeben kann wodurch keine "Yes/No" Abfrage kommt? Ich würde nämlich gerne per Cron das Backup auf eine Ersatz SD zurücksichern lassen. Der Paramter -y scheint nicht zu funktionieren.

Danke im Voraus!
#31 framp 2015-08-16 22:00
Vielen Dank beMoD für deine ausführliche Erklärung sowie Deine Hilfe das Problem zu identifizieren. Ohne diese hätte es ziemlich sicher sehr lange gebraucht diesen tricky Fehler in parted zu finden.
#30 beMoD 2015-08-16 21:31
Nach relativ aufwändiger Suche scheint mein Problem jetzt gelöst zu sein, bzw. zumindest ist der Auslöser bekannt.

Ich habe festgestellt, dass das dd, mit dem das Image der boot Partition zurückgespielt wird bei mir eine reguläre Datei /dev/sdb1 anlegt, anstatt wie es richtig wäre in das Blockdevice /dev/sdb1, also die erste Partition der SD Karte, zu schreiben. Daher kommt dann der "No space left on device" Fehler, da unter /dev nur 10MB Platz sind.

Weitere Untersuchungen haben dann ergeben, dass das tool partprobe direkt vor dem dd Aufruf aufgerufen wird. Durch den Aufruf von partprobe wird die Partitionstabelle der SD Karte neu eingelesen. Interessanterweise verschwand aber kurz nach der Beendigung von partprobe das Device /dev/sdb1. Das sollte nicht passieren und sieht für mich wie ein Bug in partprobe aus. Genau in dem Moment hat dd dann angefangen dort hinzuschreiben´und dadurch wurde die reguläre Datei angelegt.

Das Problem scheint nur in parted 3.2 (enthalten im jessie Release von Raspbian oder Debian) aufzutreten. Nach einem Downgrade auf parted 2.2 trat das Problem nicht mehr auf.

Grüße,
beMoD
#29 framp 2015-08-13 23:39
Moin beMoD,

da sieht man wieder dass es wichtig ist den Restore zu testen :-)

Du musst den restore mit -l 1 -m 1 aufrufen und mir das Log bereitstellen. Die Konsolausgabe reicht nicht. Kannst mir das Log auch per email zuschicken (-> Kontakt Seite).

Cu framp
#28 beMoD 2015-08-13 23:21
Hiho,

endlich konnte ich das restore testen. (Verdammte interne SD-Karten Leser, die sich nicht in eine VM einbinden lassen wollen.) Das System bootet und es scheint alles gut.
Allerdings schmeisst das dd beim restore einen Fehler. Was mich auch ein wenig stutzig macht sind die zusätzlichen Partitionen sdb3 und sdb4. Wo kommen die her?
Hier die interessanten Zeilen des logs: http://nopaste.linux-dev.org/?674344

Grüße,
beMoD
#27 framp 2015-08-03 20:21
Moin Jan,

vielen Dank für den erfolgreichen Test des Fixes.

In der nächsten Version wird der Fix dann verfügbar sein.

Cu framp
#26 Jan 2015-08-02 22:44
Hallo,

danke, hatte mir sowas schon gedacht, warte gerne auf den fix, ist auch nichts dringendes. Teste dann gerne.
Gruß
Jan
#25 framp 2015-08-02 17:50
Moin Jan,

Es liegt daran, dass Du als Hostnamen Cam-Garage benutzt. Würde Dein Host CamGarage heissen würde der Fehler nicht auftreten :-) Momentan mag das Script keine Hostnamen mit Bindestrich :oops:

Es gibt jetzt 2 Möglichkeiten:

1) Du änderst alle Dateien im Backupvereichnis
Cam-Garage-backup.img
Cam-Garage-backup.mbr
Cam-Garage-backup.sfdisk
Cam-Garage-tar-backup-20150802-112641.tar

dass sie

CamGarage-backup.img
CamGarage-backup.mbr
CamGarage-backup.sfdisk
CamGarage-tar-backup-20150802-112641.tar

heissen. Dann wird der Restore funktionieren.

2) Du wartest bis ich einen Fix für das Script gebaut habe den ich Dir dann per eMail zuschicke zum Testen. Du musst mir nur Bescheid geben ob Du auf den Fix warten möchtest.

Cu framp
#24 Jan 2015-08-02 17:06
Hallo,

bekomme beim Versuch eine tar sicherung zurückzuspielen folgendes gemeldet:

pi@Cam-Haus ~ $ sudo raspiBackup.sh -X -d /dev/sda -r /mnt/backup/Cam-Garage/Cam-Garage-tar-backup-20150802-112641.tar
??? RBK0034E: File /mnt/backup/Cam-Garage/Cam-backup.sfdisk not found
pi@Cam-Haus ~ $

folgende Dateien wurden bem Backup angelegt:
/mnt/backup/Cam-Garage/
Cam-Garage-backup.img
Cam-Garage-backup.mbr
Cam-Garage-backup.sfdisk
Cam-Garage-tar-backup-20150802-112641.tar

Gruß
Jan
#23 framp 2015-03-10 22:08
Fein. Ich dachte dass die Beschreibung zu dem -r Parameter genau genug ist. Ich habe sie jetzt noch etwas erweitert :-)
#22 Friesen 2015-03-10 21:10
Super, das hat funktioniert! Danke :lol:
#21 framp 2015-03-10 19:16
Moin Friesen,

Du musst die backup tar Datei angeben - also sowas wie raspberrypi-tar-backup-20150215-033001.tar. Dann sollte es funktionieren. Dein Log was Du mir zugeschickt hat war hilfreich. Denn ich muss zugeben, dass der Restore da noch besser und vor allen Dingen früher prüfen sollte, ob alle Dateien vorliegen. Das werde ich fixen.

Cu framp
#20 Friesen 2015-03-09 22:09
Also ich bin gerade dabei ein frisch eingerichtete SD Karte zu restoren. Hier mein Backupbefehl "sudo /usr/local/bin/raspiBackup.sh -p /media/usbhdd/Backups -t tar"

Beim Restore verwende ich "sudo ./raspiBackup.sh -X -d /dev/sdf -r /medie/stas/Daten/Backups/raspberrypi/"
Dabei bekomme ich direkt eine Fehlermeldung, dass die *.sfdisk nicht gefunden wurde. Die ist aber definitiv da drin.
Naja nicht weiter tragisch, dann wähle ich diese explizit aus: sudo ./raspiBackup.sh -X -d /dev/sdf -r /medie/stas/Daten/Backups/raspberrypi/raspberrypi-backup.sfdisk

Hier die Übersicht der Mounts
/dev/sda1 ext4 / 7f83fe1c-2a8a-4563-afd6-cb9ad6ab94c1
/dev/sda5 swap c07e5da8-f62e-4adc-a335-ae455b5b44d5
/dev/sdb1 vfat boot (not mounted) 140A-14B7
/dev/sdb2 ext4 (not mounted) f24a4949-f4b2-4cad-a780-a138695079ec
/dev/sdc1 ntfs Daten /media/stas/Daten 7640A2E740A2ACF5

ist der letzte restrorebefehl ok?

VG Friesen
#19 framp 2015-03-09 00:00
Moin Friesen,

der Restore sollte eigentlich booten wenn Du beim Backup nicht alle Services gestopt hat. Dass Deine Services dann vielleicht ein Problem haben ist eine andere Story :-*

Aber versuche es nochmal und schicke mir dannraspiBackup.log an meine eMail damit ich mir das mal ansehen kann,

Cu framp
#18 Friesen 2015-03-08 23:53
Hallo,
danke für deine Antwort, ich habe es eben mit dem neuem Script versucht. Er hat auf jeden fall etwas gemacht. Nach dem die Meldung erschien, dass die Wiederherstellung erfolgreich abgeschlossen wurde, wollte ich natürlich den raspli von der Karte booten. Das hat nicht geklappt. :sad: Aber ich vermute, dass es evt. an dem Backup noch liegen kann. Denn ich habe das Backup gezogen ohne jegliche Dienste zu beenden. Ich hatte Seafile und Baikal am laufen. Ich werden morgen den Raspi noch mal neue aufsetzten, dann Backup machen und erneut wiederherstellen. Danach werden ich von meinen Taten berichten.
#17 framp 2015-03-08 20:48
@Friesen,

Du lässt nix mehr von Dir hören. Wie sieht es nun aus mit dem Restore? Funktioniert es?

Cu framp
#16 framp 2015-03-04 20:20
Moin Friesen,

absolut richtig den Restore auch zu testen bevor man ihn dann wirklich mal braucht!

zu 1): Nein, das geht nicht. technisch ist das sicherlich möglich zum implementieren, aber dazu habe ich keine Zeit.

zu 2): Benutzt Du die aktuelle Version. ich habe gerade letztens an der Stelle was gefixed - aber nur theoretisch, da ich die HW nicht habe. Es kann also sein dass da immer noch was nicht ganz OK ist. Bitte lade die aktuelle Scriptversion runter und versuche den restore nochmal. Wenn es immer noch nicht funktioniert füge den Parameter -l 1 (kleines L) im Aufruf dazu und schicke mir das raspiBackup.log File an meine eMailAdresse, die Du im Kontaktbereich findest und ich sehe mir das dann genauer an.

Cu framp
#15 Friesen 2015-03-04 00:47
Hallo Zusammen,
ich habe mit diesem Script ein Tar Backup auf eine externe Festplatte erstellt. Soweit so gut :roll:
Anschliessend möchte ich es natürlich auch testen, ob das Restore funktioniert.
Jetzt zur meinen Fragen.
1. muss der Restore auf einem anderen Linux Rechner erfolgen, oder kann er sich selbst überschreiben. Also ich meine das Raspberry Pi hat diese SD karte drin und ich lasse es auf sich selbst restoren. Ich denke das wird nicht funktionieren?
2. Zum testen wurde ein Debiansystem verwendet. BackupHDD gemountet, SD Karte wird unter /dev/sdb aufgelistet. Es gibt zwei weiteren Unterpartitionen sdb1 und sdb2, die sind nicht gemountet. Wenn ich das Befehl zu Restore ausführe "sudo ./raspiBackup.sh -X -d /dev/sdb -r /media/usbhdd/Backus/ezbraspi/" bekomme ich ein Fehler "RBK0011E: Keine boot Partition mmcblk0p1 gefunden" Was mache ich falsch? kann mir bitte einer Helfe.
Besten Dank im Voraus.
#14 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.
#13 framp 2015-02-15 19:43
Good catch. Eine unpartitioniert SD Karte habe ich bislang nicht zum Restore genommen :oops:
#12 Michael 2015-02-15 13:10
Zu 2) Mit '/dev/mmcblk0p' schlägt das Anlegen der Partitionen fehl. Zumindest bei unpartitionierten SD-Karten gibt es also Probleme.

Zu 3) Ich habe mir das inzwischen auch selbst beantwortet:
Ich habe alle Referenzen auf '/mnt' in der Funktion 'restore()' durch eine Variable ersetzt, die auf '/mnt/raspiBackup' zeigt. Das Verzeichnis wird zu Beginn angelegt, falls es noch nicht existiert. Das scheint so zu funktionieren.

Den Code kann ich Dir bei Interesse zukommen lassen.


Viele Grüße, Michael
#11 framp 2015-02-14 20:51
Moin Michael,

Danke fuer Deine Anmerkungen.

zu 1) Da ist richtig. Die Doc werde ich updaten. Der restoreschwerpunkt lag auch bislang immer beim rsync und da ist die doc OK
zu 2) Geht es nicht wenn /dev/mmcblk0p angegeben wird? Anyhow werde ich das mal prüfen.
zu 3) Ist richtig. Hat sich aber noch niemand beschwert :-* Das nehme ich mir auch vor und aendere das.

Cu framp
#10 Michael 2015-02-14 14:21
3. Das Skript scheint davon auszugehen, dass es volle Kontrolle über das Verzeichnis '/mnt' auf dem Laptop hat, dass darunter keinerlei andere Laufwerke gemountet sind, und dass es problemlos alle evtl. gemounteten Laufwerke unmounten kann. Das erscheint mir ein bisschen weltfremd. Unter '/mnt' sind häufig in weiteren Unterverzeichnissen andere Netzwerk-Laufwerke gemountet (bei mir z. B. das Raspi-Backup-NAS der Fritzbox), was unweigerlich zum Konflikt führt.
Kannst Du die Mount/Unmount-Aktivitäten von RaspiBackup (Restore) vielleicht auf ein Unterverzeichnis von '/mnt' (z. B. '/mnt/raspiBackup') beschränken? Das würde wahrscheinlich einige Konflikte vermeiden.

Ansonsten, keep up the good work!


Viele Grüße, Michael
#9 Michael 2015-02-14 14:18
Hallo Framp,

ich probiere gerade die Restore-Funktion Deines Backup-Skripts (Version 0.5.8.8) aus, und habe einige Kommentare dazu. Ich erstelle ein Backup im TGZ-Modus auf ein gemountetes Laufwerk (das NAS von der Fritzbox). Das klappt soweit auch ganz gut. Den Restore führe ich auf meinem Laptop mit Linux durch. Im Laptop ist die SD-Karte des Restore-Raspis eingesteckt, und erscheint als 'dev/mmcblk0p1' und 'dev/mmcblk0p2' in Linux.

Dabei gibt es die folgenden Auffälligkeiten:
1. Als Aufrufparameter muss ich den vollen Pfad der Backup-Datei (mit Endung '.tgz') angeben, und nicht nur das Verzeichnis (wie in der Anleitung beschrieben).

2. Ds Skript kommt mit der Notation des (virtuellen) Laufwerks der SD-Karte nicht klar. Es erwartet ein physikalisches Device (z. B. '/dev/sda'), an das nur eine Ziffer als Partitionskennung angehängt wird (z. B. '/dev/sda1'). Bei SD-Karten läuft das aber anscheinend anders (zumindest in meiner Linux-Distribution auf dem Laptop): Das physikalische Device hat den Namen 'dev/mmcblk0', und die Partitionen haben die Namen 'dev/mmcblk0p1' und 'dev/mmcblk0p2'. Da mogelt sich also noch ein 'p' dazwischen. Ich habe den Code entspr. angepasst (ca. Zeile 1550 im Skript):

if [[ $RESTORE_DEVICE = "/dev/mmcblk0" ]]; then
BOOT_PARTITION="${RESTORE_DEVICE}p1"
else
BOOT_PARTITION="${RESTORE_DEVICE}1"
fi
logItem "BOOT_PARTITION: "

ROOT_PARTITION_DEFINED=1
if [[ -z $ROOT_PARTITION ]]; then
if [[ $RESTORE_DEVICE = "/dev/mmcblk0" ]]; then
ROOT_PARTITION="${RESTORE_DEVICE}p2"
else
ROOT_PARTITION="${RESTORE_DEVICE}2"
fi

Das kannst Du gerne übernehmen.

Punkt 3 folgt in einer weiteren Nachricht, da sie sonst zu lang würde.
#8 framp 2015-01-01 19:31
Moin Bernd,

Dir wünsche ich auch alles Gute im neuen Jahr - sowie auch ein erfolgreichen Backup und Restore Deiner Raspi :-) .
Ich habe jetzt zwei Beispielaufrufe des Backupscripts für die beiden Arten des Restores oben in der Beschreibung aufgenommen. Die habe ich schlichtweg vergessen :oops:

Welche Parameter Du genau einsetzen musst kann ich aus Deinen Informationen nicht entnehmen, da diese Informationen die aktuellen Daten der Pi zum Zeitpunkt des Backups sind. Beim Restore sieht es meist ganz anders aus.

Ich würde den Restore bei mir auf meinem Linuxdesktop wie folgt machen:
1) Einstecken der SD Karte und sie wird bei mir als /dev/sdf erkannt. Vermutlich ist es bei Dir /dev/sdb oder wenn Du ein CDRomLaufwerk hast /dev/sdc. Am besten nach dem Einstecken mit sudo fdisk -l prüfen. (-d Parameter)
2) Einstecken der USB Platte, die die Rootpartition restored bekommen soll. Ist bei Dir vermutlich /dev/sdc oder /dev/sdd. Dieses wieder mit sudo fdisk -l prüfen. Da Deine Rootpartition /dev/sda6 ist, soltest Du dann /dev/sdc6 oder /dev/sdd6 sein. (-R Parameter)

Wichtig ist, dass Deine externe Platte, wenn Du sie an Deine Pi anschliesst, dann wieder als /dev/sda erkannt wird. Sonst wird der Boot schiefgehen.

Solltest Du kein Linux System im Zugriff haben, musst Du die Pi selbst zum Restore benutzen und irgendein raspbian auf Deiner Pi starten und dann die o.g. Schritte vornehmen.

Cu framp
#7 Bernd 2015-01-01 18:31
Hallo framp,
nachdem ich erfolgreich einige rysync-Backups erstellt habe, möchte ich diese auch testen. Also RESTORE mit dem raspiBackup.sh Skript auslösen.
Nur, wie sollte der Aufruf lauten?

Anbei meine für's Backup verwendete raspiBackup.conf:

# Pfad, um die Backupdatei zu speichern
DEFAULT_BACKUPPATH="/mnt/raspiBackups"
# wie viele Backups
DEFAULT_KEEPBACKUPS=3
# Art der Sicherung: dd, tar, xbmc or rsync
DEFAULT_BACKUPTYPE="rsync"
# Befehle, um Dienste zu beenden, getrennt durch Semicolon ;
DEFAULT_STOPSERVICES="/usr/local/etc/raspiBackupStartStop.sh stop"
# Befehle, um Dienste zu sraten, getrennt durch Semicolon ;
DEFAULT_STARTSERVICES="/usr/local/etc/raspiBackupStartStop.sh start"
......

Hier noch ein Auszug aus der rasperrypi.log:

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 7761919 3819520 83 Linux

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 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 identifier: 0x7082746c

Device Boot Start End Blocks Id System
/dev/sda1 * 1904640 1216630783 607363072 7 HPFS/NTFS/exFAT
/dev/sda2 1216630784 1250260991 16815104 f W95 Ext'd (LBA)
/dev/sda5 1216632832 1229213695 6290432 83 Linux
/dev/sda6 1229215744 1250260991 10522624 83 Linux

Boot = /dev/mmcblk0p1
Root = /dev/sda6

Wie sollte der Aufruf für rsync-Restrore lauten?

Danke + Alles Gute für's 2015

mfg Bernd
#6 Rene 2014-11-18 21:25
...hmm und der Restoreversuch bringt:
root@vdebian:/usr/local/bin# ./raspiBackup.sh -X -d /dev/sdc -r /media/backup
--- vdebian: raspiBackup.sh 0.5.7.9d started at Tue Nov 18 21:20:17 CET 2014 ...
??? /media/backup-backup.sfdisk not found

Im entsprechenden Verzeichnis liegt eine raspberrypi-rsync-backup.sfdisk :cry:
#5 Marko 2014-06-09 13:05
Stimmt, mein Kommentar bezieht sich auf Backupfunktion. Mein Fehler. Kannst Du ihn an die richtige Stelle transferieren oder löschen?
Ich schreibe die genauere Erklarung an die Backup Seite.
#4 framp 2014-06-09 10:25
Vielen Dank Marco für Dein Feedback. Ich nehme das gerne auf. Leider habe ich nicht verstanden was das Problem war und wir Du es gelöst hast. Auch sieht es mir so aus als bezieht sich Dein Kommentar auf die Backupfunktion und nicht auf die Restorefunktion.
#3 Marko 2014-06-09 09:00
sendEmail wollte nicht Email schicken, mit der Meldung:
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!

Das Problem lag in der Zeille:
sendEmail -f meine.email@google.com -t meine.email@google.com -s smtp.gmail.com -u 'raspbmc: raspiBackup completed successfully' -m '--- raspbmc: raspiBackup.sh 0.5.2.7a started at Mon Jun 9 09:08:00 CEST 2014 ...'

Die Emails kommen wieder, nachdem ich in raspiBackup.sh Meldungen "--- raspbmc: raspiBackup.sh 0.5.2.7a started at ..." mit "*** raspbmc: raspiBackup.sh 0.5.2.7a started at ..."
gewechselt habe.

Vielleicht ist das gut zu berücksichten bei Folgenden versionen ...
#2 framp 2014-04-18 17:00
Fuer -d gibt es einen Default der ist sdd und genau das Device, als das eine SDKarte bei meinem Linuxsystem wo ich den Restore ausfuehre erscheint :-* . Wenn Du den Restore auf einer Pi ausfuehrst wo eine USB Platte angeschlossen ist wird das sda sein. Mit Code:sudo fdisk -l bekommst Du raus welche Devices an Deinem System haengen. Aber Vorsicht !!! Wenn Du da z.B. aus Versehen eine lokale Platte nimmst und nicht die SDKarte ... dann zerschiesst Du Dir den Platteninhalt :o
#1 Yannick 2014-04-18 16:26
Hallo framp,

beim restore meines tar backups bekomme ich beim Starten des restores gleich einen Fehler:

https://dl.dropboxusercontent.com/u/1684046/2014-04-18%2016.17.56.jpg

Habe ich die Parameter falsch verwendet?
-X
-d mmcblk02p (rausgefunden df)
-r (Pfad in der die Backupdatein liegen. Wieso könnte das script die Datei nicht finden ? Sie ist doch in dem Ordner...)