(SP1)-Installationsfehler: 0x800F0A13

Laut Microsoft Hilfe und Support kann der Fehler durch folgenden, vier Gründe verursacht werden, die bei mir aber nicht zutrafen:

1. Während des Setup wird die Systempartition nicht automatisch eingebunden bzw. für Windows zugänglich gemacht.
2. Die Festplatte, auf der sich die Systempartition befindet, wurde vor der Installation von SP1 entfernt.
3. Windows wird in einem Storage Area Network (SAN) ausgeführt, und der Zugriff auf die Systempartition wurde deaktiviert.
4. Ein Tool zur Datenträgerverwaltung eines anderen Softwarehersteller wurde zum Kopieren (oder Klonen) des Datenträgers oder der Partition verwendet, auf dem bzw. der SP1 installiert werden soll.

Nachdem ich Google befragt habe, bin ich aber auch auf einen Post im Technet-Blog von joscon gestoßen, der empfahl zuerst das Systemupdate-Vorbereitungstool auszuführen. Falls die Installation danach immer noch nicht funktioniert, gibt es dort auch noch einige andere Lösungsvorschläge. Jedoch keiner dieser Vorschläge hat geholfen.

Die Lösung brachte letztendlich ein Heise Artikel. Nachdem ich wie in den Artikel beschrieben die aktive Partition gesetzt hatte und den Server neu gebootet hatte, funktionierte die Installation des ServicePacks.

Update:
Bei einem anderen Windows 2008R2 Server lief die Installation erst, nachdem ich der vom System reservierten 100 MB Partition einen Laufwerksbuchstaben gegeben hatte. Dazu wurde im Technet Forum geraten.

Nachdem man die Live-CD gebootet hat kann man sich mit dem folgenden Befehlt eine Liste der Festplatten anzeigen lassen.

fdisk -l

Dabei bezeichnet /dev/hda die erste IDE-Platte und /dev/hdb bezeichnet die zweite IDE-Platte. Bei SCSI-Platten bezeichnet analog dazu /dev/sda die erste Platte und /dev/sdb die zweite. Befindet sich beispielsweise auf der Festplatte /dev/hda das System, kann man davon mit dem Programm dd ein Image erzeugen. Am besten leitet das Image gleich mit netcat auf einen anderen PC. Die genaue Anweisung dazu lautet dann wie folgt:

Empfänger:

netcat -w 30 -vvnl 3333 | gzip -dc > hda.raw

Sender:

dd if=/dev/sda | gzip -c | netcat -w 30 -vvn 192.168.1.1

In dem Beispiel liest dd die Festplatte /dev/hda und schickt die Standardausgabe durch gzip zum Komprimieren. Der komprimierte Datenstrom wird von netcat an die IP-Adresse 192.168.1.1 zu dem Port 3333 gesendet. Auf dem Empfangsrechner nimmt netcat den Datenstrom auf dem Port 3333 entgegen. gzip dekomprimiert diesen Datenstrom. Die Ausgabe wird in die Datei hda.raw umgeleitet. Ist die Übertragung zu Ende, kann dieses Image direkt in QEMU oder KVM als virtuelle Maschine getestet werden.

kvm -hda /mnt/berlindc_backup/sda.raw -m 1024 -net nic,model=virtio -vnc :1
192.168.30.2:1

1. Die Paketliste des alten Computer in eine Datei sichern

   dpkg --get-selections "*" > paketliste.txt

2. Die Pake aus der Datei bei dem neuen Computer auswählen

   dpkg --set-selections < paketliste.txt

3. Die Pakete auf dem neuen Computer installieren

   apt-get dselect-upgrade

Dabei ist zu beachten, dass das ganze natürlich nur mit Root-Rechten funktioniert!

Wenn man jedoch viele Linux-Server betreibt benötigt man eine Backup-Lösung, die mehrere Server sichert und eine leistungsfähige Volume-Verwaltung mitbringt. Für solche Anforderungen eignen sich die beiden Programme amanda (Advanced Maryland Automatic Network Disk Archiver) und bacula (Wortspiel aus Backup und Dracula / Der Slogan des Programms lautet deshalb auch: “It comes by night and sucks the vital essence from your computers”).

Amanda
Amanda wurde ursprünglich von James da Silva an der University of Maryland’s entwickelt und wird inzwischen von einem ganzen Team weiterentwickelt. Es ist inzwischen auch schon über 10 Jahre alt und sehr ausgereift. Deshalb ist es auch bei jeder Linux-Distribution und den meisten UNIX-Derivaten im Lieferumfang enthalten und kann relativ leicht über die Softwareverwaltung installiert werden. Allerdings ist es recht umfangreich und auf Anhieb nicht leicht zu durchschauen. Leider gibt es auch noch keine GUI. Alles muss per Kommandozeile oder Konfigurationsdatei eingestellt werden.

Bei Amanda gibt es einen Bandrechner, an dem sich das Laufwerk befindet, und auf dem der Server installiert wird, während die zu sichernden Rechnern mit dem Client auszustatten sind. Eine zentrale Konfiguration für den Server gibt vor, welche Dateien von welchen Rechnern und mit welcher Priorität zu sichern sind, wie viele Bänder insgesamt vorhanden und in einem Zyklus sind, usw. Während der Sicherung speichert Amanda alle Informationen zu den gesicherten Dateien in einer Datenbank. Amanda sagt einem also bei einer Rücksicherung welche Bänder einzulegen sind, wenn man angibt welche Dateien von welchem Datum man von welchem Rechner haben möchte.

Bacula
Bacula ist das umfangreichste, kostenlose Backup-Programm, dass es im Augenblick für Linux gibt. Es ist noch umfangreicher als Amanda jedoch in einigen Bereichen noch nicht so ausgereift. Die Entwicklung wurde im Jahr 2000 begonnen und die erste stabile Version wurde erst im Jahr 2006 fertig gestellt. Die zweite stabile Version wurde 2007 fertig gestellt und lässt kaum noch Wünsche offen. Das Programm ist aber leider noch nicht bei allen Linux-Distributionen im Lieferumfang enthalten, da es noch so neu ist. Man kann auf der Webseite der Entwickler neben den Sourcen aber auch viele fertige Pakete für verschiedene Linux-Distributionen finden.

Die Bacula-Software besteht aus drei Programmen, die auch für Windows verfügbar sind: einem Client / File Daemon (dem Computer mit den Dateien, die gesichert werden sollen), einem Storage Daemon (dem Computer mit den Medien, auf die gesichert werden soll) und dem Backup-Servers / Director (dem Computer, der den Backup-Vorgang steuert). Die Konfiguration dieser drei Programme erfolgt jeweils in einer Konfigurationsdatei. Der Backup-Server kann danach über ein CLI (Command Line Interface) gesteuert werden. Es gibt aber inzwischen auch GUI-Software, welche die Bedienung der CLI erleichtert. Unter Linux kann man mithilfe des Programms bat (Bacula Admin Tool) die gebräuchlichsten Verwaltungsaufgaben per GUI erledigen.

Für Windows gibt es die bwx-console, die zumindest eine Rücksicherung per GUI ermöglicht. Darüber hinaus kann Bacula mit SQlite-, MySQL- oder PostgreSQL-Datenbanken umgehen, alle Komponenten kommunizieren über TSL-verschlüsselte Verbindungen und sogar die gesicherten Daten lassen sich durch Verschlüsselung vor neugierigen Blicken verbergen.

Fazit
Sobald man viele Linux-Server sichert sollte man sich Bacula und Amanda näher anschauen. Beide lassen sich in größeren Umgebungen sehr gut einsetzten. Amanda besticht durch seine Stabilität und große Verbreitung. Insbesondere die fehlende GUI erschwert aber den Zugang für unerfahrene Admins. Bacula ist umfangreicher und flexibler als Amanda. Insbesondere der große Funktionsumfang und die GUI werden dafür sorgen, dass Bacula zukünftig öfter eingesetzt wird. Es wird sicherlich bald in allen Linux-Distributionen zu finden sein.