Achtung bei EBS-Snapshots vom Windows Root-Volume

Am vergangenen Freitag haben wir einen Disaster-Recovery-Test bei einem unserer Kunden durchgeführt und haben in diesem Zuge einen schwerwiegenden Fehler im Zusammenhang mit EBS-Snapshots festgestellt.

Im Rahmen des Backup-Plans des Kunden werden nachts automatisiert EBS-Snapshots von allen EBS-Root-Volumes der Windows-Instanzen erstellt, die Instanzen sind währenddessen weiterhin im Betrieb.

Während des Recovery-Tests wollten wir nun mit Hilfe eines EBS-Snapshots das Windows Root-Volume wiederherstellen und mussten feststellen, dass dieser und alle anderen erstellten EBS-Snapshots inkonsistent und unbrauchbar waren.

Nachdem wir Kontakt mit dem AWS Support hatten und einige weitere Tests mit EBS-Snapshots und Windows-/Linux-Instanzen durchgeführt hatten konnten wir folgende Punkte festhalten:

  • Snapshots vom Root-Volume einer Windows-Instanz können aktuell nur im „stopped“-State erstellt werden.
  • Snapshots vom Root-Volume einer Windows-Instanz die im „running“-State erstellt werden, sind inkonsistent und unbrauchbar.
  • Snapshots von zusätzlichen Volumes einer Windows-Instanz sind von dem Problem generell nicht betroffen.
  • Snapshots vom Root-Volume und zusätzlichen Volumes einer Linux-Instanz sind generell auch nicht betroffen.

Eine Ursache für das Problem scheint laut AWS Support der Windows DMA IRQ Pool zu sein, in welchem das Root-Volume registriert und gelockt ist. Dieser Pool wird beim Herunterfahren der Instanz geleert.

Der AWS-Support bearbeitet dieses Problem momentan intern und informiert uns über Neuigkeiten zu diesem Thema.

Amazon Glacier: Archiv Speicher für einen Penny pro GB pro Monat

Mit einem kleinen Paukenschlag hat Amazon AWS einen komplett neuen Service bereitgestellt: Amazon Glacier ist ein sehr kostengünstiger Archiv-Speicher in der Cloud. Hier die zusammengefassten Leistungsmerkmale:

  • Pro Gigabyte gespeicherter Daten verlangt Amazon je nach AWS-Region zwischen 1 und 1,2 US-Cent im Monat
  • Die Daten werden wie bei S3 multiredundant gespeichert, Amazon spricht von einer Verfügbarkeit von 99.999999999%
  • Innerhalb von Glacier sind die Daten mit 256-AES verschlüsselt, wobei Amazon die Schlüssel selbst verwaltet
  • Der Upload von Daten erfolgt über ein eigenes API bzw. über Tools von Drittherstellen wie z.B. http://fastglacier.com/, wie bei Amazon AWS üblich, ist der Traffic für eingehende Daten kostenlos
  • Der Abruf der Daten ist allerdings nicht wie bei S3 sofort möglich, sondern es muss ein Request für den Download erfolgen, innerhalb von 3-4 Stunden wird dann ein Download-Link zu den Daten bereitgestellt. Der Download kostet, sofern er ein definiertes Limit überschreitet extra Geld. Somit reduziert sich das Einsatzszenario von Glacier auf Daten, die langfristig dauerhaft archiviert werden müssen und nur gelegentlich abgerufen werden müssen.

Es existieren bereits einige Tools, die wie hier aufgelistet haben:

S3 als Laufwerk für EC2-Windows oder Linux mappen

S3 ist der zentrale Speicherdienst von Amazon AWS. S3 hat für den Kunden eine unlimitierte Größe, verfügt über ein Rechtemanagement, kann Objekte versionieren bzw. mit Verfallsdaten versehen und ist über mehrere Availibility-Zonen verteilt, so dass die Daten sehr sicher gespeichert sind.

Über ein eigenes API kann man in S3 Daten speichern und entsprechend abrufen oder über HTTP wieder herunterladen …  manchmal aber braucht man für eine vielleicht existierende Software den Lese- und Schreibzugriff auf S3 über einen Laufwerkszugriff … gücklicherweise gibt es hier sowohl für Windows als auch für Linux entsprechende Software, die dann z.B. direkt auf einer entsprechenden EC2-Instanz installiert werden kann. Hier eine aktuelle Aufstellung:

EBS-Volumes mit einem Windows-Script als Snapshot sichern

Um dieses Skript auszuführen, müssen die Bitnami Cloud Tools installiert sein. (siehe diesen Artikel). Anschließend erstellt man im Root Verzeichnis der Bitnami Cloud Tools eine AWS-Backup.bat Datei und fügt dort das folgende Skript ein:

@echo off

CALL "D:\AWS-BI~1\scripts\setenv.bat"
CALL "D:\AWS-BI~1\aws-setenv.bat"

:: Path for your AWS home directory
set AWS_HOME=D:\AWS-BI~1\
:: Hier wird der Endpunkt für die Region EU gesetzt.
set EC2_URL=https://ec2.eu-west-1.amazonaws.com:443

cd "D:\AWS-BitNami"

:: Set today's day of week parameter, German Date with . otherwise /
for /F "tokens=1 delims=. " %%a in ('DATE/T') do set dateDayOfMonth=%%a

:: Create a file with all attached volumes
ec2-describe-volumes|find /i "attached">%AWS_HOME%\Volumes.txt

:: Create a file with old scheduled snapshots using same day of week parameter
ec2-describe-snapshots|find /i "%dateDOW%: Daily Backup for">%AWS_HOME%\SnapshotsDOM.txt

:: Create a file of instances filtering on the instance tag Name
ec2-describe-instances|find /i "TAG"|find /i "Name">%AWS_HOME%\InstanceNames.txt

:: Create snapshots of all attached volumes
for /F "tokens=2,3" %%d IN (%AWS_HOME%\Volumes.txt) do for /F "tokens=3,5" %%a IN (%AWS_HOME%\InstanceNames.txt) do if %%a EQU %%e ec2-create-snapshot %%d -d "%dateDayOfMonth%: Daily Backup for %%b (VolID:%%d InstID:%%e)"

::Delete old Snapshots listet in SnapshotsDOM.txt
for /F "tokens=2" %%i in (%AWS_HOME%\SnapshotsDOM.txt) do ec2-delete-snapshot %%i

pause

Das ganze Skript basiert auf einer Vorlage von Mark Sehmer, ich habe nur ein paar Änderungen durchgeführt, damit es bei mir auch funktioniert.