SSD 256GB - davon nur 16GB nutzen im RasPi4

wie oben schon erwähnt ist das image deiner sd karte halt nur so groß wie die sd-karte. daher muss man zunächst die partition vergrößern und danach das dateisystem vergrößern. wichtig ist.
bei raspberry ist diese funktion bereits im config-programm eingebaut. das macht dir alles vollautomatisch. vgl den 1.link
bei anderen bevorzuge ich eigentlich was grafisches (gparted). aber wenn kein desktop isntalliert ist (deswegen aber nicht nachträglich installieren) dann geht es auch über die shell. vgl den 2.link

Homoran

@oliverio sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

expanding-the-root-partition-of-the-sd-card/

will er doch gar nicht.

er will seine Platte klonen, aber nicht die Platte, sondern nur die Installation :-)

OliverIO

@homoran
ach er will das andersrum? normalerweise wollen die leute immer von sd karte nach ssd umziehen
ich glaube bei extX-Dateisystemen kann man nicht verkleinern.
https://wiki.ubuntuusers.de/Dateisystemgröße_ändern/#Dateisysteme-und-ihre-Eigenschaften
korrektur: nur wenn das image nicht gemounted ist.

aber besser er macht backitup, da ist ja alles drin. image ist meist verschwendeter speicherplatz wenn die festplatte/karte nicht voll ist

Homoran

@oliverio sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

ach er will das andersrum?

auch nicht ganz ;-)
er will seine SD auf eine Partition der SSD klonen
(oder nur die Partition der SSD klonen)

HerrFrodo

@homoran Hey, Du verstehst mich ja doch!
Ich fühle mich geschmeichelt :-)

Genau! Ich möchte die SSD nutzen, weil sie eh da ist und weil sie schneller ist und vielleicht auch noch sichererererererer. Das bitte jetzt aber nicht diskutieren, denn ich bin auch noch ein spielmops....

Also: Die SSD soll für den Raspi und dessen Backup nicht größer sein als eine 16GB MicroSD.
Das erzeugte Backup schob bisher raspi-backup (ok, mit DD) ohne irgendwas kurzzeitig zu beenden, auf die SynologyNAS.
Gibt es ein Problem, dann möchte ich das Backup von der Syno per Win32DiskImager innerhalb von ein paar Minuten (SSD dauert 3min) auf eine MicroSD flashen (dauert glaube 8min).
Geflashte MicroSD in den Raspi, SSD abklemmen und schauen was los ist.....oder so.

:-)

OliverIO

@herrfrodo

mit welchem programm hast du von der ssd ein image erstellt?
du hast dann wahrscheinlich einfach die ganze ssd ausgewählt und nicht nur die partition.
falls das programm das nicht kann, dann musst du dd nehmen.
so wie @MartinP oben schon geschrieben hat
bspw anstatt sda (ist der ganze speicher) nur sda1 (ist nur die partition) auswählen/angeben.

HerrFrodo

@oliverio ich habe bisher von der SSD kein Image gemacht.
Ich habe eine bestehende Installation per raspi-backup von framp (darin per DD) auf einen Ordner der SynologyNAS, täglich und per NFS, sichern lassen.
Das raspi-backup Image habe ich per Win32 DiskImager auf die SSD geflashed.
Dann ist irgendwas passiert - möglicherweise ich selbst - und es lief nicht mehr.
Ach ja, ich habe dummerweise in raspi config die Speicherplatzerweiterung aktiviert (obwohl ja vorher schon die Backupdatei seit Inbetriebnahme der SSD 256GB groß war)
Danach funktionierte ioBroker nicht mehr und rödelte sich tot.

HerrFrodo

Das hier könnte mir gefallen:
https://www.linux-tips-and-tricks.de/de/einstieg/13-raspberry/427-raspibackup-sh-und-benutzung-von-synology-als-backupspace

"Konfiguration einer Synology und der Raspberry um ein rsync Backup per nfs auf einer Synology zu sichern"

Homoran

@herrfrodo sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

vielleicht auch noch sichererererererer.

eine

@herrfrodo sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

16GB MicroSD.

ist da schon grenzwertig
da werden zu oft die selben Zellen beschrieben.

32 oder 64GB wären da sicherer und kosten auch nicht die Welt.

HerrFrodo

@homoran said in SSD 256GB - davon nur 16GB nutzen im RasPi4:

eine

reicht doch - wenn was ist, dann könnte ich ja immer noch ne MicroSD nachschieben.
Im Moment habe ich eine 16er im Pi und einen 16er Klon in Reserve.
Ich hätte aber gerne die SSD am Pi und die Klonse für den Notfall.
Die Klonse, reicht auch Einer, würde ich dann in Abständen upgraden.
Oder über ein zuverlässiges und lauffähiges Backup-Image neu flashen.

ist da schon grenzwertig
da werden zu oft die selben Zellen beschrieben.
32 oder 64GB wären da sicherer und kosten auch nicht die Welt.

Na toll! Das sagst Du mir jetzt....
Mal eben noch nen neuen Spieler mit ins Spiel bringen :-(

Was sorgt denn dafür, dass bei einer 32er Karte unterschiedlichere Blöcke beschrieben werden, als bei einer 16er Karte?
Das müsste doch Softwareseitig geregelt werden - gibts da auch einen Adapter für? :-)

Homoran

@herrfrodo sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

reicht doch

??? nicht zerreißen!
eine 16GB ist unsicherererer als eine 64er

Homoran

@herrfrodo sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

Was sorgt denn dafür, dass bei einer 32er Karte unterschiedlichere Blöcke beschrieben werden, als bei einer 16er Karte?

was nicht da ist kann nicht beschrieben werden!

OliverIO

@herrfrodo sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

Na toll! Das sagst Du mir jetzt....

Das ist seit anbegin die Eigenschaft von SD/SSD.
Die verteilung übernimmt das Betriebssystem auf der SD-Karte(ja da ist auch ein Betriebssystem drin)/SSD
https://de.wikipedia.org/wiki/Solid-State-Drive#Wear-leveling
https://de.transcend-info.com/embedded/technology/wear-leveling

ich habe zwar nur den artikel zu bad usb gefunden, aber theoretisch ist eine sd-card ja nix anderes, nur ein anderer form-faktor
https://www.itsb.ruhr-uni-bochum.de/themen/badusb.html

HerrFrodo

@oliverio
Danke für Deine Links!

Ich habe zum Thema Wear-Leveling bei SD-Karten das hier gefunden:
https://buyzero.de/blogs/news/raspberry-pi-sd-karten-korruption-vermeiden-geheimnisse-der-microsd-karte#:~:text=Wie bereits erwähnt schiebt der,Disturb Daten hin und her.

Bei der Neuinstallation gestern, habe ich konsequent die Anleitung von Thomas Braun befolgt: https://forum.iobroker.net/topic/51869/installation-auf-raspi-einfacher-geht-s-nicht

Auch den Code für die fstab zur Einschränkung der Schreibvorgänge habe ich ausgeführt.

sudo sed -i -e 's/defaults,noatime/defaults,noatime,commit=600/' /etc/fstab

Ja Sir @Homoran, mehr GB = mehr Sicherheit :-)

HerrFrodo

Guten Morgen!

Ich habe bis heute Morgen um 2:00 versucht den raspi-backup mit rsync ans Laufen zu bringen.
Keine Chance!
Ich habe dann nach ewigem googeln und ausprobieren diese Seite gefunden:
https://www.linux-tips-and-tricks.de/de/faq#a24

Zusammengefasst steht da, dass nfs version 4 mit rsync keine Posix ACLs unterstützt und Synology unterstützt keine ACLs mit NFSv3.

Also funktioniert es so "mal eben" nicht!

Dann habe ich mich aus der alternativen Lösungsmöglichkeitsliste für einen "tar-Backup" entschieden, mit dem Ergebnis, dass es auch nicht ging.....

pi@raspberrypi:~ $ sudo raspiBackup.sh
--- RBK0009I: raspberrypi: raspiBackup.sh V0.6.8 - 2023-08-22 (7c4a713) started at Thu Sep 21 02:13:27 CEST 2023.
--- RBK0151I: Using backuppath /backup with partition type nfs4.
--- RBK0044I: Creating backup of boot partition in /backup/raspberrypi/raspberrypi-tar-backup-20230921-021326/raspberrypi-backup.img.
--- RBK0158I: Creating native tar backup "/backup/raspberrypi/raspberrypi-tar-backup-20230921-021326/raspberrypi-tar-backup-20230921-021326.tar".
--- RBK0085I: Backup of type tar started. Please be patient.
tar: /var/lib/lxcfs: file changed as we read it
??? RBK0021E: Backupprogram for type tar failed with RC 1.
--- RBK0033I: Please wait until cleanup has finished.
--- RBK1001I: Memory usage pre backup - Used: 288 MB Free: 1975 MB
--- RBK1001I: Memory usage post backup - Used: 290 MB Free: 155 MB
--- RBK1000I: CPU temperature pre and post backup: 55.5'C - 56.4'C
--- RBK1001I: Disk usage pre backup: Used: 3.49 TiB Free: 3.46 TiB
--- RBK1002I: Disk usage post backup: Used: 3.50 TiB Free: 3.46 TiB
--- RBK1003I: Disk usage change: -3.69 GiB (0.00 %%)
--- RBK0043I: Removing incomplete backup in /backup/raspberrypi/raspberrypi-tar-backup-20230921-021326. This may take some time. Please be patient.
??? RBK0005E: Backup failed. Check previous error messages for details.
--- RBK0010I: raspberrypi: raspiBackup.sh V0.6.8 - 2023-08-22 (7c4a713) stopped at Thu Sep 21 02:16:48 CEST 2023 with rc 109.
--- RBK0026I: Debug logfile saved in /home/pi/raspiBackup.log.

Dann hatte ich irgendwie keine Lust mehr auf Bastel-Pi......

? Offline

@herrfrodo

ich schmeiße dann mal partclone in den Ring

https://partclone.org/about/

Partclone is a program similar to the well-known backup utility "Partition Image" a.k.a partimage. Partclone provides utilities to save and restore used blocks on a partition   and is designed for higher compatibility of the file system by using existing libraries, e.g. e2fslibs is used to read and write the ext2 partition.

Ob es die Anforderungen erfüllt, kann ich nicht sagen, ich brauche diese Art des Backups nicht.

@herrfrodo sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

Dann hatte ich irgendwie keine Lust mehr auf Bastel-Pi......

Zu dem Problem hast Du leider nicht alle Informationen genannt, hast Du vorher alles gestoppt, sodass es nicht zu einer Änderung von Dateien während des Backups kommen kann?
Was immer bei Dir lxcfs nutzt, sollte vorher gestoppt sein.

VG
Bernd

OliverIO

@herrfrodo sagte in SSD 256GB - davon nur 16GB nutzen im RasPi4:

raspi-backup mit rsync

evtl gibst du uns mal ein überblick an welchem teilproblem du konkret arbeitest, was gelöst ist und was noch offen ist.

du versuchst das erstellte partitions-backup nun mit rsync wegzusichern?
oder meinst du das backup des backitup adapters?
ich würde da ein mount einrichten und das image direkt da reinsichern.
wenn das mount da ist, dann kann backitup da ebenfalls reinsichern
aber wie gesagt, ich habe etwas den faden verloren