Re: Ausführungsrechte
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.
>
> Hast du dir mal rdiff-backup angeschaut? Das sollte auf dem
> Backup-Server speichern (und später auf dem Backup-Client
> wiederherstellen) können, wem welche Datei gehörte und welche Rechte er
> drauf hatte, auch wenn auf dem Backup-Server alle Daten eines
> Backup-Clients demselben Benutzer gehören. (Außerdem hast du dann nicht
> "nur" einen mirror, sondern auch binary diffs zu alten Versionen, ohne
> viel Platzverschwendung. Solltest du rsync nicht zum effizienten
> Aktualisieren von mirror backups verwenden, sondern einfach nur zum
> wiederholten Komplett-Übertragen mit regelmäßiger Komplettlöschung alter
> Backups, siehe dar.)
>
Interesannte alternative, für remote backups werde ich es wohl ab jetzt
verwenden. für lokale backups nutze ich wohl weiter rsync.
>
> 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.
gruß
PeterJordan
Reply to: