
Mailarchivierung nach GdPdu
Ab Januar 2017 ist die Übergangszeit fue die Einführung einer Mailarchivierungslösung abgelaufen. Ab jetzt drohen auch in Düsseldorf empfindliche Strafen.
Ab Januar 2017 ist die Übergangszeit fue die Einführung einer Mailarchivierungslösung abgelaufen. Ab jetzt drohen auch in Düsseldorf empfindliche Strafen.
In vielen Ladengeschäften fällt die Kasse für Zahlungen "mit Karte" aus, wenn die Internet-Verbindung ausfällt. Lange Schlangen dienen nicht der Zufriedenheit der Kunden, denen die technischen Probleme "unverständlich" sind. Wir haben kostengünstige Lösungen für den Notfall.
Unser RBlkSync wird ein Kommandozeilentool für Unix-ähnliche Betriebssysteme (programmiert auf und für Linux), mit dem der Anwender die Inhalte von Blockdevices auf einem Rechner, oder über ein IP-Netzwerk auf einen entfernten Rechner kopieren kann. Dabei kann die Quelle, wie auch das Ziel, aus einem Blockdevice oder einer Datei bestehen. Wenn das Ziel (Blockdevice oder Datei im Ziel) bereits existiert, sollen nur geänderte Blöcke kopiert werden. In einem solchen Fall nennen wir den Kopiervorgang synchronisieren, wofür das "Sync" im Namen steht.
Sind Quelle und Ziel unterschiedliche Systeme, so wird über ein IP-Netzwerk kopiert. In einem solchen Fall muss dafür Sorge getragen werden, dass die Kommunikation über das Netzwerk verschlüsselt wird. Hierzu soll RBlkSync zwei verschiedene Modi zur Verfügung stellen.
Im Server-Modus wird das lokale RBlkSync seine Daten an die Standard-Ausgabe senden - auf dem Zielserver RBlkSync im Servermodus gestartet, liest eingehende Datenströme von der Standard-Eingabe und verarbeitet diese. Antworten sendet die Serverseite von RBlkSync an seine Standard-Ausgabe, welche von dem lokalen RBlkSync an der Standard-Eingabe empfangen werden. So können die beiden Teile von RBlkSync miteinander über Standardein- und -augabe kommunizieren. Werden die beiden Teile von RBlkSync auf verschiedenen Rechnern gestartet und nutzt man zum Starten SSH, so erfolgt die Kommunikation dank SSH über das Netzwerk und wird verschlüsselt.
Im Daemon-Modus wird RBlkSync intern dafür Sorge tragen, dass die Netzwerkkommunikation verschlüsselt ist. Aus Performance-Gründen habe ich mich für eine synchrone Verschlüsselung entschieden, die Schlüssel dazu sollen über ein Public-Key-Verfahren ausgetauscht werden. Die Verschlüsselung soll per Default aktiv sein - bei einer Synchronisation im LAN aber abgeschaltet werden können. Gerne würde ich für die reine Nutzdatenübertragung UDP verwenden, um den TCP-Overhead einzusparen. Für die ersten Versionen werde ich allerdings TCP nutzen und später, sollten eingehende Tests mit UDP positiv verlaufen, die Datenübertragung per UDP als Option anbieten. Ich werde verschiedene Kompressionsverfahren für die Datenblöcke anbieten. Die Kompression der zu übertragenden Datenblöcke kann per Option abgeschaltet oder auch festgelegt werden. Bei der automatischen Kompression wird der "Sender" (die Quelle) anhand seiner Netzwerkwarteschlangen bestimmen, welches Kompressionsverfahren eingestzt wird. Je länger die Warteschlange für das Senden über das Netzwerk, je höher (und damit zeitaufwändiger) wird das Kompressionsverfahren gewählt.
Die Projektbeschreibung ist nicht final. Sollten uns während der Projektdurchführung weitere nützliche Features und Optionen einfallen, wird die Projektbeschreibung geändert.
Die Roadmap ist eine grobe Zeitplanung und nicht final. Durch erhöhtes Arbeitsaufkommen kann sich die für solche Projekte zur Verfügung stehende Arbeitszeit vermindern. In einem solchen Fall müssen wir die Roadmap anpassen.
Entlasten Sie Ihre IT und entscheiden Sie sich für unsere Produkte und unseren Support. Wir machen uns stark für Ihren Erfolg.