Von den insgesamt fünf für Fallout 3 verfügbaren AddOns ist vor allem Broken Steel herauszuheben, stellt dies im Gegensatz zu den anderen Addons (Operation: Anchorage, The Pitt, Point Lookout und Mothership Zeta) nicht nur ein zusätzliches Spielfeld mit eigener Storyline zur Verfügung sondern fügt auch mehrere Änderungen ins Hauptspiel ein.

Broken Steel erzählt die Geschichte nach dem Ende von Fallout 3 weiter und setzt nahtlos am Abspann des Hauptspiels an. Der Lone Wanderer kann nicht nur die Früchte seiner Arbeit aus früheren Tagen bewundern, sondern stellt auch ernüchtert fest, daß - kaum das nun Purified Water in ausreichender Menge verfügbar ist - auch gleich wieder die nächsten Probleme dadurch entstehen. Hauptsächlicher Dreh- und Angelpunkt der Geschichte ist aber die Fortsetzung des Kampfs gegen die Enclave, deren Truppen sich auf der Adams Air Force Base verschanzt haben.

Im Gegensatz zum festen Ende des Hauptspiels darf nach dem Ende der Broken Steel-Storyline weitergespielt werden und so können weitere, bisher ungelöste Quests in Angriff genommen und noch nicht besuchte Orte genauer unter die Lupe genommen werden.

Eine weitere segensreiche Erweiterung ist, daß das mit Level 20 viel zu niedrig angesetzte LevelCap mit der Installation von Broken Steel auf Level 30 erhöht wird und den bestehenden Perks noch einige weitere sinnvolle Auswahlmöglichkeiten hinzugefügt werden.

Der Installationszeitpunkt sollte allerdings clever gewählt werden: Neben den für den Spieler positiven Ergänzungen werden auch einige neue Gegnerarten hinzugefügt, von denen besonders die Albino Radscorpions und die Feral Ghoul Reaver einiges an Übung benötigen um ein unplanmäßiges Zusammetreffen halbwegs unbeschadet zu überstehen. Gleiches gilt auch für die Super Mutant Overlords, die - von Stärke und Design irgendwo zwischen Super Mutant Master und Super Mutant Behemoth angesiedelt - zwar schwere, aber glücklicherweise auch schwerfällige Brocken sind.

Während man bei alten Windows-Versionen noch zu Drittanbieter-Software wie Acronis TrueImage greifen oder selbst kreativ tätig werden musste, um Systembackups zu erstellen, ist bei Windows 7 die entsprechende Funtionalität bereits eingebaut.

Ein Backupvorgang kann jederzeit aus dem laufenden Betriebssystem heraus über das Windows-Startmenü mittels der Funktion “Sichern und Wiederherstellen” gestartet werden:

Dort ist lediglich der Menüpunkt “Systemabbild erstellen” zu wählen, dieser öffnet dann den zugehörigen Wizard, der Schritt für Schritt durch die hierfür notwendigen Angaben leitet. Alternativ kann mittels “Sicherung einrichten” auch eine regelmäßige Sicherung eingeplant werden.
Wer lieber die Kommandozeile verwendet, kann das Backup auch auf diesem Weg starten, hierfür ist der Befehl “wbadmin” zuständig.

Obige Befehlszeile startet eine Sicherung aller, für die Ausführung von Windows erforderlicher Laufwerke und legt diese auf dem Laufwerk ‘D:’ ab.

Sollte als Sicherungsziel der gleiche physikalische Datenträger gewählt werden, auf dem auch die Systemplatte liegt, so gibt wbadmin eine entsprechende Warnung aus. Diese kann allerdings ignoriert werden, falls die Sicherung z.B. zusätzlich auf eine externe Platte kopiert wird.

Auf dem Ziellaufwerk wird - falls noch nicht vorhanden - ein Ordner namens “WindowsImageBackup” angelegt, in diesem befindet sich ein Order mit dem Rechnernamen, welcher die eigentliche Sicherung enthält.

Während im professionellen Sektor RAID-Systeme zum Alltag gehören, finden diese sich auch immer mehr im Heimbereich wieder, meist basierend auf der falschen Annahme, daß ein RAID sicherer als kein RAID sei.

Dem ist aber nicht so: ein RAID erhöht lediglich die Verfügbarkeit der Daten, nicht aber deren Sicherheit.

Grundsätzliches

Das Problem an obiger Annahme ist, daß ein RAID nur gegen den Ausfall von Festplatten wappnet, nicht jedoch gegen Software- und Bedienfehler und darüber hinaus eine neue Gefahrenquelle hinzufügt: den Controller.

Letztendlich wird das RAID von genau diesem Controller erstellt und verwaltet, der in der Regel zu keinem anderen Controller außer absolut baugleichen (und dazu zählt auch die Firmware des Controllers) kompatibel ist.

Ausfall des Controllers

Solange der Controller einfach nur seine Funktion einstellt, reicht es, den defekten Controller durch einen eineiigen Zwilling zu ersetzen, um weiterhin auf die Daten zugreifen zu können. Ist ein solcher nicht mehr zu beschaffen (z.B. Gerät zu alt), kann auf die Daten nicht mehr zugegriffen werden.

Hat der Controller einen sonstigen Defekt, so kann es sein, daß durch diesen Defekt das RAID zerstört wird und es zum totalen Datenverlust kommt.

Ausfall einer Festplatte

• RAID 0: alle Daten auf allen Platten sind verloren

• RAID 1, 5: solange nur eine Platte ausfällt, läuft das Raid weiter und die Platte kann ersetzt werden. Allerdings müssen die fehlenden Daten für die ersetzte Platte aufbereitet werden, was verstärkte Last auf den restlichen Platten erzeugt und damit deren Ausfallwahrscheinlichkeit erhöht.

• Kein RAID: wenn eine Platte ausfällt, sind die Daten auf der ausgefallenen Platte verloren. Den Daten auf den anderen Platten passiert nichts, sie können jederzeit in ein x-beliebiges anderes Gerät eingebaut und von dort auf die Daten zugegriffen werden.

Ausfall mehrerer Festplatten

• RAID 0, 1, 5: alle Daten auf allen Platten sind verloren

• Kein RAID: s.o.

Fazit

Ein RAID ersetzt in keinem Fall eine Datensicherung auf einen physikalisch getrennten(!) Datenträger.

Da eine solche unabdingbar ist, ist es gerade im Small Office/Home-Office-Bereich fraglich, ob die Implementierung eines RAIDs sinnvoll ist. Einzige Ausnahme wäre ein Hochverfügbarkeitsszenario, das in diesem Bereich eher selten anzutreffen ist.

Bricht der Apache-Start mit einer Fehlermeldung ähnlich

[Thu Jan 13 12:11:57 2011] [error] (79)Value too large for defined data type:
could not open transfer log file <Pfad zu Apache>/logs/ssl_request_log.

ab, so lohnt ein Blick auf die Größe der angegebenen Datei - diese hat unter Umständen die 2GB-Grenze überschritten.

Nach Umbenennen oder Löschen der betroffenen Datei startet Apache dann wieder.

Nach einer Neuinstallation von Windows 7 war der Zugriff auf andere Server im Netz wieder wie vorher, lediglich Zugriffe auf einen auf dem lokalen Rechner betriebenen Webserver erfolgten nur mit einer mehrsekündigen Denkpause.

Da der Webserver mit Hife des Perl-Moduls HTTP::Server::Simple bereitgestellt wird und weder an der Perl-Version, noch den verwendeten Modulen oder dem eigentlichen Skript irgendwelche Änderungen vorgenommen wurden, schied der Server selbst als Ursache aus.

Auch die standardmäßige Windows-Firewall sowie die Antivirus-Lösung, die beide unter kurzzeitigen Verdacht gerieten, konnten sich mit Hilfe einer testweisen Deaktivierung vom Anfangsverdacht befreien.

Einen ersten Hinweis in die richtige Richtung lieferte der Artikel “Firefox ist langsam bei Aufruf einer Seite von localhost mit Visual Studio”, dessen Lösungsansatz den Firefox-Parameter “network.dns.disableIPv6” vom standardmäßigen “false” auf “true” abzuändern zwar eine Behebung der Symptome im Firefox brachte, aber nicht das Problem als solches behob.

Die Lösung findet sich letztendlich in der Windows-“hosts”-Datei unter “%windir%\system32\drivers\etc” liegt und die folgenden Hinweis enthält:

# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    ::1             localhost

Nach Entkommentieren des IPv4-Eintrags (und nur dieses!) funktioniert der Zugriff auf den localhost wieder verzögerungsfrei.