Sicherung des Raspberry Betriebssystems

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

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.

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/

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.

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.

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.

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.

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.

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.

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.

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?