Autor Thema: Fileserver, Datensicherung etc. für wichtige persönliche Erinnerungen  (Gelesen 6400 mal)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5620
  • Finger weg von der fhem.cfg
Bitte denke langfristig.Einen RAID-Level im Betrieb zu ändern ist gruselig (ja, es geht, aber wehe die USV versagt). Ich würde eher mehr in Platten invenstieren und von Anfang an mit dem richtigen RAID-Level starten.
Ich habe für mich entschieden, dass für mich Raid1 der richtige Level ist. Bei Raid5/6 gefällt mir nicht, dass im Prinzip keine Datei komplett auf einer Platte liegt. Bei Raid1 kann ich zur Not einfach eine der Platten nehmen und an irgend einen Rechner hängen. ...zumindest so lange der das Dateisystem kann.
Sollte ich das Raid-Level tatsächlich in ein paar Jahren mal ändern wollen, dann sieht sowieso wieder alles ganz anders aus. Dann stecke ich da einfach eine quantenverschränkte Doppel-Exabyte-Platte rein und gut ist. ;-)
Im Ernst: Bei meiner momentanen Planung können bis zu drei Platten kaputt gehen und für die ganz wichtigen Sachen gibt's noch ein Cloud Backup. Ich denke mal, dass mir das für die nächsten Jahre reicht.

mache ich mein Cloud Backup auf verschiedenen NAS von Freunden und Verwandten und nicht bei einem Cloud Anbieter...
Das hat was, aber mein QNap ist sozusagen das Live-System, das kann ich erstmal nicht weggeben.
Im Prinzip gebe ich Dir schon Recht. Allerdings ist die Cloud inzwischen so billig geworden, dass es sich kaum noch lohnt, ein zweites System bei einem Freund hinzustellen. Es gibt natürlich noch andere Gründe als den Preis...
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 5585
Aber dafür gibt es immer noch "Verschlüsselung".
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 927
Hmm, das Thema gehen einige sehr "high-end" an. RAID5/6 sind dann doch einige Platten, die schon ein bißchen Strom brauchen. Und Lärm machen. Und für jemanden, der sich nicht oft damit beschäftigt, eine ziemliche Herausforderung (Einrichtung, Wartung, etc.).

Ich würde für den Hausgebrauch da eher etwas einfacheres empfehlen. Und v.a. komplett auf RAID od. "exotische" Dateisysteme verzichten. Sofern sich das nicht alles mit klicki-klicki auf einer Weboberfläche administrieren lässt - was ich nicht beurteilen kann.

Ich hab mir irgendwann mal einen kleinen Server zusammengeschraubt. Der ist allerdings mehr auf Stromsparen und geringe Lärmentwicklung getrimmt, als auf Datensicherheit. Da liegen alle Daten drauf und werden mit einer Cloud-Lösung synchronisiert. Aber nur manuell, wenn's Änderungen gibt.
Und dann gibt's noch regelmäßige Backups bei größeren Änderungen auf zwei externe Festplatten. Wobei eine davon außer Haus gelagert ist.

Die Platten im Server und die externen werden alle 2 Jahre mal ausgetauscht.

Meiner Meinung nach reicht das vollkommen und ist ziemlich einfach zu handhaben. Restrisiko hab ich natürlich (unbemerkte Bitfäule z.B.), aber damit kann ich leben.

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5620
  • Finger weg von der fhem.cfg
Ich würde für den Hausgebrauch da eher etwas einfacheres empfehlen. Und v.a. komplett auf RAID od. "exotische" Dateisysteme verzichten.
Naja, zumindest Raid1 ist ziemlich einfach zu verstehen. Sogar meine alte kleine QNap TS-210 kann Raid1.

Zitat
Sofern sich das nicht alles mit klicki-klicki auf einer Weboberfläche administrieren lässt - was ich nicht beurteilen kann.
Gekaufte NASse können das. Nur dass das nicht so ganz das Richtige für mich ist. Man hat zwar eine bunte Oberfläche, aber wenn's mal nicht ganz auf Anhieb klappt, dann wird es schwierig. ...meiner Meinung nach.

Zitat
...Aber nur manuell, wenn's Änderungen gibt.
Und dann gibt's noch regelmäßige Backups bei größeren Änderungen auf zwei externe Festplatten. Wobei eine davon außer Haus gelagert ist.
Das ist ja alles gut, wenn man's dann auch wirklich macht. Das habe ich jetzt ein paar Jahre versucht und die Qualität meiner Backups... Naja. Für mich braucht's da was Automatisches.[/quote]
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 927
Zitat
Man hat zwar eine bunte Oberfläche, aber wenn's mal nicht ganz auf Anhieb klappt, dann wird es schwierig. ...meiner Meinung nach.
Ja, mir ist auch lieber, ich weiß, was sich im Hintergrund tut.

Zitat
Das ist ja alles gut, wenn man's dann auch wirklich macht. Das habe ich jetzt ein paar Jahre versucht und die Qualität meiner Backups... Naja. Für mich braucht's da was Automatisches.
Korrekt :)
Deswegen hab ich's so gelöst, dass ich nur die externe Festplatte anschalten muss und schon beginnt das Backup. Und die steht in PC-Nähe, ich kann's also gar nicht vergessen.

Beim automatischen Backup ist halt immer die Gefahr, dass einem ein Crypto-Trojaner das Backup verschlüsselt. Oder verschlüsselte Dateien sichert und die "guten" überschreibt.

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 5585
Dafür ist eine HD "in der Nähe" bei einem Brand auch weg ...

Und einen Automatismus vergisst man nicht.

Übrigens der Hinweis, das Rauid5/6 etc. mehr als eine Platte und damit auch deutlich mehr Stromverbrauch frisst (bei HDWare-Kontrollern erst recht), vergessen die meisten Experten im Hausgebrauch!
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline PeMue

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4950
Hallo zusammen,

ich habe jetzt mal die Ganze Zeit mitgelesen, aber ab und zu ein paar Sachen nicht verstanden.

RAID6 schützt Dich vor dem Festplatten-Ausfall (maximal zwei).
Warum braucht man da unbedingt RAID6? Würde nicht auch RAID1 reichen (ok, das sind nur gespiegelte Platten, aber wenn eine ausfällt, ist die andere immer noch da)?

Die USV schützt Dich vor dem Stromausfall und Datenverlust.
Was wäre in diesem Fall das "Horror-Szenario"? Stromausfall, wenn ich gerade auf das NAS schreibe und das Dateisystem geht so kaputt, dass beide Platten (ich gehe von RAID1 aus) defekt sind?

ZFS schützt Dich vor Bitrot.
Was versteht man darunter? Das graduelle "Kaputtgehen" der Festplatten? Kann man das nicht mit SMART oder anderen Tools überwachen?

Meine derzeitig angedachte Konfiguration wäre die folgende:
- DS216j mit 2x2TB in RAID1 (ohne USV)
- externe Festplatte, auf die ich regelmäßige Komplett Backups mache (allerdings stelle ich mir das externe Lagern bei den Eltern, o.ä. schwierig vor)
Wenn ich hier Platten vom selben Hersteller verwende (mit ggf. einem systematischen "Fehler" in der Degradation) würden die doch auch in einer ähnlichen Zeitspanne kaputt gehen, oder (zumindest theoretisch)?

Gruß PeMue
1x FB7170 (29.04.88) 5.7 1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F)
1x RPi BV2LCDCSM 1.63 5.7 2xMAX HKT, 1xMAX RT, V200KW1
1xFB 7490 (113.06.05) 5.7 1xCUL V3 1.63 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 1xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU 1xRFXtrx 90 1xWT440H 1xCM160 3xTFA30.3150 5xFA21

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19410
Zitat
Warum braucht man da unbedingt RAID6? Würde nicht auch RAID1 reichen (ok, das sind nur gespiegelte Platten, aber wenn eine ausfällt, ist die andere immer noch da)?

wenn dir der platz den eine platte liefert reicht und geschwindigkeit kein problem ist dann ist raid1 so gut wie raid5. bei beidem kann eine platte ausfallen. mit raid5 bekommst du mehr kapazität und/oder ein schnelleres system durch kleiner und/oder mehr platten. raid5 ist aber durch die prüfsumme etwas besser.

bei raid 6 können zwei platten ausfallen und es können mehr bit fehler erkannt und korrigiert werden.

das sind relevant weil selbst bei den aktuellen enterprise platten die garantierten fehlerraten etwa so gross sind das beim einmal komplette lesen der platte mit einem gekippten bit zu rechnen ist. aktuelle consumer platten haben nur fehlerraten von 2-3 bits pro komplettem lesen.

bei raid1 werden beide platten ziemlich gleich beansprucht. wenn sie aus der gleichen charge sind ist die wahrscheinlichkeit das die zweite genau dann den gleichen fehler zeigt und kaputt geht nicht zu vernachlässigen. das gilt besonders für ssd. ausserdem werden die platten durch das recovery zusätzlich beansprucht. je kürzer das braucht um so besser.

bei vielen kleinen platten ist der ersatz und recovery auch deutlich schneller als bei wenigen grossen.

Zitat
Was wäre in diesem Fall das "Horror-Szenario"? Stromausfall, wenn ich gerade auf das NAS schreibe und das Dateisystem geht so kaputt, dass beide Platten (ich gehe von RAID1 aus) defekt sind?
genau. filesystem so kaputt das nichts mehr zu machen ist. bei 'normalen' filesystemen gibt es fsck das meist noch etwas retten kann. journaling filesteme versuchen durch transaktionen das ganze so sicher zu machen das das problem nicht auftritt. ob durch design oder implementierungsfehler oder die verkettung unglücklicher umstände gelingt das nicht zu 100%.

'konventionelle' filessteme kann man im worst case eventuell durch kommerzielle 'retten' lassen. bei zfs wäre das ziemlich aussichtslos.

Zitat
Was versteht man darunter? Das graduelle "Kaputtgehen" der Festplatten? Kann man das nicht mit SMART oder anderen Tools überwachen?
zum beispiel die oben erwähnten bitfehler. zfs hat mehrstufige prüfsummen die diese verhindern. dafür erkauft man sich eventuell andere risiken. usv zwingend, ecc ram, kein fsck oder recovery.

smart tools helfen bei diesen fehlern nicht. da sie den daten nicht anzusehen sind. jedenfalls nicht ohne eine prüfsumme an genau dieser stelle.


es gibt professionelle systeme die platten von 3 oder 4 herstellern verwenden und die daten auf zwei redundanten systemen spiegeln die unterschiedliche software/firmware stände haben.

ich denke privat ist man mit drei sicherungen an zwei stellen schon ziemlich gut abgesichert. und man sollte nie vergessen das raid/zfs/... kein backup ist und dieses auch nicht ersetzt.

gruss
  andre

ps: 'nur' extern lagern reicht eigentlich nicht. in dem augenblick in dem du die platte bei dir hast um zu sichern ist alles an einem ort. ausserdem: wenn du da alte backup überschreibst und es dabei probleme gibt ist es futsch. externe daten sollte man über mindestens zwei sätze rotieren. dadurch ist beim überschreiben immer noch eines der beiden da und es sind nie alle am selben ort. ob das für den provatgebrauch wichtig ist muss jeder selber entscheiden. aber man sollte zumindest die stolperfallen kennen.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2127
  • On the Highway to Shell
solte man nicht durch "geschicktes" syncen eine ziemlich gute Ausfallsicherheit schaffen können?

Daily lokale Sicherung
Freitags Home --> Freund A (via rsync)
Donnerstags --> Freund A nach Freund B (via rsync)

Dann habe ich 3 "Generationen" verfügbar und auch an 3 verschiedenen Orten

lokal kann ich etwas schnelles haben und bei den "Freunden" etwas sparsames mit z.B. 8 oder 10 TB Archive Platten in einem einfachen NAS oder vielleicht auch an einem Raspberry PI :-) Geschwindigkeit brauchen wir ja nicht wirklich für nen Backup ...
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5620
  • Finger weg von der fhem.cfg
Hi,
inzwischen hat sich bei mir einiges getan. Ganz fertig ist das Setup noch nicht, aber möglicherweise interessiert sich ja jemand dafür.

Hardware
  • HP ProLiant Gen8 MicroServer - Celeron G1610T (Das ist der Backup-Server.)
  • Festplatten: 2 6TB WD Red Festplatten
  • Ein 32GB USB-Stick für's Betriebssystem
  • Ein Werbegeschenk-USB-Stick mit 128MB als Installationsmedium
  • Eine alte NAS: QNap TS-210 (Das ist sozusagen das Live-System.)
  • ...mit 2 neuen Platten: 4TB WD Red
  • Eine (auch etwas ältere) 1TB-USB-Platte als "Zwischenlager"

Setup Backup-Server
Diese ProLiant-Teile haben ein so genanntes "Intelligent Provisioning", das einem irgendwie helfen soll, die aktuelle Firmware zu bekommen. Außerdem gibt es andere gaaanz tolle Dinge auf den Teilen, die aber alle nicht richtig funktionieren wollten. Trotz Registrierung mochte das Teil mein Netzwerk nicht. Außerdem haben diese Tools es auch nicht gemocht, dass ich das System erstmal ohne Festplatten eingerichtet habe.
Das einzige, was wirklich funktioniert hat, war das gute alte BIOS-Setup, in dem ich statt dem Hardware-Raid "AHCI" gewählt habe.

Der Server hat im Gehäuse einen USB-Slot und einen SD-Card Slot. Das kam mir gelegen, da ich das Betriebssystem nicht auf den Daten-Platten haben will. Jetzt ist das ganze nicht ganz so einfach wie bei einem RasPi. Man braucht also einen Monitor, eine Tastatur und ein Installationsmedium. Zum Glück lag noch irgendwo ein USB-Stick rum. Naja, 128MB ist nicht gerade viel. Es gibt aber einen aktuellen Debian-Installer, der nur 29MB braucht.
Also wie bei einer RasPi-Installation per Win32DiskImager das Installationsimage auf den Mini-Stick geflasht, den 32GB-Stick innen rein und den 128MB-Stick außen. ...und starten.
Die Installation hat auf Anhieb geklappt, nur dass der nächste Reboot nur eine Fehlermeldung brachte. Das Problem war, dass der Installer nur eine Partition fabriziert, die aber anscheinend für's BIOS beim Booten zu groß ist. Also alles nochmal und beim Installieren eine eigene /boot Partition am Anfang des 32GB-Sticks erstellt.
Jetzt klappt auch der Reboot.

Nächster Schritt: Festplatten einbauen. Das ist einfach...
Das Dateisystem soll ein ext4 auf einem normalem Software-Raid1 sein. Also mit mdadm ein Raid1-Device (/dev/md0) aus /dev/sda und /dev/sdb erstellen. Manche Anleitungen sagen zwar, dass man die Platten erst Partitionieren muss, aber das war zumindest bei mir unnötig.
Das Syncen der Platten kann man mit "cat /proc/mdstat" beobachten. Am Anfang erschien das furchtbar langsam, aber irgendwann lief's dann schneller. Man muss aber nicht darauf warten.
...also gleich mkfs.ext4 und das ganze in die /etc/fstab eingetragen.

"Upgrade" der Qnap TS-210
Blöderweise gibt es bei dem Teil keine Möglichkeit, die Festplattenkapazität zu vergrößern. (Auch nicht, wenn man erstmal eine austauscht, dann Raid-Sync, dann die andere etc.)
Also mit dem QNap "Backup" alles auf eine externe USB-Disk, die alten Platten raus und neue rein.
Beim nächsten Start merkt das Teil, das alles neu ist und lässt sich komplett frisch aufsetzen. Das war sowieso mal fällig... Man darf wohl nur nicht den Fehler machen, den ganze Multimedia-Kram zu aktivieren. Das einzige, was das Teil wirklich schafft ist der Minim-Server.
Jetzt per Qnap-Backup alles wieder zurückspielen. Blöderweise gibt das immer nach etwa 1000 Dateien auf, obwohl das Backup durch genau dieses Tool geschrieben wurde. Na dann eben ssh und cp, das klappt.

Spaßeshalber habe ich ausprobiert, ob QSync jetzt besser klappt als vorher. In der Tat, das tut es. Jetzt werden die Fotos von unseren Smartphones automatisch gespeichert und die Laptops habe sowas wie eine private Dropbox.

...to be continued.
Gruß,
   Thorsten

 

RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5620
  • Finger weg von der fhem.cfg
Hi,
so, jetzt geht's weiter mit der rdiff-backup Installation. Doch zuerst zu meinem Plan: Die Idee ist, die QNap-Kiste per rdiff-backup auf den Backup-Server zu sichern. Um das Zurückholen und Überprüfen der Backups einfach zu gestalten, sollen die Backups per rdiff-backup-fs gemountet und per Samba-Share zur Verfügung gestellt werden.

Installation von rdiff-backup auf QNap TS-210
Damit rdiff-backup richtig funktioiert, muss es auf beiden Systemen installiert sein. Für die QNap-Kisten gibt es dazu Anleitungen, die aber so nicht (mehr) funktionieren. Das liegt daran, dass Optware nicht mehr unterstützt wird. Man findet dann irgendwo Entware, aber das wurde jetzt wohl durch Entware-ng ersetzt. Der Rest geht sinngemäß...
Also rdiff-backup ließ sich mit Entware-ng installieren. Allerdings heißt es bei rdiff-backup, dass die Versionen auf beiden Maschinen gleich sein sollte. Also:
[~] # rdiff-backup -V
rdiff-backup $version
Super... Die Version ist "$version". Zumindest erzeugt der Aufruf keine Fehlermeldung. Es hat sich am Ende herausgestellt, dass das nur eine Warnung erzeugt, aber es scheint alles ganz normal zu funktionieren.

Installation von rdiff-backup und rdiff-backup-fs auf dem Backup-Server
Das ging problemlos mit apt-get. Ich habe auch gleich rdiff-backup-fs mitgenommen.
Von der Kommandozeile aus funktioniert rdiff-backup jetzt. Bei ersten Mal hat es natürlich eine Weile gedauert, danach aber nur noch ein paar Sekunden.
Das ganze mounten per rdiff-backup-fs war erstmal auch kein Problem. Das Ergebnis sieht dann so aus:
thorsten@backupserver:/backup-fs$ ls -ls
insgesamt 0
0 dr-xr-xr-x 12 root root 4096 Okt 23 19:58 2016-10-23-10-05-42
0 dr-xr-xr-x 12 root root 4096 Okt 23 19:58 2016-10-23-14-08-58
0 dr-xr-xr-x 12 root root 4096 Okt 23 19:58 2016-10-23-17-55-00
0 dr-xr-xr-x 12 root root 4096 Okt 23 19:58 2016-10-23-17-57-18
thorsten@backupserver:/backup-fs$
D.h. jeder "Snapshot" wird als eigenes Verzeichnis dargestellt, das die kompletten Daten zu dem entsprechenden Zeitpunkt zu enthalten scheint.

rdiff-backup-fs und Samba
Jetzt wurde es etwas abenteuerlich. Man könnte meinen, dass das ganz einfach wäre. Den Mountpoint vom rdiff-backup-fs in Samba als read-only freigeben und das war's. Tja, alle Versuche enden auf der Windows-Seite immer mit etwas wie "Zugriff verweigert".
Nach einigem Suchen zu rdiff-backup-fs und anderen "fuse"-Dateisystemen habe ich die fuse-Option "allow_other" gefunden, die das Samba-Problem normalerweise löst. Dummerweise kann rdiff-backup-fs aber keine allgemeinen fuse-Optionen. ...zumindest laut man-Page.
Jetzt habe ich aber irgendwo was gefunden, was tatsächlich rdiff-backup-fs mit fuser-Optionen benutzt. Also das ganze bei git gefunden und den Sourcecode betrachtet. Laut Sourcen geht das, aber bis etwa vor 6 Jahren gab es genau da einen Bug. Also Sourcen von git geholt und das ganze mal selbst zusammengebaut (ok, das hat auch etwas gedauert). Damit klappt's dann auch mit Samba, wenn man die Option "-o allow_other" verwendet.
...naja, fast. Die Dateinamen der Verzeichnisse auf den Linux-Seite enthalten ":" (also nicht so wie oben, das ist nach meinen Änderungen). Nach einer kleinen Änderung in den Sourcen klappt jetzt auch das. (Siehe Screenshot.) Wenn sich jemand für die rdiff-backup-fs-Version interessiert, bitte Bescheid sagen.

Blöderweise habe ich gerade gemerkt, dass sich über das Share die Dateien selbst nicht runterladen lassen. ...aber das wird sich auch noch hinbiegen lassen.

Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5620
  • Finger weg von der fhem.cfg
Hier ist jetzt auch der Patch, der das letzte Problem mit rdiff-backup-fs hinbiegt:
https://github.com/rbrito/rdiff-backup-fs/issues/11
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5620
  • Finger weg von der fhem.cfg
Antw:Fileserver, Datensicherung etc. für wichtige persönliche Erinnerungen
« Antwort #42 am: 13 November 2016, 22:32:20 »
Hi,
inzwischen habe ich eine (meiner Meinung nach) ganz gute Lösung gefunden. ...aber nicht mit rdiff-backup. Es sieht so aus, als ob rdiff-backup nicht wirklich weiterentwickelt wird. Es gab damit mehr und mehr Problemchen. Ich hatte dann mal kurz mit dirvish angefangen, aber damit bin ich auch nicht wirklich klargekommen.
Also die Platten wieder platt gemacht und dann doch btrfs drauf. Die Möglichkeit, einfach mal schnell einen Snapshot zu erzeugen oder wegzuwerfen ist für ein Backup-System schon richtig gut. 
Ein Backup geht dann einfach, indem man die Daten per rsync in ein Subvolume schiebt, und davon dann einen Snapshot macht. So ungefähr sehen meine Backup-Skripte aus:   
 
 
#!/bin/sh
COMMAND="rsync --progress --archive --one-file-system --hard-links --inplace --delete --delete-excluded --include-from=/var/backups/rsync/backup-list-kellerassel kellerassel::root /backup/kellerassel/next"
export RSYNC_PASSWORD="<something more or less secret>"
#run rsync
stdbuf -oL $COMMAND
# if this went ok, create a new snapshot and soft-link it to .current
if [ $? -eq 0 ]
then
    NEWNAME="`date +'%Y-%m-%d.%H-%M-%S'`"
    /sbin/btrfs subvolume snapshot /backup/kellerassel/next /backup/kellerassel/$NEWNAME
    rm /backup/kellerassel/current
    ln -s /backup/kellerassel/$NEWNAME /backup/kellerassel/current
else
    echo 'Something went wrong with rsync'
fi
Die Dinger sind über cron automatisiert, so dass ich jeden Morgen ein Protokoll über das nächtliche Backup bekomme.
Über /backup/kellerassel/current kann man dann immer auf das neuste Backup zugreifen. Ältere Backups haben Datum und Zeit im Namen.
Das ganze geht auch mit Windows-Rechnern, wobei die Installation von rsync da etwas komplizierter als normal ist.
Die Backup-Verzeichnisse (also eigentlich nur /backup) ist als read-only Samba-Share freigegeben. So kann man dann ganz gemütlich auf alles zugreifen. Das ganze sieht dann so wie im Screenshot im Anhang aus.

Da das alles nicht wirklich Unterverzeichnisse sind, sondern btrfs-Subvolumes, lassen sie sich auch schnell löschen, wenn dann doch mal der Plattenplatz knapp wird. Das dürfte aber noch eine Weile dauern, dank COW.

Wichtige Sachen werden außerdem noch in die Amazon-Cloud geschoben. Das passiert momentan auch über rsync, wobei die Amazon-Cloud über acd_cli gemountet ist. Allerdings geht das sehr, sehr langsam. Das liegt auch daran, dass das ganze jede Nacht abschmiert. Ich glaube, dass das an der kurzen Verbindungs-Trennung der Fritzbox liegt. Dabei bleibt dann entweder acd_cli oder irgendwas im rsync so übel hängen, dass man einen der rsync-Prozesse nicht einmal mehr mit kill -9 abschießen kann. Man muss dann zuerst den acd_cli-Prozess abschießen, dann mit "umount -rl" die Amazon Cloud trennen. Dann "stirbt" auch der rsync irgendwann und man kann von vorne anfangen.
Hat dazu vielleicht noch jemand eine Lösung parat? Möglicherweise ist es aber auch gar nicht so wild. Wenn der initiale Lauf mal durch ist, dann sollte das ja auch nicht immer so lange dauern, dass die Zwangstrennung dazwischenkommt.

Gruß,
   Thorsten
 

 
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 5585
Antw:Fileserver, Datensicherung etc. für wichtige persönliche Erinnerungen
« Antwort #43 am: 14 November 2016, 09:20:36 »
Hast Du denn wirklich noch "Zwangstrennung"? Wenn das Telefon auch darüber leuft, macht die TELEKOM die Zwangstrennung nicht mehr ...

Ansonsten knnst Du nur Probieren, die Zwangstrennung nicht in der FritzBox, sondern von Deinem Backupsystem auszulösen:
Zitat
rsync-stoppen
AWS unmounten
Trennung und Wiederverbindung auslösen
AWS mounten
rsync wieder starten
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5620
  • Finger weg von der fhem.cfg
Antw:Fileserver, Datensicherung etc. für wichtige persönliche Erinnerungen
« Antwort #44 am: 14 November 2016, 10:07:12 »
Hast Du denn wirklich noch "Zwangstrennung"? Wenn das Telefon auch darüber leuft, macht die TELEKOM die Zwangstrennung nicht mehr ...
Tja, zumindest sagt meine Fritzbox das hier:
14.11.16 03:56:44 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
Danke aber für Deinen Hinweis, ich habe das jetzt in der Fritzbox abgeschaltet. Mal sehen, ob die Telekom tatsächlich die Verbindung "ewig" hält.
Auch wenn das jetzt klappt, dann ist es trotzdem ärgerlich, dass acd_cli oder rsync of diese Art und Weise abschmiert. Es kann ja immer mal sein, dass die Verbindung kurzzeitig aussetzt. Eigentlich würde man erwarten, dass das System dann eine Weile wartet und dann normal weitermacht oder aber mit einem Timeout die entsprechenden Prozesse gestoppt werden.

Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

 

decade-submarginal