Re: Backup-Lösungen
* Peter Jordan <usernetwork@gmx.info> (Sun, 08 Jul 2007 19:21:52 +0200):
>
> Fabian Pietsch, 07/08/07 18:30:
>
> > 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)
>
> Die Schlüsseldatei wird mit wipe gelöscht, sollte eigentlich reichen.
>
> Mir ist da keine wirklich abhörsichere Methode bekannt, die auch bei
> einem gekapperten Rechner noch wirksam wäre. Ich lasse mich sofort eines
> besseren belehren
Sollte ja nicht abhörsicher sein, nur nicht nach physischem Diebstahl
wiederherstellbar. Und da wäre's halt am sichersten, garnicht erst auf
die Platte zu speichern. Paranoide Gestalten haben da ja auch Angst vor
automagischem Remapping fehlerhafter Sektoren innerhalb der Festplatte
oder anderweitigen modernen Späßen. ;) Ansonsten sollte wipe gut sein.
Und speziell "abhörsicher": Client-lokal verschlüsseln sollte es tun.
(Natürlich den Schlüssel irgendwie anderweitig backuppen. ;)
> > 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. ;)
> >
> >
> > 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.)
> >
>
> Das Programm übersteht zB keinen kurzen Verbindungsabbruch und es werden
> stets die Katalogdateien vom Remoteserver heruntergeladen, so dass es
> mit jedem Backup länger dauert, die Daten zu sichern.
rdiff-backup kommt meiner Erfahrung nach auch nicht gut mit
Verbindungsabbrüchen klar... Es erkennt zwar den Fehlversuch, setzt
(mittels der Rückwärts-Binär-Diffs) alle Daten auf vor dem Fehlversuch
zurück.. kann einen aber trotzdem in den Wahnsinn treiben, wenn mehrfach
nach gut einer Stunde wegen Verbindungsabbruch von vorn begonnen werden
muss. Ist also nichts für große Datenmengen über begrenzte/
fehlerträchtige Leitungen. ;) Sind Verbindungsfehler selten, sollte es
jedoch ok sein.
dar (für sich) holt nie automagisch Katalogdateien o.ä.; es verwendet
höchstens einen einzelnen, explizit angegebenen Katalog (der bei
mehrfach-inkrementellem Backup gleichbleibend groß zum Katalog des full
backup sein sollte) und bringt dazu einen Katalog-Manager mit, dem man
explizit Kataloge in eine explizit angegebene Datenbank füttern kann
(also leicht mehrere parallel möglich). Da kann dann schnell nachgesehen
werden, welche Backup-Dateien man zur Wiederherstellung bestimmter Daten
bräuchte.
An sich erzeugt dar nur Archiv-Dateien; man müsste sie noch selbst
übertragen. Direkt in SSH pipen wäre unschön bei Verbindungsabbruch,
aber man kann nach Vollendung des Backups die Archivdatei mit irgendwas,
was Fortsetzung kann (z.B. rsync ;) übertragen. Ist wenig Platz
vorhanden, kann man auch dar's Archiv-Split-Funktionen nutzen, es
jeweils nur eine kleine Archiv-Teildatei erstellen und warten lassen,
bis man die sicher übertragen hat. Dann wäre auch ohne Fortsetzbarkeit
der Übertragung bei einem Verbindungsabbruch nicht zu viel verloren.
Nachteil ist sicherlich, dass dar keine vollständige Backup-Lösung für
sich darstellt, sondern man sich seinen Arbeitsfluss drumherum selbst
bauen muss. Angesichts der Fehleranfälligkeit "fertiger" Lösungen ist
das aber nicht unbedingt von Nachteil, und du hast so ja scheinbar auch
viel manuell um rsync herum bauen müssen.
> > 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.
Gruß, Fabian
--
Fabian "zzz" Pietsch - http://zzz.arara.de/
Reply to: