[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backuplösung für ein Debian System



Hallo,

David Raab wrote:
> Hmm,
> ich frage mich eigentlich warum jeder versucht immer wieder sein eigenes
> Backup zusammen zu frickeln?

darauf gibt es mehrere Antworten:

a) Viele Backup-Systeme sind komplex und oft auch noch auf den Betrieb
mit Sicherungsbändern etc. ausgelegt, die heute in vielen Fällen vom
Preisleistungsverhältnis nicht so recht passen. (Über'n Daumen:
Bandlaufaufwerk >1000€, Band 50-100€, dafür bekommt man auch einen Satz
externer Festplatten mit gleichen oder höherem Datendurchsatz,
wahlfreiem Zugriff, längerer Haltbarkeit und ohne Abhängigkeit vom
Sicherungsgerät.)

b) Die Anforderungen an ein Backup sind oft diffizil und fertige Systeme
erfüllen oft die individuellen Anforderungen nicht.

> Ein Backup ist so wichtig, und es gibt immer wieder Leute die meinen man
> kann es mit drei Befehle nachbauen. Nun Sicherlich muss man nicht gleich
> zu Lösungen wie Bacula greifen, aber die Idee eines simplen Backups
> hatten schon viele und dementsprechend gibt es schon einige Lösungen.
> 
> Und nebenbei beim Backup kommt es nicht auf das Backupen sondern auf das
> Wiederherstellen drauf an. Das vergessen die meisten. Ein Backup bringt
> dir nichts wenn du im Problemfall schwer oder gar nicht an deine Daten
> kommst.
> 
> Zwei simple fertige Lösungen wären rsnapshot oder BackupPC. Was ich dir
> empfehlen würde.

Mir sind diese beiden (wie ich bereits schrieb) auch sympathisch, vor
allem das erstgenannte, weil man hier ggf. mit simplem cp oder rsync
rücksichern kann. Mit diff kann man direkt verfolgen, was passiert. D.h.
der Restore ist "stressfrei". Außerdem sind diese Systeme weniger
Blackbox, d.h. man kann mit Standardtools sehr leicht im Auge behalten,
ob die Sicherung noch klappt, vollständig ist usw.

Eine einfache, oft (nicht immer), sinnvole Strategie ist daher in meinen
Augen: Datenbanken, LDAP & Co. dumpen und dann das komplette Filesystem
(mit wenigen Ausnahmen) mit rsync wegschreiben. Außerdem sind
Generationen zu bilden.

Was mir an rsnapshot und BackupPC nicht gefällt, sind Security-Fragen.
BackupPC braucht Vollzugriff auf alle Systeme. (Die Vorschläge, dass mit
sudo abzusichern erscheinen mit nicht ausreichend. Wer rsync mit
beliebigen Parametern ausführen kann, kann auch alle Daten ändern. D.h.
er kann sich auch Vollzugriff verschaffen. Ein "übernommener"
Backuphost, sollte aber nicht zur Kompromittierung aller Hosts führen,
die er sichert.) Bei rsnapshot gab es auch Probleme, zumindest konnte
man nach meinem Kenntnisstand nicht verhindern, dass ein
kompromittierter Host alte Backups manipuliert.

Ich suche daher noch ein effizientes und übersichtliches Backup-System
vergleichbar BackupPC, welches aber folgende Sicherheitsaspekte
berücksichtigen sollte:

a) Das Backup-System hat keinen Zugriff auf die Clients.
b) Die Clients haben nur Schreibrechte auf ihr aktuelles Backup.
Archivierte Backups dürfen von ihnen ausschließlich gelesen werden
können. (Damit wirkt man versehentlicher Beschädigung oder beabsichtiger
Kompromittierung von Backups entgegen.)

Desweiteren sollten mehrere Sicherungsmedien einsetzbar sein, die man
rotieren kann. Diese sollten "in sich" vollständig sein, es sollten also
keine Metadaten außerhalb des Mediums abgelegt werden. Das
Sicherungssystem soll den Verlust eines Mediums ohne Eingriffe
kompensieren können. Ebenso sollten neue Medien problemlos hinzugefügt
werden können, ohne diese aufwendig initialisieren oder einem Pool
zuordnen zu müssen. Auch Bedienfehler (falsches Medium zum Sichern
eingelegt) sollten vom System kompensiert (es sollte "das Beste" draus
machen) werden.

Ein Restore sollte im Notfall auch mit simplem cp möglich sein, wenn man
ein Medium direkt mit dem Zielsystem verbindet.

Eine Skizze, wie man das implementieren könnte:


Client:

Sicherung:

/etc/backup.d (Verzeichnis mit Skripten die diverse Sachen lokal dumpen,
anschließend rsync auf den Backup-Server)

Rücksicherung:

Teilbaum der Sicherung eines konkreten Datums per rsync wahlweise in
gesonderten Ordner oder "in place". DB & Co müssen danach manuell
wiederhergestellt werden.

Server:

Sicherung:

Bietet rsync-Schnittstelle mit Schreibzugriff auf aktuelle lokale Kopie
(interne HDD). (Schreibzugriff auf /intern/host)

Rücksicherung:

Bietet rsync-Schnittstelle mit Lesezugriff auf die vorliegenden Archive
(interne oder externe HDD). (Lesezugriff auf /extern/host)

Generationenbildung:

Exemplarisch: Kopie der aktuellen lokalen Kopie (interne HDD) auf
Archivierungsmedium (interne oder externe HDD), z.B. mit rsync
--link-dest /extern/host/neuestes /intern/host /extern/host/heute,
abschließend rm -rf /extern/host/aeltestes.


* Das Backup ist für die Clients wegen rsync effizient.
* Die Sicherheitsanforderungen wurden gewährleistet.
* Die Medien sind mit normalen Tools lesbar.
* Das irrtümliche Einlegen eines falschen Mediums führt zu geringfügigem
Fehler: das älteste Backup des Mediums wird gelöscht, das neue Backup
auf jedenfall aber geschrieben. Unterbinden könnte man auch dies, wenn
man die Medien geeignet markiert.

Implementieren kann man dieses Backup-System übrigens mit einer handvoll
Drei-Fünfzeilern und cron. (Sichern, Rücksichern, Archivierung)

Das Archivierungsbackend, welches aus externe Medien schreibt, könnte
von "rsync --link-dest/rm" auch gegen tar, cpio o.ä. getauscht werden
und komplette (oder inkrementelle) Backups wegschreiben.

Oder man programmiert eine Kombination: die aktuellsten Backups hält man
lokal vor, für schnelles und einfaches Restore und ausgewählte (z.B.
monatliche) Vackups schreibt man zusätzlich auf ein Band zur
"Langzeit"archivierung.

Die Implementierung hat übrigens einen Haken: rsync --link-dest ist
nicht das schnellste, wenn man sehr viele Dateien hat. Das gleiche gilt
für rm. Einige Millionen Hardlinks anzulegen oder zu löschen dauert.

Verbesserungsvorschläge nehme ich gern entgegen, vielleicht könnte man
sowas auch mal sauber und konfigurierbar implementieren und paketieren.
Falls das jemand vor hat, ich helfe gern, habe aber selbst zuwenig Zeit
und Ahnung vom paketieren, um es allein zu tun. Oder jemand kennt ein
System, was das (fast) kann und wir verbessern es gemeinsam...

Viele Grüße

Michael

-- 
EDV-Serviceteam Annika & Michael Hierweck GbR
Egerstraße 53, 44225 Dortmund (Germany)
http://www.edv-serviceteam.net


Reply to: