|
|
| Zeile 3: |
Zeile 3: |
| =Wohin es geht= | | =Wohin es geht= |
|
| |
|
| Wir wollen die Daten unserer Benutzer nicht an einem x-beliebigen Platz speichern, daher wird das Backup momentan auf ''bilbo.bwurst.net'' gemacht, das ist ein Rechner, der bei mir zuhause steht und über DSL angebunden ist.
| | Sei unserem Umzug zum Provider 1&1 haben wir Zugriff auf einen FTP-Backup-Speicherplatz. Der Nachteil dieses Speicherplatzes ist, dass er nicht vertrauenswürdig ist. Der Zugriff erfolgt unverschlüsselt, es ist nicht definiert, wer auf die Daten zugreifen kann und wer nicht. |
| | Daher wird unser Backup lokal verschlüsselt und signiert und so auf dem FTP-Server gespeichert. |
|
| |
|
| ==Hardware== | | =Software= |
| | | Angeregt durch den Artikel »Hinter Schloss und Siegel« aus der Zeitung c't 13/06 benutzen wir das Script »ftplicity«, ein Wrapper um »duplicity«. |
| Der Rechner ist ein P-III mit 700 MHz und 256 MB RAM. Als Speicherplatz stehen 2 x 160 GB und 1 x 80 GB zur Verfügung. Dabei ist eine der 160 GB Platten für das Backup vorgesehen und bietet genügend Platz dafür.
| | Dank der Benutzung von librsync werden dabei nur Änderungen übertragen. |
| | | =Wiederherstellung von Dateien= |
| ==Software==
| | Datei <code>my/file</code> nach <code>/root/target/file</code> wiederherstellen. |
| | | <pre>ftplicity fetch my/file /root/target/file</pre> |
| Keiner hätte es geglaubt, aber ''bilbo'' läuft ebenfalls auf Gentoo Linux. ;-)
| |
| | |
| =Autentifizierung=
| |
| | |
| Die nächste Frage stellt sich, wie wird gesichert, dass nur das Backup vom schokokeks Zugriff darauf hat und wie wird überhaupt sichergestellt, wer da was macht?
| |
| | |
| Die Antwort ist simpel. Das Script auf dem Server nutzt einen speziellen rsync-Befehl, der eben grade dazu genutzt wird, Dateien ''vom Server auf bilbo'' zu übertragen. Dieser Befehl wird per SSH gesendet und dort von einem Script abgefangen. Nur wenn exakt dieser erlaubte Befehl genutzt wird, wird der Befehl ausgeführt. Unter anderem muss das Zielverzeichnis auf bilbo stimmen und der letzte Parameter sein. Somit ist auch keine übertragung vom Backup möglich, das heisst nichtmal Administratoren des schokokeks können Dateien aus dem Backup zurückholen.
| |
| | |
| =Daten zurückholen=
| |
| | |
| Um Daten aus dem Backup zurückzuholen ist root-Zugriff auf bilbo nötig. Nicht mehr und nicht weniger.
| |
| | |
| =FAQ=
| |
| | |
| Auch wenn mir keiner bisher konkrete Fragen gestellt hat, schreib ich mal das, was ich hierzu fragen würde. ;-)
| |
| | |
| '''Und das funktioniert, Backup zum DSL-Rechner?'''
| |
| :Ja, recht gut sogar. Dank rsync werden nur die änderungen übertragen.
| |
| | |
| '''Ist das nicht schweinelangsam?'''
| |
| :Das Backup läuft etwa 10 Minuten täglich. Klar, für das Backup nutzt man ja den downstream, die Daten kommen ja zu mir rein. Also 80KB/s.
| |
| | |
| '''Was, wenn deine Verbindung kurz vorher einbricht und die IP plötzlich jemand anderem zugeteilt wird?'''
| |
| :Theoretisch gibt es nur ein Zeitfenster von 2 Minuten, dann wird der DynDNS aktualisiert. Wenn er das nicht wird (warum auch immer) kommt das Zwangs-DNS-Update alle 2 Stunden. Wenn in der Zeit jemand anders die selbe IP bekommt (unwahrscheinlich aber nicht ausgeschlossen), dann werden dahin erstmal gar keine Daten übertragn, weil der SSH-Host-KEY ja dann garnicht stimmt. Erst wenn der stimmt (praktisch nicht fälschbar), wird per Public-key eingeloggt. Also muss derjenige erstmal den public-key des backups kennen. Auch das ist zwar theoretisch möglich aber praktisch nicht vorstellbar. Ja, ein Backup zu einem Rechner mit fester IP wäre mir auch lieber, aber ich will die Daten nicht in anderer Leute Hände geben. Ich kann mir kein Szenario vorstellen, in der alle obigen Faktoren genau zusammentreffen. Dazu müsste jemand entweder den DNS auf dem Server oder meine DSL-Leitung manipulieren, denn zufällig kommt das nicht alles zusammen...
| |
Ich will hier kurz erläutern, wie das Backup bei uns momentan funktioniert.
Wohin es geht
Sei unserem Umzug zum Provider 1&1 haben wir Zugriff auf einen FTP-Backup-Speicherplatz. Der Nachteil dieses Speicherplatzes ist, dass er nicht vertrauenswürdig ist. Der Zugriff erfolgt unverschlüsselt, es ist nicht definiert, wer auf die Daten zugreifen kann und wer nicht.
Daher wird unser Backup lokal verschlüsselt und signiert und so auf dem FTP-Server gespeichert.
Software
Angeregt durch den Artikel »Hinter Schloss und Siegel« aus der Zeitung c't 13/06 benutzen wir das Script »ftplicity«, ein Wrapper um »duplicity«.
Dank der Benutzung von librsync werden dabei nur Änderungen übertragen.
Wiederherstellung von Dateien
Datei my/file nach /root/target/file wiederherstellen.
ftplicity fetch my/file /root/target/file