[linux-l] Crypto-Backup (was: RSync für Device-Files)

Mi Mai 30 13:37:33 CEST 2012

Hallo Peter,

vielen Dank für die ausführlichen Gedanken. Ich merke,
dass ich die Motivation hinter meinem Vorhaben genauer
schildern sollte, was ich hiermit nachhole:

Meine regelmäßigen Backups sollen nicht mehr nur auf die
externe Festplatte, sondern auch verschlüsselt auf einen
oder mehrere Server abgelegt werden.

Sind das _fremde_ Server, ist Verschlüsselung ein klares
Muss. Sind das _eigene_ Server, ist das aber ebenfalls
sinnvoll. Denn wozu muss der Server das Backup (temporär)
entschlüsseln können? Das ist einfach ein unnötiges Risiko,
wenn auch ein kleines.

Der klassische Ansatz ist ein fettes Tar-Archiv, dann GPG
drüber jagen und hochladen. Aber Effizienz wie bei RSync
ist dabei undenkbar. Zwar könnte man RSync-freundliche Crypto
wie rsyncrypto [1]  verwenden, aber dennoch: Warum muss ich
extra fürs Backup alle meine Daten nochmals verschlüsseln?
Die liegen doch bereits verschlüsselt auf der Festplatte!

Deshalb die Idee, dass ich direkt den Crypto-Container
übertragen will.

(Und natürlich passiert vorher ein LVM-Snapshot. :-))

Peter Ross schrieb:
> On Mon, 28 May 2012, Volker Grabsch wrote:
> 
> >RSync legt lediglich auf dem Zielsystem ein ähnliches Block-
> >Device an.
> 
> Die Device-Nodes werden abhängig von der Hardware erzeugt und sind
> bei unterschiedlicher Hardware auch nicht die gleichen - es macht
> daher gar keinen Sinn, /dev zu synchronisieren.
[...]
> Wenn /dev/sda1 bei Dir auf eine gleichgroße Partition auf einem
> anderen System "gemappt" werden kann, ist das eher Zufall als
> Absicht (oder halt Deine)

Klar darf das nicht das Default-Verhalten von RSync sein, aber
eine entsprechende Option wäre eine sehr sinnvolle Erweiterung.
Außerdem kann das auf Serverseite ja wieder eine Datei sein,
nur auf Clientseite ist es halt ein Block-Device.

Es gibt wiegesagt Patches, aber nichts wirklich brauchbares.
Außerdem sollte RSync dann auch automatisch auf Rolling-Checksums
verzichten und stattdessen Block-Checksums verwenden, wiegesagt.
Das alles in RSync einzubauen erscheint mir aber sehr aufwändig,
daher habe ich dann nach anderen Tools gesucht.

> >   https://github.com/vog/bscp
[...]
> Ich benutze nun eine Weile ZFS (unter FreeBSD, aber es gibt auch
> ZFSonLinux, und das ähnlich gebaute BTRFS), und meine Strategie
> besteht aus regelmäßigen "zfs snapshot; zfs send | ssh $remote "zfs
> receive"

Klingt super, aber für mein eigentliches Problem helfen mir
ZFS-Snapshots nicht weiter, oder? Denn das passiert ja alles
auf Klartext-Ebene, nicht auf der verschlüsselten Ebene. Oder
übersehe ich was?

> Gemessen an dem "ollen Kram" wir rsync und unison (nicht zu reden
> von rsync/unison-Implementierungsproblemen) ein Segen. Ich will,
> außer vielleicht für ein paar spezielle Ausnahmefälle für bestimmte
> Anwendungen, nie wieder was anderes als copy on write.

Kann ich gut verstehen. :-)

> Intern machen LVM-Snapshots das ja auch. Und dieses hier sollte
> vielleicht hiilfreich sein, um eine inkrementelle Anwendung von
> Snapshots zu ermöglichen:
>
> http://www.mjmwired.net/kernel/Documentation/device-mapper/snapshot.txt
>
> Siehe vorallem die Merge-Option.
>
> Du brauchst meines Erachtens nicht manuell nach geänderten Blöcken
> suchen. LVM kennt die schon.

Es gibt bereits ein Tool namens "lvmsync" [1], das genau auf
dieser Idee aufsetzt. Ich verlinke von meinem Projekt aus auch
dorthin.

Der klare Vorteil ist, dass die Checksummen nicht mehr bei
jeder Übertragung neu berechnet werden müssen, das spart Aufwand
auf beiden Seiten.

Doch das erste Problem ist, dass hier ein LVM-Snapshot angelegt
wird, der so lange gehalten werden muss, bis das nächste Backup
ansteht. Wenn in dieser Zeit viel passiert, kann sich der Snapshot
ziemlich "vollfressen". Normalerweise muss ein LVM-Snapshot nur
die sehr kurze Zeit _während_ des Backups existieren, und nicht
die längere Zeit _zwischen_ den Backups.

Wenn man natürlich viel freien Platz auf seiner Platte hat, oder
sowieso regelmäßig ältere Snapshots aufbewahrt, ist das kein
Problem mehr.

Dennoch: Wozu einen kompletten alten Snapshot aufbewahren,
wenn mich eigentlich nur interessiert, _welche_ Blöche sich
geändert haben? (und nicht deren Inhalt)

Das zweite Problem ist die Handhabbarkeit. Die Server müssen
immer auf dem gleichen Stand sein, oder ich brauche einen
extra Snapshot pro Backup-Server. Und wenn das Backup mal
schief geht, oder ein Server auf einen alten Stand zurück-
gesetzt werden musste? Dann kann man wieder von vorn anfangen.

Dieses ganze "lvmsync"-Konzept erscheint mir irgendwie zu
fragil. Oder übersehe ich was?

Ideal wäre eigentlich, wenn man stattdessen einfach Checksummen
cachen könnte. Wenn sich ein Teilblock des Block-Devices ändert,
wird automatisch dessen Checksumme aktualisiert (oder zumindest
invalidiert und bei Bedarf neuberechnet). So bräuchten Server
und Client nur noch ihre Checksummen-Listen vergleichen und
wüssten genau, welche Teilblöcke zu übertragen sind - egal was
in der Zwischenzeit auf Client- oder Serverseite vorgefallen ist.

Aber gibt es sowas nicht schon?

Man könnte etwa den Crypto-Container als Datei in einem ZFS-
Dateisystem anlegen, und dort Snapshot und Sync vornehmen. Das
kommt mir aber ziemlich umständlich vor. Oder man erstellt
zumindest auf Serverseite keine große Datei, sondern nur noch
einzelne Dateien pro Teilblock, die nach ihrer Checksumme
benannt sind (ähnlich wie in Git). Oder man macht irgendwas
schickes mit Bittorrent, aber mir fällt da leider nichts
Konkretes ein.

Oder denke ich hier zu kompliziert?

Gruß
Volker

[1] http://rsyncrypto.lingnu.com/
[2] http://theshed.hezmatt.org/lvmsync/

-- 
Volker Grabsch
---<<(())>>---