Dropbox und TrueCrypt – verschlüsselte Daten in der Cloud
von caschy | 110 Kommentare
Einige von euch nutzen Dropbox – und sicherlich auch TrueCrypt, oder? Beide Programme gibt es für Windows portabel (Portable TrueCrypt / Portable Dropbox). Sowohl Dropbox als auch TrueCrypt kann man unter Windows, Linux und Mac OS X nutzen. Vorhin habe ich ein wenig rumexperimentiert. Folgendes ist interessant: Dropbox synchronisiert alle veränderten Dateien – was bei einem TrueCrypt-Container kompliziert sein könnte. Dieser würde dann ja immer vollständig synchronisiert, da es sich quasi nur um eine Datei handelt. Wäre also albern einen 100 Megabyte großen Container jedes Mal hoch- und runterzuladen, nur weil man eine Textdatei im Container geändert hat.
Ich führte einen kleinen Testlauf durch: ich erstellte in meiner Dropbox (die ja lokal als auch online in der Cloud vorhanden ist) einen verschlüsselten Container. Die Dropbox-Software begann sofort mit dem Upload des Containers. In meinem Testlauf spielte ich erst einmal mit einem 10-Megabyte-Container herum. Ich mountete den Container und schob einige Daten hinein – wieder begann die Software mit der Aktualisierung des ganzen Containers – schließlich hatte sich der Zeitstempel geändert.
Nun habe ich TrueCrypt gesagt, dass er in Zukunft nicht den Zeitstempel ändern soll:
Diese Einstellungsmöglichkeit findet ihr unter Mac OS X in den Einstellungen im Security-Tab. Unter Windows ändert ihr dieses in den TrueCrypt-Voreinstellungen unter dem Punkt „Windows“ – „Zeiteinstellungen von Containerdateien behalten“.
Jetzt wurde nicht der komplette Container synchronisiert – sondern tatsächlich nur die Dateien, die innerhalb des Containers geändert wurden.
Wie es nun funktioniert, dass die Dropbox erkennt, dass sich neue und / oder veränderte Daten im Container befinden – keine Ahnung. Aber es funktioniert. Es werden immer nur die Änderungen im Container abgeglichen. Nicht der ganze Container. Klingt komisch – ist aber so.
Natürlich sollte man beachten, dass die Änderungen am Container erst vorgenommen werden, wenn dieser via TrueCrypt ausgehangen wird.
Ihr könnt nun also gefahrlos Daten online in der Cloud speichern. Ihr könnt zum Beispiel auf eurem USB-Stick einen Container anlegen und diesen immer mittels Portable Dropbox mit euch herumtragen. Selbst wenn ihr diesen verliert – kein Problem – einfach via Webinterface in die Dropbox – da habt ihr ja noch eine Kopie eurer verschlüsselten Daten.
Coole Lösung – und hier noch einmal der Fotobeweis, dass nur geänderte Daten abgeglichen werden (und nicht der komplette Container):
Vielleicht kann ja jemand was mit meiner Lösung anfangen =) Falls jemand Schwierigkeiten mit TrueCrypt hat – hier hatte ich eine Anleitung verfasst – alternativ sollte die Blogsuche weiterhelfen.
Wird geladen ...
Es scheint das dieser Trick in der neuen Version nicht funktioniert.
Ich habe mir extra ein Script gebastelt was das für mich automatisiert aber Dropbox will jetzt den Container nicht mehr aktualisieren
EDIT: Hm Dropbox springt erst an wenn man den Container während Dropbox läuft verändert
ein super Programm
https://www.dropbox.com/referrals/NTk0ODA3Njk
🙂 Thx!
Neuer Dropbox Account? Referral:
https://www.dropbox.com/referrals/NTgzOTc2ODk
Genialer Tipp! Hat bei mir super funktioniert.
ansonsten biete ich mit diesem Link 250 MB für mich und Euch mehr
Grüße
https://www.dropbox.com/referrals/NTUyMDE1OTg5
Hat das schon jemand mit der neuen Paket HiDrive von Strato hinbekommen? Mir will das nicht gelingen… Zumindest mit rsync unter Linux und AllwaySync unter Windows nicht.
Das kann doch gar nicht funktionieren? Wie will die Software erkennen, dass sie irgendwo ein Bit geändert hat, wenn sie nicht jedes Bit vergleicht?
Aber genau das kommt doch der Übertragung der kompletten Datei gleich. Kann mir das bitte jmd. erklären.
an Ich & Ich
Tja, wie will die Software das erkennen?
Ich habs so recherchiert (…und hoffe das ist korrekt):
Es werden eindeutige Prüfsummen von Teilen der Datei gebildet.
Wenn man eine Datei immer weiter „teilt“ (natürlich ist nicht wirkliches physisches Teilen gemeint, sondern nur Abrattern der Datei) bzw. das oft genug macht, findet man ziemlich schnell heraus wo die veränderten Bits der Datei lokalisiert sind.
Nur diese werden dann übertragen.
Trotzdem : auf der Gegenstelle auf dem Server oder sonstwo muss (muss? – das passiert zumindest in der praxis) die Datei wieder komplett neu zusammengebaut werden.
Daher ist es mit sehr großen Dateien dann auch nicht mehr so witzig und wirklich schnell.
Strato HiDrive:
fand ich zu simple, da fehlen Features, hab ich wieder abbestellt. Teanmdrive, Humyo und Dropbox finde ich deutlich besser.
Leider hat Teamdrive (immer noch) kein RSYNC, sonst wäre es mein Favorit.
Ich glaub es nicht…….und schon wieder meint hier jemand alle hätten grade nur auf seinen Dropbox Werbelink gewartet….
Hi,
super Sache. Bin zufällig auf diesen Beitrag gestoßen und er lieferte mir genau die Lösung für das problm ean dem ich gerade herum grüble!
Echt klasse Sache 😀
Hey,
wurde inzwischen eine Möglichkeit gefunden das ganze mittels einer alternativen Software über den eigenen Webspace laufen zu lassen?
Ich bin nämlich auch dringendst auf der Suche.
Wär der Hammer!
hallo caschy!
eine DAU-Frage: was muß ich denn jetzt beim Zeitstempel-Kästchen machen: Haken setzen oder wech?
Im Englischen ists mir ja klar – preserve meint aufheben, aber bei Windows würde meiner Interpretation nach ein Haken setzen bedeuten, den ursprünglichen Zeitstempel (unverändert) zu behalten…???
Habe einen 750MB-Container eingerichtet und möchte auf meiner 3Tausender-DSL-Leitung nicht wirklich ausprobieren, was was bewirkt… Danke für Deine Antwort!
Vielen Dank für diesen Test und den Hinweis. Habe ich eben bei mir nachvollzogen und es funktioniert! 🙂
Ich hatte kürzlich den gleichen Versuch mit UbuntuOne gemacht und hier scheint dieses „partielle Abgleichen“ (oder wie man es nennen will), *nicht* zu funktionieren. Es wird dort offenbar in jedem Fall immer der komplette Container hochgeladen, auch wenn der Haken bei „Preserve time…“ in TC gesetzt ist 🙁
Hat noch jemand das mit UbuntuOne probiert und kann das bestätigen (oder wiederlegen)?
@steven:
Supper recherchiert/gewusst. 🙂
Aber mit einem Teil von Deiner Nachricht bin ich nicht so ganz einverstanden.
Es stimmt, man kann einen Truecrypt Container (virtuell) zerteilen und die Prüfsummen der beiden Teile übertragen und vergleichen. Die Zerteilung findet nur virtuell statt. Wenn sich nur ganz wenig im Container verändert hat, hat man schon die eine Hälfte aussortiert. Den anderen Teil kann man dann wieder halbieren (virtuell natürlich) und man hat dann nur noch 25 % zu bearbeiten und so weiter. Nach Zehn Schritten hat man 99.9 % aussortiert. Sind mal bei einem solchen Vergleich beide Teile unterschiedlich in der Prüfsumme, z.B. weil im Container halt doch an mehreren Stellen was geändert wurde, dann muss man entsprechend diese beiden Hälften separat weiterverfolgen.
Das kann man natürlich nicht nur mit Truecrypt Containern machen, sondern mit jeder Datei.
Irgendwann hat man dann eine Liste von ganz kleinen Abschnitten, die unterschiedlich sind. Diese sind dann z.B. 1 KByte gross, denn noch feiner zu suchen erzeugt nur zu viel Overhead.
Man lädt dann nur noch die veränderten Blöcke zum Server hoch, zusammen mit der Info, welche das sind. Die übertragene Datenmenge ist dann nur ein bischen größer als die geänderten Blöcke.
(Ich hab das jetzt mal andersrum geschrieben, weil zwei verschiedene Erklärungen vielleicht noch mehr Klarheit schaffen.)
Wo ich aber noch eine Anmerkung habe, ist daß auf dem Server dann die Datei neu geschrieben werden muss, indem die nicht veränderten Blöcke der Originaldatei mit den soeben hochgeladenen kombiniert werden.
Das macht man in der Praxis gerne, weil man als Programmierer der Software dann sicherstellen kann, dass wenn was schief läuft, man immer noch zumindest die alte Version des Containers hat. Das kann passieren, wenn zum Beispiel die Verbindung abbricht, die Festplatte im Server voll läuft oder dem Server der Strom ausfällt. Man löscht dann halt die unvollständig geschriebene Version des Containers und zeigt dem User an: „Ging nicht.“.
Theoretisch könnte man auf dem Server die hochgeladenen Blöcke direkt in den Container eintragen. Bricht der Vorgang ab, hat man einen inkonsistenten Container, und keine ‚vorherige Version‘. Eine Möglichkeit wäre, die Blöcke, die man im Container überschreibt, einfach vorher wegzuspeichern. Dann kann man nach einem Fehler die Vorgängerversion zumindest rekonstruieren. Da muss man aber das Caching auf dem Server gut beherrschen, sonst kann’s passieren dass bei einem Server Crash die weggespeicherten Blöcke es nicht auf die Festplatte geschafft haben. Datenbanken haben deshalb Transaktionen.
Eine andere Lösung wäre, serverseitig gar nicht erst die aktualisierte Containerdatei zu rekonstruieren, sondern die hochgeladenen Blöcke samt Info welche das sind in einer separaten Datei zu speichern. Man nennt sowas dann „Delta Datei“. Es sammelt sich dann auf dem Server dann die erste Version des Continers, plus alle Deltas bis zur aktuellen Version an.
Wird die aktuelle Version dann abgerufen, muss diese dann aus den ganzen Deltas on-the-Fly rekonstruiert werden. Der Vorteil ist aber, dass man auch genauso einfach eine frühere Version abrufen kann.
Übrigens machen das so auch virtuelle Machinen (VMWare, VirtualBox, etc) mit den Festplatten Images. Es gibt eine erste Version und mehrere Deltas, und das Guest OS sieht die on-the-Fly rekonstruierte aktuelle Version.
Irgendwann werden die Online Storage Dienste das auch anbieten.
Hoffe das war nicht zu lang.
@heiner
War (für mich) definitv nicht zu lang, vielen Dank für die Infos!
Endlich find ich mal jemand der sich auskennt.
Hab mir alles mühsam zusammegesammelt, denn gerade diese Delta Datei Geschichte -Abspeichern und Übertragen- find ich äuerst interessant & sehr brauchbar.
Mich wundert übrigens, dass diese Technik nicht viel mehr angewendet wird.
Mögliche Antwort: „Speicherplatz verkaufen ist viel lukrativer als ihn einzusparen…“
😉
Beim Übertragen ala Dropbox usw. siehts dann halt schon anders aus, denn wer hat schon fette uploadraten? Da muss dann effizient Übertragen werden um die User nicht zu vegraulen.
Vielleicht hast Du ja einen Tip für dieses (sehr verwandte) Thema:
http://stadt-bremerhaven.de/time-machine-fuer-windows-genie-timeline/
Ich suche nämlich:
1) eine Backupsoftware mit Versionierung via Delta Dateien
2) eine Systemimagesoftware mit Versionierung via Delta Dateien
(Bislang hab ich nur arcea gefunden)
Die Hersteller schweigen sich lustig drüber aus, was sie genau anbieten – und mich kostet das Testen dann sehr viel Zeit.
Bsp.: selbst das kostenpflichtige Acronis True Image nennt sein Backup zwar „inkrementell“, schreibt aber alle geänderten Files komplett zu 100% neu, macht also zwar „Versionierung“, aber dummerweise wird keine Differenzspeicherung angewendet.
Ist also ein richtig übler Speicherfresser, wenn man sehr große Files regelmäßig sichern will.
Nur für die Annalen und um es zusammen zu fassen (auch damit ich es hier ggf. wieder finde):
Haken muss gesetzt sein und Dropbox muss bei der Befüllung des Containers laufen, sonst funktioniert es nicht (Aktuelle Version 7.0a)!
Klasse Geschichte, Cashy! Danke …
Hallo,
das Problem mit der Containergröße ergibt sich nur, wenn gleichzeitig TC-portable im Container ist, richtig?
Meine kdbx ist < 35 KB. Es reicht also ein Container mit Mindestgröße von 292 KB.
Lasse mich gern korrigieren.
Besten Dank für die Info nachträglich und auch für die Infos in den Kommentaren!
@caschy: Kannst du pipimans frühpupertären Unsinn evtl. entfernen? So etwas muss ja trotz der amüsanten Kommentarnummer nun nicht unbedingt sein, oder? 😉
(Dieser Absatz kann wg. des Links danach natürlich entfernt werden)
erledigt
Das ging flott.
war zufällig online 😉
Wann nicht? 😉