everflux

Ich bekomme seit einer Weile Werbung für USB Sticks und anderen Speicher Krams von einer Firma die angeblich in Schweden sitzt – zumindest steht es so in der E-Mail drinn (das könnte natürlich auch gefälscht sein):

Speicher-Depot ist ein Unternehmen der Techimport AB.
Stensätravägen 2, 127 39 Stockholm, Schweden
Geschäftsführer Håkan Ericson
SteuerIdNr: SE556689899401 , 17/080/26413
Tel.: 0800 200 300 5

Leider hat das Eintragen in die „Sperrliste“ bisher auch nicht geholfen. (Wobei viele Spam Experten auch davon abraten, sich da einzutragen, weil man damit seine E-Mail validiert und mit noch mehr Spam rechnen muss.)

Solche unerwünschten E-Mails stellen eine deutliche Störung dar – in diesem Fall jedoch ist etwas anders. Die Firma stellt als Kundenservice eine kostenlose Rufnummer zur Verfügung.
Hier könnte entsprechende Abhilfe (Bereinigung des Adressverteilers) durch den Anbieter erfolgen, sobald sich genug Leute per Telefon beschweren. Ich werde jedenfalls bei jeder unerwünschten E-Mail bei dem guten Laden anrufen und um Austragung bitten.

Bei Caliper handelt es sich um ein Framework um Mikrobenchmarks für Java Programme durchzuführen. Caliper ist bei Google code gehostet – http://code.google.com/p/caliper/ – und steht unter der Apache 2 Lizenz, kann somit sehr frei verwendet werden.

Caliper verfolgt einen ähnlichen Ansatz wie JUnit, Methoden müssen mit „time“ als Prefix benannt werden, und einen Parameter vom Typ int entgegennehmen um dann ausgeführt zu werden. Dieser Parameter gibt an, wie viele Iterationen der zu messenden Methode durchzuführen sind.

Leider ist Caliper bisher noch nicht in einer Version 1.0 released worden, daher bleibt nur selber bauen. Derzeit ist das jedoch auch nicht ganz einfach: Caliper haengt von Google Guava ab, nutzt in der svn-trunk Version dazu auch bereits Features von Guava r10, was auch noch nicht released ist. Also auch hier: Selber bauen, und die Abhängigkeit in Caliper korrigieren. Mein favorisiertes Build Tool ist in diesem Fall maven.

Möchte man noch während des Benchmarks die Speichernutzung analysieren, so bietet Caliper dies auch an – über einen Java Agent der von dem Google Projekt java-allocation-instrumenter (http://code.google.com/p/java-allocation-instrumenter/, Apache 2 Lizenz) bereitgestellt wird. (Leider ist hier derzeit der Maven Build nicht so konfiguriert, dass als Artefakt ein nutzbarer Java Agent erzeugt wird. Dies ist im Ant basierten Build in Ordnung, und kann mit einem kleinen Patch der Maven Konfiguration auch behoben werden.)

Der letzte Wehrmutstropfen bleibt nun, dass Caliper gerne eine Environment Variable, statt bspw. einem System Property, hätte, um den zu nutzenden Java-Agent zu spezifizieren – diese lässt sich bei Ausführung als Script zwar einfach setzten, jedoch aus einer Java Anwendung heraus eigentlich nicht. Dazu später mehr.) Weiterlesen »

Ich verwende zur Datensicherung ein selbst gebautes Script und brenne die Daten danach auf Bluray Medien zur externen Hinterlegung.
Bisher habe ich dazu in etwa folgenden Aufruf verwendet:

tar -v --label="tkruse-home" -l -c -p --totals --ignore-failed-read ... | gpg --compress-algo bzip2 --cipher-algo AES256 -z 9 -c

Nun komprimiert bzip2 ja nicht besonders gut im Verhältnis zum dafür erforderlichen Aufwand (und die Dekomprimierung ist langsam). Leider unterstützt GPG von Haus aus lediglich bzip2 und zlib, nicht den von mir favorisierten lzma Algorithmus. (Der kommt bei 7zip auch zum Einsatz und sorgt für die gute Kompressionsrate.)
Jedoch ist bei modernen Linux Distributionen wie Debian und dem darauf basierenden Ubuntu auch das Kommandozeilentool „lzma“ verfügbar. Dies kann in guter alter Unix Manier als Filter eingesetzt werden, lediglich gpg muss dann noch beigebracht werden, keine eigene Komprimierung einzusetzen. Dies geschieht wenn man als „Algorithmus“ einen der Werte „none“ oder „uncompressed“ verwendet.
Der Aufruf sieht dann so aus:

tar -v --label="tkruse-home" -l -c -p --totals --ignore-failed-read ... | lzma -c -z -9 | gpg --compress-algo none --cipher-algo AES256 -c


Leider unterstützt das lzma Tool derzeit (2011) noch kein multithreading (im Gegensatz zu 7zip), so dass keine Parallelität auf multi-core Maschinen ausgenutzt werden kann.

Im Gegensatz zu anderen Backup Lösungen hat meine Lösung den Nachteil kein inkrementelles Backup zu unterstützen, die Backup Datei hat keine Redundanz gegen defekte Blöcke und als Ausgabe kommt lediglich eine große Datei heraus, die anschließend gesichert werden muss. Für mich reicht das – für einen normalen Anwender ist es vermutlich nicht das Mittel der Wahl.