Re: Backup-Lösungen (War: Ausführungsrechte)
* Peter Jordan <usernetwork@gmx.info> (Fri, 06 Jul 2007 23:04:55 +0200):
>
> Hallo Fabian,
>
> danke für deine äußerst ausführliche Antwort.
>
> > Hallo Peter!
> >
> > Man muss die Daten auf dem Backup-Server ja nicht unbedingt denselben
> > Benutzern wie auf den Backup-Clients gehören lassen(, i.d.R. sind
> > ohnehin nicht überall genau dieselben Nutzer vorhanden). Außerdem ist
> > von den Backup-Clients ferngesteuertes cryptsetup ohne die Schlüssel auf
> > dem Backup-Server zu speichern (Ich lese da heraus, dass du das so
> > machst.) auch nicht viel sicherer als sie dort zu speichern, da sie bei
> > Kompromittierung des Backup-Servers auch einfach beim nächsten Backup
> > abgehört werden können.
> >
>
> Das ist richtig, das ist die einzige krux an meinem Backupscript. Ich
> nutze cryptsetup (die Schlüsseldatei kopiere ich vor dem Backup auf den
> REMOTESERVER und lösche sie nach öffnen der Partion wieder), damit die
> Daten bei einem Diebstahl des Servers sicher sind. Bei einer
> Komprimitierung des Servers sind die Daten ungeschützt, das ist mir
> leider bewusst.
Die Schlüsseldatei liegt dann aber noch (gelöscht) auf der Platte des
Servers herum, evtl. nach Diebstahl wiederherstellbar. Vllt. könnte man
die Schlüsseldatei stattdessen (via SSH) in cryptsetup pipen (kenne mich
mit dem Programm nicht aus) oder sie stattdessen auf dem Backup-Server
nur in einem tmpfs halten o.ä., falls du das nicht schon tust. (Und
hoffen, dass sie nie indirekt auf die Platte geswapt wird. ;)
> >
> > Außerdem gibt es dar (Disk ARchive); damit kann man die Daten in ein
> > einzelnes file pro backup sichern, in welchem auch die Nutzer- und
> > Rechte-Informationen vorliegen. Es kann inkrementelle Backups, ohne auf
> > die alten Backups direkt zugreifen zu müssen. (Man kann deren Kataloge
> > extrahieren, auch direkt bei ihrer Erstellung.) Außerdem kann es nativ
> > (also ohne z.B. tar durch gpg zu pipen o.ä.) verschlüsseln, was dann
> > Backup-Client-seitig geschieht und auch bei Kompromittierung des
> > Backup-Servers zumindest nicht die Daten aller Backup-Clients lesbar
> > macht.
> >
>
> Bin mir nicht sicher, ob dar meinen Anforderungen entsprechen kann, habe
> duplicity mal ne zeitlang verwendet (jedoch zu viele Fehler). Die
> Verschlüsselung ist aber eine sehr nützliche Funktion. Rsync mit einer
> client basierten Verschlüsselung würde mir gefallen :-), aber egal, so
> muss ich dafür sorgen, dass der Backupserver nicht komprimitert wird.
Was genau meinst du mit Fehlern? Ist das Programm buggy? Ansonsten:
duplicity habe ich nie benutzt, klingt aber interessant. (Bei dar würden
für inkrementelle Backups ja nur die Kataloge herangezogen, eine
geänderte Datei also komplett neu gesichert.)
Rsync mit client-basierter Verschlüsselung: Du kannst ja auf den Clients
alles innerhalb von cfs machen und beim Backup dann dessen im "echten"
Dateisystem liegenden verschlüsselten Versionen der Dateien rsync-en. ;)
Gruß, Fabian
--
Fabian "zzz" Pietsch - http://zzz.arara.de/
Reply to: