Automatisches Komplettbackup der SD-Karte

[Hollo]

...Ich bin relativ schnell mit dem "Wiederinstallieren", d.h. es reicht mir rein die Konfiguration von Programmen. Entsprechend ist das Backup aufgebaut:
/etc
/opt/fhem
/daten

+ eine "Liste" der installierten Pakete; im Laufe der Zeit hat man ja so manches zusätzliche Paket benötigt 

[Wernieman]

Kann man ja vor dem Backup (automatisch) erstellen lassen 

[Bennemannc]

Hallo,

was ist mit rsync ? Ich habe da im Ubuntuforum etwas gefunden. Eigentlich geht es darum, auf einen neue Platte umzuziehen - ich nutze das zum Backup. Ok ich habe dann kein lauffähiges System - das muss ich aus dem Standartimage wiederherstellen - aber meine Dateien, Logfiles, Config Files, Installierte Programme und Co. werden gesichert. Auf einem Cubie ist das noch etwas einfacher. Der bootet von Nand und hat dann nur seine Dateien auf einer SSD - aber rsync ist eigentlich genau dafür gemacht um Verzeichnisse abzustimmen. Da nur geänderte Dateien (Zeitstempel) übertragen werden ist das auch sehr schnell fertig. Man muss natürlich --exclude /mnt/backup (oder wo auch immer das Backupverzeichnis liegt) machen, damit das Backup sich nicht selber sichert. Zudem sollten /sys und /proc nicht mitgesichert werden.

Gruß Christoph

[reibuehl]

Ich verwende auf mehreren Raspberry Pis eine Kombination aus dem bereits von Jörg empfohlenen raspiBackup.sh und rsnapshot, einem auf rsync basierenden File-Backup. Ich habe auch schon ein paar mal raspiBackup dd backups erfolgreich wiederhergestellt. rsnapshot bietet die Möglichkeit, vor Beginn des rsync-Backups noch eigene Scripte auszuführen. Diese nutze ich, um einen dump der dpkg Packetliste und meiner mysql Datenbanken zu machen:

Code Auswählen Erweitern

backup_script   /usr/bin/dpkg --get-selections > packages.txt   ./installed_packages/
backup_script   /usr/bin/mysqldump -u backup --events --opt --all-databases | gzip > mysqldump  ./mysql/


[Wernieman]

Eigentlich hat rsync wie dd probleme bei einem laufendem System. Eine im Zugriff befindliche Datei kann eben nicht gesichert werden.
Zusätzlich wird das "bootsystem" nicht gesichert. Im wort-case-fall muß also erst ein linux installiert werden, bis man rsync zurückspielen kann.

rsnapshot, dirvish und ähnliche, auf rsync aufbauende Frontends haben eigentlich den Vorteil, mit Hardlinks arbeiten zu können, wenn das Zielspeichermedium Hardlinks versteht.

Hintergrund:
Es wird am 1. Tag ein Full-Backup gemacht.
Am 2. und allen folgenden läufen wird ein inc (Teil) backup gemacht, es sieht für den user aber wie ein Fullbackup aus.
-> Für den User sind alle Backups schnell wiederherstellbar (FULL)
-> Es wird aber nur die Änderung weggesichert

Bei mir Läuft als Backup ein dirvish, bei meinem Arbeitskollegen ein rsnapshot. Wenn diese Laufen, dann .....

Hinweis:
Ich würde diese aber nicht als Damons, sondern per eigenem Cron-Script aufrufen.
1. Läuft ein Deamon weniger
2. Mann kann eigene Scripte vorher, nachher oder sonstiges laufen lassen

[Gunther]

- Laufende Sicherung der Daten (Hier .B. komplett /opt/fhem + /etc)

Kannst Du mir dazu noch einen Tipp geben?

[Wernieman]

Bitte verstehe mich nicht falsch:
Was ist Dir nicht verständlich?

/(Manchmal sieht man als "Profi" nicht die Probleme der "Anfänger" ...)

[Gunther]

Vielleicht habe ich etwas übersehen. Ich habe nur Links zu Komplettbackups gefunden.
Wie kann ich einzelne Ordner automatisiert auf SSD oder besser auf Synology NAS sichern?

[Wernieman]

rsync, rsnapshot, dirvish, cp ... gibt viele Möglichkeiten ...

Zuerst die Frage:
Wie gibt Deine NAS denn den Speicher frei?

Dann:
Was willst Du Sichern?
Welche Versionsmenge? (nur eine Copie, die letzten 5 ...)
Wie häufig?
....

[rr725]

Eigentlich hat rsync wie dd probleme bei einem laufendem System. Eine im Zugriff befindliche Datei kann eben nicht gesichert werden.

hm...wie oft denn noch !?
das ist so nicht richtig- bezgl. dd
dd dient zum bit-genauen Kopieren von Festplatten, Partitionen oder Dateien. "Bit-genaues" Kopieren bedeutet, dass der Datenträger Bit-für-Bit bzw. Byte-für-Byte ausgelesen und beschrieben wird, unabhängig von dessen Inhalt und Belegung.

D. h.  zum Zeitpunkt "x" wird auch eine "im Zugriff befindliche Datei" mit dem Inhalt zu diesem Zeitpunkt gesichert.
Teste dies doch bitte selbst erst einmal aus. Noch einmal. Ich mache seit Jahren mein Backup mit DD. Es gab früher einmal Probleme, die sind BEHOBEN. Extra gerade nochmal getestet. LOG DATEI GEÖFFNET UND AUTOMATISCH BESCHREIBEN LASSEN UND BACKUP ANGESTOSSEN.....DIE DATEI WIRD GESICHERT !!!!!, wie die gesamte SD Karte halt.

[JoWiemann]

Das ist richtig, heißt aber noch lange nicht, das die Integrität, z.B. einer Datenbank oder anderer Systeme mit relational abhängigen Daten gewahrt bleibt.


Grüße Jörg

Gesendet von iPad mit Tapatalk

[rr725]

was denn nun....
mal schreibst du ". Eine im Zugriff befindliche Datei kann eben nicht gesichert werden"
und darunter das meine anmerkung richtig sei ?!

auch dies bitte erst selbst testen und dann die ergebnisse posten- ich hab auf meinen raspi´s  apache, php´s  und sql´s laufen.
noch nie gab´s probleme.

aber ich geb es nun auf........

[Wuppi68]

beste Beispiel ist doch das Stafefile aka fhem.save

es wird gesichert ABER im RAM ist eine womöglich komplett andere Version (die noch nicht geschrieben ist)

bei fhem.save ist es relativ egal - aber Datenbanken verzeihen einem das in den seltensten Fällen

[Wernieman]

@rr725

a)
Du vergisst aber, das eine "Sicherung" per dd Zeit braucht. Es kann eine 1zu1 Kopi sein und trotzdem nicht mehr laufen!
Du sicherst ein teil der Datei, während ein anderer prozess schreibt. Dann passiert was??

b)
Viel Wichtiger:
Schon mal von den Problemen gehört, die man bekommen kann, wenn man ein Unix(Linux)-System einfach abschaltet (Stromlos)?
Warum kann dieses zu Probleme führen? Weil die Daten auf der Platte eben nicht "sauber" sein können! Unix (Linu) cacht und deshalb sind eventuell die Daten auf der Platte nicht konsistent

Wie schon mal von mir geschrieben:
Wenn Du weist, wie man dann ein System trotzdem zu laufen kriegt, super!
Ein Normaler Dau (nicht negativ gemeint), wird aber gerade dann ..... und deshalb wirst Du immer hören: Backup mit dd nicht sauber.

Und das dieses nicht nur meine Meinung ist, siehe Sicherheitshinweis:
https://wiki.ubuntuusers.de/dd/

[SCMP77]

noch nie gab´s probleme.

aber ich geb es nun auf........

Die Bedenken, welche hier zu diesem Verfahren geäußert werden, sind durchaus berechtigt. Das DD-Befehl puffert ja nicht vorher die Daten. Wenn Datei A schon gesichert wurde, aber Datei A und B während des DD-Befehls von einem Prozess verändert wird, so sind auf der Sicherung zwei nicht zusammen passenden Stände dieser beiden Dateien. Die Wahrscheinlichkeit für ein solches Problem ist natürlich sehr gering, insbesondere wenn man relativ selten schreibt, aber die Gefahr besteht einfach. Da der DD-Befehl ein echtes physikalische Abbild macht, sind auch noch weitere Situationen denkbar, dass kann bis hin zu einer vermurksten File-Hierarchie gehen. Es müssen dann aber immer mehrere Dinge zusammen kommen, daher wird man es selten beobachten können. Einiges repariert sich dann auch von alleine, da lebensnotwendige Strukturen häufig redundant sind bzw. repariert werden können.

Dass Du es nie beobachtet hast, schließt es daher nicht aus. Man merkt es ja auch erst beim Zurückspielen einer Sicherung und so häufig macht man das eben nicht.

Unter Windows gibt es eine Betriebssystem-Funktion, die quasi vor einer Sicherung ein Snapshot erstellt, dass nutzen einige Backup-Programme. Nur dann kann man sich auf ein solches Backup verlassen.