Re: Backuplösung für ein Debian System
On 08/27/2010 01:11 PM, Michael Hierweck wrote:
> a) Viele Backup-Systeme sind komplex und oft auch noch auf den Betrieb
> mit Sicherungsbändern etc. ausgelegt,
Wenn man komplexe Umgebungen hat, braucht man das auch. Solche komplexen
abläufe wird man wohl kaum durch paar Selbst geschriebene Shell Skripte
lösen.
> 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,
Bänder sind in meinen Augen aber deutlich portabler und weniger
anfällig. Aber hier hängt es sicherlich von Verwendungszweck ab. Ich
denke einige kommen heute mit einer HDD Sicherung aus. Musst du aber
Daten auf 10 Jahre Archivieren wirst du wohl nicht um die passende
komplexe Software drum herum kommen.
> b) Die Anforderungen an ein Backup sind oft diffizil und fertige Systeme
> erfüllen oft die individuellen Anforderungen nicht.
Kann ich so nicht unterschreiben. Je nach Anforderung gibt es diverse
Systeme. Von komplex bis einfach. Hat man komplexe anforderrung wird man
um ein komplexes System nicht drum herum kommen das entsprechend
individuell konfigurierbar ist.
Es kann nicht jeder erstmal anfangen sein eigenes Backup Programm zu
schreiben. Und wenn sich die Anforderungen ändern alles
umschreiben/neuschreiben etc.
> 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.
Mir ist letzteres Sympathischer. :) Hatte zuerst rsnapshot dann Bacula
und mitlerweile BackupPC. Bin mit BackupPC sehr zufrieden.
> 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.
Das sehe ich bei rsnapshot überhaupt nicht so. Das ist gerade das was
mich an rsnapshort störte.
Ob nun rsnapshot in der Nacht erfolgreich lief oder zwischendurch
abgebrochen ist oder wirklich alle Dateien gesichert wurden weißt du
nicht wirklich.
Bei Rsnapshot hatte ich damals einen Cronjob auf den Clients erstellt
der dateien mit timestamps erzeugt und ein Nagios Plugin das überwacht
hat ob die Dateien auch aktuell waren und ob überhaupt ein Backup lief.
BackupPC aber auch Bacula schicken von sich aus Mails wenn etwas nicht
lief in einem Fehler lief oder du kannst dir einfach den Status anzeigen
lassen.
> 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.
Du kannst auch mithilfe von rsyncd oder smb sichern. SMB macht bei Unix
ähnlichen Systemen wohl wenig sinn daher mag das weg fallen.
Aber du kannst auch auf dem Rechner der zu Sichern ist den rsyncd laufen
lassen der die Dateien dann anbietet, damit hat dann der Backuprechner
nicht vollständigen Zugriff auf das zu sichernde System.
> Bei rsnapshot gab es auch Probleme, zumindest konnte
> man nach meinem Kenntnisstand nicht verhindern, dass ein
> kompromittierter Host alte Backups manipuliert.
rsnapshot läuft durch nur rein auf rsync, daher hast du die "Probleme"
dort erst recht.
> a) Das Backup-System hat keinen Zugriff auf die Clients.
Wie soll es dann sichern? ;)
Also Zugriff muss es schon haben, du meinst wohl nur eingeschränkt, dass
müsste aber auch BackupPC mit rsyncd erfüllen, ansonsten eben Programme
die Client/Server Teile besitzen.
> b) Die Clients haben nur Schreibrechte auf ihr aktuelles Backup.
Hmm, warum sollten Clients also die zu sichernden Rechner schreibzugriff
haben? in der Regel hat doch nur der Server diese.
> Archivierte Backups dürfen von ihnen ausschließlich gelesen werden
> können.
Das könnte Bacula. Dort kann der Client vor dem versenden die Daten
verschlüsseln. Dann kann nichtmal der Server also bacula die Daten lesen.
> Desweiteren sollten mehrere Sicherungsmedien einsetzbar sein, die man
> rotieren kann.
Bacula check.
> Diese sollten "in sich" vollständig sein, es sollten also
> keine Metadaten außerhalb des Mediums abgelegt werden.
Hmm, gibt es bisher wohl nichts das dies macht. Zumindest kenne ich nichts.
> Das Sicherungssystem soll den Verlust eines Mediums ohne Eingriffe
> kompensieren können.
Bacula check.
> Ebenso sollten neue Medien problemlos hinzugefügt
> werden können,
Bacula check.
> ohne diese aufwendig initialisieren oder einem Pool
> zuordnen zu müssen.
Das bietet Bacula nicht, aber wie willst den Sachen hinzufügen/entfernen
ohne sie einem "Pool" hinzuzufügen/entfernen? Genau das ist es doch. Du
fügst es dem Pool hinzu und es kann zum Sichern genutzt werden. Du
entfernst es vom Pool und kannst es eben im Tresor legen. Aufwendig sehe
ich das Initialisieren aber nicht. Bacula macht das Initialisieren zum
Beispiel automatisch wenn du willst.
> Auch Bedienfehler (falsches Medium zum Sichern
> eingelegt) sollten vom System kompensiert (es sollte "das Beste" draus
> machen) werden.
Mir ist unklar wie so ein Bedienfehler entstehen kann/soll.
> Ein Restore sollte im Notfall auch mit simplem cp möglich sein, wenn man
> ein Medium direkt mit dem Zielsystem verbindet.
Mit deinen bisherigen anforderungen wohl ein Ding der unmöglichket. Wie
willst du Archive erstellen das ebenfalls Meta-Daten enthält zurodnungen
zu Clients, nicht für alle Les/Schreibbar aber trotzdem sollen die Daten
irgendwo "Roh" liegen?
> Implementieren kann man dieses Backup-System übrigens mit einer handvoll
> Drei-Fünfzeilern und cron. (Sichern, Rücksichern, Archivierung)
Ja das glaubt so jeder. Weswegen jeder meint es auch tun zu müssen.
Rsnapshot das man schon als absolut simpel und minimalistisch einstufen
kann und für das Backup selber auf rsync zurückgreift ist trotzdem satte
200KiB Perl Code groß.
Nun wenn du noch mehr Funktionalität schafft in einer "handvoll" 3-5
Shellzeiler solltest du ja morgen damit fertig sein. :)
Reply to: