News
Insights

Insight

File Level Restore auf Linux VPS
Die hochverfügbaren Schweizer Cloud Server von Hostfactory verfügen über ein umfangreiches Backup-/Restore-Konzept als "Self-Service". Nebst der Option "Always-On VPS Instant Disaster Recovery", welche einen vollständig unbrauchbaren Server innert weniger Augenblicke aus dem zuvor erstellten Backup online wieder zur Verfügung stellt, steht für eine individuelle Datenwiederherstellung die Möglichkeit "Cloud Server File Level Recovery (FLR)" zur Verfügung - Hier wird erklärt, wie Daten auf einem Linux VPS per FLR individuell wiederhergestellt werden können.

Ein Umfangreiches VPS Backup-/Restore-Konzept

Die High Availability Swiss Cloud Server und der hochverfügbare VPS WebEdition von Hostfactory verfügen nebst einer redundanten Infrastruktur über ein umfangreiches Backup-/Restore Konzept, welches als "Self-Service" bedient werden kann. So steht dem VPS-Administrator via sein Kundencenter "my.hostfactory" mitunter die Option "Backup erstellen" zur Verfügung. Hierbei wird eine vollständige Systemsicherung des jeweiligen Servers erstellt und komplett auf einen entfernten Storage kopiert.

Image: linux-vps-flr.jpg

Always-On VPS Disaster Recovery

Ist dieses Backup des virtuellen Servers erst einmal erstellt, eröffnen sich bei Bedarf dem Systemadministrator folgende zwei Möglichkeiten für die Wiederherstellung von Daten:

  • Always-On VPS Instant Disaster Recovery
  • Cloud Server File Level Recovery (FLR)

Im ersten Fall, also bei einem Instant VPS Disaster Recovery, wird der aktuelle Server gestoppt und das zuvor gesicherte System aus dem Backup, welches zum aktuellen Zeitpunkt noch auf dem entfernten Storage liegt, gestartet. Hierbei wird also Ihr System vollständig durch das früher gesicherte System ersetzt. Der grosse Vorteil an dieser "Always-On VPS Instant Disaster Recovery" Lösung besteht darin, dass Ihr System innert kürzester Zeit wieder online zur Verfügung steht. Erst anschliessend, nachdem Ihr Server längst wieder zur Verfügung steht, wird das Backup aus dem entfernten Storage Repository in den produktiven Storage Cluster am eigentlichen Standort kopiert. Restore auf Level Enterprise, möchte man sagen! Oder eben: Always-On VPS!

File Level Restore - Individuelle Wiederherstellung als "Self-Service"

Ich möchte aber an dieser Stelle viel mehr auf die zweite Lösung, das "Cloud Server File Level Recovery (FLR)" Konzept von Hostfactory eingehen. Hierbei wird die Möglichkeit angeboten einzelne Verzeichnisse und Dateien aus dem zuvor angefertigten Backup wiederherzustellen, indem die früher gesicherte Disk im derzeit produktiven Serversystem zur Verfügung gestellt wird.

FLR starten und zweite Disk auf Server anzeigen lassen

Der oben beschriebene VPS File Level Restore wird ebenfalls als "Self-Service" - und somit zu jedem beliebigen Zeitpunkt und unmittelbar - via Kundencenter "my.hostfactory" lanciert. Anschliessend zeigt sich dem Systemadministrator auf seinem Virtual Private Server unter Linux folgendes Bild:

  1. # fdisk -l

Image: zweite-disk-auf-server-anzeigen-lassen.png

Identische UUID: Cannot mount "xvdb2"

Zumal es sich bei "/dev/xvdb2" um ein exaktes, früheres Abbild von "/dev/xvda1" handelt, besitzen beide Volumen die gleiche UUID:

  1. # blkid | grep 2
  2. /dev/xvdb2: UUID="73b7999e-79bb-4bc1-acf3-ee7b9f89709d" TYPE="xfs" PARTUUID="19ab9fb3-02"
  3. /dev/xvda2: UUID="73b7999e-79bb-4bc1-acf3-ee7b9f89709d" TYPE="xfs" PARTUUID="19ab9fb3-02"

Diese Tatsache führt dazu, dass "xvdb2" nicht gemountet werden kann:

  1. # mkdir /mnt/xvdb2
  2. # mount -t xfs /dev/xvdb2 /mnt/xvdb2

Image: filesystem-has-duplicate-uuid.png

UUID von "xvdb2" ändern

Entsprechend sollte die UUID von "/dev/xvdb2" wie folgt geändert werden:

  1. # mkdir /mnt/xvdb2
  2. # mount -o nouuid /dev/xvdb2 /mnt/xvdb2
  3. # umount /dev/xvdb2
  4. # xfs_admin -U generate /dev/xvdb2
  5. Clearing log and setting UUID
  6. writing all SBs
  7. new UUID = fec8c7fc-fa41-4fd1-aeb3-2901de670c04
  8. # blkid | grep 2
  9. /dev/xvdb2: UUID="fec8c7fc-fa41-4fd1-aeb3-2901de670c04" TYPE="xfs" PARTUUID="19ab9fb3-02"
  10. /dev/xvda2: UUID="73b7999e-79bb-4bc1-acf3-ee7b9f89709d" TYPE="xfs" PARTUUID="19ab9fb3-02"

Device mounten

Wichtig: Wenn Sie ab hier einen Device ab der "xvdb"-Disk mounten, sollten Sie diesen unmittelbar nach dessen Verwendung unbedingt wieder aushängen! Sofern Sie den FLR nämlich nicht manuell rechtzeitig beenden, wird das Backupsystem die zweite Disk nach zwei Stunden automatisch entfernen. Ist zu diesem Zeitpunkt ein Volumen ab dieser Platte noch eingehängt, wird dies Ihr System anhalten und nach einem Hard-Reset verlangen!

Wie wir weiter oben per "# fdisk -l" gesehen haben, befinden sich die aktiven und produktiven Daten des laufenden Systems auf der ersten Disk "xvda", während nun auf der zweiten Disk "xvdb" im Device "/dev/xvdb2" das früher von "/dev/xvda2" erstellte Backup befindet. Dieses Volumen wird nun, nachdem die UUID von "xvdb2" geändert wurde, wie folgt auf dem System eingehängt (mount):

  1. # mkdir /mnt/xvdb2
  2. # mount -t xfs /dev/xvdb2 /mnt/xvdb2
  3. # ls -la /mnt/xvdb2/

MEMO: Vergessen Sie nicht, die "xvdb2" auszuhängen (# umount /dev/xvdb2), sobald sie diesen Mountpunkt nicht mehr benötigen (siehe oben).

Individuelle Verzeichnisse oder Dateien aus dem Backup kopieren

Ab jetzt können die aus dem Backup benötigten Daten und Verzeichnisse entsprechend kopiert werden. Hierfür bieten sich entweder die Linux Commands "# cp" und "# mv" an oder aber es wird beispielsweise "# rsync" verwendet:

  1. # apt-get install rsync

Im folgenden kopieren wir das Verzeichnis '/mnt/xvdb2/home/a/b/c' aus dem Backup nach '/home/a/b'; bereits gleichnamig vorhandene Files werden überschrieben:

  1. # rsync -avz /mnt/xvdb2/home/a/b/c /home/a/b

Falls Files, welche seit Erstellung des Backups verändert wurden, nicht überschrieben werden sollen, ergänzen wir die Option "u":

  1. # rsync -azvu /mnt/xvdb2/home/a/b/c /home/a/b

Sofern Sie Daten, welche im aktiven Verzeichnis "/home/a/b" vorhanden, im Backup jedoch nicht existieren, löschen wollen, ergänzen sie die obigen Commands mit der "--delete"-Option:

  1. # rsync -azvu --delete /mnt/xvdb2/home/a/b/c /home/a/b

"rsync" bietet eine Vielzahl weiterer Optionen, welche für das individuell Wiederherstellen von Daten nützlich sein können. Alle Möglichkeiten erhalten Sie per "# rsync -h" angezeigt, die vollständige Anleitung per "# man rsync".

Zweite Disk abschliessend aushängen (umount)!

Wie bereits oben darauf hingewiesen, sollte der Mount der "xvdb2" nach Abschluss der Datenwiederherstellung unbedingt beendet werden. Der Device kann hierbei wie folgt beendet werden:

  1. # umount /dev/xvdb2

Der FLR wird abschliessend via Kundencenter "my.hostfactory" beendet.

FLR auf einem Windows VPS

Die gleichen Optionen zur Wiederherstellung von Daten stehen selbstverständlich auch auf einem Windows Cloud Server zur Verfügung. Das "Mounten" wird jedoch unter Windows via "Computerverwaltung" > "Datenträgerverwaltung" erledigt (Laufwerkbuchstaben zuweisen). Anschliessend erfolgt das Kopieren der individuell benötigten Daten beispielsweise per Drag&Drop im Windows Explorer.

Hostfactory VPS-Support hilft, wenn nötig

Selbstverständlich steht bei Bedarf der VPS-Support von Hostfactory an 365 Tagen pro Jahr mit Rat und Tat zur Verfügung.

Self-Service Data Restore auch für Virtual Shared Webhosting

Übrigens: Auch mit einem Schweizer Webhosting ist das Wiederherstellen von Webfiles, E-Mails und Datenbanken bis zu 30 Tage zurück und ebenfalls als "Self-Service via Kundencenter möglich.

Mit Begeisterung!
Andi Herzig

hostfactory.ch
Anleitung