RaspiBackup / Verständnisproblem

Gerd1972 · September 7, 2019 at 9:12 AM

Moin Zusammen,

Bevor ich einsteige, Erst mal ne kurze Vorstellung von mir

Bin ein Mittvierziger und vor 8 Wochen zu meinem ersten Raspi gekommen

Mit dem ich meine Photovoltaikanlage auslesen möchte. Dies mache ich mittels Influx und Grafana. Soweit ist auch alles gut und das gute Teil macht was es machen soll.

Für die Sicherung habe ich mich für RaspiBackup entschieden, Danke an framp hierfür

Gestern nach der Installation ausgetestet und gleich gewundert.

Zum Hintergrund - ich Boote meinen PI 3+ von USB. Nach Abschluss war aber das dd Backup aber 32Gbyte groß, obwohl der USB Boot Stick nur 16 GByte hat. Also warum...

Da hatte ich die Idee, das es vlt an dem 2ten USB Stick liegt der ebenfalls eingesteckt war. Diesen abgesteckt und erneut das Backup gefahren . Ergebnis dd Image hat jetzt knapp 15Gbyte.

Aber warum ist das so?

Denn den 2ten Stick möchte ich für ein kontinuierliches Backup der Influx DB nutzen

Kann mir jemand helfen?

Vg Gerd

Bot · Vor 5 Minuten

RaspiBackup / Verständnisproblem? Schau mal ob du hier fündig wirst!

fred0815 · September 7, 2019 at 9:20 AM

Ich habe RaspiBackup noch nicht probiert, aber es gibt sicher Ausnahmen, die man irgendwo eintragen kann.

Gerd1972 · September 7, 2019 at 9:54 AM

Ich sehe es ähnlich, denke er macht ein Vollbackup.

Was ich aber nicht möchte ... möchte einfach nur das eigentliche Image auf dem Stick sichern um es im Fall der Fälle zurück zuspielen

Bot · Vor einem Moment

framp · September 7, 2019 at 9:59 AM

Moin Gerd,

der dd Backup sollte eigentlich wie Du auch richtig vermutest so gross sein wie die root Partition. Ich vermute Dein 2ter USB Stick ist auch 16GB gross. Dann wurden offensichtlich beide USB Sticks gesichert

Ich habe eine Vermutung: Kannst Du mal bitte den Teil aus dem Debuglog posten der mit -> inspect4Backup beginnt und mit <- inspect4Backup endet? Gerne auch per PN wenn Du Bedenken wg der Sensitivitaet der Logdaten hast.

fred0815 Bei tar und rsync kann man beliebige Verzeichnisse excluden. Beim dd Backup sollte nur /dev/mmcblk0 bzw /dev/sda gesichert werden

Gerd1972 · September 7, 2019 at 10:07 AM

framp

20190906-180326 DBG 4069: <- getRootPartition PARTUUID=8978ce14-02

20190906-180326 DBG 4094: -> inspect4Backup

20190906-180326 DBG 4096: -- ls /dev/mmcblk*:

20190906-180326 DBG 4096: --

20190906-180327 DBG 4097: -- ls /dev/sd*:

20190906-180327 DBG 4097: -- /dev/sda

20190906-180327 DBG 4097: -- /dev/sda1

20190906-180327 DBG 4097: -- /dev/sda2

20190906-180327 DBG 4097: -- /dev/sdb

20190906-180327 DBG 4097: -- /dev/sdb1

20190906-180327 DBG 4097: -- /dev/sdb2

20190906-180327 DBG 4098: -- mountpoint /boot: 8:17 mountpoint /: 8:2

20190906-180327 DBG 4105: -- Legacy boot discovery

20190906-180327 DBG 4108: -- part: /dev/sdb1

20190906-180327 DBG 4111: -- bootDeviceNumber: 8:17

20190906-180327 DBG 4112: -- rootDeviceNumber: 8:2

20190906-180327 DBG 4177: -- BOOT_DEVICE: sdb

20190906-180327 DBG 4181: -- BOOT_DEVICENAME: /dev/sdb

20190906-180327 DBG 1585: -> getPartitionPrefix sdb

20190906-180327 DBG 1594: <- getPartitionPrefix sdb

20190906-180327 DBG 4185: -- BOOT_PARTITION_PREFIX: sdb

20190906-180327 DBG 4188: <- inspect4Backup

20190906-180327 DBG 4032: -> commonChecks

20190906-180327 DBG 4051: <- commonChecks

20190906-180327 DBG 2065: -> getFsType /media/nas

20190906-180327 DBG 2071: <- getFsType cifs

20190906-180327 DBG 4325: -- Found partitions on /dev/sdb: 2

20190906-180327 DBG 2088: -> isPathMounted /media/nas

20190906-180327 DBG 2097: -- Path: /media/nas

20190906-180327 DBG 2105: <- isPathMounted 0

--- RBK0151I: Backuppfad /media/nas wird benutzt.

20190906-180327 MSG 4464: --- RBK0151I: Backuppfad /media/nas wird benutzt.

20190906-180327 DBG 3604: -> backup

20190906-180327 DBG 1861: -> executeBeforeStopServices

20190906-180327 DBG 1875: <- executeBeforeStopServices

20190906-180327 DBG 1837: -> stopServices

Gerd1972 · September 7, 2019 at 10:09 AM

framp

und so ohne den 2ten Stick

20190906-200115 DBG 4094: -> inspect4Backup

20190906-200115 DBG 4096: -- ls /dev/mmcblk*:

20190906-200115 DBG 4096: --

20190906-200115 DBG 4097: -- ls /dev/sd*:

20190906-200115 DBG 4097: -- /dev/sda

20190906-200115 DBG 4097: -- /dev/sda1

20190906-200115 DBG 4097: -- /dev/sda2

20190906-200115 DBG 4098: -- mountpoint /boot: 8:1 mountpoint /: 8:2

20190906-200115 DBG 4105: -- Legacy boot discovery

20190906-200115 DBG 4108: -- part: /dev/sda1

20190906-200115 DBG 4111: -- bootDeviceNumber: 8:1

20190906-200115 DBG 4112: -- rootDeviceNumber: 8:2

20190906-200115 DBG 4177: -- BOOT_DEVICE: sda

20190906-200115 DBG 4181: -- BOOT_DEVICENAME: /dev/sda

20190906-200115 DBG 1585: -> getPartitionPrefix sda

20190906-200115 DBG 1594: <- getPartitionPrefix sda

20190906-200115 DBG 4185: -- BOOT_PARTITION_PREFIX: sda

20190906-200115 DBG 4188: <- inspect4Backup

20190906-200115 DBG 4032: -> commonChecks

20190906-200115 DBG 4051: <- commonChecks

20190906-200116 DBG 2065: -> getFsType /media/nas

20190906-200116 DBG 2071: <- getFsType cifs

20190906-200116 DBG 4325: -- Found partitions on /dev/sda: 2

20190906-200116 DBG 2088: -> isPathMounted /media/nas

20190906-200116 DBG 2097: -- Path: /media/nas

20190906-200116 DBG 2105: <- isPathMounted 0

--- RBK0151I: Backuppfad /media/nas wird benutzt.

20190906-200116 MSG 4464: --- RBK0151I: Backuppfad /media/nas wird benutzt.

Bot · Vor einem Moment

framp · September 7, 2019 at 10:17 AM

Gerd1972 Danke. Meine Vermutung ist falsch

Man sieht dass Du zwei USB Sticks /dev/sda und /dev/sdb hast wobei /dev/sda Dein OS beherbergt.

Bist Du sicher dass Dein USB Stick nur 16GB hat oder ist es so dass Deine Root Partition 16GB hat, aber noch weitere 16GB auf dem USB Stick frei sind?

Kannst Du mal die Ausgaben zeigen von

Code

sudo parted /dev/sdb print
sudo parted /dev/sda print

PS: Noch einen Hinweis. Bitte benutze Code Tags fuer Deine Ausgaben (Ist das Icon </>). Dann lesen sich die Ausgaben leichter

Gerd1972 · September 7, 2019 at 10:27 AM

Code

~# sudo parted /dev/sdb print
Error: Could not stat device /dev/sdb - Datei oder Verzeichnis nicht gefunden.
Retry/Cancel? r
Error: Could not stat device /dev/sdb - Datei oder Verzeichnis nicht gefunden.
Retry/Cancel? rc
parted: invalid token: rc
Retry/Cancel? c
root@solaranzeige:~# sudo parted /dev/sda print
Model: SanDisk Ultra Fit (scsi)
Disk /dev/sda: 15,4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  273MB   268MB   primary  fat32        lba
 2      277MB   15,4GB  15,1GB  primary  ext4

Display More

auf sdb abgefragt kommt ein fehler, da der Stick gezogen ist

Code

~# df -h
Dateisystem                                               Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root                                                   14G    3,4G  9,9G   26% /
devtmpfs                                                   459M       0  459M    0% /dev
tmpfs                                                      464M     12M  452M    3% /dev/shm
tmpfs                                                      464M     13M  451M    3% /run
tmpfs                                                      5,0M    4,0K  5,0M    1% /run/lock
tmpfs                                                      464M       0  464M    0% /sys/fs/cgroup
/dev/sda1                                                  253M     40M  214M   16% /boot
tmpfs                                                       93M       0   93M    0% /run/user/1000
//192.168.178.1/fritz.nas/Samsung_SSD_840_250Gbyte/Backup  234G    104G  131G   45% /media/nas
tmpfs

Display More

ich sage schon mal danke

RTFM · September 7, 2019 at 10:37 AM

Du solltest einen Stick nicht einfach abziehen, immer "sicher entfernen" (auch unter Windows)

Servus !

Bot · Vor einem Moment

framp · September 7, 2019 at 10:43 AM

Liest sich jetzt besser mit den Code Tags.

Kannst Du noch mal den zweiten USB Stick einstecken und

Code

sudo parted /dev/sdb print
df -h
sudo blkid

zeigen?

Ausserdem noch eine Ausgabe von Deinem Backup img:

Code

sudo fdisk -l <BACKUP-VERZEICHNIS>/<hostname>-dd-backup-<DATUM>.img

Gerd1972 · September 7, 2019 at 10:53 AM

Stimmt liest sich besser

Code

part 1

~# sudo parted /dev/sdb print
Model: SMI USB DISK (scsi)
Disk /dev/sdb: 31,5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

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

Display More

II

Code

# df -h
Dateisystem                                               Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root                                                   14G    3,4G  9,9G   26% /
devtmpfs                                                   459M       0  459M    0% /dev
tmpfs                                                      464M    9,8M  454M    3% /dev/shm
tmpfs                                                      464M     13M  451M    3% /run
tmpfs                                                      5,0M    4,0K  5,0M    1% /run/lock
tmpfs                                                      464M       0  464M    0% /sys/fs/cgroup
/dev/sdb1                                                   30G     64K   30G    1% /boot
tmpfs                                                       93M       0   93M    0% /run/user/1000
tmpfs                                                       93M       0   93M    0% /run/user/0
//192.168.178.1/fritz.nas/Samsung_SSD_840_250Gbyte/Backup  234G    104G  131G   45% /media/nas

Display More

III

Code

~# sudo blkid
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="0C61-73F5" TYPE="vfat" PARTUUID="8978ce14-01"
/dev/sda2: LABEL="rootfs" UUID="43f2d0bb-83be-464f-94d0-9a751f376c64" TYPE="ext4" PARTUUID="8978ce14-02"
/dev/sdb1: LABEL="USB-1" UUID="E45D-DB14" TYPE="vfat" PARTUUID="8978ce14-01"

framp · September 7, 2019 at 11:03 AM

Jetzt haben wir die Ursache

raspiBackup hat ein Backup von Deinem zweitem USB Stick gemacht der auch 32GB gross ist .

Der Grund liegt hier drin:

Code

/dev/sdb1                                                   30G     64K   30G    1% /boot

Du hast Deinen 32Gb Stick in /boot gemounted. Dort muss /dev/sda1 stehen. Dann sichert raspiBackup auch Deinen 16GB Stick.

Code

mount

liefert bei mir bei einem USB gebooteten System

Code

/dev/sda2 on / type ext4 (rw,noatime)
...
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
...

Bot · Vor einem Moment

Gerd1972 · September 7, 2019 at 11:08 AM

IV

Code

Disk /.../...////dd-backup-20190906-180320.img: 29,3 GiB, 31457280000 bytes, 61440000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8978ce14

Device                                                         Boot  Start      End  Sectors  Size Id Type
/dd-backup-20190906-180320/...//dd-backup-20190906-180320.img1        8192   532480   524289  256M  c W95
/dd-backup-20190906-180320/...//dd-backup-20190906-180320.img2      540672 15417343 14876672  7,1G  c W95

ich hab mir erlaubt, die Pfade (/...//../) ein wenig anzupassen, sonst hätte ich es Hockkant schicken müssen

Gerd1972 · September 7, 2019 at 11:14 AM

Man jetzt fällt der Groschen!

Sorry !!!

Den 32er Stick hatte ich vorher zum Booten verwendet. Die Daten darauf, nach dem Wechsel auf den 16er auch gelöscht.

Gerade habe ich ihn unter Windows neu formatiert, das Backup stoße ich noch mal an und werde berichten

Noch einmal Danke für Deine Unterstützung. Bin seit knapp 20 jahren raus und noch nicht ...ganz zurück

framp · September 7, 2019 at 11:34 AM

Quote from Gerd1972

Noch einmal Danke für Deine Unterstützung. Bin seit knapp 20 jahren raus und noch nicht ...ganz zurück

NP. Ist immer wieder interessant was doch so fuer Probleme mit raspiBackup auftreten

Im fdisk von dem Backup sieht man auch einen der Nachteile des dd Backups: Es werden nur 8GB in der Rootpartition benutzt, aber der ganze USB Stick mit 32GB gesichert. Wenn Du etwas aehnliches bei Deinem 16GB Stick hast solltest Du FAQ16 lesen. Alternativ pishrink einsetzen.

Bot · Vor einem Moment

Gerd1972 · September 7, 2019 at 1:38 PM

Das Problem besteht weiterhin, auch nach dem Formatieren des Sticks

wenn beide USB Sticks gesteckt sind sichert er diese beiden

Auf der Suche nach der Ursache via df -h bin ich auf Fstab gekommen, dort sind zu Anfang folgende Einträge:

proc /proc proc defaults 0 0

PARTUUID=8978ce14-01 /boot vfat defaults 0 2

PARTUUID=8978ce14-02 / ext4 defaults,noatime 0 1

Code

proc /proc proc defaults 0 0

PARTUUID=8978ce14-01 /boot vfat defaults 0 2

PARTUUID=8978ce14-02 / ext4 defaults,noatime 0 1

Die PARTUUID ist genau die des 2ten Sticks, der nicht zum boot gemounted werden soll

Wie die da rein kamen mir ein Rätsel ...

Also dachte ich mir, ich kommentiere die beiden Zeilen aus und ich bin das Problem los ...nix wars ...der raspi war im read-Only Mode

Alle Prozesse ließen sich durch den RO Mode nicht starten

Wohl mit mehr Glück, als Wissen, ist es mir gelungen die beiden PARTUUID Einträge wieder auf aktiv zu setzen und der raspi läuft wieder

Jetzt frage ich Euch, bevor ich mich noch einmal selber aussperre, muss hier die UUID des eigentlichen USB Sticks rein??

Vg Gerd

framp · September 7, 2019 at 2:12 PM

Code

~# sudo blkid
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="0C61-73F5" TYPE="vfat" PARTUUID="8978ce14-01"
/dev/sda2: LABEL="rootfs" UUID="43f2d0bb-83be-464f-94d0-9a751f376c64" TYPE="ext4" PARTUUID="8978ce14-02"
/dev/sdb1: LABEL="USB-1" UUID="E45D-DB14" TYPE="vfat" PARTUUID="8978ce14-01"

Aus irgendeinem Grund haben Deine beiden USB Sticks dieselbe UUID. Du musst die von /dev/sdb aendern. Das geht mit

Code

sudo fdisk /dev/sdb

und dem extended Menu (x) und (i) und stellst da eine zufaellige achtstellige Hexnummer rein die Du vorher mit

Code

od -A n -t x -N 4 /dev/urandom

erstellt hast.

Oder Du benutzt den Oneliner. Ich wuerde es aber an Deiner Stelle manuell machen. Der Lerneffekt ist groesser

Code

echo -ne "x\ni\n0x$(od -A n -t x -N 4 /dev/urandom | tr -d " ")\nr\nw\nq\n" | sudo fdisk /dev/sdb

RTFM · September 7, 2019 at 3:10 PM

Auf einem Linux Host muss die Ausgabe von < lsblk -o name,partuuid,uuid > einmalig sein.

Wird ein ganzes Device - Image mit dd übertragen, wird auch die partuuid (der MBR/GPT-Partitions-Tabel) und die uuid (jedes Filsystems) "kopiert". Wenn beide Images gleichzeitig betrieben werden, muss der Admin dafür sorgen, dass die "einmaligen"IDs wieder einmalig werden und die cmdline.txt und die /etc/fstab berichtigt werden.

Servus !

Bot · Vor einem Moment

framp · September 7, 2019 at 4:24 PM

RTFM Ein Problem gibt es ja nur wenn die Partitions zusammen an einem System vorhanden sind. So ist das restorte Image identisch zur Source bzgl UUIDs. Bislang hatte auch noch nie jemand deswegen Probleme - ausser der TE jetzt

Momentan laesst raspiBackup die beiden UUIDs unveraendert. Ich denke ich baue das mal ein dass diese beiden immer beim Restore veraendert werden. Oder sollte es besser ueber eine Option gesteuert werden koennen? Dann ist die Frage was ein vernuenftiger Default ist: UUIDs aendern oder beibehalten?

**hyle** · September 7, 2019 at 4:34 PM Official Post

framp

Der eingebaute Kopierer überlässt dem User die Wahl. Das ist die flexiblere und imho bessere Lösung als eine statische, unveränderbare Einstellung, zumindest aus Usersicht.

Participate now!