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

[Peter Ross]

HI Volker,

On Wed, 30 May 2012, Volker Grabsch wrote:

> 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:

Ich ahnte schon, daßDu noch was Spezielles vorhast;-)

> Peter Ross schrieb:
>> On Mon, 28 May 2012, Volker Grabsch wrote:
>>
>>>   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?

ZFS kann leider derzeit nur unter Solaris 11 Verschlüsselung, soweit 
ich weiß. Es braucht ZFS Version 30, derzeit ist die letzte 
veröffentlichte ZFS-Version Version 28 in FreeBSD integriert.

Man kann aber trotzdem damit arbeiten:

Encrypted ZFS In FreeBSD
http://0xfeedface.org/blog/lattera/2011-12-19/encrypted-zfs-freebsd

Die idee ist, das ZFS-Volume (den Blocklevel-Container) auf ein geli 
aufzusetzen.

(geli ist ein verschlüsseltes GEOM-Objekt, GEOM ist das FreeBSD-Framework, 
um mehr oder weniger beliebige Blocklevel-Objekte aufeinander zu stapeln 
(z.B. ein gmirror auf Platten/Partitionen, und dann ein GELI drauf, oder 
ein RAID-Management-Framework gvinum)

D.h. das Blockdevice ist verschlüsselt.

Die Snapshots würden dann entschlüsseln - remote mußt Du auch wieder 
verschlüsseln. Ja, das erhöht die Schlüsselmanagement-Komplexität.

Du könntest aber auch lokal gleich wieder in der Pipe verschlüsseln

zfs send zfs at snapshot - | verschlüssel_mal(PGP etc) | ssh remote > 
snapshot_file

Dann hast Du remote nur verschlüsselten Binay-Müll), den Du erst entpacken 
und entschlüsseln mußt, um ihn wieder nutzbar zu machen.

(cat snapshot_file | entschlüssel_mal | zfs receive snapshot)

>> 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.

Ah, danke. Das hatte ich nicht gesehen.

> 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.

Ja, so ist das bei mir. Ich bin halt faul;-)

Ich mache regelmäßige Snapshots, und kann so z.B. ganz schnell mal ein 
Samba-Verzeichnis von gestern wiederherstellen:

(Jede Nacht etwas wie "zfs snapshot filesystem at Wednesday", und dann

zfs clone restore_filesystem filesystem at Wednesday
zfs set mountpoint=/jails/samba/shares/recover restore_filesystem )

Das ist das Schöne bei Snapshots auf Filesystem-Ebene. Ich kann mir das 
bei LVM-snapshots nicht so recht vorstellen.

Es ist eben ZFS als "Gesamtpaket", mit Backup, Spiegeln, Klonen (z.B. neue 
"Jails", virtuelle Maschinen ala VServer, in einem Skript und 5 Sekunden) 
etc.

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

Das stimmt. Bequemlichkeit des Vorhandenen - und Speicherplatz ist so 
billig heutzutage.. Ich kriege meine Platten hier kaum voll;-)

> 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.

Naja, ich habe z.B. neben dem -migrate-Snapshot noch eine zweite 
@migrate-old-Kopie. So kann es einmal schiefgehen, und ich kann immer noch 
inkrementell kopieren.

Das kann man bei Bedarf um beliebig viele alte Snapshots erhöhen.

Ich vermute, daß klappt auch bei lvmsync.

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

Nein, aber ich halte es für beherrschbar.

Ich habe mal verschiedene Fileserver mittels rsync lokal gespiegelt (da 
gab es in jedem der 5 Rechnenzentren weltweit einen zweiten 
Standby-Fileserver), und dann von jedem zu einem Rechenzentrum für 
Disaster Recovery.

Dann brach mal ein ssh ab, man mußte sperren, daß nicht mehrere Kopien 
gleichzeitig liefen, und dann nacharbeiten, wenn es schief ging, alle 
400GB waren die Systeme so groß geworden, daß rsync nicht mehr effektiv 
lief, d.h. es mußten neue Filesysteme angelegt werden, der Applikation 
gesagt, wo zu schreiben ist..

Mit ZFS-Snapshots fäellt der Vergleich weg, und das dauert halt bei großen 
Datenmengen. Die Snapshots sind in kurzer Zeit "durch".

Ich wäre sehr sehr froh gewesen, damals ZFS gehabt zu haben. Ich erinnere 
mich an ganze Wochenenden unter Stress (mit dem Atem des Chefs im Nacken), 
die Backups alle wieder auf die Reihe zu bringen)..

Ich vermute, mit lvmsync wäre es auch einfacher gewesen. Aber mit ZFS 
ginge noch soviel mehr (z.B. ein Filesystem für Unterverzeichnis "ganz 
schnell mal").

> 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.

Wie wärs mit einer Liste mit Timestamps?

> Aber gibt es sowas nicht schon?

ZIL?

"The write SSD cache is called ZIL (ZFS Intent Log). ZIL improves 
synchronous writes and is similar to a journal log. All data is written to 
the ZIL, but is only read after a crash. Thus, the ZIL data is normally 
never read."

Sieht doch aus wie das richtige Werkzeug dafür, ähnlich wie 
MySQL-Binlogs..

Es grüßt
Peter