Beiträge von Peety
-
-
Ja... da lag auch schon der fehler... copy and paste zwei mal UUIDD=UUIDD
-
Hallo,
ich habe irgendwie keine Berechtigung obwohl ich lauf Franjo's Anleitung eigentlich alles machen können soll.
Franjo G was mache ich falsch ?
Raspberry Pi 4B REV 1.1 Linux raspberrypi 5.10.17-v7l+
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
Windows 10
-
Wie bescheuert ist denn das nun bitte....
Ich schließe einen USB Stick an, richte den ein, mache und tue, bekomme ihn nicht gemounted, raspian rastet völlig aus und wirft scheinbar mountpoints durcheinander?
Es sind BEIDE Devices verbunden zum Backup fahren habe allerdings ja EIGENTLICH die 500GB ext 2,5er HDD!
raspiBackup macht das Backup! Mit beiden Devices... wo zum Teufel verbindet er hin?! Wie geht das ganze im Hintergrund ?
Scheinbar schreibt er auf die HDD (rot markiert unten im Quellcode)
Ich ziehe eins der Geräte ab: Alles kaputt macht nichts mehr Ich glaube ich besorge mir mal ne anständige HDD mit externer stromversorgung OHNE Hub und teste dann nochmalAi ai ai ist das eine SCH.... öne Sache!
Code
Alles anzeigenroot@raspberrypi:~# raspiBackup --- RBK0009I: raspberrypi: raspiBackup V0.6.5.1 (9cc17fc) Mi 11. Nov 23:08:01 GMT 2020 gestartet. --- RBK0128I: Logdatei ist /media/peet-cloud-backup/raspberrypi/raspberrypi-rsync-backup-20201111-230800/raspiBackup.log. --- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt. --- RBK0151I: Backuppfad /media/peet-cloud-backup wird benutzt. --- RBK0008I: Services werden gestoppt: 'systemctl stop mariadb && systemctl stop cron && systemctl stop apache2'. --- RBK0081I: Backup vom Typ rsync wird in /media/peet-cloud-backup/raspberrypi/raspberrypi-rsync-backup-20201111-230800 erstellt. --- RBK0036I: Partitionslayout wird gesichert. --- RBK0044I: Backup der Bootpartition wird in /media/peet-cloud-backup/raspberrypi/raspberrypi-rsync-backup-20201111-230800/raspberrypi-backup.img erstellt. 256+0 Datensätze ein 256+0 Datensätze aus 268435456 bytes (268 MB, 256 MiB) copied, 8,20934 s, 32,7 MB/s --- RBK0044I: Backup des Partitionlayouts wird in /media/peet-cloud-backup/raspberrypi/raspberrypi-rsync-backup-20201111-230800/raspberrypi-backup.sfdisk erstellt. --- RBK0046I: Backup des Masterbootrecords wird in /media/peet-cloud-backup/raspberrypi/raspberrypi-rsync-backup-20201111-230800/raspberrypi-backup.mbr erstellt. --- RBK0133I: Verzeichnis /media/peet-cloud-backup/raspberrypi/raspberrypi-rsync-backup-20201111-230017 wird für Hardlinks benutzt. --- RBK0158I: rsync Backup "/media/peet-cloud-backup/raspberrypi/raspberrypi-rsync-backup-20201111-230800" wird erstellt. --- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld. --- RBK0078I: Backupzeit: 00:02:02. --- RBK1001I: Speicherauslastung - Vor dem Backup - Belegt: 69 MB Frei: 2916 MB - Nach dem Backup: Belegt: 71 MB Frei: 167 MB --- RBK1000I: CPU Temperatur vor und nach dem Backup: 64.0'C - 66.0'C --- RBK1002I: Partitionsauslastung vor dem Backup: Belegt: 3.56 GiB Frei: 430.57 GiB --- RBK1003I: Partitionsauslastung nach dem Backup: Belegt: 6.00 GiB Frei: 428.14 GiB --- RBK1004I: Änderung freier Platz: -2.43 GiB (0,00 %) --- RBK0007I: Services werden gestartet: 'systemctl start apache2 && systemctl start cron && systemctl start mariadb'. --- RBK0159I: 3 Backups werden für den Backuptyp rsync aufbewahrt. --- RBK0205I: Ältestes Backup /media/peet-cloud-backup/raspberrypi in wird gelöscht. Das kann etwas dauern. Bitte Geduld.
-
/media/peet-cloud-backup/backup
Normalerweise nicht.
Lass mal den letzten / weg
wie hast du die platten angeschlossen? Direkt am Pi oder mit einem usb-Hub
HUB - Sonst zu wenig Strom --- zumindest unter Last
Das mit dem letzten / hatte ich schon probiert. Negativ...
-
Muss ich noch ein Verzeichnis erstellen auf der Partition ? --- NEIN...?
Rechte?
Festplatte im Anus?
Ich versuche mal nen Stick ... -
-
Das sieht alles ok aus.
Normalerweise müsste die platte so gemounte werden.
Mounte mal manuell.
sudo mount -t ext4 /dev/sdb1 /media/peet-cloud-backup
und schaue dann nochmal mit lsblk nach ob die platte gemountet ist.
Jetzt hat er sie... aber wieso??? beim booten hat er sie auch gehabt...
Codelsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk └─sda1 8:1 0 931,5G 0 part /media/peet-cloud sdb 8:16 0 465,8G 0 disk └─sdb1 8:17 0 465,8G 0 part /media/peet-cloud-backup mmcblk0 179:0 0 29,7G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 29,5G 0 part /
(Handybild, Monitor mal angeklemmt)
seltsam liegt wohl an dem ollen USB-3 device für die externe Stromversorgung...
-
-
Den Pi neustarten,
mit lsblk überprüfen, ob die platte gemountet ist.
Wenn ja, kannst du raspiBackup nochmal starten.
raspiBackupInstallUI.sh nochmal aufrufen um config zu machen Ich bin gespannt Mensch ich lerne richtig was, das macht spaß So mal abwarten:) Danke erstmal soweit
-
Ja, in der /etc/fstab die PAARTUUID ändern.
Dann STRG O (Otto) ENTER
STRG X verlassen?Siehe oben Franjo G
-
Code
root@raspberrypi:/media# ls -lisa /media insgesamt 16 24002 4 drwxr-xr-x 4 root root 4096 Nov 11 15:51 . 2 4 drwxr-xr-x 23 root root 4096 Nov 11 15:40 .. 2 4 drwxr-xr-x 5 root root 4096 Nov 8 19:56 peet-cloud 128013 4 drwxrwx--- 2 root root 4096 Nov 11 15:16 peet-cloud-backup
Nun nochma mit raspibackup versuchen? Oder noch was anderees testen? Franjo G
-
richtig, mit "w" wird das ganze erst ausgeführt.
Zeig jetzt bitte noch mal die Ausgabe von blkid
Code/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat" PARTUUID="2fae3b36-01" /dev/mmcblk0p2: LABEL="rootfs" UUID="2887d26c-6ae7-449d-9701-c5a4018755b0" TYPE="ext4" PARTUUID="2fae3b36-02" /dev/sda1: UUID="347c7858-f3e2-4ad1-aedc-95fb488d51e8" TYPE="ext4" PARTLABEL="primary" PARTUUID="186b8b61-2fed-4c33-8d4a-e724910d9a84" /dev/mmcblk0: PTUUID="2fae3b36" PTTYPE="dos" /dev/sdb1: UUID="18a89476-52c3-4216-a420-40d7fb770e5e" TYPE="ext4" PARTUUID="d97b3d30-01"
Die PARTUUID sieht "kürzer" aus liegt das daran, dass die Platte vorher mal BTRFS war? und die peet-cloud deshalb eine lange PARTUUID hat?
Nun vermutlich wieder den fstab-Eintrag schreiben mit nano /etc/fstab
STRG O (Otto)
STRG X verlassen? -
Code
Alles anzeigenCommand (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-976773163, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-976773163, default 976773163): Created a new partition 1 of type 'Linux' and of size 465,8 GiB. Command (m for help): quít root@raspberrypi:/home/XXXX# nano /etc/fstab root@raspberrypi:/home/XXXXX# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk └─sda1 8:1 0 931,5G 0 part /media/peet-cloud sdb 8:16 0 465,8G 0 disk mmcblk0 179:0 0 29,7G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 29,5G 0 part /
Mhhhh wieso taucht sdb1 nicht auf?
AHHHHH AM ende nicht QUIT sondern W ... OKay... learned:)
CodeNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk └─sda1 8:1 0 931,5G 0 part /media/peet-cloud sdb 8:16 0 465,8G 0 disk └─sdb1 8:17 0 465,8G 0 part mmcblk0 179:0 0 29,7G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 29,5G 0 part /
Nun Partition erstellen
Code
Alles anzeigenroot@raspberrypi:/home/XXXX# sudo mkfs.ext4 /dev/sdb1 mke2fs 1.44.5 (15-Dec-2018) Creating filesystem with 122096389 4k blocks and 30531584 inodes Filesystem UUID: 18a89476-52c3-4216-a420-40d7fb770e5e Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done
-
Code
Alles anzeigenCommand (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-976773163, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-976773163, default 976773163): Created a new partition 1 of type 'Linux' and of size 465,8 GiB. Command (m for help): quít root@raspberrypi:/home/XXXX# nano /etc/fstab root@raspberrypi:/home/XXXXX# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk └─sda1 8:1 0 931,5G 0 part /media/peet-cloud sdb 8:16 0 465,8G 0 disk mmcblk0 179:0 0 29,7G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 29,5G 0 part /
Mhhhh wieso taucht sdb1 nicht auf?
-
Ich würde die Partition erst einmal löschen, neu erstellen und dann mit ext4 formatieren
wird getestet
Danke
-
jetzt habe ich doof gemacht habe ausversehen die ganze Platte gemäht..
es gibt kein sdb1 mehr weil ich folgendes gemacht habe:
Nun sieht das so aus
Coderoot@raspberrypi:/home/XXXX# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk └─sda1 8:1 0 931,5G 0 part /media/peet-cloud sdb 8:16 0 465,8G 0 disk mmcblk0 179:0 0 29,7G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 29,5G 0 part /
Codeblkid /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat" PARTUUID="2fae3b36-01" /dev/mmcblk0p2: LABEL="rootfs" UUID="2887d26c-6ae7-449d-9701-c5a4018755b0" TYPE="ext4" PARTUUID="2fae3b36-02" /dev/sda1: UUID="347c7858-f3e2-4ad1-aedc-95fb488d51e8" TYPE="ext4" PARTLABEL="primary" PARTUUID="186b8b61-2fed-4c33-8d4a-e724910d9a84" /dev/mmcblk0: PTUUID="2fae3b36" PTTYPE="dos" /dev/sdb: UUID="f2ce9ca8-e248-4d6a-87dd-d665fc146733" TYPE="ext4"
Das System war mal vorher irgendwann dank NextcloudPI BTRFS allerdings hatte ich das auch schon mal mit raspiBackup am laufen und sogar bereits ein Backup gefahren gehabt!
nur, da der Raspi 4 nicht zwei 2,5er Platten gleichzeitig mit strom versorgen mag, habe ich nun einen Hub zwischen geklemmt mit externen Stromversorgung, DANN neu ext4 formatiert, dann versucht wieder mit raspiBackup drauf zu zugreifen,Siehe Oben.
-
-
-