[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backup-Lösungen



* Peter Jordan <usernetwork@gmx.info> (Sun, 08 Jul 2007 21:55:53 +0200):
> Fabian Pietsch, 07/08/07 20:30:
> > > > 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. ;)
> > >
> > > Hmmm, ob das realisierbar wäre? ;-)
> > 
> > Warum nicht? ;) Wäre nur wohl auf dem Client potentiell langsam... (?)
> > Und vllt. sprechen noch andere Dinge dagegen, auf die ich nicht komme.
> 
> Dazu fehlen mir wohl die Kenntnisse :-)

Vorhin ist mir noch was eingefallen... Aus der cfs package description:

| CFS can use any available file system for its underlying storage
| without modification, including remote file servers such as NFS.

(In /usr/share/doc/cfs/README.Debian geht das quote noch weiter: )

| System management functions, such as file backup, work in a normal
| manner and without knowledge of the key.

Du könntest also auch vom Backup-Server auf dem -Client NFS oder sshfs
o.ä. mounten, dadrauf dann cfs und *darauf* ("lokal") sichern; auch dann
wird's client-seitig verschlüsselt und man muss nichtmal in den
Backup-Tools was dafür tun. ;)

Die alte Idee (Client komplett in einem cfs laufen lassen) wäre wohl
wirklich aufwändig zu implementieren -- im Alleingang Automatismen für
Herum-chroot-en beim Start und eine Hintertür zum späteren Zugriff
außerhalb des chroots lassen [1] etc. Ich habe sowas mal gemacht [2],
anders als ursprünglich gedacht ist das wirklich kein Spaß, wenn man
möchte, dass nachher alles auch stabil und automatisch läuft. Aber es
wäre wohl technisch möglich. ;)

Persönlich würde ich wohl (nach all dem Wust möglicher Lösungen ;) einen
Versuch mit dar wagen. Wie Martin Lange schon schrieb, kann es -E; damit
könnte man es z.B. auch in vielen kleinen Slices sichern lassen und die
jeweils gleich nach Erstellung übertragen und lokal löschen, sollte man
auf dem Client wenig Platz haben.

Gruß, Fabian


[1] z.B. durch einen früh gestarteten sshd

[2] als ich keine separate Partition für ein Debian chroot in einem SuSE
hatte, aber trotzdem "das Debian booten" *und* von daraus auf die Daten
im Rest der Partition zugreifen können wollte; außerdem kann man aus
einem chroot in einem *Teil* des Dateisystems es nicht read-only
remounten, vor dem poweroff... :-S

-- 
Fabian "zzz" Pietsch - http://zzz.arara.de/



Reply to: