- Stabiler täglicher Betrieb ohne Wartungsarbeiten
- Komprimierter Transfer der Daten im Netzwerk
- Bandbreitenlimitierung des Backup-Prozesses
- Sicherer Transfer der Daten – ssh-verschlüsselt
- Snapshot des gebackupten Systems, Rekonstruktion eines bestimmten Zustandes vor n-Tagen möglich
- Bequemes Backup auf einfachen Festplatten, ohne teuren Tape-Roboter oder teure Bandlaufwerke. Große Datenmengen möglich.
- Schnelles Zurückspielen der Daten in Festplattengeschwindigkeit möglich (schneller als Bandlaufwerke)
Wir haben unsere rsync-Lösung im Linux-Magazin Heft 9/04 vorgestellt. Einige Leser haben sinnvolle Ergänzungen eingebracht, die wir Ihnen nicht vorenthalten wollen. Weitere Varianten befinden sich am Ende dieser Seite.
Die Technik
rsync kann Verzeichnisse auf zwei Rechnern abgleichen und synchronisieren. Dabei werden nur geänderte Dateien, bzw. sogar nur die geänderten Teile einer geänderten Datei übertragen: Wird in einer 10 MByte großen Datei im Mittelteil etwas verändert, wird nur die Änderung (zuzügl. etwas Overhead) durch das Netz transportiert. Das findet über einen ssh-Tunnel statt, der das Ganze verschlüsselt und komprimiert. Die durch das Netz zu transportierenden Daten können kaum geringer sein, die Ressourcen werden optimal geschont.Auf dem Zielsystem werden die gebackupten Daten auf einer reservierten großen Festplatte gespeichert und täglich wird eine Kopie der Daten gemacht – allerdings nicht komplett physikalisch, sondern die Dateien werden nur in einen neuen Ordner neu verlinkt ("hardlink-copy"). Eine Datei kann damit 20mal auf der Festplatte existieren, belegt aber nur einmal physikalisch Speicher.
Wird eine Datei geändert, wird rsync diese Änderung übertragen und in das Backup einpflegen. Zuvor allerdings löst rsync den Hardlink auf und erzeugt eine neue Kopie der Datei. Sie existiert dann (aber erst dann!) physikalisch zweimal, einmal in der alten, einmal in der neuen Fassung (und belegt dann auch zweimal Speicherplatz).
Wir sind dadurch in der Lage täglich eine neue Snapshot-Kopie zu machen, die keinen Speicherplatz kostet, solange sich nichts ändert. Gleichzeitig können wir täglich eine neue Hardlink-Kopie in neuen Ordnern anlegen und so den Snapshot von vor 10 Tagen rekonstruieren, wenn nötig.
Möglicher Nachteil dieser Vorgehensweise: Die Daten sind nicht komprimiert auf der Festplatte. Ich sehe das jedoch als Vorteil an, denn das erhöht die Sicherheit des Backups (ein komprimiertes Archiv kann durch einen einzelnen Fehler komplett unbrauchbar gemacht werden) und das ermöglicht ein schnelles und zügiges Zurückspielen der Daten (zur Not wird die Backup-Platte direkt an den Server gehängt und kann lokal in Höchstgeschwindigkeit umkopiert werden).
Wir benutzen als Backup-Server einen alten Pentium 200 mit IDE-Platte – 128 oder 256 MByte Speicher sind sinnvoll, denn der rsync-Prozess kann bei vielen Dateien auf dem Server schnell sehr viel Arbeitsspeicher verbrauchen – aber zur Not wird geswappt, wen stört's?). SCSI-Platten sind sicher stabiler und sicherer als IDE, aber angesichts der Preise für ausreichend große SCSI-Platten, haben wir uns dagegen entschieden. Besser ist es unserer Ansicht nach dann, ein IDE-RAID-Array mit hot-swap auf dem Backup-Server aufzusetzen. Aber das ist eine Frage des persönlichen Geschmacks und des Geldbeutels.
Die Scripte
Wir setzen zwei Scipte ein – der rsync-Prozess ist vom Rotieren der Snapshots komplett abgekoppelt. Auf diese Art und Weise können wir nachts binnen weniger Stunden alle rsync-Prozesse abarbeiten und tagsüber in Ruhe rotieren. Andernfalls würde der Gesamtprozess angesichts unserer enormen Datenmengen (rund 150 Gbyte bei uns) so lange dauern, dass er bis zu den Morgenstunden nicht fertig werden würde.- backup-rotate: Rotiert die Snapshots jeden Tag.
- backup-rsync: Backt jeden Tag per rsync Snapshots von den Servern.
Dazu gibt es noch zwei weitere Scripte, die die eigentlichen Arbeitsscripte aufrufen und den Servernamen dabei jeweils als Aufrufparameter übergeben. So lassen sich bequem ein halbes Dutzend Server backuppen:
- backup-daily: Startet für jeden Server das Script "backup-rotate".
- backup-nightly: Startet für jeden Server das Script "backup-rsync"
Tragen Sie für die letzten beiden Scripte nun jeweils einen cron-Job ein, einen tagsüber, einen nachts.
Die Absicherung über SSH
Damit die rsync-Prozesse auf die zu backuppenden Server heraufkommen, brauchen Sie dort einen root-Login. Um den möglichst sicher zu gestalten, sollten Sie mit SSH auf dem Backup-Server einen Key generieren und den Public-Key davon auf jedem Server in
/root/.ssh/authorized_keys ablegen. Damit wäre allerdings ein voller SSH-Shell-Zugriff möglich. Ein Angreifer auf dem Backup-Server könnte sich ohne Kontrolle mit jedem Server des Netzwerkes weiterverbinden.Aus diesem Grunde sollten Sie die SSH-Schlüssel auf den Servern jeweils auf das rsync-Kommando limitieren. Dann ist es nicht mehr möglich durch
ssh server2.domain.de eine root-Shell zu kriegen. Ergänzen Sie die Zeile mit dem Key deshalb um "command=..". Dabei muß alles in eine Zeile – mitsamt dem Schlüssel:command="rsync --server --sender -vlogDtprz --delete-excluded --numeric-ids . /" ssh-dss AAAAB3 [...und der Rest des Keys...]
Was sonst noch zu beachten ist
- Prüfen Sie vor allem am Anfang die Entwicklung des Festplattenplatzes und die Logfiles auf dem Backup-Server.
- Ich bevorzuge es
/etc/shadowy/nicht mit in das Backup einzubeziehen. Ein Angreifer auf dem Backup-Server könnte sonst leicht die darin enthaltenen (root-) Passwörter aller Server knacken. Lieber ist es mir, mir im Falle eines Totalverlustes eines Servers neue Passwörter auszudenken. - Diese Lösung zieht ein Vollbackup der Server-Festplatte ohne dabei auf die Konsistenz zu achten. Sollten dort z.B. Datenbanken laufen, sollten Sie diese vorher sauber "dumpen" (z.B. mysqldump).
- Es ist unbedingt notwendig zwei Backup-Platten zu haben und diese zuverlässig regelmäßig zu tauschen, so dass sich immer eine Platte außerhalb des Serverraumes oder des Hauses befindet und nicht an den Stromkreis angeschlossen. Hier gelten die gleichen Regeln wie für alle anderen Backups- und Backupmedien wie Tapes etc. ganz genauso! Besorgen Sie sich für einige wenige EUR zwei UDMA-133 Wechselplattenrahmen.
- Die hier vorgestellte Lösung "comes, as it is", wir übernehmen keinerlei Gewährleistung, Haftung etc.
Literatur
Wir können das Backup-Buch von Wolfgang Barth bei Open Source Press nur wärmstens empfehlen:
- Datensicherung unter Linux, Wolfgang Barth, ISBN 3-937514-00-7, 280 Seiten, 24,90 EUR. Link zu Amazon.
Heinlein Professional Linux Support
Hilft und berät Sie gern bei der Entwicklung einer eigenen Backup-Strategie und Software-Lösung.
Hier eine Ergänzung aus einer Zuschrift von:
Thomas Schreiber: Hallo LinuxMagazin Macher, den Artikel fand ich zwar ganz interessant, habe jedoch Sicherheitsbedenken. Ein Root Login extra für das Backup zu öffnen, halte ich für bedenklich. Ich habe mich deshalb hingesetzt und und es etwas verfeinert. Statt root-Login, legte ich einen User "backup" an, der bekam via sudo das Recht nur "rsync" auszuführen. Das Login schaltete ich mittelspasswd backup -lab. Vom Backup Host hatte ich den Key des Backup-Users in die .ssh/authorized_host2 eingespielt und die entsprechenden Restriktionen (command=rsync ...) wie im Artikel eingepflegt, mit dem Unterschied das dem Ganzen das "sudo" vorangestellt wird (command="sudo rsync --server --sender ...). Das Backupscript greift nun statt aufroot@[zu_sichernder_server]aufbackup@[zu_sichernder_server]zu. Ich meine, eine kleine Änderung mit großer Wirkung.
Unsere Antwort: Die sudo-Variante bringt in der Tat dann einen Vorteil, wenn normale User auf dem Server SSH-Logins benutzen dürfen und wenn diese vielleicht sogar Zugriff aus dem Internet heraus erhalten. Würde man auf sudo verzichten, wäre die vielleicht ungewollte Möglichkeit eines root-Logins per SSH möglich, der aufgrund der normalen Shell-Nutzer auch per Passwort möglich wäre. Das würde einen Brute-Force-Angriff ermöglichen. Will man den root-Login komplett verbieten können ("PermitRootLogin no"in"/etc/ssh/sshd_config"), bietet die hier vorgeschlagene sudo-Variante eine sichere Abhilfe. Ist der root-Login allerdings sowieso grundsätzlich möglich oder handelt es sich um Server-Umgebungen ohne normale Nutzer-Logins von außen, kann auf die sudo-Variante verzichtet werden.
Unsere Antwort: Tja, schönen Dank, klingt nach einer sehr netten Idee, die wir hier ungeprüft weitergeben. Nur zur Klarstellung: Die Angabe des bloßen Users "root" ohne "@rechnerdns" wäre hier natürlich dann nicht Sinn und Zweck der Sache...
Kommentare