Tar gibt es auch für Windows.
Die Sache ist aber die, dass Windows nur seine "eigenen" Filesysteme unterstützt, Linux/Unix aber weitere rd. 20 Filesysteme mounten und verwenden kann, u.A. Ext4, das für die root Partition beim Pi verwendet wird.
Servus !
Dazu musst Du erstmals wissen, welches Filesystem Du mounten willst.
Im Regelfall wird das mit der Mount-Option uid=, gid= eingestellt. Siehe < man mount >.
Servus !
Versuche gerade im Netz eine Lösung zu finden, da tune2fs nicht funzt
Warum verwendest Du nicht die "man pages" auf Deinem System ?
Die PARTUUID befindet sich in den Metadaten des Gerätes aka: Partition Table, MBR/GPT und wird beim Partitionieren eines Block-Devices angelegt.
UUID und LABEL werden in den Metadaten einer Partition beim Formatieren angelegt. Damit lässt sich eine Partition auch mounten/starten.
Der Linux (Host-)Admin ist dafür verantwortlich, dass unique (einmalige) IDs auch tatsächlich einmalig sind.
Servus ! - oha, zu spät
/dev/mmcblk0p1: PARTUUID="06b49ab7-01"
/dev/sda1: PARTUUID="06b49ab7-01"
UUID und PARTUUID müssen einmalig sein.
Das ist bei den Partitionen der MMC/SD und /dev/sda (Stick/HD) nicht der Fall.
Servus !
Das (eher nein) bezog sich auf die verwendete Forensoftware, die auf einer weltweiten Robot- to do List eher weiter hinten steht.
In Indien sitzen massenhaft Leute vor dem PC und lösen Capchas für einen Dollar/Tag.
Und in Mittel-/Südamerika ist die menschliche Arbeitsleistung nur marginal teurer.
Und (eher nein) heisst ja auch nicht, dass es kein Robot war. Dann sollten aber weitere derartige Posts folgen.
Servus !
PS: Ich habe den Link auch nicht angeklickt. Wer weiss, ob sich überhaupt Malware darauf befindet.
ich habe die Links nicht angeklickt.
Damit hast Du Dir 1 BitCoin, oder 1 komplettes Restore möglicherweise erspart.
Der Thread wurde sicher über einen Robot gefunden. Ob die Registrierung (von heute) auch vollautomatisch erfolgte, weiss ich nicht (eher nein). Die URL zeigte Richtung Panama.
Servus !
Das lässt sich sicher noch viel kompllzierter planen, Du musst aber vorerst wissen wie Du das WLAN Kabel von der Garage zum Kühlschrank verlegst.
Servus !
Und warum machst Du nicht einen manuellen Mount mit der verbose und fake (=cold run) Option und änderst Servereinstellungen und mount Befehl bis es vorerst fehlerfrei passt ?
sudo mount -vf -t nfs 192.168.178.XX:/volume1/Raspberry_Backup/Pool /mnt/mntVerzeichnis
Mit -v lässt Du Dir erklären, was geschieht, oder falsch läuft.
Mit -f startest Du einen Probelauf, ohne abschiessendem syscall (Sytemaufruf), sodass Du nicht jedesmal ein umount nach einem misslungenen mount ausführen musst.
Dass Dein Linux man-pages hat, wo alles beschrieben ist, hast Du schon gelernt ?
Servus !
< man udev > und die dortigen SEE ALSO.
Servus !
ED: google "linux udev"
Wenn Du das Datenblatt zur Hand nimmst, benötigt der Sensor in der 12-Bit Auflösung für den abgefragten Messvorgang bis 750 ms, sodass entsprechende Pausen bei der Abfrage zu berücksichtigen sind.
Fraglich ist, ob Du die werksmässig voreingestellte 12 Bit Auflösung (Auflösung 0,0625 °C) überhaupt brauchst, aber das ist ein anderes Kapitel,
Um einen verlässlich brauchbaren Wert zu erhalten, solltest Du mehrere Messingen hintereinander vornehmen, die Extremwerte verwerfen und mit dem Rest einen Mittelwert ziehen.
Ob Deine Sensoren, oder Dein Multimeter falsche Werte liefert, geht, mangels Gegenüberstellung der Werte, ais Deiner Schilderung nicht hervor. Vor der ersten Messwertwandlung beträgt nach einem Reset die Temperatur (im Sensor-Scratchpad) 85 °C. Eine Abwerichung von 10 °C des Sensorwertes von der Ist-Temperatur ist eigentlich technisch nicht möglich. Ein Bitfehler bei der Datenübertragung wird durch eine CRC Prüfung abgefangen.
Das 1-wire Treiber Modul wird durch Eintrag in die /boot/config.txt aktiviert. Da hat sich im Laufe der Zeit etwas verändert, sodass es möglich sein kann, dass eine ältere "Anleitung" nicht mehr aktuell ist. Aber auch das würde eine 10 °C Abweichung des Messwertes nicht ermöglichen.
Servus !
das unterschreibe ich mal so. Zurückschreiben, fertig. Für rsync brauchst Du ja immer ein FS, was die Rechte abbilden kann. Hat nicht jeder.
Ja, aber tar kann alles, auch das Anhängen der geänderten Dateien an ein bereits vorhandenes tar Archiv, das auf einem Netzlaufwerk oder einer NTFS Partition liegen kann. Warum tar am Pi nicht öfters zum Einsatz kommt, weiss ich nicht.
Servus !
Ich frage mich auch immer warum so viele dd bzw ddz benutzen.
Das dient auch mehr dem ruhigen Gewissen ("Ich habe eh was getan"). Wenn die wüssten, dass die dd - Sicherung teilweise gar nicht funktioniert. Z.B. wenn ein (dateiintensiver) Cronjob beim dd-en läuft, Von den Badblocks rede ich noch gar nicht.
Dein raspiBackup hat sich ja inzwischen schon ganz schön gemausert. Aber ohne lesen der Dox (die hervorragend sind) kommt ein leseggeschwächter Windower halt auch nicht zurecht, und er greift zu dem, was halt "funktioniert".
Servus !
@RTFM
Bei dem Konventionellen Backup wird ja immer die ganze SD-Karte kopiert und nicht nur der Teil mit Daten.
Dafür ist doch PiShrink gedacht?
Ein Speicherabbild vom ersten bis zum letzten Sektor einer HD/SD zu ziehen ist schonmal kein konventionelles Backup. Das machen nur Datenforensiker und pi User.
Pi-User deshalb, weil der "Hauptrechner" auf Windows läuft und der mit Linuxfiles ind -Partitionen nicht umgehen kann und deshalb als Workaround für eine Komplettsicherung der gesamte Speicher der SD als Speicherabbild verwendet wird.
Bei einem konventionellen Backup wird üblicherweise tar oder rsync verwendet.
Servus !
Auf eine 8 GB SD hast Du ein Original Image (Raspian Light ?)
Disk /home/pi/backup/piager/betarelease_Denni.img: 7,3 GiB, 7820279808 bytes, 15273984 sectors
Units: sectors of 1 * 512 = 512 bytes
Device Boot Start End Sectors Size I d Type
P Nr1 8192 93236 85045 41,5M c W95 FAT
P Nr2 94208 3862527 3768320 1,8G 8 3 Linux
Weil die Root Partition Nr.2 so klein ist, dass sie nicht weiter verkleinert werden kann, beendet sich pishrink in Zeile 226 (#111)
Die Filegrösse würde aber erst danach berichtigt (Zeile 279) und daher nicht mehr abgearbeitet.
Jetzt hast Du manuell das Fileende auf 1977614336 Bytes, Sektor 3862528 gesetzt und jetzt sollte fdisk
am Anfang
Disk /home/pi/backup/piager/betarelease_Denni.img: 1,9 GiB, 1977614336 bytes, 3862528 sectors
stehen.
Kleiner gehts nur mehr, wenn Du betarelease_Denni.img noch kompromierst.
Normalerweise wird bei der Einrichtung/Installatuin einer 8 GB Karte das root Filesystem auf die 8 GB Grenze ausgedehnt und nicht auf der Grenze des Installations Image, 1,8 GB, belassen.
Servus !
@ root@rpi-Pi-Ager:sudo /usr/local/bin/pishrink.sh /home/pi/backup/betarelease_Denni.img
Wenn pishrink mit nur einem Filenamen aufgerufen wird [/home/pi/backup/betarelease_Denni.img] wird das File selbst geshrinkt.
Ein bereits einmal geshrinktes File kann nicht nochmals geschrinkt werden --> Image already shrunk to smallest size.
root# sudo ... funktioniert nur dann verlässlich fehlerfrei, wenn der User root in die sudoers aufgenommen wird :)
Was ist denn die Ausgabe von:< sudo fdisk -l /home/pi/backup/betarelease_Denni.img >
Servus !
Und weiterhin gibt es keine Kernel-Panik. Das System selbst laeuft dann noch. Nur die SD-Karte ist nicht mehr ansprechbar.
Das EXT4 Filesystem löst eigentlich kein Kernel-Panic aus.
Im EXT4 Error Behavior ist bei den Pi-Distris "continue" oder "remount ro" voreingestellt. Die "panic" Option muss der Admin selbst einstellen, (genauso den Check-Intervall bei 24/7/365 laufenden Systemen)
Mit .< dumpe2fs -h /dev/xxxx > oder < tune2fs -l /dev/xxxx > ist der EXT4 Superblock-Header für den Admin einsehbar.
Servus !
Wenn in den Logfiles kein Hinweis auf den Fehler abgelesen werden kann, würde ich das Netzteil wechseln.
Verwaiste Prozesse, die den Speicher langsamm füllen (bis er überläuft), sollten auch mit < ps aux > erkennbar sein. Dann hättest Du aber in mehreren Scripts (Sommer und Winter) Schleifenfehler eingebaut.
Servus !
Ja, habe ich. Gleiche Einstellungen wie bei den anderen beiden Systemen ...
Das sagt gar nichts. Der 3B+ hat eine andere Firmware und damit abweichende Module und Bootparameter.
Vllt. hilft Dir das https://www.raspberrypi.org/forums/viewtopic.php?t=170214
Der serielle Port /dev/ttyUSB0 darf nicht schon von einem anderen Programm benützt werden, wenn Du minicom darauf verbindest. < ps aux > zeigt in der TTY Spalte die verwendeten Devices an.
Servus !
crw-rw---- 1 root dialout 188, 0 Okt 3 10:14 /dev/ttyUSB0
hast Du als Schnittstelle im minicom eingestellt ?
Servus !
