hier ein Beispiel:
1-unverschlüsselt = 1101101011....
2-verschlüsselt = 101111011.... (mit key =abc)
was wird lokal gespeichert ? = 2-(!33#)
was wird in der Cloud gespeichert ? = 2-
das kann doch dedupliziert werden --- oder?
Ja, das setzt aber voraus dass sich dieser Block nicht ändert. Das ist keine Deduplizierung. Wenn aber sich nur ein einziges Bit in 1 ändert, ändert sich nicht automatisch nur das korrespondierende Bit in 2, das ist Dir schon klar oder?
Fassen wir Deiner Logik nach mal alles zusammen: verschlüsselte Blöcke, die sich nicht ändern, werden "dedupliziert" ("" deswegen, weil das keine Deduplizierung ist, sondern nur eine Abwandlung traditioneller inkrementeller Datensicherung, nur auf Blockebene statt Fileebene). Wann aber verändern sich verschlüsselte Blöcke nicht? genau, wenn sich nicht ein einziges Bit des zugrundeliegenden Klartexts ändert.
Deduplizierung funktioniert aber anders: sie erkennt das historische Delta zwischen zwei Klartext-Blöcken, genauer erkennt sie sich wiederholende Muster und speichert dann nur eine Referenz auf das "Urmuster". Bei verschlüsselten Blöcken lassen sich aber genau solche Muster nicht feststellen, da die Verschlüsselungsalgorithmen bewusst so stark gewählt werden, dass es eben keine erkennbaren Muster gibt!
Somit bleibt nur ein Schluss: verschlüsselte Daten lassen sich nicht deduplizieren. Es kann nur maximal verhindert werden, dass unveränderte verschlüsselte Speicherblöcke wiederholt vom Client zum Server übertragen werden. Dies erreicht man maximal bei Archivdaten, die sich nicht verändern. Bei Bewegungsdaten dedupliziert sich da also nichts.
Zu Deiner Frage: jedes gute Backupsystem wie Networker oder Netbackup beherrscht Deduplizierung und Kompression auf der Clientseite. Meistens setzt man es aber nicht ein, da entsprechende Freikapazitäten auf den Clients vorhanden sein müssen.
Und nun bin ich hier raus.
