Admin bloggt

Wenn man den neuen BackupPC Pool verschieben möchte, weil man z.B. größere Platten einsetzen möchte, steht man vor dem Problem, dass Backup sehr viele Hardlinks verwendet. Wenn man nun einfach alles kopiert werden die Hardlinks verworfen und der benötigte Plattenplatz steigt gewaltig an. Aber BackupPC bietet seit der Version 3 eine kleines Script welches extra für diesen Zweck gedacht ist:

Ich gehe in dem Beispiel davon aus, dass das alte Verzeichnis /opt/backuppc ist und das neue /var/lib/backuppc

1. BackupPC stoppen (/etc/init.d/backuppc stop)
2. Die Verzeichnisse conf, pool und log in das neue Verzeichnis verschieben (z.B. /var/lib/backuppc)
3. Das Verzeichnis pc wird nun mittels BackupPC_tarPCCopy kopiert:
   su – backuppc
   cd /var/lib/backuppc
   mkdir pc
   /usr/share/backuppc/bin/BackupPC_tarPCCopy /opt/backuppc/pc | tar xvPf -

Wenn beim letzten Schritt die Meldung “Argument /opt/backuppc/pc must be an absolute path starting with /var/lib/backuppc” erhält, muss in die Konfigurationsdatei /etc/backuppc/config.pl gehen und dort den Wert $Conf{TopDir} ändern auf /opt/backuppc.

Wie es genau dazu gekommen ist weiß ich leider immernoch nicht. Ich habe einige Einstellungen an einem Hardware-Raid-Controller geändert um eine bessere Performance zu erreichen und irgendwann waren beim Booten meine Partionen weg (schön, dass die Root-Partition nicht im LVM lag).

Ein pvscan brachte mein Herz erstmal zum stottern:

# pvscan
Couldn’t find device with uuid ‘Tn9B92-M94z-i9Yl-9gjp-poi2-eFl9-lg1dSN’.

Wahhh!! Keine Panik. Man bekommt alles wieder sauber hin
Wie gut, dass es den Ordner /etc/lvm/backup gibt.

Ein einfach vgcfgrestore funktioniert leider nicht:

# vgcfgrestore vg1
Couldn’t find device with uuid ‘Tn9B92-M94z-i9Yl-9gjp-poi2-eFl9-lg1dSN’.
Couldn’t find all physical volumes for volume group vg1.
Restore failed.

Erstellen wir also erstmal das pv wieder mit der selben uuid:

# pvcreate –uuid Tn9B92-M94z-i9Yl-9gjp-poi2-eFl9-lg1dSN /dev/sda1
Physical volume “/dev/sda1″ successfully created

Und nun siehts auch schon besser aus:

# vgcfgrestore vg1
Restored volume group vg1

# vgscan
Reading all physical volumes. This may take a while…
Found volume group “vg1″ using metadata type lvm2

# vgchange -ay vg1
1 logical volume(s) in volume group “vg1″ now active

Jetzt zur Sicherheit noch das Dateisystem überprüfen:

# e2fsck /dev/vg1/home

Wenn man übrigens mehrere physical volumes hat, dann hilft ein Blick in die Dateien unter /etc/lvm/backup – dort sind auch die uuids immer angegeben. So kann man die richtige uuid dann kopieren.

Tagesaktuell müssen sie ja eigentlich nicht unbedingt sein, aber PassMark stellt unter http://www.cpubenchmark.net entsprechende Charts zur Verfügung. Wenn man vor der Entscheidung für einen neuen Prozessor steht, kann diese Seite sicherlich eine Hilfe darstellen. Schön ist vorallem, dass nicht nur Desktop-CPUs sondern auch Server-CPUs in den Charts auftauchen.

Das kostenlose OpenSource-Tool TestDisk kann einem wirklich den Arsc* retten. Eine tolle Funktion ist unter anderem Partitionstabellen wiederherzustellen. TestDisk gibt es für Windows, Linux, OS X, DOS, … – daher sollte man sich das Tool unbedingt merken.

Wenn sich eine virtuelle Maschine im Virtual Center Client (vSphere Client) mal aufhängt und man sie auch nicht mehr stoppen kann, weil die Meldung “another task is already in progress” kommt, hat man erstmal schlechte Karten. Auch über die Konsole kommt man z.B. mit dem Kommando vmware-cmd nicht weiter.

Abhilfe schafft der Neustart eines Dienstes:

# service mgmt-vmware stop

Dann auf jedenfall ca. 30 Sekunden warten und den Dienst neu starten:

# service mgmt-vmware start

Ein direkter Neustart des Dienstes mit dem Kommando “restart” funktioniert scheinbar nicht. Nach dem Start kann man auch die VM wieder hart stoppen.