Getesteter Bestand

Folgende Dinge werden für den Test verwendet:

Brenner/Lesegerät

Phillips DVDR 1648P1 P2.2

Brenngeschwindigkeit

1-fach

Rohlinge

CD Original

1x vom 29.11.1995, 1x vom 09.04.1996

CD-R, Tevion

2x 10.05.2006, 1x vom 12.05.2005 (die war mit 40x Geschwindigkeit gebrannt worden)

CD-R, BASF Ceram Guard

1x vom 05.10.1999

DVD-R, Octron 16x (HerstellerID: ritekf 1)

2x vom 17.05.2009, 1x vom 16.5.2009

DVD+R, Platinum 16x (HerstellerID: MBIPG101R05)

1x vom 28.03.2009, 1x vom 16.05.2009

DVD-RW, Verbatim 4x (HerstellerID: MCC 01 RW 4X)

1x vom 28.03.2009, 2x vom 16.05.2009

DVD+RW, Maxell 4x (HerstellerID: ritek 004)

2x vom 17.05.2009, 2x vom 20.09.2009

Bei den Tests gab es bisher noch keine Fehler. Leider ist bisher auch nur der Hauch einer Tendenz zu erkennen, und zwar bei einer einzigen DVD.

Bei dieser einen Octron DVD-R, die am 17.05.2009 gebrannt wurde, gibt es leichte Probleme beim Lesen des Anfangssektors und sporadisch auch mal im Endbereich.

Mit den Erkentnissen aus den vorherigen Kratzertests, nämlich dass Fehler die mit der Spur laufen gravierend sind und Fehler am Beginn der DVD den Datenträger unbrauchbar machen können, ist das schon alarmierend. Vor allem, da die DVD gerade mal ein halbes Jahr alt ist. Bei der besagten DVD braucht das Laufwerk auch einige Sekunden, bis es den Datenträger als solchen erkennt. Wird der Fehler stärker, wird die DVD nicht mehr lesbar sein und die Daten sind verloren.

Bei den getesteten CDs ist zu sehen, dass diese sich für dauerhafte und sichere Backups sehr gut eignen. Die 15 Jahre alten, gepressten original-CDs sind, wie zu erwarten war, noch wie neu.

Der 10 Jahre alte BASF-Rohling hat zwar eine etwas unruhige Kennlinie beim Auslesen, diese änderte sich aber in dem halben Jahr nicht.

Und selbst der fast 5 Jahre alte billig-Rohling von Tevion, immerhin nur mal nebenbei mit 40x Geschwindigkeit gebrannt, sieht nicht anders aus und änderte sein Verhalten auch nicht im Testzeitraum. Es ist also zu erwarten, dass die Dinger im Zweiffel auch noch in 20 Jahren laufen würden, wobei der Tod dort warscheinlich auch plötzlich und ohne Vorwarnung eintreten wird.

Fazit

CDs sind, wie erwartet, bewährt, haltbar und zu empfehlen. Da bei den DVDs bisher keinerlei Ungewöhnlichkeiten oder Probleme auszumachen waren, kann ich daraus noch keinen Schluss ziehen.

Da auf den DVDs meine eigenen Backups liegen, allerdings jeweils doppelt und zusätzlich noch auf einer Backup-HD, werd ich den Test weiter fortführen. Wenn meine Theorie stimmt, sollte innerhalb der nächsten anderthalb Jahre irgendwas gravierendes passieren. Hoffentlich diesmal ohne das Daten verloren gehen

Erstens: eigene Erfahrung
In Wiesbadens Innenstadt lauern ja öfter mal Spendensammler, und beim “Bund deutscher Tierfreunde” hatte ich mich mal spaßeshalber eingetragen. Da die Leute am Stand mal abgesehen von herzzerreißenden Geschichten über Tierquälerei nichts weiter von sich geben, hab ich mich auf die 14 Tage Sonderkündigungsrecht gestützt und erst NACH der Unterschrift nachgeforscht. Unter Charitywatch.de bin ich zu dem Verein gleich mehrfach fündig geworden. Die Kündigung war kein Problem, aber ein gegen einen anderen Verein laufen gerade Ermittlungen wege Datenmissbrauch. D.h. meine Bankdaten währen dort ggf. schon weitergegeben worden.

Ich hab für mich entschieden, dass ich bei solchen “Anfixern” jetzt mal mindestens folgende Fragen stellen werde, bevor ich überhaupt nur daran denke was zu spenden:

• Haben Sie das Spendensiegel
• Wo kann ich die Bilanzen einsehen? (Spendensiegel-Vereine verpflichten sich zur Selbstauskunft)
• Wohin fließen die Gelder konkret. Mindestens 2 Projekte mit Ortsangaben und Geldbetrag
• Wo kann ich mir das ansehen? (Und wenn es in Timbuktu ist, wenigstens eine Adresse/Anschrift etc)

Zweitens: eine Recherche vom Deutschlandfunk
Im Deutschlandfunk gab es heute einen Bericht über Spenden bei der Tsunami-Katastrophe vor 5 Jahren. Zugegeben wohl eines der extremen Beispiele, aber sowohl der Aufwand auf Seiten des Betrügers als auch die Reaktion der zuständigen Staatsanwaltschaft kann man als extrem gering betrachten.

Der Betrüger konnte völlig unbehelligt noch einige Zeit in Deutschland leben und ist dann einfach ausgereist. Einen Haftbefehl, für immerhin 2,3 Millionen unterschlagene Euro und offensichtliche Urkundenfälschung, gibt es bis heute nicht. Wenn ich mal Geld brauche werd ich wohl kaum noch eine Bank überfallen. Diese Art ist viel einfacher, lukrativer und ist quasi straffrei >:)

Fazit

Spenden ist eine gefährliche Sache. Selbst wirklich großen Vereinen kann man nur bedingt vertrauen, denn auch da gibts z.B. bei Charitywatch Eintragungen die nichts gutes heißen. D.h.: erst Prüfen und unbequeme Fragen stellen und erst dann, wenn adequate Antworten kommen, Geld geben. Am besten natürlich: die Verwendung sicher nachprüfen (lassen).

Es ist mal eine wirklich interessante Mischung von 2 “Genres”, die eigentlich so gar nichts miteinander zu tun haben und es sind einige Level dabei, bei denen man die grauen Zellen schon ein wenig Anstrengen muss. Eine Spielbeschreibung lohnt sich kaum, denn das Prinzip ist extrem simpel und intuitiv. Und Nebenbei: auch die Musikuntermalung ist wirklich nett gemacht.

Insgesamt hab hatte ich etwas unter 2 Stunden meinen Spaß mit dem Spiel. Die Level kann man auch überspringen, wodurch man das Spiel ganz entspannt über viele Tage verteilen kann.

Wer also auf Knobelspaß steht, sollte es einfach mal ausprobieren.

• Ein ein mal gesetztes Float kann nur durch ein Clear aufgehoben werden (oder mit hässlichen Hacks, die aber in verschiedenen Browsern verschiedene Probleme machen)
• Man kann immer nur ALLE floats (einer Richtung) aufheben. Also nicht nur das eine bestmmte, sondern im Zweiffel auch alle anderen, die man nicht erwischen wollte.
• In so ziemlich jeder unterschiedlichen IE-Version gibt es damit unterschiedliche Fehler.
• In allen Browsern brechen die “gefloeteten” Elemente aus ihrem umgebenden Container aus. Das muss man dann auch wieder mit Hacks irgendwie umgehen (und das ist, finde ich, das schlimmste Problem, weil am nervigsten)

Und wenn man es sich mal genau überlegt, wofür float eigentlich gedacht ist, ist es eigentlich klar, dass es so viele Probleme damit gibt. Ich denke es ist eben für Dinge wie ein Bild, was von Textblöckem umflossen wird und nicht um z.B. Navigationspunkte horizontal in einer Reihe anzuordnen oder ein 3-Spalten-Layout zu erstellen.

Und genau die zwei letztgenannten Anforderungen trieben mich dazu, mal in der Liste der CSS-Angaben zu suchen. Gefunden hab ich dort display: inline-block, was zwar auch nicht ohne Probleme ist, aber die sind örtlich begrenzt und eher handhabbar als ein außer Kontrolle geratenes Float.

Man definert mit dieser Angabe, dass sich das aktuelle Element nach “außen” wie ein inline-Element verhält, also keinen Umbruch hat und die Breite ggf. automatisch wählt, “innen” aber alles wie beim Block möglich ist. Also fixe Breitenangaben, wenn man denn will, margin und padding etc. Außerdem ist es extrem stressfrei, da es eben nur für genau dieses eine Element gilt und in dem umgebenden Block quasi eingesperrt bleibt. Also keine Nebenwirkungen außerhalb haben kann. Und will man den Elementfluss unterbrechen, um z.B. mehrere Zeilen zu haben, reicht ein einfaches <br/>.

Da das aber zu schön ist, gibts dann doch noch ein paar Probleme, nämlich folgende:

Whitespaces

Gibt es Zeichen zwischen den Elementen, z.B. Whitespaces, dann werden die, wie bei Fließtext auch, zwischen den Elementen dargestellt und erzeugen einen Abstand. Das kann man verhindern, in dem umgebeenden Block die Schriftgröße 0 zuteilt. Dazu muss es aber eben immer einen Umgebenden Block geben. Wenn man dann nicht für jedes enthaltene Element wieder definieren will, wie groß die Schrift dort wieder sein soll, muss man global eine absolute Schriftgröße angeben (* { font-size; 10pt; }). Alternativ kann man auch einfach keine Zeichen zwischen die Elemente setzen, auch keinen Zeilenumbruch, und braucht dann nicht mit den Schriftgrößen hantieren (der Quellcode ist dann aber unleserlich).

FireFox vor Version 2

Alle Versionen des FireFox vor Version 3 kennen die Angabe nicht. Allerdings gibt es dafür dort eine properitäre Angabe die genau das gleiche macht. Und die inline-block Angabe wird komplett ignoriert. Also kann man einfach VOR display:inline-block; die Angabe display:-moz-inline-box; setzen und alle FF sind glücklich

IE vor Version 8

Alle IE vor der Version 8 kennen die Angabe nicht. Allerdings ist display:inline; dort so fehlerhaft umgesetzt dass es sich exakt so wie display:inline-block verhält Dumm ist nur, dass man nicht so einfach vorgehen kann wie beim FF kleiner v3 da die unbekannten Angaben trotzdem verwendet werden (was auch immer er dann macht, aber es ist falsch). Hier kann man entweder ConditionalComments benutzen, worurch die Angaben aber voneinander getrennt abgelegt werden, oder folgende Hacks:

Für IE 6

* html MEINELEMENT { display: inline; }

Für IE 7

*+ html MEINELEMENT { display: inline; }

Leider muss man BEIDE Angaben einzeln machen, da der eine Hack für den IE7 den für den IE6 unbrauchbar macht.

Unterschiedliche Höhen

Die Elemente, die man nebeneinander platzieren möchte, sind ja nicht immer alle gleich groß. Der Trick, das am einfachsten und effektivsten ist, ist einfach alle per vertical-align:top an der oberen Kante ausrichten.

Damit lassen sich für folgende Browser alle Unzulänglichkeiten ausbügeln, die mir bisher aufgefallen sind und es sieht dort überall gleich aus:

• Opera seit mindestens v9.5
• IE seit v6
• FF seit mindestens v0.9

Hier mal ein Beispiel und der Code für eine Liste, deren Elemente nebeneinander stehen sollen und nach deren dritten Element eine zweite Zeile beginnen soll. Natürlich ist das für so ein einfaches beispiel viel einfacher per float umsetzbar, aber ich will gar nicht wissen, wie viele Zeilen CSS-Hacks ich schon geschrieben habe, um genau so einfache Sachen in größeren Layouts für den IE wieder gangbar zu machen.

Bsp: Display:inline-block in Aktion.


<style type="text/css">
/* solve whitespace-problem, part 1 */
* {
font-size: 12pt;
}
div#codeexdib {
/* solve whitespace-problem, part 2 */
font-size: 0;
/* only to show... */
border: solid 2px blue;
margin: 0;
padding: 0;
list-style: none;
}
div#codeexdib div {
/* FF before v3 solved */
display: -moz-inline-box;
display: inline-block;
/* force alignment */
vertical-align: top;
/* only to show... */
border: solid 2px red;
margin: 0;
padding: 1em;
}
/* IE6 solved */
* html div#codeexdib div {
display: inline;
}
/* IE7 solved */
*+ html div#codeexdib div {
display: inline;
}
</style>
<div id="codeexdib">
<div style="height:8em">Eins:1</div>
<div>Zwei:1</div>
<div style="width:4em">Drei:1</div>
<br/>
<div>Eins:2</div>
<div>Zwei:2</div>
</div>


Nachtrag: Ich hatte im Beispiel vormals UL und LI verwenden und darin ein BR, das funktioniert natürlich nicht weils nicht valide ist. Interessanterweise “mekern” nur alle IE (6 bis und verschieben das BR in das davor liegende LI um wieder validen Code zu haben.

Da auf meinem Server das gesamte /var/www in einer RAM-Disk liegt und die natürlich nicht so sonderlich groß ist, musste eine Lösung her. Bei der Suche nach dem Schuldigen in Sachen Platzverbrauch kam das /languages/messages Verzeichis mit immerhin 31MB in Frage. 99% dieser Sprachen kann man, wenn man kein internationales Publikum auf seinem Wiki erwartet, entfernen. Folgendes muss getan werden, damit nur DE übrig bleibt und das gesamte Wiki damit auf 12MB zusammengeschrumft wird:

cd mediawiki/languages/messages

Ins Sprachverzeichnis wechseln

mkdir tmp

Ein Sammelverzeichnis anlegen

mv Messages* tmp

Erst mal alle Dateien beiseite schieben

mv tmp/MessagesDe_formal.php .;mv tmp/MessagesDe.php .;mv tmp/MessagesEn.php .

Die nötigen Sprachdateien wieder zurück verschieben

rm -rf tmp

Die anderen Sprachdateien entfernen

Jetzt stehen in der Konfiguration die anderen Sprachen aber noch zur Auswahl. Wenn man die jetzt wählt, ist das Wiki für den Benutzer leer und er kann die Sprache auch nciht wieder zurücksetzen. Das kann geändert werden, in dem man die Datei ediawiki/languages/Names.php editiert und alle Zeilen bis auf DE und EN mit // am Anfang auskommentiert (oder Blockweise per /* … */).

Aufgetretene Probleme:

• Die EN-Sprachdatei wird zwingend benötigt. Ohne sie gibt es einen Laufzeitfehler
• Die DE_formal-Sprachdatei scheint fix mit DE verknüpft zu sein. Fehlt sie, ist der Inhalt des Wiki komplett leer. Man kann “formal” in der Names auch auskommentieren und es taucht in der Auswahl trotzdem auf
• Benutzer, die eine andere Sprache ausgeewählt haben, können das Wiki nicht mehr benutzen. Deswege kann diese Methode nur bei der Installation oder wenn man sich seiner Sache ganz sicher ist angewandt werden

Nebenbei: bei der Suche und installation des Wiki ist mir mal wieder deutlich gezeigt worden, warum PHP bei solchen Projekten so beliebt ist. Ich hatte vorher Foswiki versucht zu installieren und das ist mäßig dokumentiert und die Abhängigkeiten, z.B. vom CPAN, sind mäßig leicht auflösbar. Beim Mediawiki lief es auf ein raufkopieren, aufrufen im Browser und DB-Benutzer anlegen hinaus. Leichter gehts kaum.

Warum könnend bei Perl-Projekten die benötigten CPAN-Module nicht einfach mitgeliefert werden und im Modulverzeichnis liegen? Das vereinfacht das Ganze doch erheblich.

Nach dem Update sehen die Einstellungen komplett anders aus. Es gibt keine Clean-Cache-Events mehr sondern nur noch den “Cache invalidation mode”. Den hab ich auf “all” gelassen und es scheint soweit die gleiche Funktion zu erfüllen. Ändert man an den Daten etwas, werden alle Cache-Daten entfernt.

Gzip wurde in “Enable compression” umbenannt, was etwas verwirrend ist, da die Funktionsweise nicht genau erklärt wird. Das steht nach wie vor auf “ein”. Außerdem gibts ein neues “Disk space usage”, was genauso wenig erklärt wird. Ich hab es erst mal aus gelassen, da dort was von “less performant” steht und der Cache nicht wirklich kleiner wurde.

Nachdem ich alle Optionen neu gesetzt hatte wollte ich den Cache testen. Die Startseite funktionierte tadellos und wurde auch gecacht und im Quelltext stand das HyperCache-Kommentar ganz am Ende. Alle anderen Seiten wurden aber NICHT gecacht. Nach etlichen Einstellungsversuchen und auch einem Downgrade auf Version 2.3.2 änderte sich das nicht. Erst, als ich mal durch Zufall den Browser schloss und dann nochmal testete.

Was war passiert? HyperCache aktiviert normalerweise den Cache für alle anonymen Benutzer, für eingelogggte ist er IMMER abgeschalten. Warum auch immer, aber die Startseite ist da wohl eine Ausnahme, was bei mir kräftig für Verwirrung sorgte. Also immer dran denken, wenn man den Cache testet: erst wieder ausloggen.

Ansonsten rennt das Plugin nach wie vor wie Hulle ( Tendenz Otze )

Das blanke Verzeichnis als Repository

SVN hat eigentlich gar keinen Server, sondern nur eine Vorggegebene Verzeichnisstruktur und eine dazugehörige Datenbank, die zusammen ein Repository darstellen. Man kann als Datei direkt per svn [COMMAND] file:///my/repository/path darauf zugreifen. Da man hier aber nur lokal zugreifen kann, die Benutzerrechte entsprechend anpassen muss und ansonsten auch keinerlei Zugriffsschutz einrichten kann, fiel das schonmal flach.

Als Apache2-Modul

Ein Apache-Server in dem per WebDAV und SVN connector auf das Repository zugegriffen werden kann. Hier hab ich keine brauchbare Anleitung finden können, die mir schnell genug zum Ziel führte. Außerdem müsste dann immer ein Apache laufen, was mir ein wenig wie mit Kanonen auf Spatzen zu schießen erscheint. Also so auch nicht.

Der mitgelieferte svnserve-Deamon

Ein eigener Deamon der mit svn schon mitgeliefert wird und super simpel funktioniert. Er ist nicht sonderlich sicher, aber ich greife nur über ein VPN auf den Dienst zu, da ist die Sicherheit nicht ganz so wichtig. Hier war diese Anleitung ganz hilfreich, die mir hier auch als Grundlage diente.

Folgendes muss (als Root oder per Sudo) getan werden, um ein SVN-Repository incl. “Server” aufzusetzen:

Vorbereiten

apt-get install subversion

Alle benötigten SVN Module installieren

mkdir /home/svn;chown root:root /home/svn;chmod go-rwx /home/svn

Das Root-Verzeichniss anlegen, in dem alle SVN-Repositories untergebracht werden sollen, und die Rechte so setzen, dass nur root darin etwas machen kann

echo -e “[users]\nmyUser = myUnencryptedPwd” > /home/svn/.passwd

Legt die allgemeingültige “Benutzertabelle” für SVN an. Hier der Benutzer myUser mit dem Passwort myUnencryptedPwd. Neue Benutzer einfach in die Datei in eine neue Zeile eintragen. Aber ACHTUNG: die Passworter liegen im Klartext vor und das lässt sich in der Form auch nicht ändern. Also am besten eigene, nur für dieses SVN gedachte Passwörter benutzen.

echo -e “[general]\nanon-access = none\nauth-access = write\npassword-db = ../../.passwd” > /home/svn/svnserve.conf

Legt die SVNServe-Config an und zwar so, dass die eben angelegte Benutzertabelle verwendet wird und nur autorisierte Benutzer auf die Repositories zugreifen dürfen

chmod 600 /home/svn/.passwd;chmod 600 /home/svn/svnserve.conf

Die Rechte zur Sicherheit nochmal einschränken, schließlich stehen da Passwörter im Klartext drin

Die angelegte Benutzertabelle und die Server-Config sollen in allen Repositories gelten, weswegen sie hier im SVN-Root-Verzeichnis liegen. Man kann das auch für jedes einzelne Repository machen, aber das das brauche zumindest ich an dieser Stelle nicht.

Server einrichten und starten

Dieses Init-Script runterladen…

…und dann die Zeile
DAEMON_ARGS="-d -r /home/svn --listen-host 127.0.0.1"anpassen. IP und Port z.B. Das Script selber stammt aus der oben erwähnten Anleitung.

mv [INITDATEI] /etc/init.d/svnserve;chmod +x /etc/init.d/svnserve

Die Datei im Standart-Startordner des Systemes ablegen und die Rechte anpassen

update-rc.d svnserve defaults

Bewirkt, dass der Server beim Systemstart immer mitgestartet wird

/etc/init.d/svnserve start

Startet des SVN-Server

Ein Repository anlegen

Diesen Schritt kann man für jedes neue Repository ausführen

svnadmin create /home/svn/myFirstRepo

Legt das Repository an, also die SVN Datenbank und die Grundlegenden Verzeichnisse. In dem Fall mit dem Namen myFirstRepo

cd /home/svn/myFirstRepo/conf;rm *;ln -s ../../svnserve.conf;

Entfernt die Config und Benutzertabelle für das Repository und verwendet die oben angelegten, globalen Dateien

/etc/init.d/svnserve restart

Startet des SVN-Server neu, damit er die Änderungen auch mitbekommt

Jetzt kann man per svn info svn://127.0.0.1/myFirstRepo, nur eben mit der passenden IP, prüfen ob alles geht. Der Login sollte abgefragt und ein paar grundlegende Daten über das Repository angezeigt werden.

Dem neuen Repository fehlen aber noch ein paar Dinge, die die meisten SVN-Clienten einfach voraussetzen. Z.B. dass man Branches im /branches Verzeichnis ablegt und dass der Trunk unter /trunk liegt u.v.m. Deshalb ist es sinnvoll, gleich die empfohlene Verzeichnisstruktur anzulegen. Hierzu muss man als normaler Benutzer folgendes tun:

mkdir tmp
mkdir tmp/trunk
mkdir tmp/trunk/myFirstProject
mkdir tmp/branches
mkdir tmp/branches/myFirstProject
mkdir tmp/tags
mkdir tmp/tags/branches
mkdir tmp/tags/branches/myFirstProject
svn import tmp svn://127.0.0.1/myFirstRepo -m "svn-Verzeichnisstruktur erstellt"

Weiteres Projekt einem repository hinzufügen

Damit werden die grundlegenden Verzeichnisse im Repository abgelegt. Die myFirstProjekt-Verzeichnisse sind die Verzeichnisse für ein einzelnes Projekt. Will man eines weiteres hinzufügen, muss man folgendes, wieder als normaler Benutzer, tun:

svn co svn://127.0.0.1/myFirstRepo
mkdir myFirstRepo/trunk/mySecondProject
mkdir myFirstRepo/branches/mySecondProject
mkdir myFirstRepo/tags/branches/mySecondProject
svn ci myFirstRepo -m"Weiteres Projekt angelegt

Alles in allem gar nicht viel Arbeit, aber die Tatsache, dass es ziemlich unsicher ist, hinterlässt schon einen starken Nachgeschmack. Aber in meinem VPN laufen noch ganz andere, extrem unsichere Dienste, so dass das hier den Kohl auch nicht fett macht.

DVD-RW dagegen bestehen aus anorganischem Material, ebenso wie DVD-RAMs. Bei letzteren hörte ich nur Gutes von der Haltbarkeit, musste aber feststellen, dass das ein absolut unbrauchbares Format ist. Kein mir bekanntes DVD-Laufwerk unterstützt die Dinger und zum Kauf hab ich auch noch keine gesehen. DVD-RWs dagegen sind zwar etwas teurer als DVD-ROMs, aber mit ca. 1 € pro Rohling könnte ich gut leben, wenn es denn hält.

Ein weiterer Punkt für die Anfälligkeit aller DVD-Arten der öfter genannt wurde ist, mit Ausnahme bei der DVD-RAM, die offenbar schlecht umgesetzte “Fehlerkorrektur”. Es werden bai allen dieser Datenträger redundante Daten “intelligent” auf der Oberfläche verteilt und zwar so, dass übliche Fehler wie Kratzer, ausgeglichen werden können. Es gibt aber bei der DVD das Problem, dass die inneren und die äußeren Bereiche damit nicht ordentlich abgedeckt werden und somit besonders gefährdet sind. Beim Innenbereich ist das besonders kritisch, denn wenn der unlesbar ist, erkennt das Laufwerk den Datenträger nicht mehr als solchen und man kann gar nichts mehr machen. Für diesen Fall gibt es zwar auch Programme im Netz, aber die haben bei mir keinen Erfolg gebracht.

Der Kratztest

Alleine die Aussagen der Händler oder die Infos im Netz helfen mir wenig. Praxiserfahrung musste her. Also ging ich im ersten Schritt daran, verschiedene Rohlinge voll zu schreiben und Kratzer in verschiedener Formen und an verschiedenen Stellen zu machen und die Auswirkungen zu untersuchen. Da das Programm dvddisaster auch eine Checksummendatei zur besseren Fehlerkorrektur anbietet und ich ja dann schon defekte Datenträger hatte, konnte ich das auch gleich mit testen.

Zur Vorbereitung hab ich eine DVD und eine CD voll beschrieben und das ISO-Image der beiden auf die Platte gesichert. Von diesen Images hab ich mit dvddisaster zwei Checksummendatei (ECC) mit den Standardvorgaben des Programmes erstellt. Eine “normal” mit 14,2% und eine “hoch” mit 33,5% Redundanz. Nebenbei: selbst wenn diese Dateien gut sind, haben sie doch das Problem, dass man auch sie irgendwo sichern muss. Sinniger weise nicht auf der gleichen und eigentlich auch auf keiner anderen DVD, aber wo dann?

Nachdem ich auf die Art vom gleichen Image einige DVDs und CDs gebrannt hatte, fing ich an, mit einer Schere Kratzer auf die Unterseite zu machen. Die extreme dabei hab ich mal notiert

Fehlerverhalten bei Kratzern auf DVDs

Alle Typen verhalen sich gleich: +RW, -RW, +R, -R

4 Kratzer von der Mitte bis zum Außenrand

Kein Schaden. Das kann die Fehlerkorrektur gut ab, scheinbar ist sie genau dafür da.

Ein 2cm Kratzer, fast mit der Spur

4500 x 5 Sektoren kaputt. Das sind bei 2KB Sektorgröße 45MB, aber im Zweifel schon ein riesen Problem. Mit der normalen Checksummendatei ist es komplett restaurierbar. Anmerkung: auf dem Bild ist noch ein Kratzer zu sehen, den hatte ich später drau gemacht und weiter getestet. Der hatte keine weitere Auswirkung mehr.

6 Kratzer, davon 4 mit der Spur

Die hälfte der Daten ist Defekt. Die hohe Checksummendatei hilft genauso wenig weiter wie die normale. Damit lassen sich noch ein paar Prozent retten, mehr aber nicht.

3 mal 1cm Kratzer innen fast am Loch und fast mit der Spur

Die DVD lässt sich nicht mehr lesen, d.h. das Laufwerk will sie nicht mehr haben. Dementsprechend ein Totalverlust. Mit ein bisschen Rumprobieren hab ich es auch mit einem einzigen, 1cm langen Kratzer hinbekommen. Die Archillesferse der DVD. Da darf nix schief gehen.

Ich hab einige Rohlinge zerlegt und konnte immer nur wenige Kratzer hinterlassen, bevor nicht über 50% der Daten drauf gingen. Gab es einen kratzer in der mitte wurde die DVD oft nicht mehr als solche erkannt. Die Checksummendateien von DVDdisaster helfen bei kleinen Fehlern, aber ansonsten sind sie eher was zum Gewissen beruhigen als eine echte Hilfestellung.

Fehlerverhalten bei Kratzern auf CDs

Hier war ich ziemlich erstaunt. Ich fing vorsichtig an und mit jedem Kratzer gab es Fehler. Egal ob mit oder quer zur Spur. Die Fehler ließen sich mit den Checksummendateien nur ganz am Anfang nurtzbringend verwenden. Ab 4 Kratzern war es dann egal und es gab Datenverluste. Interessant fand ich nur, dass ich den Datenträger nicht zerstören konnte. Ich hinterließ 38 tiefe Kratzer mit bis 5cm länge, mit und quer zur Spur . Auch so verteilt, dass sowohl ganz innen und ganz außen mit der Spur einiges zerkratzt war. Danach hatte ich weder Lust noch Kraft und außerdem irgendwie keinen Platz mehr auf der Oberfläche um noch was beschädigen zu können. Die CD war zu 95% nicht mehr lesbar, wurde aber noch korrekt als CD erkannt.

Fazit aus dem Kratzertest

DVDs sind gerade ganz innen tatsächlich extrem empfindlich. Fehler von innen nach außen sind gut abgefangen aber solche mit der Spur sind ein riesen Problem. Bei CDs sind Fehler immer ein Problem, aber es gibt keine besonders empfindlichen Stellen. Diese Info nützt, ganz allein für sich, gar überhaupt nichts. Im Zusammenhang ist es aber entscheidend. Dazu mehr im dritten Teil.

Und noch Abschließend, obwohl ich es oben schon erwähnt hatte: die ECC-Checksummendateien von dvddisaster sind wenig hilfreich. Eine sinnvolle Speicherlösung bringt da mehr.

Demnächst dann Teil 3 mit dem Langzeittest der Alterung von DVD- und CD-Rohlingen und dem abschließenden Fazit.

Das Problem

Insgesamt hatte ich über 2 1/2 Jahre hinweg, meine Backups sporadisch auf DVD’s verteilt, wie es halt gerade passte. Insgesamt haben sich 15 DVDs auf die Art angesammelt, die ich vor einiger Zeit dann mal sortieren und sauber archivieren wollte. Allesamt, ok bis auf eine, in der Hülle im Schrank aufbewahrt und ohne Kratzer, Staub oder sonstige Gebrauchsspuren. Beim Auslesen erhielt ich folgendes, niederschmetterndes Ergebnis:

2 DVDs komplett unbrauchbar

Eine lag für ca. eine Woche auf meinem Schreibtisch (Nordseite des Hauses) und war komplett ausgeblichen, da kann ich den Schaden ggf. noch verstehen, wenn auch nicht wirklich. Die andere war von einfach so kaputt, ohne verkratzt oder ausgeblichen zu sein. Kein Laufwerk konnte sie noch als DVD erkennen. Ein Totalverlust.

4 DVDs schwer beschädigt

Nicht verblichen und keine Kratzer zu sehen. Die äußeren Sektoren waren komplett im Eimer und auch in der Mitte gabs gute Fehlerstellen (woher ich die Fehlerstellen so genau weiß gibts weiter unten). Insgesamt waren ein paar 100MB weg.

6 DVDs leicht beschädigt.

Wieder trotz einwandfreihem Zustand. Hier gabs nur vereinzelte Feher, meißt am Außenrand

2 DVDs minimal beschädigt

Wieder ein super Zustand. Wenn ich sie nur “normal” ausgelesen hätte z.B. über die Dateiverwaltung, währen auch hier Fehler wie bei den 6 leicht beschädigten aufgetreten. Aber mit meinem Lebensretter-Tool konnte ich wenigsten die Daten komplett retten

Damit bleibt, nach Adam Riese, genau EINE komplett unbeschädigte DVD übrig. Da ich das Datum des Brennvorganges auf die DVD gekritzelt hatte, kann ich sagen, es hat sehr viel, wenn nicht alles, mit dem Alter der DVDs zu tun. Der Rohling-Typ war uninteressant, denn Vertreten sind die Marken Fujifilm, Tevion, Intenso und Octron und keiner der Rohlingtypen wurde von Fehlern verschont.

Die (teilweise) Rettung

Geholfen hat mir in erster Linie die Tatsache, dass meine Backups so verteilt und völlig unorganisiert waren. Dadurch waren viele Daten redundant und ich konnte so ca. 90% retten. Aber 10% Verlust, gerade bei z.B. alten Fotos, sind zu hart. Für weitere ca. 9% half mir das Linux-Tool dvddisaster. Die Idee dahinter ist so einfach wie genial. Man kann eine DVD einlesen und jeder einzelne, korrekt gelesene Sektor wird einem ISO-image auf der Platte hinzugefügt. Man kann dann das Image auf einen anderen Rechner legen und mit dessen Laufwerk das ganze nochmal versuchen. Sind dort Sektoren lesbar, die bisher noch fehlten, wird das ISO-Image aufgefüllt. Auf die Art kommt man schon recht weit.

Außerdem kann man das Laufwerk noch so ansteuern, dass die eingebaute Fehlerkorrektur umgangen und diese Arbeit vom Programm übernommen wird. Auch das hilft enorm. Auf diese Art konnte ich die 2 minimal beschädigten DVDs komplett und fehlerfrei auslesen. Mit den Einstellungen, jeden Sektor 10 mal zu lesen und die Fehlerkorrektur auf jede erdenkliche Art zu versuchen, kann man wirklich was erreichen. Das erkauft man sich aber durch sehr viel Zeit, denn meine schlimmste DVD brauchte ganze 1 1/2 Tage um ausgelesen zu werden. Leider nicht komplett fehlerfrei.

Besonders gut an dem Programm ist, dass man aus zwei oder mehr fehlerhaften DVDs eine ganze machen kann, vorausgesetzt man hat exakt gleiche Kopien einer DVD und die Fehler liegen nicht an den selben Stellen. Aber ich dachte ja, zumindest damals, dass Redundanz dieser Art nicht mehr nötig sei.

Der Verlust

Auf den 2 komplett unbrauchbaren DVDs war nur ein TV-Mitschnitt eines Konzertes und ein “bisschen” Musik. Beides ist nicht toll, aber verschmerzbar. Es hätte mich schlimmer erwischen können. Ansonsten fehlt mir nur ein 20KB großes Stück eines tgz-Archives, was gesamt 150MB groß ist. Das sind alle Bilder von vor 2002 die ich besitze. Man könnte denken, dann ist halt nur ein, maximal noch ein Zweites Bild im Archiv kaputt. Aber auch da war mir das Glück nicht hold.

Probleme mit Archiven

TGZ Archive sind scheinbar extrem FehlerINtolerant, denn ich kann die 500kb VOR der fehlerhaften Stelle entpacken, alles dahinter liegende nicht. Ich habe noch keine Möglichkeit gefunden, das zu Umgehen, hoffe aber noch auf eine Rettunng. Auf der Suche nach brauchbaren Alternativen bin nur über Gerüchte gestolpert, das RAR da besser sei. Das werd ich aber auch noch mal genauer testen.

Weiteres Vorgehen

Den Grund für die Ausfälle wollte ja schon herausfinden, also musste Ursachenforschung betrieben werden. Außerdem eine neue Lösung für Backups.

Da das Tool einem auch anzeigt, wo genau die fehlerhaften Sektoren auf der Oberfläche zu finden sind, zumindest kann man sehen, ob es eher im Innenbereich oder eben weiter außen Fehler gab, erhält man einen guten Überblick über den Zustand der DVD. Durch die Anzeige, wie schnell welcher Teil ausgelesen werden konnte, sieht man auch bei komplett fehlerfreihen DVDs und CDs, wie es um den Datenträger steht, da das Laufwerk langsamer wird, je problematischer der Lesevorgang war. Das war eine gute Grundlage, mal ein paar Tests mit den löchrigen Scheiben zu machen.

Folgende Dinge habe ich bereits durchgeführt und werde die Tage ausführlicher darüber berichten:

• Ursachenforschung, warum DVDs so Probleme machen und ob und wie man die umgehen kann
• Test der Fehlerkorrektur bei DVD und CD bei Kratzern.
• Qualität der Checksummen-Dateien zur Fehlerkorrektur mit dvddisaster
• Langzeittest der Alterungserscheinungen von DVD-ROM, DVD-RW und CD

Fazit

Backups IMMER redundant anlegen und DVD-ROM keinesfalls vertrauen. Da kann man auch gleich seine Daten in /dev/null schieben. Auch Archive oder Verschlüsselung bei Backups nicht verwenden, da die das Problem nur vergrößern. Lieber mehr Datenträger benutzen und die dann wegschließen. Und Teil 2 lesen