Forum: PC-Programmierung Sicherung des Raspberry Betriebssystems


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von sunshineh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Peter II (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
zippen und nur 8-16GB Karten maximal einsetzen, >16GB hat doch kaum Sinn

von Resepp (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von lala (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Tobias M. (hoaxus)


Bewertung
0 lesenswert
nicht lesenswert
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
von Rolf M. (rmagnus)


Bewertung
2 lesenswert
nicht lesenswert
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...

von Sheeva P. (sheevaplug)


Bewertung
3 lesenswert
nicht lesenswert
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
von Daniel F. (df311)


Bewertung
3 lesenswert
nicht lesenswert
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.

von blubb (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Peter II (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter II (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von blubb (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ..

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch keine SD Karte gesehen, die den trim befehl unterstützt.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Ich habe noch keine SD Karte gesehen, die den trim befehl unterstützt.

Woran willst Du das sehen?

von blubb (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.