Leider habe ich nichts passendes gefunden.
Gibt es eine Möglichkeit ein regelmäßiges und automatisches Komplettbackup der Micro-SD-Karte im RPI2 auf SSD oder NAS anzufertigen?
ja, gibt es.
mittels at, oder doif.
z.b. mit "dd"
sudo dd if=/dev/mmcblk0 of=/opt/Backup/Raspi.img bs=1M
Schau auch mal hier: http://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/
Grüße Jörg
Leider nein, ein Linux sollte man nicht im laufenden Betrieb "abziehen"
Es ist sehr wahrscheinlich, dass dir lockfiles das zurück spielen kräftig verhageln. Der Vorschlag mit dd ist nicht sinnvoll.
Hast du ein System soweit fertig, dann zieh einmal ein Image der sd-Karte und sichere den fhem Ordner regelmäßig, dafür gibt es eine Backup Routine.
Wenn du dblog hast, dann musst du die DB noch regelmäßig backuppen.
Gesendet von meinem ONE A2003 mit Tapatalk
Zitat von: bartman121 am 31 Januar 2016, 16:03:33
Der Vorschlag mit dd ist nicht sinnvoll.
aha.... dann mach ich seit ca. 2 Jahren nicht sinnvolles.jeder wie er mag...bei mir funktionert das backup und ein lauffähiges restore damt einwandfrei. dann hast du wohl was falsch gemacht, wenn es bei dir nicht funktioniert
Es ist und bleibt bei dd ein Glücksspiel ein laufendes System zu sichern...
Vgl hier: http://blog.wenzlaff.de/?p=2643
Einfach Kommentare lesen....
Du wiegst dich in falscher Sicherheit.
Gesendet von meinem ONE A2003 mit Tapatalk
Diese Diskussion hatten wir schon mal.
Wenn es bei Dir läuft: Super
Einem Anfänger, wenn solche Fragen aufkommen muß man davon ausgehen, sollte man damit sicherheitshalber NICHT kommen! Der weiß auch nicht, wie er ein "beschädigtes" Linux wieder zum Laufen kriegt!
Deshalb ist mein Backup-Favorit für DAU immer noch:
- Kaltes Dump des Systemes
- Laufende Sicherung der Daten (Hier .B. komplett /opt/fhem + /etc)
Zitat von: bartman121 am 31 Januar 2016, 17:16:30
Du wiegst dich in falscher Sicherheit.
wenn du es sagst, dann wird es auch so sein.
dann mache ich anscheinend etwas falsch, wenn meine images lauffähig sind.
mir ist es noch nicht einmal gelungen ein ncht lauffähiges zu erstellen.
da mache ich mir nun natürchlich massive gedanken, was ich falsch mache und werde mir eine andere backup lösung überlegen, die nicht funktioniert.
okay, aus Versehen habe ich das Thema ja in eine falsche Richtung gedrückt ...
Gunther, hast du jetzt eine Lösung gefunden?
@rr725, das kannst du gern so machen, dann ist es halt MIST.
Danke für Eure Tipps!
In folgende Richtung überlege ich nun:
1.) Backup nach Herunterfahren des Systems damit ich auf der sicheren Seite bin
2.) Regelmäßige Backups von FHEM
3.) ggf. zusätzlich Komplettbackup im laufenden Betrieb (mit dem Risiko, dass es nicht restored werden kann).
Hallo,
ich habe das auch mit RaspiBackup.sh gelöst. Ich mache damit wöchentlich ein DD-Backup (wenigstens fhem halte ich dazu an) und habe immer die letzten 4 Backups auf dem NAS. Das FHEM-Backup z.B. vor einem Update wird auch auf dem NAS gespeichert.
Ich habe schon zwei defekte SD Karten gehabt und jedes mal hat das wiederherstellen der SD Karte aus dem DD-Backup funktioniert. Die Wiederherstellung ist halt schnell und einfach. Sollte es dann mal nicht klappen, kann ich immer noch ein älteres Backup nehmen oder halt alles von Grund auf neu installieren und die Daten aus dem FHEM-Backup einspielen.
Womit ich anfangs Probleme hatte war, dass ich das Filesystem vom Raspi auf die ganze SD-Karte expandiert hatte. Dadurch konnte ich das DD-Backup dann nur bedingt auf anderen SD Karten wieder herstellen, weil dann je nach SD Karte am schluss mal ein oder zwei Blocks nicht mehr auf die neue Karte passten und dann lief halt nix...
Gruß
Ingo
Das mit der zu kleinen SD-Karte habe ich auch hinter mir. War für mich Laien schon aufwendig das Ganze wieder zum Rennen zu bekommen. Nun habe ich absichtlich etwas verkleinert und noch identische SD-Karten parat.
Zitat von: automatisierer am 01 Februar 2016, 18:56:44
Ich habe schon zwei defekte SD Karten gehabt und jedes mal hat das wiederherstellen der SD Karte aus dem DD-Backup funktioniert. Die Wiederherstellung ist halt schnell und einfach.
Hallo Ingo, na endlich mal jemand der das auch hingekriegt hat mit "DD". Ich hatte schon ein schlechtes Gewissen was ich denn falsch mache und jeder über mich herfällt, wenn man hier nur erwähnt dass man es benutzt und es ja nie funktionieren kann.
Ich bin einfach nur begeistert und ich habe auch mehrere Images in der Rückhand, falls es mal kracht. Und hatte auch noch nie den Fall, dass ein Image nicht lauffähig war. Früher- da gab es mal Probleme, aber Wheezy wird ja auch immer weiter gepflegt und wenn man brav patcht, werden auch Fehler behoben. Ich kann es ganz beruhigt weiterempfehlen.
@rr725,
es hat ja keiner behauptet, dass es überhaupt nicht funktioniert. Es kann klappen, aber es kann auch in die Hose gehen... Mein GMV Sagt mir, dass es nicht gut sein kann, Dateien zu kopieren während sie in Benutzung sind, allerdings habe ich noch keine bessere Alternative gefunden mit der ich auch noch so klamotten wie z.B. CUPS und andere Systemeinstellung fernab von FHEM sichern kann und das auch noch voll automatisch und regelmäßig.
Gruß
Ingo
Du solltest Dir die Frage, stellen, was Du mit dem backup erreichen willst.
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
Zitat von: Wernieman am 02 Februar 2016, 11:31:18
...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 ;)
Kann man ja vor dem Backup (automatisch) erstellen lassen ;D
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
Ich verwende auf mehreren Raspberry Pis eine Kombination aus dem bereits von Jörg empfohlenen raspiBackup.sh (http://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/) 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:
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/
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
Zitat von: Wernieman am 31 Januar 2016, 18:12:50
- Laufende Sicherung der Daten (Hier .B. komplett /opt/fhem + /etc)
Kannst Du mir dazu noch einen Tipp geben?
Bitte verstehe mich nicht falsch:
Was ist Dir nicht verständlich?
/(Manchmal sieht man als "Profi" nicht die Probleme der "Anfänger" ...)
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?
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?
....
Zitat von: Wernieman am 02 Februar 2016, 15:21:15
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.
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
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........
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
@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/ (https://wiki.ubuntuusers.de/dd/)
Zitat von: rr725 am 04 Februar 2016, 11:12:04noch 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.
ok...ich geb es zu dd funktioniert nicht. es gibt nur probleme und man sollte es nicht benutzen
DAS .. wurde so nicht gesagt .. 8)
Zitat von: Wernieman am 04 Februar 2016, 12:04:15
a)
Du vergisst aber, das eine "Sicherung" per dd Zeit braucht.
b)
Viel Wichtiger:
Schon mal von den Problemen gehört, die man bekommen kann, wenn man ein Unix(Linux)-System einfach abschaltet (Stromlos)?
a) Hm....welches Backup benötigt keine Zeit ?! Ich benutze auch DD. Meine kleine SD Karte wird in ca. 15 min gesichert. Ich mache das NAchts- wem stört es ??
b)
mein kleiner Raspberry mit Kodi wird immer brutalst ausgeschaltet, einfach Strom weg, mit Schaktsteckdose. Der hat noch nie gemeckert.
Ja sicher, es kann immer etwas schiefgehen. Die Erde könnte morgen auch aufhören sich zu drehen.
Ein Komet könnte einschlagen. Paranoia ?! Hey- es geht hier um eine Sicherung eines Raspberrys, nicht um eine Herz- Lungenmaschine. Ich komme aus dem Schmunzeln nicht mehr heraus. Wenn dies alles so extrem "unsicher" ist, muss man einmal ganz anders an die Sache herangehen. Dreifache Redundanz, USV, Backup Stromleitung vom Stromlieferanten, man weiss ja nie, damit der Raspberry nie offline geht. Wahnsinn.........ich frag mich wie manche den Tag überstehen......
Sagen wir es mal so: Es gibt eine gewisse Wahrscheinlichkeit bei der Teilnahme am Straßenverkehr zu verunfallen. Auch wenn man selber noch nie verunfallt ist, sollte man bei der Teilnahme am Straßenverkehr auf diese Möglichkeit hinweisen. Was Du dann tust in Deine Sache. Wenn es aber schief geht, dann bitte nicht jammern, man sei ja nicht darauf hingewiesen worden.
Grüße Jörg
Gesendet von iPad mit Tapatalk
a) innerhalb der 15 Minuten KANN ein prozess schreiben. Für einen rchner sind 15 Minuten laaaang
b)
Dieses hat nichts mit Paranoia zu tuen. mache Dich bitte mal schlau, wie Unix (Linux) mit Platten umgeht.
Es ist heute besser geworden, vor 10 Jahren habe ich 2 Unix-Server deswegen verloren. USV kaputt, keiner der Zuständigen "Tester" hat es geprüft und der Bagger hat Stromleitung gekappt ......
P.S. Deine Erwähnung wegen "die Erde könnte morgen auch aufhören sich zu drehen. Ein Komet könnte einschlagen. Paranoia ?!" sehe ich mal als Billige Polemik und eigentlich unter Deiner Würde. Wenn Du aber meinst .... 8)
Edit:
@ JoWiemann
Danke für DIESEN Beitrag. YMMD
Zitat von: JoWiemann am 04 Februar 2016, 13:38:46
Wenn es aber schief geht, dann bitte nicht jammern, man sei ja nicht darauf hingewiesen worden.
Dafür habe ich ja dann funktionierende DD Images
Nochmals....es geht hier um einen Raspberry !!!!
Zitat von: DieterL am 04 Februar 2016, 13:52:10
Dafür habe ich ja dann funktionierende DD Images
Nochmals....es geht hier um einen Raspberry !!!!
Das ist doch ganz egal ob es sich um einen Raspberry handelt oder nicht.
Fakt ist, dass einen Ausschalten oder ein Backup mit dd zu Problemen führen
KANN.
Wie Du selber schreibst, der Backup über dd dauert 15 Minuten. Der Zeitraum, wo es zu einem Auseinanderlaufen von unterschiedlichen Dateiständen kommen kann, beträgt 15 Minuten, für einen Computer - auch den Raspberry - eine Ewigkeit.
Ich habe meinen Raspberry auch an einer Zeitschaltuhr hängen und trenne den regelmäßig alle 24h kurz vom Netz, da der 300km entfernt von mir läuft. Mir ist es schon passiert, dass der Raspberry nach einer solchen Aktion nicht mit startete. Wenn man nicht vor Ort ist, helfen einem dann auch keine funktionierenden dd-Images. Daher habe ich aktuell auf diesem Raspberry ein Read-Only-Betriebssystem drauf (das Arch-Linux für den Raspberry ist defaultmäßig ein solches) und die Daten, welche geschrieben werden müssen, werden auf ein USB-Stick geschrieben. Ich kann mir nicht leisten, hier einfach mal 300 km durch Deutschland zu fahren, nur weil das Teil durch das harte Abschalten nicht mehr bootet. Den USB-Stick kann ich zur Not aus der Ferne neu formatieren.
Daher sollte man hier nicht einfach Vorsicht als Paranoia abtun, das muss jeder für sich von Fall zu Fall entscheiden. Wenn hier behauptet wird, es klappt IMMER, so ist das schlicht und einfach falsch. Und Murphy schlägt meist genau dann zu, wenn man es nicht brauchen kann.
Zitat von: SCMP77 am 04 Februar 2016, 14:31:56
>Das ist doch ganz egal ob es sich um einen Raspberry handelt oder nicht.
ja, ein raspberry ist ja auch ein hochverfügbarkeitssystem
>Wie Du selber schreibst, der Backup über dd dauert 15 Minuten
Der Backup? Ok, nun hab ich's wir sprechen gar nicht über das Backup. Dann liege ich natürchlich verkehrt.
Wie es mit der Bachup aussieht, da kann ich nicht mitreden.
>Daher sollte man hier nicht einfach Vorsicht als Paranoia abtun, das muss jeder für sich von Fall zu Fall >entscheiden.
EBEN
Zitat von: SCMP77 am 04 Februar 2016, 14:31:56
und trenne den regelmäßig alle 24h kurz vom Netz
OT: Wieso macht man sowas? ???
Zitat von: Benni am 04 Februar 2016, 18:27:19
OT: Wieso macht man sowas? ???
Es gibt mehrere Gründe. Der Hauptgrund sitzt zwischen Bildschirm und Rückenlehne. Ich habe mehrere Raspberrys, über die ich mit per ssh einlogge. Ein Raspberry steht in einer Entfernung von 300km und wenn man - wie leider schon geschehen - da versehentlich im falschen Fenster shutdown eingegeben hat, hätte man ohne Schaltuhr die A****karte gezogen. Mit einer Zeitschaltuhr weiß man, dass man spätestens in 24h wieder an das Teil kommt. Das ist meist zu verschmerzen.
Ein anderer Grund wäre der, wenn wirklich mal das Betriebssystem abschmiert, aber das ist mit bei den Raspberrys ohne mein dazutun noch nie passiert, obgleich im 24/7-Betrieb (also in der Praxis kein Grund).
Zitat von: SCMP77 am 04 Februar 2016, 14:31:56
...Ich habe meinen Raspberry auch an einer Zeitschaltuhr hängen und trenne den regelmäßig alle 24h kurz vom Netz, da der 300km entfernt von mir läuft. Mir ist es schon passiert, dass der Raspberry nach einer solchen Aktion nicht mit startete...
Dann würde ich ihn einfach durchlaufen lassen. ;)
Da hätte ich viel mehr Vertrauen zu, als zu einem täglichen Reboot.
Wozu soll das gut sein?
Mach Dir nen cronjob, der prüft und zur Not rebootet und/oder bieg das System um, dass ein shutdown immer ein shutdown -r bewirkt.
Hallo,
das einfach "vom Strom trennen" ohne sauberes runterfahren kann das Dateisystem zerschießen. Also wenn das trennen vom Strom notwendig oder sinnvoll ist, sollte der Raspi vorher mit einem Cronjob sauber heruntergefahren werden.
Gruß Christoph
Zitatauf diesem Raspberry ein Read-Only-Betriebssystem drauf
hast schon gelesen oder?
Hallo,
würde also heißen alle Log's, auch die vom System sind deakiviert bzw. schreiben in den Arbeitsspeicher / Ramdisk ? Na ja - ich habe bei " einfach abschalten" durch Strom weg irgendwie immer Bauchschmerzen. Fhem oder Betriebssystem ohne Log's - wie will man denn da rausfinden, wenn mal was nicht läuft.
Aber egal - jeder wie er mag, funktioniert ja anscheinend seit einiger Zeit problemlos so.
Gruß Christoph
Zitat von: Hollo am 04 Februar 2016, 20:12:14
dass ein shutdown immer ein shutdown -r bewirkt.
Danke für den Tip. Daran hatte ich nicht gedacht, so leicht bekommt man das Problem zwischen Bildschirm und Rückenlehne unter Linux in Griff.
Zitat von: Bennemannc am 05 Februar 2016, 07:08:46
würde also heißen alle Log's, auch die vom System sind deakiviert bzw. schreiben in den Arbeitsspeicher / Ramdisk ? Na ja - ich habe bei " einfach abschalten" durch Strom weg irgendwie immer Bauchschmerzen. Fhem oder Betriebssystem ohne Log's - wie will man denn da rausfinden, wenn mal was nicht läuft.
Die Logs werden auf den USB-Stick geschrieben, so dass die SD-Karte im Normalfall nie Schreibzugriffe sieht. Darauf sind die Logs-Files mittes fstab umgebogen.
Aber Du kannst ganz beruhigt sein, ich fahre das Teil kurz bevor es die Schaltuhr vom Strom trennt auch brav mit shutdown über systemd (ist ein Arch-Linux) runter. Nur wenn wirklich das Betriebssystem - aus welchem Grund auch immer - tot ist, gäbe es diesen Zwangsreset, ist aber bisher noch nie vorgekommen trotz mehr als 1 Jahr in dieser Form im Einsatz.
Schon mal darüber nachgedacht ein Fullbackup mit tar zu machen? Ich hatte da vor Jahren auf meinen Gentoo Servern mal so ein Script gehabt. mit --exclude kann man so Sachen wie /tmp /dev /sys /proc und so ausschließen.
Bedeutet, einmal ein dd Imagebackup machen. Und dann halt im INTERVAL ein Backup mit tar ziehen.
Und JA ein dd im laufenden Betrieb kann je nach Filesystem und Applikation zu erheblichen Problemen beim zurückspielen führen.
- asyncrones schreiben
- Vorhalten von Daten im RAM
- Datenbankapplikaionen
und so weiter.
Wenn es vereinzellt funktioniert heisst es einfach nur das das System Anspruchslos arbeitet. Auf gut Deutsch, Kinderkram drauf läuft.
Grüße
Zitat von: DieterL am 04 Februar 2016, 17:39:34
ja, ein raspberry ist ja auch ein hochverfügbarkeitssystem
Ich glaube Du verwechselst Betriebsicherheit mit Datensicherheit. Es ist nicht das gleiche.
1. Betriebsicherheit: Das System ist verfügbar
-> RAID, USV etc.
2. Datensicherheit: Bei Verlust sind die Daten trotzdem noch vorhanden
-> Backup (nur durch Backup)
Das 1. kann der RasPi nicht bieten, das 2. sehr wohl.
OT:
Kleiner Joke am Rande:
Ich amüsiere mich immer, wenn ich höre: Ich brauche kein Backup, ich habe doch ein RAID *lol*
Und bezüglich Tar:
Da kann man die gleichen Probleme wie mit rsync bekommen. Aber wenn man weiß damit umzugehen, ist es eine Lösung.
Ich denke mal das die meisten Leute hier und von denen Du sowas hörst wie ich habe doch Raid einfach nicht wissen was Datensicherung bedeutet. Sie kennen halt nur ihre privaten Sachen.
Leute die als IT'ler in nem Unternehmen mit Datensicherheit, Desasterrecovery und dergleichen zu tun haben denken da dann anders.
Ein Raid, ein Backup auf USB Stick oder externer Festplatte ist keine Datensicherung. Datensicherung bedeutet das eine nicht veränderbare Kopie eines Datenbestandes an einem externen Ort vorgehalten wird.
Auf gut Deutsch, alle Woche fahre ich mit ner Kiste Bänder zu einem Securityunternehmen.
Das ist Datensicherheit auf Firmenebene.
Wobei "alle Woche fahre ich mit ner Kiste Bänder zu einem Securityunternehmen." schon sehr extrem ist 8)
Aber schon eine Kopie kann eine Datensicherung und ein Backup sein. Und (auch privat!) wird eine Datensicherung immer wichtiger.
Kenne schon genügend Leute, die privat viel verloren haben. z.B. in einem Falle (nicht meinem): Alle Bilder der ersten 2 Jahre des Kindes .. weil der Laptop "runtergefallen ist" ...
Ich mache es deshalb:
Automatisches Backup auf eine, nur dafür hochgefahrene, USB-Festplatte. (Geht über Schaltbare Steckdose sehr gut 8) )
1 mal im Quartal lagere ich bei den Schwiegereltern aus.
Aber das wird jetzt hier OT ;o)
Thats my life 8)