Hallo, ich habe OpenElec und Raspbian auf meine Raspberry Pi 2 aufgespielt und mit dem Win32 Disk Imager jeweils eine Sicherung auf meinen PC gespielt. Diese hat auch 32 GB obwohl OpenElec z.B. beim Herunterladen nur 548MB belegt. Kann ich mir meine gemachten Änderungen auch sichern, ohne jedesmal die 32GB meiner SD-Karte auf meinen Rechner kopieren zu müssen?
sunshineh schrieb: > Diese hat auch 32 GB obwohl OpenElec z.B. beim Herunterladen nur 548MB > belegt. ja, weil die Partition bei ersten Booten vergrößert wird. > Kann ich mir meine gemachten Änderungen auch sichern, ohne jedesmal die > 32GB meiner SD-Karte auf meinen Rechner kopieren zu müssen? ich wüsste dafür keinen einfachen weg. Datei einfach zippen ist wohl das einfachste. Oder die Partition nicht auf 32GB vergrößern sondern nur auf 2 oder 4GB. Dann eine zusätzliche Partition mit dem Rests der nicht gesichert wird.
zippen und nur 8-16GB Karten maximal einsetzen, >16GB hat doch kaum Sinn
Vorher Partition aushängen und danach auf minimum verkleinern. Dann bist du wieder bei deinen 600 MB. Aber unter dem laufen ? Ich weiss nicht so recht. Habe immer die Karte in den PC geschobe, die Partition verkleinert, ein Image gezogen und danach gezippt. Perfektes kleines Image für den Download auf meiner Seite :-D
sunshineh schrieb: > Diese hat auch 32 GB obwohl OpenElec z.B. beim Herunterladen nur 548MB > belegt. Resepp schrieb: > Vorher Partition aushängen und danach auf minimum verkleinern. > Dann bist du wieder bei deinen 600 MB. Ich denke bei einer solchen Frage, kommt der TO mit deiner Antwort nicht weit. (Aufgrund des mangelnden Wissen) Insgesamt ist deine Antwort aber die Lösung :p sunshineh schrieb: > Kann ich mir meine gemachten Änderungen auch sichern, ohne jedesmal die > 32GB meiner SD-Karte auf meinen Rechner kopieren zu müssen? Bedenke, dass deine neue SD-Karte auf's Byte genau so groß sein muss, wie deine jetztige. Das wird wahrscheinlich nicht klappen. Deine neue SD Karte wird daher wohl 64GB groß werden... Ein Image verkleinern ist daher sinnvoll ;-) Aber dafür solltest du einfach mal Google befragen. Da kann man sich dann durch die Foren lesen. Die stichwörter hast du ja: raspberry pi image verkleinern Da du das verkleinern so schnell wohl nicht hinbekommst, kannst du jedenfalls momentan einfach ein 32GB-Basis-Image erstellen und anschließend regelmäßig mit "rsync" o.ä. die wichtigsten Dateien einfach seperat sichern. Dafür haben viele Menschen sogar schon automatisierte Skripte bereitgestellt. Da wird auch Google helfen. Stichwort: rsync backup script cronjob In der Zwischenzeit kannst du einfach mal nachlesen, wie man mit rsync manuelle Backups erstellen kann
Wenn du z.B. auf btrfs umsteigst, dann kannst du die Dateien relativ einfach auch im laufenden Betrieb sichern. Ansonsten geht auch jedes andere FS. Bei Wiederherstellen/Zurückkopieren der Dateien ist es lediglich nötig den Bootloader neu zu installieren. Ansonsten gibt es unter Linux z.B. das Program "partimage", das sichert nur belegte Sektoren und komprimiert das ganze auf Wunsch auch noch. Beim Wiederherstellen brauchst du dennoch eine mindestens ebenso große Speicherkarte wie ursprünglich.
:
Bearbeitet durch User
lala schrieb: > Resepp schrieb: >> Vorher Partition aushängen und danach auf minimum verkleinern. >> Dann bist du wieder bei deinen 600 MB. > > Ich denke bei einer solchen Frage, kommt der TO mit deiner Antwort nicht > weit. (Aufgrund des mangelnden Wissen) > Insgesamt ist deine Antwort aber die Lösung :p Sehe ich anders, denn so eine Resize-Operation ist schon ein recht tiefer Eingriff in das Dateisystem. Man sollte daher auf jeden Fall vorher ein Backup machen. Also macht man erstmal ein Backup der gesamten Karte, damit man dann die Partition verkleinern kann, um danach dann ein platz- und zeitsparenderes Backup machen zu können...
sunshineh schrieb: > ich habe OpenElec und Raspbian auf meine Raspberry Pi 2 aufgespielt und > mit dem Win32 Disk Imager jeweils eine Sicherung auf meinen PC gespielt. > > Diese hat auch 32 GB obwohl OpenElec z.B. beim Herunterladen nur 548MB > belegt. > > Kann ich mir meine gemachten Änderungen auch sichern, ohne jedesmal die > 32GB meiner SD-Karte auf meinen Rechner kopieren zu müssen? Du kannst Deine Backups auch auf Dateisystebene machen, statt Dateisystem-Images zu kopieren. Alles, was Du aus anderen Quellen -- wie zum Beispiel Deinem Installations-Image -- wiederherstellen kannst, mußt Du nicht ins Backup aufnehmen. Dieses Backup sollte idealerweise online, also ohne das Gerät herunterfahren zu müssen, und zu regelmäßigen Zeiten stattfinden. Wichtig: teste Dein Backup regelmäßig! Es ist ein sehr beliebter Fehler, das zu unterlassen und dann im Zweifelsfall mit einem Backup dazustehen, in dem wichtige Daten fehlen oder das sich aufgrund von Fehlern des Formats, des Datenträgers oder ähnlichen Gründen nicht wiederherstellen läßt. Solch ein Backup ist dann natürlich nur von sehr begrenztem Wert -- genauso wie ein Backup, von dem Du nicht weißt, wie Du es zurückspielen kannt. Dazu brauchst Du nur eine zweite SD-Karte und etwas Zeit. ;-) Ebenso wichtig: das Backup sollte zuverlässig und regelmäßig stattfinden, also ohne manuelle Eingriffe. Nichts ist ärgerlicher, als ein Backup zu haben, das völlig veraltet ist und ausgerechnet die letzten komplizierten und aufwändigen Änderungen nicht enthält. Außerdem solltest Du Dich für eine Backup-Strategie entscheiden. Eine der beliebtesten Strategien ist, jeden Tag die Änderungen zum vorherigen Tag zu sichern (incremental backup), einmal pro Woche ein vollständiges Backup (full backup) zu machen, und die letzten n Full-Backups aufzubewahren. Das verringert die für das Übertragen und Sichern der Backup-Daten notwendigen Netzwerk- und Speicherressourcen. Und dann ist da noch die Frage nach dem Ort eines Backups. Dieser richtet sich im wesentlichen nach zwei Fragen. Nämlich erstens: wogegen willst Du Dich absichern? Und zweitens: welche Ressourcen hast Du zur Verfügung? Wenn bei einem Hausbrand sowohl Dein Gerät als auch das Backup zerstört wird, ist das Backup ziemlich wertlos. Über ein 100 MBit-Netzwerk kannst Du maximal ein knappes Terabyte pro Tag sichern, weil dann Dein Netzwerk saturiert ist. Deswegen gilt es, sowohl den Ort des Backups als auch die darin zu sichernden Daten sorgfältig auszuwählen. Wir haben sehr gute Erfahrungen mit den Backup-Werkzeugen Duplicity und dessen Frontend duply gemacht. Die können Dein Backup sogar verschlüsseln, um Deine Backups vor neugierigen Blicken zu schützen, sollten sie einmal in falsche Hände geraten. Mit duply kannst Du einfach /home und /etc, je nach Installation, auch noch /usr/local, /opt, /root und / oder /var/log sowohl inkrementell als auch vollständig sichern, siehe dazu [3] und [4]. Ein weiteres hilfreiches Werkzeug nicht nur, aber auch für die Sicherung der systemweiten Konfiguration unter /etc ist außerdem etckeeper. Das macht aus Deinem /etc-Verzeichnis ein VCS-Repository, standardmäßig mit git, und merkt sich alle Änderungen daran mit Datei, Tag, und -- wenn Du es diszipliniert benutzt -- auch einer Commit-Nachricht, die idealerweise beschreibt, warum Du die Änderung gemacht hast. etckeeper kann täglich einen automatischen Commit machen und die Änderungen optional auf ein zweites Repository pushen, entweder auf einer lokalen Festplatte oder auf einem anderen Rechner. Leider kenne ich OpenELEC nicht, und meine Spielereien mit RaspBMC sind auch schon eine Weile her. Daher kann ich leider nicht sagen, ob es duply, Duplicity und etckeeper auch für OpenELEC gibt. Aber im Grunde sollte es für Dich vollkommen ausreichen, das Home-Verzeichnis von Kodi sowie das Verzeichnis /etc zu sichern. Dies kann mit den erwähnten Werkzeugen, oder mit Shell-Bordmitteln, über das Netzwerk auf einen anderen Rechner, auf eine USB-Festplatte oder gar einen USB-Stick geschehen, die Du direkt an den RasPi anschließt. Siehe dazu auch [1] und [2]. Wenn Dir USB-Platten oder -Sticks einzeln zu unsicher sind, kannst Du auch zwei Platten oder zwei USB-Sticks anschließen und entweder über LVM, Linux' SoftRAID oder die Möglichkeiten von BTRFS zu einem gespiegelten RAID verbinden. Ach ja, ganz vergessen: wenn Du trotzdem auch Image-Backups machen willst, kannst Du die unbenutzten Blocks Deines Dateisystems mit zerofree vorher nullen und so sicherstellen, daß Dein Backup-Image effizient komprimiert werden kann. [1] http://kodi.wiki/view/backup [2] http://blog.helmutkarger.de/raspberry-media-center-teil-19-datensicherung/ [3] https://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_duply [4] http://duply.net/
:
Bearbeitet durch User
Sheeva P. schrieb: > Wichtig: teste Dein Backup regelmäßig! das ist dann die "Messung" an Schrödingers Backup: Der Zustand eines Backups ist unbekannt bis man versucht es wiederherzustellen.
Daniel F. schrieb: > das ist dann die "Messung" an Schrödingers Backup: > Der Zustand eines Backups ist unbekannt bis man versucht es > wiederherzustellen. +1 ymmd!
Sheeva P. schrieb: > Ach ja, ganz vergessen: wenn Du trotzdem auch Image-Backups machen > willst, kannst Du die unbenutzten Blocks Deines Dateisystems mit > zerofree vorher nullen und so sicherstellen, daß Dein Backup-Image > effizient komprimiert werden kann. Wenn er auf dem Raspi in einem wöchentlichen Cron-Job ein fstrim -a drin hat (was er dringendst sowieso drinhaben sollte um die SD-Karte zu schonen) dann werden alle unbenutzten Sektoren sowieso regelmäßig genullt.
Bernd K. schrieb: > fstrim -a > > drin hat (was er dringendst sowieso drinhaben sollte um die SD-Karte zu > schonen) dann werden alle unbenutzten Sektoren sowieso regelmäßig > genullt. wie soll denn eine zusätzlichen schreiben die SD-Karte schonen?
Peter II schrieb: > wie soll denn eine zusätzlichen schreiben die SD-Karte schonen? Indem nicht geschrieben wird. Die Blöcke sind per TRIM nur als gelöscht markiert. Ein Lesezugriff darauf gibt möglicherweise Nullen zurück. Was freilich voraussetzt, dass die µSD TRIM kennt.
:
Bearbeitet durch User
Peter II schrieb: > Bernd K. schrieb: >> fstrim -a >> >> drin hat (was er dringendst sowieso drinhaben sollte um die SD-Karte zu >> schonen) dann werden alle unbenutzten Sektoren sowieso regelmäßig >> genullt. > > wie soll denn eine zusätzlichen schreiben die SD-Karte schonen? Indem es - wie Du durch einfaches Googlen auch ohne mich zu fragen hättest herausfinden können - die unbenutzten Sektoren dem Wear-Leveling-Pool der Karte zurückgibt.
A. K. schrieb: > Indem nicht geschrieben wird. Die Blöcke sind per TRIM nur als gelöscht > markiert. Ein Lesezugriff darauf gibt möglicherweise Nullen zurück. ja, aber das schont auch nicht die SD-karte.
Bernd K. schrieb: > Indem es - wie Du durch einfaches Googlen auch ohne mich zu fragen > hättest herausfinden können - die unbenutzten Sektoren dem > Wear-Leveling-Pool der Karte zurückgibt. und, was soll daran schonend für die Karte sein?
Peter II schrieb: > Bernd K. schrieb: >> Indem es - wie Du durch einfaches Googlen auch ohne mich zu fragen >> hättest herausfinden können - die unbenutzten Sektoren dem >> Wear-Leveling-Pool der Karte zurückgibt. > > und, was soll daran schonend für die Karte sein? Sie kann dann dynamisches Wear Leveling machen. Das kann sie nämlich nur wenn sie noch freie Sektoren hat, und je mehr sie davon hat desto besser kann sie die Schreiblast auf selbige verteilen.
Peter II schrieb: > ja, aber das schont auch nicht die SD-karte. Es schont aber das komprimierte Backup-Image. Genullte Blöcke sind besser komprimierbar. Es gibt freilich auch Programme für Image-Backups, die bei bekannten Filesystemen vorneweg nur genutzte Sektoren kopieren. Clonezilla macht das beispielsweise.
Bernd K. schrieb: > Sie kann dann dynamisches Wear Leveling machen. Das kann sie nämlich nur > wenn sie noch freie Sektoren hat, und je mehr sie davon hat desto besser > kann sie die Schreiblast auf selbige verteilen. nein, sie kann auch so Sektoren umsortieren wenn sie voll sein - es ist nur langsamer. Trim ist hilfreich, damit die Karte sofort Daten schreiben kann und nicht erst löschen oder umsortieren muss. Aber eine Schonung für die Karte ist es nicht.
Peter II schrieb: > Trim ist hilfreich, damit die Karte sofort Daten schreiben kann und > nicht erst löschen oder umsortieren muss. Wenn Du eine SD-Karte findest die statisches Wear-Leveling kann. Kennst Du eine? Und was ist gegen eine Verdopplung der Schreibgeschwindigkeit durch TRIM einzuwenden? TRIM schont die Karte weil Du keine Karte mit statischem Wear-Leveling finden wirst und wenn Du doch zufällig eine findest dann verdoppelt regelmäßiges TRIM deren Schreibgeschwindigkeit bzw hält sie dauerhaft aufrecht.
:
Bearbeitet durch User
Bernd K. schrieb: > Und was ist gegen eine Verdopplung der Schreibgeschwindigkeit durch TRIM > einzuwenden? TRIM schont die Karte weil Du keine Karte mit statischem > Wear-Leveling finden wirst und wenn Du doch zufällig eine findest dann > verdoppelt die Schreibgeschwindigkeit. hast du dafür belege? Selbst bei Festplatten merkt man keinen unterschied ob sie vorher getrimmt wurden oder nicht. Bei SD-Karten im Raspi ist das Interface das langsamste. Wenn SD-Karten kein Static wear leveling haben, würden sie auch so nach kurzer Zeit im Raspi sterben weil normale Filesystem auch regelmäßig auf die gleichen Sektoren schreiben - da hilft auch kein Trimm. Ich habe zwar auf die schnelle nicht gefunden, aber ich vermute mal das aktuelle Karten (was bei 32GB der Fall sein dürfte) Static arbeiten.
Peter II schrieb: > sterben weil normale Filesystem auch regelmäßig auf die gleichen > Sektoren schreiben - da hilft auch kein Trimm. Doch, genau dann hilft trim. Genau deswegen.
A. K. schrieb: > Es schont aber das komprimierte Backup-Image. Genullte Blöcke sind > besser komprimierbar Daher habe ich auch mein großes image nach dem schrumpfen der Partitionen nochmal mit /dev/nul vollgeschrieben und anschließend komprimiert ;) Ist aber ein Witz, wenn die Partitionen auf 10mb free space geschrumpft werden ..
Ich habe noch keine SD Karte gesehen, die den trim befehl unterstützt.
Daniel A. schrieb: > Ich habe noch keine SD Karte gesehen, die den trim befehl unterstützt. Woran willst Du das sehen?
Ich wollte diesen Thread nochmal kurz ausgraben und zwei Links hier reinwerfen: Artikel: https://linuxundich.de/raspberry-pi/pishrink-verkleinert-raspberry-pi-images/ Quelle des Tools: https://github.com/Drewsif/PiShrink/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.