Netz - Rettung - Recht (Artikel mit Tag Backup)

Synology DS220+

nospam@example.com (Thomas Hochstein) — Thu, 17 Feb 2022 05:15:00 +0000

In den Jahren 2011 und 2013 hat sich jeweils einiges an der heimischen IT-Infrastruktur - im Heimnetz - getan. 2011 habe ich - mehrere Jahre nach dem Umzug - in unserer neuen Wohnung einen Server eingerichtet und die alte Maschine an anderem Orte in den Ruhestand geschickt; außerdem habe ich die gesammelten Daten von primär einem, letztlich aber mehreren alten Rechner gesammelt auf meinen aktuellen Desktoprechner übertragen und eine aktuelle Version meines damaligen (und jetzigen) Mail- und Newsreaders installiert. 2013 kamen ein Multifunktionsgerät (Drucker/Scanner/Fax) und ein NAS - eine DiskStation von Synology - hinzu (und ein neuer Desktop, der Vorgänger meines aktuellen Geräts).

Überraschend viel davon ist geblieben: der nunmehr mehr als 11 Jahre alte Homeserver, für den schon ein Ersatz bereitsteht, den ich irgendwann einmal einrichten müsste; die Datenstruktur auf meinem Desktoprechner und Agent als News- und Mailclient; bis vor zwei Jahren der Drucker; und auch das NAS. Im Prinzip war ich mit letzterem und meinem Backupkonzept auch ganz zufrieden; 2017 hatte ich nach einem (mutmaßlichen) Plattenschaden mal neue, etwas größere Platten (4 TB statt 3 TB) eingebaut, aber nach diesem Plattentausch ging alles weiter seinen geregelten Gang.

Dieser Gang war allerdings in den letzten Monaten etwas holprig, denn oft mangelte es an Platz, sowohl auf dem NAS als auch (vor allem) auf den USB-Platten für das externe Backup. Auf das NAS laufen Backups des Homeservers (täglich, automatisch, inkrementiell mit jedem Monat einem neuen Vollbackup), des Desktops und zweier Laptops (manuell, üblicherweise wöchentlich). Und mit der Zeit wurden (vor allem auf dem Desktop, aber auch den Laptops) die Platten größer, die Datenmengen wuchsen und man musste den Platzbedarf etwas im Blick haben. Zuerst erforderten die externen Backups regelmäßige manuelle Eingriffe (Löschen aller vorigen Versionen, damit das neue Backup passt), was schon nervig genug ist; ein Backup von 2-3 TB über USB 2.0 kann schnell länger als 24 Stunden dauern, und wenn das Backup dann fehlschlägt, muss man der Software beim Löschen des angefangenen Backups und der noch auf der Platte befindlichen Vorversion(en) das Händchen halten und das Backup dann später neu starten. Das ist ein deutlich größerer Aufwand als “einmal pro Woche morgens die Platte abstöpseln, ins Büro mitnehmen und am Abend die aus dem Büro mitgebrachte andere Platte wieder anstöpseln” und führt daher dazu, dass das externe Backup eher so alle 4-6 Wochen anstatt wöchentlich erfolgte. Und erst das, dann aber tatsächlich auch der knapper werdende Platz auf dem NAS führten dazu, dass ich erst die Anzahl der inkrementiellen Backups heruntergesetzt habe und dann immer fauler mit den Backups wurde - auch weil diese gerade als Vollbackup mit Validierung so lange dauerten, dass morgens der Rechner nicht zur Verfügung stand, weil das über Nacht gestartete Backup noch nicht fertig war. (Und weil ich die verschlüsselte Platte mit privaten Daten vor dem Backup dismounte, damit der Container ordentlich gesichert wird, kann ich dann nicht richtig arbeiten.) So fanden dann auch die Sicherungen von Desktop und Laptop mehr monatlich - beim Laptop aufgrund der seltenen Nutzung eher quartalsweise - als wöchentlich statt. Alles sehr unbefriedigend.

Dann las ich Anfang Februar zufällig bei Isotopp einen Blogbeitrag über eine Erweiterung des Fileservers - weil der Nachwuchs eine größere Platte im Laptop hat und daher mehr Backupplatz benötigt wird. Da wurden mal eben zwei zusätzliche 10-TB-Platten als RAID eingebaut. Und nachdem ich das gelesen hatte, habe ich mich ernsthaft gefragt, warum ich nicht einfach schon vor Jahren schlicht größere Festplatten gekauft habe. Gut, ich habe keinen Platz, um sie dazuzustecken, ich müsste die Platten austauschen, aber das ist kein großes Problem, und es ist nicht so, dass ich mir das nicht leisten könnte. Und deutlich größere Platten würden das Platzproblem schlicht lösen; mir war gar nicht recht präsent, welche Plattengrößen jetzt üblich und erschwinglich sind, zumal ich im Desktop nicht viel Platz brauche. Kaum hatte ich mir das gedacht, erinnerte ich mich daran, dass mich neben dem Platzmangel auch die fehlende Leistung des NAS zunehmend störte; es dauerte alles lange, die CPU war immer ausgelastet, und der Weboberfläche konnte man beim Start einer App gemütlich zuschauen und mal schnell einen neuen Kaffee holen. Nach 9 Jahren durfte es auch da vielleicht mal etwas Neues sein.

Eigentlich wollte ich darüber in Ruhe nachdenken und mich dann am Wochenende entscheiden, aber die Sache ließ mir keine Ruhe - eine kurze Recherche ergab, dass man problemlos Platten mit 10 TB, 12 TB oder mehr bekommt, und auch die Auswahl bei der Vielzahl der auf der Website von Synology angebotenen Geräte fiel mit passenden Filtern und den angebotenen Assistenten leicht: mindestens zwei Platten sollten es sein, und Hot-Swap-fähig sollte das Gerät auch sein. Nach kurzer Bedenkzeit - es müssen nicht drei oder vier Platten sein; optisch gefällig wäre schon schön; und ich muss zwar nicht sparen, aber auch nicht verschwenden - fiel dann noch am selben Tag die Entscheidung für ein Synology DS220+ und zwei 12-TB-Platten von Western Digital. Am Folgetag entschloss ich mich dann in der Mittagspause, das Konzept des externen Backups auf USB-Platten fortzuführen und kaufte noch zwei 14-TB-USB-Platten von Western Digital dazu. Bis Freitag war dann auch alles da, und ich konnte abends mit der Installation beginnen (um am Wochenende die Daten umzukopieren).

Allerdings hatte ich die Rechnung ohne den Wirt gemacht: trotz vielem hin und her erkannte das NAS nur eine Festplatte. Und nachdem ich die Platten im laufenden Betrieb getauscht hatte, ging natürlich gar nichts mehr. Eine Neuinstallation mit vertauschten Platten schlug fehl; der dritte Versuch - wieder in der ursprünglichen Konfiguration - brachte auch wieder das ursprüngliche Ergebnis. Und wenn man aufmerksam lauschte, hörte man auch das typische Klicken einer Platte, die anzufahren versucht, aber nicht anläuft. Offenbar war eine der Platten “dead on arrival”. Das kann natürlich passieren, nervte mich aber einigermaßen - zumal der Samstagvormittag schon mit diversen Besorgungen gefüllt war. Aber es half ja nichts, und so schob ich noch einen Besuch bei der örtlichen Filiale des Computerhändlers meines Vertrauens ein und kaufte eine dritte 12-TB-Platte. Wieder zuhause setzte ich sie ein … und endlich lief alles so, wie es laufen sollte, und ich konnte mein neues NAS endlich einrichten.

Damit war ich sehr zufrieden: alles läuft so flott und flüssig, und es ist soviel Platz! Jetzt noch schnell ein letztes Backup des alten NAS auf die mobile Platte, das dann Überspielen, und dann ist alles fertig. Nur … passte das Backup natürlich nicht auf die USB-Platte. Wie immer. Also musste ich das Backup dann nach vielen Stunden abbrechen, die alten Versionen löschen und es dann neu starten. Und das dauerte. Und dauerte.

Datensicherungsaufgabe: USB-Sicherung 1
Sicherungsziel: usbshare1
Start: Mo, 7 Feb 2022 19:37:33
Dauer: 3 Day 2 Hour 11 Minute 3 Second

Glücklicherweise hatte ich bereits am Wochenende begonnen, die Daten einfach “manuell” umzukopieren. Beide NAS exportieren die entsprechenden Verzeichnisse als Netzlaufwerke, also per SMB, und so kann man im Prinzip schlicht alles über den Windows-Explorer von einem aufs andere Verzeichnis verschieben. Das ging ganz gut und war nach wenigen Stunden erledigt. Die unter einem anderen Account laufenden Dateien des Server-Backups ließen sich nicht auf diese Weise verschieben - Windows mäkelte, dass es nicht zwei Verbindungen unter verschiedenen Nutzerkennungen zum selben Gerät vornehmen könne, und ich hatte keine Lust, eine Lösung dafür zu suchen. Warum nicht einfach vom Server aus die Dateien umkopieren? Gesagt, getan … und nachdem SFTP/SCP dafür nicht das richtige Tool schien, habe ich mich auch da für SMB entschieden. Ein wenig Googeln führte zu folgender einfacher Lösung:

mkdir /mnt/nasalt
mkdir /mnt/nasneu
mount -t cifs -o user=serveruser //nasalt/home /mnt/nasalt
mount -t cifs -o user=serveruser,vers=2.0 //nasneu/home /mnt/nasneu
cp -av /mnt/nasalt/backups/* /mnt/nasneu/backups/

Auch das war binnen vergleichsweise kurzer Zeit erledigt.

Für duply und duplicity auf dem Server reichte die Änderung des Backupziels; ähnlich funktionierte das mit Acronis True Image für Desktop und Laptop, wobei dort nach der Änderung des Backup-Ziels das dort bereits vorhandene Backup noch eingebunden werden musste. Das nächste Backup machte dann einfach dort weiter, wo es auf dem alten NAS aufgehört hatte, und zumindest gefühlt ging es auch schneller.

Danach habe ich direkt die erste externe Sicherung durchgeführt, und die ging nicht nur gefühlt schneller, sondern war - mit schnellerer CPU und USB 3 statt USB 2 - sehr, sehr deutlich spürbar flotter. Die beiden folgenden Screenshots zeigen u.a. die Dauerlast der CPU auf beiden Geräten im Vergleich; auf dem neuen NAS ist sie nicht einmal halb so hoch.

Nachdem mehr als drei Tage später (!) die Sicherung des alten NAS auf USB-Platte abgeschlossen war, habe ich von dieser Platte die letzten noch fehlenden Daten auf das neue NAS überspielt und dann das alte NAS (und die nicht mehr benötigten alten USB-Platten) neu initialisiert. Jetzt kann die alte Synology DS213 mal zeigen, was ein solches Gerät wirklich kann, statt nur als Fileserver für Backups zu dienen: sie soll nämlich in Zukunft an ihrem neuen Standort (bei der FRITZ!Box) als Medienserver für den Hausstand dienen, zunächst einmal für Musik, späer vielleicht auch für Fotos und Videos. Dafür konnte ich dann die NAS-Funktion in der FRITZ!Box deaktivieren und die dort angehängte externe USB-Platte anderweitig verwenden.

Bislang gefällt mir die neue Lösung, die sich auch in der Beschreibung auf meiner Website widerspiegelt, ausnehmend gut.

Titelbild © blickpixel - Fotolia

Backupkonzepte

nospam@example.com (Thomas Hochstein) — Mon, 17 Jul 2017 05:45:00 +0000

Je mehr wir uns auf Computer verlassen und wesentliche Teile unseres Lebens, unser Erinnerung nur noch digital existieren, desto wichtiger wird der Schutz dieser Daten sowohl gegen unbefugten Zugriff als auch gegen Verlust oder mutwillige Zerstörung.

Ich hatte in der Vergangenheit bereits das eine oder andere Mal berichtet, wie ich meine Daten sichere - nicht immer sehr fleißig und mit größter Konsequenz, weil die Bequemlichkeit oft vorgeht, aber über die Jahre dann doch überall irgendwie.

Grundsätzliche Überlegungen

Backups nutzen nur, wenn sie möglichst aktuell sind und sich auch möglichst leicht wieder einspielen lassen.

Backups werden nur genutzt, wenn sie möglichst wenig manuellen und zeitlichen Aufwand erfordern.

Daraus ergibt sich die Notwendigkeit einer möglichst weitgehenden Automatisierung. Hinzu kommen Überlegungen zur Datensicherheit (Unbefugte sollen auf die Backups nicht zugreifen können), auch bei der Übertragung, und auch zur Redundanz (was nützt ein Backup, wenn Einbrecher oder Feuersbrunst zusammen mit Rechner und Daten auch das Backup zerstören?).

Jedenfalls für mich bedarf es auch unterschiedlicher Konzepte für (Miet-)Server in einem Rechenzentrum gegenüber Rechnern in der heimischen Wohnung, für im Dauerbetrieb befindliche Maschinen (Server) gegenüber Laptops oder Desktoprechnern und für Linuxrechner gegenüber Windowsmaschinen.

Für das alles gibt es eine Vielzahl von Lösungen. Ich möchte meine hier vorstellen.

Backups von Mietservern

Oft ist - oder war jedenfalls früher - bei Mietangeboten für Server ein (meist nur über FTP erreichbarer) “Backupspace” inkludiert. Teilweise kann man solchen kostenpflichtig hinzubuchen. Nicht immer überzeugte das Konzept; bei 1&1, einem nicht gerade kleinen Anbieter, waren Backupserver nicht nur ab und an nicht erreichbar (was man dem Support jeweils mitteilen musste - das blieb sonst mehrere Tage lang so), es ist mir dort auch direkt zweimal passiert, dass die Daten auf dem Backupspace plötzlich “weg” waren (ebenfalls ohne dass es darüber eine Benachrichtigung gegeben hätte). Ich nutze daher dort, wo es keinen kostenlosen Backupspace gibt, Amazons Simple Cloud Storage Service‎ S3, und dort, wo es Backups gibt, lege ich regelmäßig ein Zweitbackup via S3 an. Damit habe ich auch zugleich ein “Offsite-Backup”.

Früher habe ich die Backups teilweise nach Hause geholt - das Problem daran ist (und war insbesondere zu Zeiten von DSL-2000 & Co.), dass der Download über Nacht schnell geht, aber der Upload für ein mögliches Restore keinen Spaß macht.

Für das Backup verwende ich duply (bzw. duplicity). Damit sichere ich im Prinzip die komplette Platte, täglich inkrementell und einmal monatlich vollständig. Vorher dumpe ich die mySQL-Datenbanken in gepackte Textdateien, um sie in einem definierten Zustand vorliegen zu haben. duply verschlüsselt die Backups mit einem GPG-Schlüssel, so dass das Übertragungsprotokoll letztlich egal ist; auch FTP geht. Einmal eingerichtet, ist der Aufwand gering; es läuft eben alles automatisch.

Mein Vorgehen habe ich bereits 2011 bzw. 2016 hier im Blog beschrieben:

Die Beschreibungen sind - gerade bei dem Text aus 2011 - vielleicht nicht auf dem allerneuesten Stand, lassen sich aber mit leichten Anpassungen immer noch so umsetzen.

Alternativen zu duply wären bspw.

BorgBackup, ein Fork von Attic
Obnam von Lars Wirzenius

Ein Nachteil verbindet alle diese Lösungen: die Backups werden vom jeweiligen Server auf den Backupspace übertragen, was bedeutet, dass die Zugangsdaten auf dem zu sichernden Server gespeichert sind. Wenn ein Eindringling dort Root-Rechte erlangt, kann er auf die Zugangsdaten zugreifen und so auch das Backup zerstören.

Backups im heimischen Netz

Zuhause ist die IT-Landschaft vielfältiger: es gibt einen Linux-Server, der ständig durchläuft, und mehrere Windows-Rechner, die nur bei Bedarf betrieben werden, und es gibt auch keine dicke Anbindung ins Netz, mit der man mal eben ein paar (zig) GB wegsichern kann, sondern nur VDSL-50 (und vorher DSL-16000). Außerdem muss ich auch meinen Backupspeicher selbst zur Verfügung stellen und für funktionsfähige Hard- und Software sorgen.

Hier läuft daher als Backupspace eine Synology DiskStation DS213 (ein NAS) mit (mittlerweile) zwei 4-TB-Platten als Raid. Der Server greift über FTP darauf zu; hier verwende ich wie “draußen im Netz” duply (bzw. duplicity) und sichere täglich. Auf den Windowsrechnern ist jeweils Truecrypt von Acronis installiert, das ebenfalls verschlüsselte inkrementelle und volle Backups unterstützt. Sicherungen nehme ich einmal wöchentlich manuell vor; dafür habe ich einen Task in meinem Taskplaner angelegt. Der Zugriff auf das NAS erfolgt einfach über SMB, d.h. als Sicherungsziel wird ein Windows-Netzlaufwerk angegeben. Hier stellt sich dann natürlich das Problem des unbefugten Zugriffs in verschärfter Weise, zumal einerseits kein Rootzugriff erforderlich ist, sondern nur Benutzerrechte, und die Windows-Passwörter schon aus Gründen der Bequemlichkeit im lokalen Netz nicht besonders stark sind: ein Cryptotrojaner würde tatsächlich nicht nur den Rechner, sondern auch das Backup zerstören.

Da außerdem auch Einbrüche oder ein Brand - so ungern man das hört - in der eigenen Wohnung deutlich wahrscheinlicher sind als in einem Rechenzentrum, ist ein “Offsite-Backup” besonders wichtig, aber leider auch schwerer umzusetzen. Regelmäßige Uploads von am Ende mehreren TB erscheinen mir über eine typische asymetrische Heimanbindung wenig sinnvoll. Nach langem Nachdenken bin ich dann auf eine - wie ich finde - so einfache wie geniale Idee verfallen: ich sichere schlicht (automatisch) jede Woche (und zwar nach meinen wöchentlichen Backups) den Inhalt des NAS auf eine von zwei USB-Festplatten, die ich dann ins Büro mitnehme und dort im Schreibtisch einschließe (und dafür die dort eingeschlossene Platte der vergangenen Woche mit nach Hause nehme). Ich habe also immer ein externes Backup, das nicht viel älter als eine Woche ist - ohne ein Bankschließfach dafür zu benötigen.

Das heimische Backupkonzept hat sicherlich noch Optimierungspotential. Ich könnte bspw. die Frequenz der Backups erhöhen und sie dergestalt automatisieren, dass sie jedesmal beim Herunterfahren erfolgen. Allerdings dauern Backup und dessen Verifizierung doch länger (im Bereich von Viertelstunden oder mehreren Stunden); außerdem möchte ich vorher alle Programme schließen und vor allem meine verschlüsselten Partitionen unmounten, um sie weder doppelt noch in einem inkonsistenten Zustand zu sichern. Außerdem könnte ich mir mehr Gedanken über den Zugriff auf die Backups machen oder gar einen zentralen Backupserver einrichten, der sich die Backups von den einzelnen Maschinen zieht, ohne dass man auf diesen etwas tun muss. Bisher bin ich aber ganz zufrieden mit meiner Lösung.

Kommentare, Vorschläge, Erfahrungsberichte und Diskussion.

Das ist meine Lösung.

Und wie geht ihr mit dem Problem um, sowohl was ggf. gehostete Server oder auch nur die Datenbank eures Blogs betrifft als auch zuhause?

Plattentausch im NAS

nospam@example.com (Thomas Hochstein) — Wed, 12 Apr 2017 09:50:00 +0000

Das von mir genutzte Synology-NAS DS 213 ist mittlerweile rund viereinhalb Jahre alt und hat mir seit seiner Einrichtung Ende 2012 gute Dienste geleistet - wobei ich die vielfältigen Möglichkeiten bisher in keiner Weise ausgenutzt habe und das Gerät derzeit nur für Backups des heimischen Servers und aller anderen Rechner nutze.

Symbolbild - das ist kein DS213 … © blickpixel - Fotolia

Bislang verlief das in jeder Hinsicht ereignislos … bis vergangene Woche plötzlich die erste Platte ohne Vorwarnung aus dem RAID herausfiel, was mich - als ich die Mail erhielt - einigermaßen auf- und das NAS so sehr erschreckte, dass es sogar vergaß, zu piepsen.

Nach Hause zurückgekehrt nahm ich mich der Sache an und dokterte etwas daran herum, nachdem es den Eindruck machte, dass die Platte nicht defekt, sondern “nur” aus dem RAID-Verbund gefallen war. Eine Reinitialisierung des RAIDs ging aber offenbar über die Möglichkeiten der Oberfläche und meine geringen Fähigkeiten auf der via SSH zugänglichen Shell hinaus. Jedenfalls endete die Angelegenheit - nach Entfernung der Platte aus dem RAID via Shell und dem Versuch eines Rebuilds - mit der Meldung, dass die Systeminstallation auf Platte 1 fehlgeschlagen sei.

Nun gut; Zeit, vielleicht einmal SMART-Tests laufen zu lassen (was aus irgendwelchen Gründen bisher nicht regelmäßig geschah). Zur Platte 1 ergaben sich keine neuen Erkenntnisse - aber dafür war die Platte 2 nach den Tests im Pre-Fail-Status. Auch gut - bzw. eher nicht. Auch ein Reboot (die letzte Rettung jedes Windows-Nutzers) machte die Sache nicht besser, aber immerhin interessanter, war danach bei manchen Partitionen das RAID in Ordnung, bei anderen die Platte 1 herausgefallen - und bei anderen die Platte 2.

Bei diesem Stand der Dinge habe ich dann beschlossen, weitere Experimente aufzugeben und die Gelegenheit zu nutzen, den ohnehin oft knappen Speicherplatz von 3 TB auf 4 TB zu erhöhen und statt einer neuen 3-TB-Platte zwei neue 4-TB-Platten bei ARLT geordert. Dabei hatte ich dann doch einiger Bedenken, wie aufwendig der Einbau und die Neueinrichtung werden würden. Grundlos, wie sich dann herausstellte.

Der Einbau erwies sich nämlich letztlich als ebenso trivial wie die Einrichtung des Geräts: die Schlitten mit den beiden Platten ließen sich einfach herausziehen, die Schrauben zur Fixierung der Platten an den Schlitten lösen, die Platten tauschen, die Schlitten wieder einschieben, vorher das doch in den vergangenen Jahren etwas angestaubte Gehäuseinnere durchpusten - fertig. Und die Einschübe sind sogar unverwechselbar gekennzeichnet, so dass ein Plattenwechsel bei einem erneuten Ausfall einer RAID-Platte auch keine Probleme bereiten dürfte. Danach wurde dann die Neuinstallation angestoßen, diesmal direkt alles richtig konfiguriert, einschließlich eines passenden SSL-Zertifikats meiner hauseigenen CA, und danach mussten dann nur noch die Backups angestoßen werden, die dann die nächsten Stunden vor sich hin liefen.

Überdies habe ich testhalber einmal angefangen, ein Sicherungsverzeichnis in die Amazon-Cloud (Amazon S3) zu syncen, Stichwort Offsite-Backup - ich fürchte aber, das macht bei Backups um die 80-100 GB für jeden Rechner und einem 10-MBit/s-Upstream keinen großen Spaß. Plan B ist daher der ergänzende Erwerb zweier 4-GB-USB-Platten, die ich dann im wöchentlichen Wechsel zur Sicherung des kompletten NAS einzusetzen plane. Die jeweils nicht “aktive” Platte muss ich dann nur noch extern verwahren - vielleicht ein Bankschließfach? Oder schlicht die Schreibtischschublade im Büro? Man wird sehen.

PS: Klar, Festplatten altern - aber sind viereinhalb Jahre für WD-Red-Platten nicht etwas kurz?

Backups in die Cloud (duply und S3)

nospam@example.com (Thomas Hochstein) — Tue, 29 Mar 2016 13:00:00 +0000

Eigentlich wollte ich schon vor gut drei Jahren, im Januar 2013, über dieses Thema schreiben, als ich die ersten Backup-Jobs dieser Art eingerichtet habe, aber irgendwie ist aus dem angefangenen Entwurf nie ein fertiger Blogeintrag geworden. - Nun denn, auf ein neues.

Nicht nur der heimische Rechner will regelmäßig gesichert werden; auch bei dedizierten Servern oder vServern ist ein regelmäßiges Backup vonnöten, um im Falle eines Falles nicht ohne (Code und) Daten dazustehen. Früher war es üblich, dass zu einem Server auch ein - meist per FTP zugänglicher - Backupplatz gehörte, der genügend Raum für ein Backup (auch über mehrere Generationen) bot. Mittlerweile müssen solche Angebote aber nicht selten kostenpflichtig hinzugebucht werden oder stehen gar nicht mehr zur Verfügung. Zwar ist es natürlich möglich, die Datensicherung auf einen anderen (eigenen oder fremden) Server durchzuführen, wobei sich die Maschine im heimischen Keller in der Regel wegen der geringen Upload-Bandbreiten nicht anbietet - schließlich will man nicht nur sichern, sondern notfalls auch wiederherstellen können. Eine Alternative ist aber Cloud-Speicher, bspw. Amazons S3 (Simple Storage Service). Die Kosten sind bei inkrementiellen Backups überschaubar: ein Gigabyte Speicherplatz kostet pro Monat ungefähr 3 Cent, dazu kommen noch geringen Kosten für Zugriffsoperationen in der Größenordnung von einem halben Cent pro 1.000 Zugriffe und für den ausgehenden Traffic - also vor allem für einen Restore - 9 Cent pro GB, jeweils zzgl. MWSt. Wöchentliche inkrementielle Backups mit monatlichen Vollbackups für vier Server kommen auf gut 10$.

Backup mit duply in einen AWS S3-“Bucket”

Für verschlüsselte und komprimierte Backups bieten sich duplicity und duply an; die grundsätzliche Einrichtung von duply habe ich bereits 2011 beschrieben. Zusätzlich benötigen wir für das Cloud-Backup noch dreierlei: einen S3-“Bucket”, in dem die Backups landen sollen, Zugangsdaten für diesen “Bucket”, und eine Anpassung der duply-Konfiguration.

Für die Nutzung der Amazon Web Services (AWS) ist eine Anmeldung dort erforderlich. Außerdem empfiehlt es sich sehr, nicht mit den Daten des Haupt-Accounts auf unseren S3-“Bucket” zuzugreifen, sondern mit einem extra dafür erzeugten Nutzeraccount, der dann auch nur auf diesen “Bucket” zugreifen kann. Dazu dient das Identity and Access Management (IAM).

AWS-Konfiguration

Fangen wir an mit der Anlage des S3-Speicherplatzes. Dazu genügt es, in der S3 Console mit Klick auf Create einen neuen “Bucket” anzulegen. Der vergebene Name muss AWS-weit eindeutig sein, es empfiehlt sich daher etwas in der Form accountname-backup-servername o.ä. Dabei muss dieser Name eine gültige Subdomain darstellen (vgl. die AWS-Dokumentation) und er sollte - um spätere Schwierigkeiten beim Zugriff zu vermeiden - keine Punkte enthalten. (Mit duplicity und den zugehörigen Libraries unter Debian Wheezy hatte ich keine Zugriffsprobleme auf Buckets, die Punkte im Namen haben, mit den Versionen in Debian Jessie jedoch sehr wohl. Better safe than sorry … ) Außerdem kann die geographische Region ausgewählt werden, in der der “Bucket” angelegt werden soll. Neben Irland ist hier nun auch Frankfurt als Standort auswählbar; für den Zugriff dort wird aber nur die Protokollversion 4 unterstützt, was wiederum zu Schwierigkeiten führen kann. Ich empfehle daher eu-west-1 (Irland) als Region.

Jetzt brauchen wir noch einen Benutzer, der auf den Bucket zugreifen kann. Ein solcher lässt sich in der IAM Console anlegen. Die dabei erzeugte Access-Key-ID und der zugehörige Secret Key müssen unbedingt heruntergeladen und sicher aufbewahrt werden.

Danach bekommt der neu erzeugte Benutzer noch eine Policy mit den nötigen Zugriffsrechten verpasst. Dazu wählen wir ihn in der Benutzerliste aus, wählen den Tab Permissions an und klicken unter Inline Policies auf Create User Policy. Diese Policy sollte dann wie folgt aussehen:

{
    "Statement": [
        {
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Action": "s3:*",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::accountname-backup-servername",
                "arn:aws:s3:::accountname-backup-servername/*"
            ]
        }
    ]
}

Statt accountname-backup-servername ist der Name des vorher neu angelegten S3-Buckets zu verwenden. Dieser Benutzer darf sich also eine Liste aller “Buckets” anzeigen lassen und auf den genannten “Bucket” und alle Dateien darin zugreifen.

duply-Konfiguration

Update: Die Beschreibung der Konfiguration gilt für Debian 8.0 Jessie und Debian 9.0 Stretch.

In der duply-Konfiguration (Datei conf) treffen wir jetzt noch folgende Einstellungen:

TARGET='s3://s3-eu-west-1.amazonaws.com/accountname-backup-servername'
TARGET_USER='AccessKeyID'
TARGET_PASS='SecretAccessKey'

Update: Ab Debian Stretch muss es statt TARGET_USER und TARGET_PASS wie folgt heißen:

export AWS_ACCESS_KEY_ID='AccessKeyID'
export AWS_SECRET_ACCESS_KEY='SecretAccessKey'

Für s3-eu-west-1 (Region Irland), accountname-backup-servername, AccessKeyID und SecretAccessKey sind jeweils die passenden Werte zu verwenden; AccessKeyID und SecretAccessKey wurden bei der Einrichtung des IAM-Benutzers erzeugt.

Außerdem müssen duplicity noch einige zusätzliche Parameter übergeben werden:

DUPL_PARAMS="$DUPL_PARAMS --s3-use-new-style --s3-european-buckets --s3-use-multiprocessing "

Update: Ab Debian Stretch benötigt auch gpg zusätzliche Parameter:

GPG_OPTS='--pinentry-mode loopback'

Jetzt kann der erste Backuplauf mit duply NAME backup gestartet werden. Nach dem Abschluss des Backup-Laufs finden sich im “Bucket” in der S3 Console die gesicherten Dateien.

Fertig!

Synology DiskStation DS213

nospam@example.com (Thomas Hochstein) — Sat, 12 Jan 2013 19:17:00 +0000

Lange habe ich an einem Backupkonzept für meine heimischen Rechner gearbeitet. Wichtige Voraussetzung war dabei immer eine möglichst niedrige Hemmschwelle, das Backup auch wirklich laufen zu lassen. Softwareseitig bin ich über die Jahre bei TrueImage gelandet; hardwareseitig hatte ich verschiedene Varianten durchprobiert: mal auf eine zweite Festplatte, dann hatte ich ein ~~bill~~ preisgünstiges NAS besorgt, das aber ein so störendes Laufgeräusch produzierte, dass an einen Dauerbetrieb nicht zu denken war. Dann hatte ich eine ganze Zeit jeweils eine große 1-TB-Platte für den Heimserver einer- und für Desktop und Laptop andererseits; ganz nett, aber nach einiger Zeit hatten die Platten überraschend viele Fehler, und die über USB an den Heimserver angekoppelte Festplatte führte dazu, dass beim Reboot der Kernel nicht gefunden wurde (ohne dass ich bei drei oder vier umfangreichen Debug-Anläufen den Grund dafür gefunden hätte).

Mitte November letzten Jahres habe ich dann - inspiriert u.a. durch Rince - beschlossen, endlich einmal etwas Geld in die Hand zu nehmen und eine richtige Lösung zu finden. So traf denn eine Woche nach dem verlinkten Blogbeitrag eine Synology DiskStation DS213 bei mir ein - und ich bin sehr zufrieden. Obschon ich sie letztlich nur als “Datengrab” nutze und die vielen sonstigen Features gar nicht ausprobiert habe, arbeitet sie zuverlässig, extrem leise, mit Stromsparmodus und “Wakeup” beim Datenzugriff über das Netzwerk sehr flott (Gigabit-LAN) und bietet eine solche Menge an Erweiterungsoptionen, dass ich wahrscheinlich noch jahrelang damit spielen kann.

Insgesamt eine lohnende Investition, auch wenn das fertige Paket aus der DiskStation und zwei WD “Red” 3-TB-Platten durchaus nicht umsonst zu haben war. Ich bin damit dennoch sehr zufrieden und kann das nur empfehlen.

[Dieser Eintrag wurde nachträglich im Mai 2014 veröffentlicht.]

Backup mit duply und duplicity

nospam@example.com (Thomas Hochstein) — Thu, 13 Jan 2011 17:18:15 +0000

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, …) schützen. Backups sollten daher

regelmäßig durchgeführt werden,
versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. "Rootserver", also Mietserver, zu denen bei üblichen Angeboten auch ein sog. "Backupspace", also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, … - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage "belauschen" können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, …) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

Eine mögliche Umsetzung für einen Mietserver sieht - unter Debian Lenny - so aus:

duplicity und ncftp installieren: aptitude -r install duplicity ncftp

duply (in /usr/local/bin) installieren:

cd /tmp
wget -O duply_1.5.4.2.tgz http://sourceforge.net/projects/ftplicity/files/duply%20%28simple%20duplicity%29/1.5.x/duply_1.5.4.2.tgz/download
tar -xzf duply_1.5.4.2.tgz 
cp duply_1.5.4.2/duply /usr/local/bin/
rm duply_1.5.4.2.tgz 
rm -r duply_1.5.4.2

Alternativ (Debian Squeeze): aptitude -r install duply

Da der gesamte Server gesichert werden soll, läuft der Backupprozess am besten mit Root-Rechten. Wir brauchen jetzt also einen GPG-Key für root und richten dann das Backup ein:

cd /root
gpg --gen-key

Wenn nicht genug Entropie vorhanden ist, um den Key zu erzeugen, empfiehlt es sich, bspw. durch mehrere größere Downloads für Netzwerkverkehr und Belastung der Festplatten zu sorgen, um den Pool aufzufüllen. Key-ID und Paßwort des erzeugten Schlüssels benötigt man im nächsten Schritt zur Einrichtung des Backups; der Name des Backups kann frei gewählt werden:

duply *NAME* create
vim .duply/*NAME*/conf

In der Konfigurationsdatei sind nun zumindest einzutragen
- die ID des erzeugten GPG-Schlüssels (GPG_KEY),
- das Paßwort desselben (GPG_PW),
- das Backup-Ziel (FTP-Server und ggf. Verzeichnis, Benutzername, Kennwort: TARGET, TARGET_USER, TARGET_PASS) und
- den Pfad, der gesichert werden soll (im Zweifel "/": SOURCE).
Für die Einzelheiten und fortgeschrittene Konfigurationsmöglichkeiten sei auf die Kommentare innerhalb der Datei und die Dokumentation von duplicity und duply verwiesen.

Als nächstes erstellt man eine Liste der Dateien, die nicht gesichert werden sollen, die mindestens spezielle Verzeichnisse wie /dev und /proc enthalten sollte: vim .duply/NAME/exclude

/dev/\*
/proc/\*
/sys/\*
/tmp/\*
/var/tmp/\*
/var/run/\*

Danach kann man noch Scripts hinterlegen, die vor oder nach dem Backuplauf ausgeführt werden; bspw. kann es sich vor dem Backup empfehlen, Datenbanken zu dumpen. Diese Scripts heißen dementspechend pre und post, können zum Beispiel Shellscripts sein und müssen
- ausführbar sein (chmod 700 .duply/NAME/pre) und
- einen entsprechenden shebang (#!/bin/bash) enthalten.

Wenn das alles paßt, kann man nunmehr sein erstes Backup starten: duply *NAME* backup

Danach sollte man das komplette Verzeichnis .duply (das dann auch eine Kopie des GPG-Schlüssels enthält) sichern (nicht auf den Backupspace, sondern an einen sicheren Ort!).

Schließlich kann man noch in die Crontab von root einen entsprechenden Eintrag einfügen:

00 5 \* \* \* /usr/local/bin/duply *NAME* backup
00 6 1 \* \* /usr/local/bin/duply *NAME* full && /usr/local/bin/duply *NAME* purge --force

Fertig. Viel Erfolg!

In gleicher Weise ist es möglich, weitere Backups zu definieren, die bspw. nur /home oder /etc (oder /var/mail …) sichern, das dann aber häufiger.

Backup und Backupkonzepte

nospam@example.com (Thomas Hochstein) — Sat, 28 Oct 2006 19:57:00 +0000

Die vergangene Woche war für manchen Online-Anbieter eine ganz schwarze. Nicht nur, daß in den Webserver der DLRG eingebrochen wurde und die dort vorhandenen Daten samt des Backups mutwillig gelöscht wurden, einen kleinen Anbieter von Internetzugängen und -diensten auf im wesentlichen ehrenamtlicher Vereinsbasis hat es noch härter gebeutelt: in das von bawue.net mitgenutzte Rechenzentrum wurde eingebrochen und in erheblichem Umfang Technik entwendet oder mutwillig zerstört. Ein kompletter Ausfall der Dienste, teilweise über Tage, und erheblicher Datenverlust war die Folge, von immenser, nächtelanger Arbeit für das Admin-Team ganz zu schweigen.

Leider wieder ein sehr trauriger Anlaß zur Mahnung und zum Überdenken des eigenen Backupkonzeptes. Der "worst case" ist oft "worse", als man denken würde.