Azure-Backup, Teil 2

Dieser Artikel erschien zuerst auf Ralfs Blog.

Ich hoffe, mein letzter Artikel zum Thema Azure Backup hat zum Nachahmen animiert und alle sichern jetzt schon nach Azure. Dann hier noch ein paar Details, die im letzten Artikel etwas zu kurz gekommen sind.

Wie mach ich ein Restore?

Der Azure Backup Agent, der beim Einrichten des Backups installiert wurde, ist auch für das Restore zuständig. Aktion „Daten wiederherstellen“ logischerweise.

Da kommt nach dem Draufklicken zuerst die Frage, ob Daten aus der Sicherung des aktuellen Servers oder eines anderen Servers wieder hergestellt werden sollen. Wir werden uns beides anschauen, zuerst das Restore auf dem selben Computer, das ist einfacher.

Restore auf gleichem Computer

Wir wählen also den eigenen Server.

• Wie bestimmen wir die wiederherzustellenden Dateien? Wir können entweder danach suchen, oder direkt navigieren.
• Das entsprechende Volume auswählen (also C: zum Beispiel)
• Den Zeitpunkt auswählen. Es erscheint ein Kalender mit fettgedruckten Tagen, an denen eine Sicherung erstellt wurde, und ein Dropdown-Feld für den gewünschten Zeitpunkt.
• Wenn wir navigieren ausgewählt haben, dann erscheint eine Explorer-Ansicht, aus der wir die Dateien oder Ordner auswählen. Bei der Suche kann mithilfe von Wildcards im ausgewählten Volume gesucht werden.
• Dann die Wahl, ob am ursprünglichen Ort oder einem anderen, Kopie erstellen, überschreiben oder nichts tun, und ob die ACL wieder hergestellt werden soll (siehe auch Screenshot weiter unten…)
• Kurz die Zusammenfassung lesen (macht ja sowieso keiner :-))
• und schon wird die Datei wie gewünscht wieder hergestellt.

Nach kurzer Zeit (well, it depends…) findet man dann zum Beispiel eine Datei mit dem Präfix „YYYY-MM-DD HH-MM Kopie von sehrwichtig.txt“ direkt neben der ursprünglichen Datei (natürlich abhängig von den gewählten Optionen).

Restore auf einen anderen Computer

Will man Daten von einem anderen Server wiederherstellen, dann gelten ein paar Einschränkungen:

• Das Betriebssystem des Zielcomputers darf nicht älter sein als das Betriebssystems des Quellcomputers (wurden also die Sicherungen von einem Win8-Client gemacht, dann lassen sich diese Dateien nicht auf einem Win7-Client wieder herstellen). Interessanterweise hab ich aber schon Dateien, die aus dem Backup meines Win8-Laptops stammen (ja, ist noch kein Win10, ich geb’s ja zu…), per Restore auf einem Windows Server 2012 R2 wieder herstellen können.
• Quellcomputer und Zielcomputer müssen im gleichen Sicherungstresor registriert sein
• Man benötigt eine aktuelle Datei mit den Tresoranmeldedaten. Die Datei, die man da runterlädt, ist ja immer nur 2 Tage gültig, daher kann die alte – bei der Installation des Backup Agent verwendete – Datei meist nicht mehr verwendet werden. Aber das ist ja kein Problem, einfach im Backup-Portal (wie im letzten Artikel beschrieben) runterladen.

Also dann wählen wir im Backup Agent die Option „Daten wiederherstellen“

• und diesmal „anderer Server“. Und schon folgt die Abfrage nach den Tresoranmeldedaten. Die Abfrage kommt übrigens jedes Mal. Innerhalb von 2 Tagen kann man einfach die gleiche nehmen.
• Datei auswählen mit den Anmeldedaten. Wenn die korrekt waren, dann wird eine Liste aller gesicherten Server Computer angezeigt.
• Quellcomputer auswählen (als der Computer, auf dem die Sicherung gemacht wurde)
• Datei auswählen, die wiederhergestellt werden soll. Hier gibt es die gleichen Optionen wie oben schon beschrieben, also suchen oder navigieren.
• Wiederherstellungsort kann ja nur „Anderer Speicherort“ sein. Der Agent erzeugt unterhalb des hier ausgewählten Verzeichnisses die komplette Original-Filehierarchie mit einem Startordner zum Beispiel „C_vol“.
• und los geht die das Restore. Ah, nicht ganz, Am Ende kommt doch noch eine Abfrage – hätte mich auch gewundert, wenn nicht…
• Passphrase eingeben. So. Hier kommt’s dann. Der handliche und übersichtliche, mindestens 16stellige Passphrase, der auf dem Quellcomputer verwendet wurde, muss hier eingegeben werden… Wenn man den nicht mehr weiß, dass war’s das hier und jetzt. Nein, keine Chance beim Azure Support Team. Der einzige, der jetzt noch helfen könnte, ist der Wahrsager ihres Vertrauens 🙂
• Aber sie kennen den Passphrase ja sicher noch. Oder haben (wie empfohlen) ein externes Medium zur Speicherung verwendet. Also eingeben und weiter.
• Fertig. Wir haben gerade erfolgreich Dateien eines anderen Computers wieder hergestellt. Super, oder?

Was kann alles gesichert werden?

• Lokale NTFS-Filesysteme (keine Netzwerk-Shares)
• keine Read-Only Filesysteme
• wenn mit Bitlocker verschlüsselt, dann müssen sie entschlüsselt werden (das heißt nicht, dass Bitlocker entfernt werden muss. Die Daten müssen nur zugreifbar sein, zum Beispiel nach dem Login)
• maximal 850 GB mit einem einzelnen Backup (ich hab aber auch schon 1,7TB als Angabe gesehen…)
• Nur „Files&Folders“, also kein Systemstate oder BareMetal Recovery. Als Abhilfe kann man aber Windows Server Backup und/oder SCDPM einsetzen.
• Applikationen wie Active Directory, Exchange, SharePoint oder SQL Server werde nicht direkt unterstützt. Hier also entweder vorher anhalten, oder aus der Applikation heraus ein Filebackup erstellen auf die Partition und das dann sichern.

Was ist das mit Lokal redundant und Geo redundant?

Beim Anlegen eines Sicherungstresors (und nur dann!) kann man auswählen, wieviele Kopien der Backupdaten erstellt werden und wo diese liegen. Naja, zumindest indirekt kann man das. Bitte beachten: Die Auswahl erfolgt bim Anlegen des Tresors und kann nach der ersten Registrierung eines Servers nicht mehr geändert werden!

Lokal redundant (LRS)

Die Daten werden 3mal repliziert innerhalb eines Standortes. Dabei werden sie verteilt in verschiedenen FDs und UDs. Ah, das sollte ich vielleicht kurz erklären: FD steht für FaultDomain, kann man sich vorstellen als Verteilung auf verschiedene Racks, falls eines ausfällt. UD steht für UpdateDomain, das heißt grob gesagt, wenn Systemupdates an Azure  erforderlich sind, werden diese zuerst in der einen UD, dann in der anderen UD vorgenommen, womit stets mindestens eine Kopie  zur Verfügung steht.

Geo redundant (GRS)

Bei dem etwas teureren Geo redundanten Storage (GRS) werden die Daten zusätzlich zu den Mechanismen des LRS auch noch an einen sog. „sekundären Standort“ repliziert und dort ebenfalls nach LRS-Mechanismen repliziert. Insgesamt also 6 Kopien verteilt auf zwei Standorte. Für Europa heißt das: Wenn als primärer Standort Westeuropa ausgewählt wurde, dann werden die Daten hier nach Nordeuropa repliziert, und umgekehrt.

Was nehme ich also?

Wenn die Daten sowieso schon mal irgendwo gesichert werden und das Azure Backup nur als weitere Sicherheit dient, dann reicht sicher LRS, zumal das auch billiger ist. Wenn es Einschränkungen gibt, in welcher Region die Daten liegen dürfen, dann muss hier ggf. auch LRS gewählt werden.

Egal was man wählt, die Auswahl muss vor der ersten Registrierung eines Servers erfolgen und lässt sich hinterher nicht mehr ändern! Allerdings können ja mehrere Sicherungstresore mit verschiedenen Optionen verwendet werden.

Trennung von Sicherungen

Generell gilt: Ordner/Dateien aus Sicherungen können wiederhergestellt werden, wenn

• es sich um den gleichen Computer handelt und das Verschlüsselungskennwort bekannt ist
• es sich um einen anderen Computer handelt, dieser im gleichen Sicherungstresor ist und das Verschlüsselungspasswort (des anderen Computers) bekannt ist

Aus dem zweiten Punkt folgen also zwei Möglichkeiten, um Sicherungen voneinander zu trennen:

• verschiedene Sicherungstresore (zum Beispiel einen für HR, einen für IT…)
• verschiedene Verschlüsselungspasswörter im gleichen Sicherungstresor
• und natürlich die Kombination (trivial, weil meistens das Passwort für den anderen Tresor sowieso anders ist)