Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Backup und Wiederherstellung für Amazon EC2 mit EBS-Volumes
AWS bietet mehrere Methoden zum Sichern Ihrer Amazon EC2 EC2-Instances. In diesem Abschnitt werden verschiedene Aspekte der Sicherung von Amazon Elastic Block Store (Amazon EBS) -Volumes oder Instance-Speicher-Volumes zur Speicherung behandelt. Erwägen Sie es AWS Backup als Ihre erste Wahl für die Verwaltung von Backups AWS , wenn es Ihren Anforderungen entspricht. Denken Sie daran, dass Backups nur dann sinnvoll sind, wenn sie mit der Funktion wiederhergestellt werden können, für die sie vorgesehen waren. Die Wiederherstellungs- und Wiederherstellungsfunktion sollte regelmäßig getestet werden, um dies zu bestätigen.
Die Lösungsarchitektur im folgenden Diagramm beschreibt eine Workload-Umgebung, die vollständig auf AWS Amazon EC2 basiert. Wie die folgende Abbildung zeigt, umfasst das Szenario Webserver, Anwendungsserver, Überwachungsserver, Datenbanken, Active Directory und Disaster Recovery (DR) -Replikation.
![\[Diagramm einer Beispielumgebung mit zwei Availability Zones, privaten Datenbanken und Replikatdatenbanken in den privaten Subnetzen und Disaster Recovery-Replikation.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/backup-recovery/images/workload-environment-aws.png)
AWS bietet viele Dienste mit vollem Funktionsumfang für viele der in dieser Architektur vertretenen Amazon EC2-Server, um die undifferenzierte Arbeit der Erstellung, Bereitstellung, Sicherung, Wiederherstellung und Optimierung der Instances und des Speichers durchzuführen. Überlegen Sie, ob diese Services in Ihrer Architektur sinnvoll sind, um Komplexität und Verwaltung zu reduzieren. AWS bietet auch Services zur Verbesserung der Verfügbarkeit Ihrer auf Amazon EC2 basierenden Architekturen. Ziehen Sie insbesondere Amazon EC2 Auto Scaling und Elastic Load Balancing in Betracht, um Ihre Workloads auf Amazon EC2 zu ergänzen. Die Nutzung dieser Services kann die Verfügbarkeit und Fehlertoleranz Ihrer Architektur verbessern und Ihnen helfen, beeinträchtigte Instances mit minimaler Auswirkung auf die Benutzer wiederherzustellen.
EC2-Instances verwenden hauptsächlich Amazon EBS-Volumes für persistenten Speicher. Amazon EBS bietet eine Reihe von Funktionen für Sicherung und Wiederherstellung, die in diesem Abschnitt ausführlich behandelt werden.
**Topics**
+ [Amazon EC2 EC2-Backup und -Wiederherstellung mit Snapshots und AMIs](ec2-backup.md)
+ [Erstellen von EBS-Volume-Backups mit und EBS-Snapshots AMIs](new-ebs-volume-backups.md)
+ [Wiederherstellen eines Amazon EBS-Volumes oder einer EC2-Instance](restore.md)
# Amazon EC2 EC2-Backup und -Wiederherstellung mit Snapshots und AMIs
Überlegen Sie, ob Sie ein vollständiges Backup einer EC2-Instance mit einem Amazon Machine Image (AMI) erstellen oder einen Snapshot eines einzelnen Volumes erstellen müssen.
## Verwenden von AMIs Amazon EBS-Snapshots für Backups
Ein AMI umfasst Folgendes:
+ Ein oder mehrere Schnappschüsse. Instance-store-backed AMIs fügen Sie eine Vorlage für das Root-Volume der Instance hinzu (z. B. ein Betriebssystem, einen Anwendungsserver und Anwendungen).
+ Startberechtigungen, die steuern, welche AWS Konten das AMI zum Starten von Instances verwenden können.
+ Eine Blockgerätezuordnung, die festlegt, welche Volumes an die Instance angehängt werden sollen, wenn sie gestartet wird.
**Anmerkung**
In den meisten Fällen benötigen Red Hat, SUSE und SQL Server AMIs für Windows korrekte Lizenzinformationen, um im AMI vorhanden zu sein. Weitere Informationen finden Sie unter [Grundlegendes zu den AMI-Abrechnungsinformationen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html). Beim Erstellen eines AMI aus einem Snapshot leitet der `RegisterImage`-Vorgang die korrekten Fakturierungsinformationen aus den Metadaten des Snapshots ab. Dazu müssen jedoch die entsprechenden Metadaten vorhanden sein. Um zu überprüfen, ob die richtigen Rechnungsinformationen verwendet wurden, überprüfen Sie das Feld **Plattformdetails** auf dem neuen AMI. Wenn das Feld leer ist oder nicht dem erwarteten Betriebssystemcode entspricht (z. B. Windows, Red Hat, SUSE oder SQL), war die AMI-Erstellung nicht erfolgreich. Sie sollten das AMI verwerfen und den Anweisungen unter [Erstellen eines AMI aus einer Instanz](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami) folgen.
Sie können AMIs verwenden, um neue Instances mit vorkonfigurierter Software und Daten zu starten. Sie können AMIs erstellen, wenn Sie eine Baseline einrichten möchten. Dabei handelt es sich um eine wiederverwendbare Konfiguration zum Starten weiterer Instances. Wenn Sie ein AMI einer vorhandenen EC2-Instance erstellen, wird ein Snapshot für alle Volumes erstellt, die an die Instance angehängt sind. Der Snapshot umfasst die Gerätezuordnungen.
Sie können Snapshots nicht verwenden, um eine neue Instance zu starten, aber Sie können sie verwenden, um Volumes auf einer vorhandenen Instance zu ersetzen. Wenn Daten beschädigt werden oder ein Volume-Fehler auftritt, können Sie aus einem Snapshot, den Sie erstellt haben, ein Volume erstellen und das alte Volume ersetzen. Sie können Snapshots auch verwenden, um neue Volumes bereitzustellen und sie beim Start einer neuen Instance anzuhängen.
Wenn Sie eine Plattform und eine Anwendung verwenden, die von AWS oder von der AMIs verwaltet und veröffentlicht werden AWS Marketplace, sollten Sie erwägen, separate Volumes für Ihre Daten zu verwalten. Sie können Ihre Datenvolumes als Snapshots sichern, die von den Volumes des Betriebssystems und der Anwendung getrennt sind. Verwenden Sie dann die Snapshots des Datenvolumens mit neu aktualisierten Daten, die von AWS oder aus dem AMIs veröffentlicht wurden. AWS Marketplace Dieser Ansatz erfordert sorgfältige Tests und Planung, um alle benutzerdefinierten Daten, einschließlich der Konfigurationsinformationen, auf den neu veröffentlichten AMIs Daten zu sichern und wiederherzustellen.
Der Wiederherstellungsprozess wird durch Ihre Wahl zwischen AMI-Backups oder Snapshot-Backups beeinflusst. Wenn Sie AMIs als Instance-Backups erstellen, müssen Sie im Rahmen Ihres Wiederherstellungsprozesses eine EC2-Instance vom AMI aus starten. Möglicherweise müssen Sie auch die bestehende Instance herunterfahren, um mögliche Kollisionen zu vermeiden. Ein Beispiel für eine mögliche Kollision sind Sicherheitskennungen (SIDs) für Windows-Instanzen, die in eine Domäne eingebunden sind. Bei der Wiederherstellung von Snapshots müssen Sie möglicherweise das vorhandene Volume trennen und das neu wiederhergestellte Volume anhängen. Oder Sie müssen möglicherweise eine Konfigurationsänderung vornehmen, um Ihre Anwendungen auf das neu hinzugefügte Volume zu verweisen.
AWS Backup unterstützt sowohl Backups auf Instanzebene als AMIs auch Backups auf Volume-Ebene als separate Snapshots:
+ Für ein vollständiges Backup aller EBS-Volumes auf der Instance [erstellen Sie ein AMI der EC2-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html). Wenn Sie ein Rollback durchführen möchten, verwenden Sie den Launch-Instance-Assistenten, um eine Instance zu erstellen. Wählen Sie im Assistenten zum Starten von Instances die Option **My** aus AMIs.
+ Um ein einzelnes Volume zu sichern, [erstellen Sie einen Snapshot](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html). Informationen zum Wiederherstellen des Snapshots finden Sie unter [Erstellen eines Volumes aus einem Snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot). Sie können das AWS-Managementkonsole oder das AWS Command Line Interface (AWS CLI) verwenden.
Die Kosten für ein Instance-AMI sind die Speicherung aller Volumes auf der Instance, nicht jedoch der Metadaten. Die Kosten für einen EBS-Snapshot entsprechen der Speicherung des einzelnen Volumes. Weitere Informationen zu den Kosten für Volumenspeicher finden Sie auf der [Amazon EBS-Preisseite.](https://aws.amazon.com/ebs/pricing/)
## Server-Volumes
EBS-Volumes sind die primäre persistente Speicheroption für Amazon EC2. Sie können diesen Blockspeicher für strukturierte Daten wie Datenbanken oder unstrukturierte Daten wie Dateien in einem Dateisystem auf einem Volume verwenden.
EBS-Volumes werden in einer bestimmten Availability Zone platziert. Die Volumes werden auf mehrere Server repliziert, um den Verlust von Daten durch den Ausfall einer einzelnen Komponente zu verhindern. Ein Ausfall bezieht sich je nach Größe und Leistung des Volumes auf einen vollständigen oder teilweisen Verlust des Volumes.
EBS-Volumen sind für eine jährliche Ausfallrate (AFR) von 0,1-0,2 Prozent ausgelegt. Dadurch sind EBS-Volumes 20-mal zuverlässiger als herkömmliche Festplattenlaufwerke, die mit einer AFR von rund 4 Prozent ausfallen. Wenn Sie beispielsweise 1.000 EBS-Volumes ein Jahr lang laufen lassen, sollten Sie damit rechnen, dass ein oder zwei Volumes ausfallen werden.
Amazon EBS unterstützt auch eine Snapshot-Funktion zum Erstellen von point-in-time Backups Ihrer Daten. Alle EBS-Volume-Typen bieten dauerhafte Snapshot-Funktionen und sind für eine Verfügbarkeit von 99,999 Prozent konzipiert. Weitere Informationen finden Sie im [Amazon Compute Service Level Agreement](https://aws.amazon.com/ec2/sla/).
Amazon EBS bietet die Möglichkeit, Snapshots (Backups) von jedem EBS-Volume zu erstellen. Ein Snapshot ist eine Basisfunktion für die Erstellung von Backups Ihrer EBS-Volumes. Ein Snapshot erstellt eine Kopie des EBS-Volumes und platziert sie in Amazon S3, wo sie redundant in mehreren Availability Zones gespeichert wird. Der erste Snapshot ist eine vollständige Kopie des Volumes. In laufenden Snapshots werden nur inkrementelle Änderungen auf Blockebene gespeichert. Einzelheiten zur [Erstellung von Amazon EBS-Snapshots finden Sie in der Amazon EBS-Dokumentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html).
Sie können über die [Amazon EC2 EC2-Konsole in derselben Region, in der Sie den Snapshot erstellt haben, einen Wiederherstellungsvorgang ausführen, einen Snapshot löschen oder die](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html) mit dem Snapshot verknüpften Snapshot-Metadaten wie Tags aktualisieren.
Durch die Wiederherstellung eines Snapshots wird ein neues Amazon EBS-Volume mit vollständigen Volume-Daten erstellt. Wenn Sie nur eine teilweise Wiederherstellung benötigen, können Sie das Volume unter einem anderen Gerätenamen an die laufende Instance anhängen. Mounten Sie es dann und verwenden Sie die Kopierbefehle des Betriebssystems, um die Daten vom Backup-Volume auf das Produktionsvolume zu kopieren.
Amazon EBS-Snapshots können mithilfe der Amazon EBS-Snapshot-Kopierfunktion auch zwischen AWS Regionen kopiert werden, wie in der [Amazon](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html) EBS-Dokumentation beschrieben. Sie können diese Funktion verwenden, um Ihr Backup in einer anderen Region zu speichern, ohne die zugrunde liegende Replikationstechnologie verwalten zu müssen.
## Einrichtung separater Servervolumes
Möglicherweise verwenden Sie bereits einen Standardsatz separater Volumes für das Betriebssystem, die Protokolle, Anwendungen und Daten. Durch die Einrichtung separater Servervolumes können Sie den Umfang der Auswirkungen verringern, die bei Anwendungs- oder Plattformausfällen auftreten, die auf ungenügenden Festplattenspeicher zurückzuführen sind. Dieses Risiko ist bei physischen Festplatten in der Regel größer, da Sie nicht die Flexibilität haben, Volumes schnell zu erweitern. Bei physischen Laufwerken müssen Sie die neuen Laufwerke kaufen, die Daten sichern und dann die Daten auf den neuen Laufwerken wiederherstellen. Mit wird dieses Risiko erheblich reduziert AWS, da Sie Amazon EBS verwenden können, um Ihre bereitgestellten Volumes zu erweitern. Weitere Informationen finden Sie in der [AWS -Dokumentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-volume-requirements.html).
Pflegen Sie separate Volumes für Anwendungsdaten, Benutzerdaten, Protokolle und Auslagerungsdateien, sodass Sie separate Sicherungs- und Wiederherstellungsrichtlinien für diese Ressourcen verwenden können. Indem Sie die Volumes für Ihre Daten trennen, können Sie je nach Leistungs- und Speicheranforderungen für die Daten auch unterschiedliche Volumetypen verwenden. Anschließend können Sie Ihre Kosten für verschiedene Workloads optimieren und fein abstimmen.
## Überlegungen zu Instance-Speicher-Volumes
Ein *Instance-Speicher* stellt für Ihre Instance temporären Speicher auf Blockebene bereit. Dieser Speicher befindet sich auf Laufwerken, die physisch mit dem Host-Computer verbunden sind. Instance-Speicher eignen sich ideal für die temporäre Speicherung von Informationen, die sich häufig ändern, wie Puffer, Caches, Scratch-Daten und andere temporäre Inhalte. Sie eignen sich auch für Daten, die über eine Flotte von Instances repliziert werden, z. B. für einen Pool von Webservern mit Lastenausgleich.
Die Daten in einem Instance-Speicher bleiben nur während der Nutzungsdauer der jeweiligen Instance erhalten. Wenn eine Instance neu gestartet wird (absichtlich oder unabsichtlich), bleiben die Daten im Instance-Speicher erhalten. Daten im Instance-Speicher gehen jedoch unter den folgenden Umständen verloren.
+ Das zugrunde liegende Laufwerk fällt aus.
+ Die Instance wird gestoppt.
+ Die Instance wird beendet.
Verlassen Sie sich daher nicht auf einen Instance-Speicher für wertvolle, langfristige Daten. Nutzen Sie hierfür stattdessen eine dauerhaftere Datenspeicherung, z. B. Amazon S3, Amazon EBS oder Amazon EFS.
Eine gängige Strategie bei Instance-Speicher-Volumes besteht darin, die erforderlichen Daten bei Bedarf regelmäßig auf der Grundlage des Recovery Point Objective (RPO) und der Recovery Time Objective (RTO) in Amazon S3 zu speichern. Sie können die Daten dann von Amazon S3 in Ihren Instance-Speicher herunterladen, wenn eine neue Instance gestartet wird. Sie können die Daten auch auf Amazon S3 hochladen, bevor eine Instance gestoppt wird. Um Persistenz zu gewährleisten, erstellen Sie ein EBS-Volume, hängen Sie es an Ihre Instance an und kopieren Sie die Daten in regelmäßigen Abständen vom Instance-Speicher-Volume auf das EBS-Volume. [Weitere Informationen finden Sie im Knowledge Center.AWS](https://aws.amazon.com/premiumsupport/knowledge-center/back-up-instance-store-ebs/)
## Kennzeichnung und Durchsetzung von Standards für EBS-Snapshots und AMIs
Das Markieren all Ihrer AWS Ressourcen ist eine wichtige Methode für die Kostenzuweisung, Prüfung, Fehlerbehebung und Benachrichtigung. Die Kennzeichnung ist für EBS-Volumes wichtig, damit alle relevanten Informationen, die für die Verwaltung und Wiederherstellung von Volumes erforderlich sind, zur Verfügung stehen. Tags werden nicht automatisch von EC2-Instances auf AMIs oder von Quell-Volumes in Snapshots kopiert. Stellen Sie sicher, dass Ihr Backup-Prozess die relevanten Tags aus diesen Quellen enthält. Auf diese Weise können Sie die Snapshot-Metadaten wie Zugriffsrichtlinien, Anhangsinformationen und Kostenzuweisung festlegen, um diese Backups in future verwenden zu können. Weitere Informationen zum Taggen Ihrer AWS Ressourcen finden Sie im [technischen paper mit bewährten Methoden zum Tagging](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf).
Verwenden Sie zusätzlich zu den Tags, die Sie für alle AWS Ressourcen verwenden, die folgenden für Backups spezifischen Tags:
+ ID der Quellinstanz
+ Quell-Volume-ID (für Snapshots)
+ Beschreibung des Wiederherstellungspunkts
Sie können Tagging-Richtlinien mithilfe von AWS Config Regeln und IAM-Berechtigungen durchsetzen. IAM unterstützt die erzwungene Verwendung von Tags, sodass Sie IAM-Richtlinien schreiben können, die die Verwendung bestimmter Tags vorschreiben, wenn Sie auf Amazon EBS-Snapshots reagieren. Wenn ein `CreateSnapshot` Vorgang ohne die in der IAM-Berechtigungsrichtlinie definierten Tags versucht wird, die Rechte gewähren, schlägt die Snapshot-Erstellung fehl und der Zugriff wird verweigert. Weitere Informationen finden Sie im [Blogbeitrag zum Taggen von Amazon EBS-Snapshots bei der Erstellung und Implementierung strengerer](https://aws.amazon.com/blogs/compute/tag-amazon-ebs-snapshots-on-creation-and-implement-stronger-security-policies/) Sicherheitsrichtlinien.
Sie können AWS Config Regeln verwenden, um die Konfigurationseinstellungen Ihrer AWS Ressourcen automatisch auszuwerten. Um Ihnen den Einstieg zu erleichtern, AWS Config stellt es anpassbare, vordefinierte Regeln bereit, die als verwaltete Regeln bezeichnet werden. Zudem können Sie eigene benutzerdefinierte Regeln erstellen. Es verfolgt AWS Config kontinuierlich die Konfigurationsänderungen Ihrer Ressourcen und überprüft, ob diese Änderungen gegen eine der Bedingungen in Ihren Regeln verstoßen. Wenn eine Ressource gegen eine Regel verstößt, werden die AWS Config Ressource und die Regel als *nicht* konform gekennzeichnet. Beachten Sie, dass die verwaltete Regel mit [erforderlichen Tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html) derzeit keine Snapshots und unterstützt. AMIs
# Erstellen von EBS-Volume-Backups mit und EBS-Snapshots AMIs
AWS bietet eine Fülle von Optionen für die Erstellung AMIs und Verwaltung von Snapshots. Sie können den Ansatz verwenden, der Ihren Anforderungen entspricht. Ein häufiges Problem, mit dem viele Kunden konfrontiert sind, ist die Verwaltung des Snapshot-Lebenszyklus und die klare Ausrichtung von Snapshots nach Zweck, Aufbewahrungsrichtlinie usw. Ohne die richtige Kennzeichnung besteht die Gefahr, dass Snapshots versehentlich oder im Rahmen eines automatisierten Bereinigungsprozesses gelöscht werden. Möglicherweise zahlen Sie am Ende auch für veraltete Snapshots, die aufbewahrt werden, weil nicht klar ist, ob sie noch benötigt werden.
## Vorbereiten eines EBS-Volumes vor der Erstellung eines Snapshots oder AMIs
Bevor Sie einen Snapshot erstellen oder ein AMI erstellen, treffen Sie die notwendigen Vorbereitungen für Ihr EBS-Volume. Das Erstellen eines AMI führt zu einem neuen Snapshot für jedes EBS-Volume, das an die Instance angehängt ist. Daher gelten diese Vorbereitungen auch für. AMIs
Sie können einen Snapshot eines angehängten EBS-Volumes erstellen, das von einer eingeschalteten EC2-Instance verwendet wird. Snapshots erfassen jedoch nur Daten, die zum Zeitpunkt der Ausführung des Snapshot-Befehls auf Ihr EBS-Volume geschrieben wurden. Dies schließt möglicherweise alle Daten aus, die von Anwendungen oder dem Betriebssystem zwischengespeichert wurden. Eine bewährte Methode besteht darin, das System in einem Zustand zu halten, in dem es keine I/O durchführt. Idealerweise akzeptiert der Computer keinen Datenverkehr und befindet sich in einem angehaltenen Zustand. Dies ist jedoch selten, da IT-Betrieb rund um die Uhr zur Norm wird. Wenn Sie Daten aus dem Systemspeicher auf die von Ihren Anwendungen verwendete Festplatte leeren und alle Dateischreibvorgänge auf das Volume so lange unterbrechen können, dass ein Snapshot erstellt werden kann, sollte Ihr Snapshot vollständig sein.
Um ein sauberes Backup zu erstellen, müssen Sie die Datenbank oder das Dateisystem stilllegen. Die Art und Weise, wie Sie dies tun, hängt von Ihrer Datenbank oder Ihrem Dateisystem ab.
Der Prozess für eine Datenbank ist wie folgt:
1. Wenn möglich, versetzen Sie die Datenbank in den Hot-Backup-Modus.
1. Führen Sie die Amazon EBS-Snapshot-Befehle aus.
1. Beenden Sie den Hot-Backup-Modus für die Datenbank oder beenden Sie die Read Replica-Instance, falls Sie eine Read Replica verwenden.
Das Verfahren für ein Dateisystem ist ähnlich, hängt jedoch von den Funktionen des Betriebssystems oder Dateisystems ab. XFS ist beispielsweise ein Dateisystem, das seine Daten für ein konsistentes Backup leeren kann. [Weitere Informationen finden Sie unter xfs\$1freeze.](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/xfsfreeze) Alternativ können Sie diesen Vorgang vereinfachen, indem Sie einen Logical Volume Manager verwenden, der das Einfrieren von I/O unterstützt.
Wenn Sie jedoch nicht alle Dateischreibvorgänge auf das Volume leeren oder pausieren können, gehen Sie wie folgt vor:
1. Hängen Sie das Volume vom Betriebssystem ab.
1. Geben Sie den Snapshot-Befehl ein.
1. Hängen Sie das Volume erneut ein, um einen konsistenten und vollständigen Snapshot zu erhalten. Sie können Ihr Volume erneut bereitstellen und verwenden, solange der Snapshot-Status noch ausstehend ist.
Der Snapshot-Vorgang wird im Hintergrund fortgesetzt, und die Snapshot-Erstellung erfolgt schnell und erfasst einen bestimmten Zeitpunkt. Die Volumes, die Sie sichern, werden nur für wenige Sekunden nicht bereitgestellt. Sie können ein kleines Backup-Fenster einplanen, in dem ein Ausfall zu erwarten ist und von den Clients ordnungsgemäß behandelt wird.
Wenn Sie einen Snapshot für ein EBS-Volume erstellen, das als Root-Gerät dient, beenden Sie die Instance, bevor Sie den Snapshot erstellen. Windows bietet den Volume Shadow Copy Service (VSS) zur Erstellung anwendungskonsistenter Snapshots. AWS stellt ein Systems Manager Manager-Dokument bereit, das Sie ausführen können, um Backups von VSS-fähigen Anwendungen auf Imageebene zu erstellen. Dazu gehören auch Daten von schwebenden Transaktionen zwischen diesen Anwendungen und dem Datenträger. Sie müssen Ihre Instances nicht herunterfahren oder die Verbindung trennen, wenn Sie alle angehängten Volumes sichern. Weitere Informationen finden Sie in der [AWS -Dokumentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html).
**Anmerkung**
Wenn Sie ein Windows-AMI erstellen, um eine weitere ähnliche Instanz bereitzustellen, verwenden Sie [EC2Config oder EC2 Launch](https://aws.amazon.com/premiumsupport/knowledge-center/sysprep-create-install-ec2-windows-amis/), um Ihre Instanz zu [sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview). Erstellen Sie dann ein AMI aus der gestoppten Instance. Sysprep entfernt eindeutige Informationen aus der Amazon EC2 EC2-Windows-Instance, einschließlich Computername SIDs und Treiber. Duplikate SIDs können zu Problemen mit Active Directory, Windows Server Update Services (WSUS), Anmeldeproblemen, der Windows-Volumenschlüsselaktivierung, Microsoft Office und Produkten von Drittanbietern führen. Verwenden Sie Sysprep nicht mit Ihrer Instance, wenn Ihr AMI zu Backup-Zwecken dient und Sie dieselbe Instance mit all ihren eindeutigen Informationen wiederherstellen möchten.
## Manuelles Erstellen von EBS-Volume-Snapshots über die Konsole
Erstellen Sie Snapshots der entsprechenden Volumes oder der gesamten Instance, bevor Sie größere Änderungen vornehmen, die auf der Instance noch nicht vollständig getestet wurden. Beispielsweise möchten Sie möglicherweise einen Snapshot erstellen, bevor Sie die Anwendungs- oder Systemsoftware auf Ihrer Instance aktualisieren oder patchen.
Sie können einen Snapshot manuell von der Konsole aus erstellen. Wählen Sie in der Amazon EC2 EC2-Konsole auf der Seite **Elastic Block Store Volumes** das Volume aus, das Sie sichern möchten. Wählen Sie dann im Menü **Aktionen** die Option **Snapshot erstellen**. Sie können nach Volumes suchen, die an eine bestimmte Instance angehängt sind, indem Sie die Instanz-ID in das Filterfeld eingeben.
Geben Sie eine Beschreibung ein und fügen Sie die entsprechenden Tags hinzu. Fügen Sie ein `Name` Tag hinzu, damit Sie das Volume später leichter finden können. Fügen Sie basierend auf Ihrer Tagging-Strategie weitere geeignete Tags hinzu.
## Erstellen AMIs
Ein AMI stellt die Informationen bereit, die zum Starten einer Instance erforderlich sind. Das AMI umfasst das Root-Volume und Snapshots der EBS-Volumes, die bei der Erstellung des Images an die Instance angehängt wurden. Sie können neue Instances nicht allein aus EBS-Snapshots starten. Sie müssen neue Instances über ein AMI starten.
Wenn Sie ein AMI erstellen, wird es in dem Konto und der Region erstellt, die Sie verwenden. Der AMI-Erstellungsprozess erstellt Amazon EBS-Snapshots für jedes Volume, das an die Instance angehängt ist, und das AMI bezieht sich auf diese Amazon EBS-Snapshots. Diese Schnappschüsse befinden sich in Amazon S3 und sind äußerst robust.
Nachdem Sie ein AMI Ihrer EC2-Instance erstellt haben, können Sie das AMI verwenden, um die Instance neu zu erstellen oder weitere Kopien der Instance zu starten. Sie können für die Anwendungsmigration oder DR auch AMIs von einer Region in eine andere kopieren.
![\[Ein Image erstellen, das Image auf einer Instanz starten und eine Kopie des Images erstellen.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/backup-recovery/images/ami-process.png)
Ein AMI muss aus einer EC2-Instanz erstellt werden, es sei denn, Sie migrieren eine virtuelle Maschine, z. B. eine virtuelle VMWARE-Maschine, zu. AWS Um ein AMI von der Amazon EC2 EC2-Konsole aus zu erstellen, wählen Sie die Instance aus, wählen Sie **Actions**, dann **Image** und dann **Create Image** aus.
## Amazon Data Lifecycle Manager
Um die Erstellung, Aufbewahrung und Löschung von Amazon EBS-Snapshots zu automatisieren, können Sie [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html) verwenden. Die Automatisierung der Snapshot-Verwaltung hilft Ihnen dabei, Folgendes zu tun:
+ Wertvolle Daten zu schützen, indem ein regelmäßiger Backup-Plan eingehalten wird.
+ Backups aufzubewahren, die für Prüfer oder interne Compliance-Vorschriften benötigt werden.
+ Speicherkosten zu reduzieren, indem veraltete Backups gelöscht werden.
Mit Amazon Data Lifecycle Manager können Sie den Snapshot-Verwaltungsprozess für EC2-Instances (und ihre angehängten EBS-Volumes) oder separate EBS-Volumes automatisieren. Es unterstützt Optionen wie regionsübergreifendes Kopieren, sodass Sie Snapshots automatisch in andere Regionen kopieren können. AWS Das Kopieren von Snapshots in alternative Regionen ist ein Ansatz, um DR-Bemühungen und Wiederherstellungsoptionen in einer alternativen Region zu unterstützen. Sie können Amazon Data Lifecycle Manager auch verwenden, um eine Snapshot-Lebenszyklusrichtlinie zu erstellen, die eine [schnelle Snapshot-Wiederherstellung](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html) unterstützt.
Amazon Data Lifecycle Manager ist eine in Amazon EC2 und Amazon EBS enthaltene Funktion. Für Amazon Data Lifecycle Manager fallen keine Gebühren an.
## AWS Backup
AWS Backup ist einzigartig bei Amazon Data Lifecycle Manager, da Sie einen Backup-Plan erstellen können, der Ressourcen für mehrere AWS Services umfasst. Sie können Ihr Backup so koordinieren, dass es die Ressourcen abdeckt, die Sie zusammen verwenden, anstatt die Backups der Ressourcen einzeln zu koordinieren.
AWS Backup beinhaltet auch das Konzept der Backup-Tresore, wodurch der Zugriff auf die Wiederherstellungspunkte für Ihre abgeschlossenen Backups eingeschränkt werden kann. Wiederherstellungsvorgänge können von jeder einzelnen Ressource aus initiiert werden, AWS Backup anstatt das erstellte Backup wiederherzustellen. AWS Backup umfasst außerdem eine Vielzahl zusätzlicher Funktionen, wie z. B. Auditmanagement und Berichterstattung. Weitere Informationen finden Sie im Abschnitt [Backup und Wiederherstellung mit AWS Backup[Backup und Wiederherstellung mit AWS Backup](aws-backup.md)](aws-backup.md) in diesem Handbuch.
## Durchführen von Backups mit mehreren Volumes
Wenn Sie die Daten auf den EBS-Volumes in einem RAID-Array mithilfe von Snapshots sichern möchten, müssen die Snapshots konsistent sein. Dies liegt daran, dass die Snapshots dieser Volumes unabhängig voneinander erstellt werden. Die Wiederherstellung von EBS-Volumes in einem RAID-Array aus nicht synchronisierten Snapshots beeinträchtigt die Integrität des Arrays.
**Um einen konsistenten Satz von Snapshots für Ihr RAID-Array zu erstellen, verwenden Sie den [CreateSnapshots](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSnapshots.html)API-Vorgang oder melden Sie sich bei der Amazon EC2-Konsole an und wählen Sie **Elastic Block Store**, **Snapshots, Snapshot erstellen**.**
![\[Der Bildschirm „Snapshot erstellen“ für die Erstellung eines Snapshots mit mehreren Volumes.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/backup-recovery/images/multi-volume-snapshot.png)
Snapshots von Instances, an die mehrere Volumes in einer RAID-Konfiguration angeschlossen sind, werden zusammen als Snapshot mit mehreren Volumes erstellt. Snapshots mit mehreren Volumes bieten datenkoordinierte und point-in-time absturzsichere Snapshots auf mehreren EBS-Volumes, die an eine EC2-Instance angeschlossen sind. Sie müssen Ihre Instance nicht anhalten, um zwischen Volumes zu koordinieren, um Konsistenz zu erreichen, da Snapshots automatisch auf mehreren EBS-Volumes erstellt werden. Nachdem der Snapshot für die Volumes initiiert wurde (normalerweise ein oder zwei Sekunden), kann das Dateisystem seinen Betrieb fortsetzen.
Nach der Erstellung werden die Snapshots als individuelle Snapshots behandelt. Sie können alle Snapshot-Vorgänge wie Wiederherstellen, Löschen und regionsübergreifendes Kopieren und Kontenkopieren wie bei einem Snapshot mit einem einzigen Volume ausführen. Sie können Ihre Snapshots mit mehreren Volumes auch wie Snapshots mit einem einzigen Volume taggen. Wir empfehlen Ihnen, Ihre Snapshots mit mehreren Volumes zu taggen, um sie bei der Wiederherstellung, beim Kopieren oder bei der Aufbewahrung gemeinsam verwalten zu können. Weitere Informationen finden Sie in der [AWS -Dokumentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html).
Sie können diese Backups auch von einem Logical Volume Manager oder einem Backup auf Dateisystemebene aus durchführen. In diesen Fällen können die Daten mithilfe eines herkömmlichen Backup-Agenten über das Netzwerk gesichert werden. Eine Reihe von agentenbasierten Backup-Lösungen sind im Internet und im [AWS Marketplace](https://aws.amazon.com/marketplace/)verfügbar.
Ein alternativer Ansatz besteht darin, ein Replikat der primären Systemvolumes zu erstellen, die sich auf einem einzigen großen Volume befinden. Dies vereinfacht den Backup-Prozess, da nur ein großes Volume gesichert werden muss und das Backup nicht auf dem Primärsystem stattfindet. Stellen Sie jedoch zunächst fest, ob das einzelne Volume während des Backups eine ausreichende Leistung erbringen kann und ob die maximale Volume-Größe für die Anwendung angemessen ist.
## Schützen Sie Ihre Amazon EC2 EC2-Backups
Es ist wichtig, die Sicherheit Ihrer Backups zu berücksichtigen und ein versehentliches oder böswilliges Löschen Ihrer Backups zu verhindern. Sie können eine Reihe von Ansätzen gemeinsam anwenden, um dies zu erreichen. Um den Verlust Ihrer wichtigen Backups aufgrund einer Sicherheitsverletzung zu verhindern, empfehlen wir Ihnen, Ihre Backups auf ein anderes AWS Konto zu kopieren. Wenn Sie mehrere AWS Konten haben, können Sie ein separates Konto als Archivkonto festlegen, auf das alle anderen Konten Backups kopieren können. Sie können dies beispielsweise mit einem [kontoübergreifenden Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html) in erreichen. AWS Backup
Ihr Notfallwiederherstellungsplan erfordert möglicherweise auch, dass Sie EC2-Instances AWS-Region bei einem regionalen Ausfall auf einer anderen reproduzieren können. Sie können dieses Ziel unterstützen, indem Sie Ihre Backups innerhalb desselben Kontos in eine andere Region kopieren. Dies kann einen zusätzlichen Schutz vor versehentlichem Löschen bieten und die Ziele der Notfallwiederherstellung (DR) unterstützen. AWS Backup bietet Unterstützung für [regionsübergreifende Backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html).
Erwägen Sie, IAM-Berechtigungen für die Aktionen [ec2: DeleteSnapshot und [ec2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeregisterImage.html):](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteSnapshot.html) zu blockieren. DeregisterImage Stattdessen können Sie Ihre Aufbewahrungsrichtlinien und -methoden den Lebenszyklus von EBS-Snapshots und Amazon EC2 verwalten lassen. AMIs Das Blockieren von Löschaktionen ist eine Möglichkeit, eine WORM-Strategie (Write-Once, Read-Many) für Ihre EBS-Snapshots zu implementieren. Sie können auch [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html) verwenden, das Unterstützung für EBS-Snapshots und andere Ressourcen bietet. AWS
[Erwägen Sie außerdem, Benutzern die Möglichkeit zur gemeinsamen Nutzung AMIs und EBS-Snapshots zu sperren, indem Sie die IAM-Aktionen [ec2: ModifyImageAttribute und ec2:](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) blockieren. ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html) Dadurch wird verhindert, dass Ihre Snapshots AMIs und Ihre Snapshots mit AWS Konten geteilt werden, die sich außerhalb Ihrer Organisation befinden. Wenn Sie verwenden AWS Backup, beschränken Sie die Benutzer darauf, ähnliche Operationen in Backup-Tresoren durchzuführen. Weitere Informationen finden Sie im Abschnitt [Backup und Wiederherstellung mit AWS Backup](aws-backup.md) in diesem Handbuch.
Amazon EBS enthält eine [Papierkorb-Funktion](https://docs.aws.amazon.com/ebs/latest/userguide/recycle-bin.html), mit der Sie versehentlich gelöschte EBS-Snapshots wiederherstellen können. Wenn Sie Ihren Benutzern das Löschen von Snapshots gestatten, aktivieren Sie diese Funktion, damit benötigte Snapshots nicht dauerhaft gelöscht werden. Benutzer sollten beim Löschen mehrerer Snapshots besonders vorsichtig sein, da Sie mit der Amazon EC2 EC2-Konsole mehrere Snapshots auswählen und in einem Vorgang löschen können. Seien Sie außerdem vorsichtig, wenn Sie Bereinigungsskripts und Automatisierung verwenden, damit Sie die benötigten Snapshots nicht versehentlich löschen. Die Papierkorbfunktion trägt zum Schutz vor solchen Situationen bei.
## Archivieren von EBS-Snapshots
Die [Archivierung Ihrer EBS-Snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html) kann eine kostengünstige Methode sein, um eine Kopie eines Volumes zu Referenzzwecken aufzubewahren, das Sie 90 oder mehr Tage lang nicht wiederherstellen möchten. Dies kann ein guter Zwischenschritt sein, bevor alle zugehörigen Snapshots für ein EBS-Volume dauerhaft gelöscht werden. Sie könnten das Archivieren von Snapshots beispielsweise als einen end-of-lifecycle Schritt für EBS-Volumes betrachten, die nicht mehr verwendet werden. Archivieren statt Löschen kann auch eine kostengünstigere Methode zur Aufbewahrung von Löschungen sein, als den Papierkorb zu verwenden.
## Automatisieren der Snapshot- und AMI-Erstellung mit Systems Manager AWS CLI, dem und AWS SDKs
Ihr Backup-Ansatz erfordert möglicherweise Operationen vor und nach der Erstellung eines Snapshots oder AMIs. Beispielsweise müssen Sie möglicherweise Dienste beenden und starten, um das Dateisystem stillzulegen. Oder Sie müssen Ihre Instance möglicherweise während der AMI-Erstellung beenden und starten. Möglicherweise müssen Sie auch gemeinsam Backups mehrerer Komponenten in Ihrer Architektur erstellen, wobei für jede Komponente jeweils eigene Schritte vor und nach der Erstellung erforderlich sind.
Sie können Ihre Wartungsfenster für Ihre Backups reduzieren, indem Sie Ihren Prozess automatisieren und sicherstellen, dass Ihr Backup-Prozess konsistent angewendet wird. Um Ihre benutzerdefinierten Vorgänge vor und nach der Erstellung zu automatisieren, erstellen Sie ein Skript für Ihren Backup-Prozess mithilfe des SDK und des AWS CLI SDK.
Ihre Automatisierung kann in einem Systems Manager Manager-Runbook definiert werden, das bei Bedarf oder während eines Systems Manager Manager-Wartungsfensters ausgeführt werden kann. Sie können Ihren Benutzern Zugriff auf die Ausführung von Systems Manager Manager-Runbooks gewähren, ohne ihnen Berechtigungen für störende Amazon EC2 EC2-Befehle erteilen zu müssen. Auf diese Weise können Sie auch überprüfen, ob Ihr Backup-Prozess und Ihre Backup-Tags von Ihren Benutzern einheitlich angewendet werden. Sie können die CreateImage Runbooks [AWS- CreateSnapshot](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createsnapshot.html) und [AWS-](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createimage.html) zum Erstellen von Snapshots verwenden AMIs, oder Sie können anderen Benutzern Berechtigungen zu deren Verwendung gewähren. Systems Manager umfasst auch die UpdateWindowsAmi Runbooks [AWS— UpdateLinuxAmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatelinuxami.html) und [AWS—](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatewindowsami.html), um das AMI-Patching und die AMI-Erstellung zu automatisieren.
Sie können das AWS CLI und auch verwenden [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/), um Ihren Snapshot- und AMI-Erstellungsprozess zu automatisieren. Sie können den AWS CLI Befehl [aws ec2 create-snapshot](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshot.html) verwenden, um in einem Schritt Ihrer Automatisierung einen Snapshot eines EBS-Volumes zu erstellen. Sie können den Befehl [aws ec2 create-snapshots verwenden, um absturzkonsistente, synchronisierte Snapshots](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshots.html) aller Volumes zu erstellen, die an Ihre EC2-Instance angehängt sind.
Sie können die AWS CLI verwenden, um neue zu erstellen AMIs. Sie können den Befehl [aws ec2 register-image verwenden, um ein neues Image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) für Ihre EC2-Instance zu erstellen. [Um das Herunterfahren, die Image-Erstellung und den Neustart Ihrer Instances zu automatisieren, kombinieren Sie diesen Befehl mit den Befehlen [aws ec2 stop-instances und aws ec2 start-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html).](https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html)
# Wiederherstellen eines Amazon EBS-Volumes oder einer EC2-Instance
Wenn Sie nur ein einzelnes Volume wiederherstellen müssen, das an eine EC2-Instance angehängt ist, können Sie dieses Volume separat wiederherstellen, das vorhandene Volume trennen und das wiederhergestellte Volume Ihrer EC2-Instance zuordnen. Wenn Sie eine gesamte EC2-Instance einschließlich aller zugehörigen Volumes wiederherstellen müssen, müssen Sie ein Amazon Machine Image (AMI) -Backup Ihrer Instance verwenden.
Um die Wiederherstellungszeit und die Auswirkungen auf abhängige Anwendungen und Prozesse zu reduzieren, muss Ihr Wiederherstellungsprozess die Ressource berücksichtigen, die ersetzt wird. Um optimale Ergebnisse zu erzielen, sollten Sie Ihren Wiederherstellungsprozess regelmäßig in niedrigeren Umgebungen (z. B. außerhalb der Produktionsumgebung) testen, um sicherzustellen, dass Ihr Prozess Ihr Recovery Point Objective (RPO) und Recovery Time Objective (RTO) erfüllt und ob der Wiederherstellungsprozess wie erwartet funktioniert. Überlegen Sie, wie sich der Wiederherstellungsprozess auf Anwendungen und Dienste auswirkt, die von der Instanz abhängen, die Sie wiederherstellen, und koordinieren Sie dann die Wiederherstellung nach Bedarf. Versuchen Sie, den Wiederherstellungsprozess so weit wie möglich zu automatisieren und zu testen, um das Risiko zu verringern, dass Ihr Wiederherstellungsprozess fehlschlägt oder inkonsistent implementiert wird.
Wenn Sie Elastic Load Balancing verwenden und mehrere Instances den Traffic verarbeiten, können Sie eine ausgefallene oder beeinträchtigte Instance außer Betrieb nehmen. Anschließend können Sie eine neue Instance wiederherstellen, um sie zu ersetzen, während die anderen Instances weiterhin den Traffic bearbeiten, ohne die Benutzer zu stören.
Die folgenden beschriebenen Wiederherstellungsprozesse gelten für Instances, die Elastic Load Balancing nicht verwenden:
+ Wiederherstellung einzelner Dateien und Verzeichnisse aus EBS-Snapshots
+ Wiederherstellen eines EBS-Volumes aus einem Amazon EBS-Snapshot
+ Erstellen oder Wiederherstellen einer EC2-Instance aus einem EBS-Snapshot
+ Wiederherstellung einer laufenden Instance aus einem AMI
## Dateien und Verzeichnisse aus EBS-Snapshots wiederherstellen
[EBS-Snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html) bieten eine point-in-time exakte Kopie des ursprünglichen Volumes, das zur Erstellung des Snapshots verwendet wurde. Um einzelne Dateien oder Verzeichnisse wiederherzustellen, müssen Sie wie folgt vorgehen:
1. [Stellen Sie zunächst das Volume aus dem EBS-Snapshot](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html#restore-snapshot) wieder her, das die Dateien oder Verzeichnisse enthält.
1. Hängen Sie das Volume an die EC2-Instance an, auf der Sie die Dateien wiederherstellen möchten.
1. Kopieren Sie die Dateien vom wiederhergestellten Volume auf Ihr EC2-Instance-Volume.
1. Trennen Sie das wiederhergestellte Volume und löschen Sie es.
## Wiederherstellen eines EBS-Volumes aus einem Amazon EBS-Snapshot
Sie können ein Volume wiederherstellen, das an eine bestehende EC2-Instance angehängt ist, indem Sie aus dem zugehörigen Snapshot ein Volume erstellen und es an Ihre Instance anhängen. Sie können die Konsolen-, die- oder die API-Operationen verwenden AWS CLI, um ein Volume aus einem vorhandenen Snapshot zu erstellen. Anschließend können Sie das Volume mithilfe des Betriebssystems in die Instance einbinden.
Beachten Sie, dass Daten aus einem Amazon EBS-Snapshot asynchron in ein EBS-Volume geladen werden. Wenn eine Anwendung auf das Volume zugreift, auf dem die Daten nicht geladen sind, kommt es zu einer höheren Latenz als normal, während die Daten von Amazon S3 geladen werden. Um diese Auswirkungen bei latenzempfindlichen Anwendungen zu vermeiden, haben Sie zwei Möglichkeiten:
+ Sie können das [EBS-Volume initialisieren](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html).
+ Gegen eine zusätzliche Gebühr unterstützt Amazon EBS die [schnelle Snapshot-Wiederherstellung](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html), sodass Sie Ihr Volume nicht initialisieren müssen.
Wenn Sie ein Volume ersetzen, das denselben Bereitstellungspunkt verwenden muss, müssen Sie dieses Volume aushängen, sodass Sie das neue Volume an seiner Stelle einhängen können. Um die Bereitstellung des Volumes aufzuheben, beenden Sie zunächst alle Prozesse, die das Volume verwenden. Wenn Sie das Root-Volume austauschen, müssen Sie zuerst die Instance beenden, bevor Sie das Root-Volume trennen können.
Gehen Sie beispielsweise folgendermaßen vor, um mithilfe der Konsole ein Volume auf einem früheren point-in-time Backup wiederherzustellen:
1. Wählen Sie auf der Amazon EC2 EC2-Konsole im **Elastic Block Store-Menü** die Option **Snapshots** aus.
1. Suchen Sie nach dem Snapshot, den Sie wiederherstellen möchten, und wählen Sie ihn aus.
1. Wählen Sie „**Aktionen**“ und anschließend „**Volume erstellen**“.
1. Erstellen Sie das neue Volume in derselben Availability Zone wie Ihre EC2-Instance.
1. Wählen Sie auf der Amazon EC2 EC2-Konsole die Instance aus.
1. Notieren Sie sich in den Instance-Details den Gerätenamen, den Sie ersetzen möchten, in den Einträgen **Root-Gerät** oder **Blockgeräte**.
1. Schließen Sie das Volume an. Das Verfahren unterscheidet sich für Root-Volumes und Nicht-Root-Volumes.
Für Root-Volumes:
1. Halten Sie die EC2-Instance an.
1. Wählen Sie im Menü **EC2 Elastic Block Store Volumes** das Root-Volume aus, das Sie ersetzen möchten.
1. Wählen Sie „**Aktionen**“ und anschließend „Volume **trennen**“.
1. Wählen Sie im Menü **EC2 Elastic Block Store Volumes** das neue Volume aus.
1. Wählen Sie „**Aktionen**“ und anschließend „**Volume anhängen**“.
1. Wählen Sie die Instanz aus, an die Sie das Volume anhängen möchten, und verwenden Sie denselben Gerätenamen, den Sie zuvor notiert haben.
Für Nicht-Root-Volumes:
1. Wählen Sie im Menü **EC2 Elastic Block Store Volumes** das Nicht-Root-Volume aus, das Sie ersetzen möchten.
1. Wählen Sie „**Aktionen**“ und anschließend „Volume **trennen**“.
1. Hängen Sie das neue Volume an, indem Sie es im Menü **EC2 Elastic Block Store Volumes** auswählen und dann **Aktionen**, Volume **anhängen** wählen. Wählen Sie die Instance aus, an die Sie es anhängen möchten, und wählen Sie dann einen verfügbaren Gerätenamen aus.
1. Verwenden Sie das Betriebssystem für die Instanz, hängen Sie das vorhandene Volume aus und mounten Sie dann das neue Volume an seiner Stelle.
Unter Linux können Sie den `umount` Befehl verwenden. In Windows können Sie einen Logical Volume Manager (LVM) wie das Disk Management System Utility verwenden.
1. **Trennen Sie alle vorherigen Volumes, die Sie möglicherweise ersetzen möchten, indem Sie sie im Menü **EC2 Elastic Block Store Volumes** auswählen und dann **Aktionen**, Volume trennen wählen.**
Sie können die auch AWS CLI in Kombination mit Betriebssystembefehlen verwenden, um diese Schritte zu automatisieren.
## Eine EC2-Instance aus einem EBS-Snapshot erstellen oder wiederherstellen
Um ein Backup zu erstellen, das zur Wiederherstellung einer gesamten EC2-Instance verwendet wird, empfehlen wir, ein Amazon Machine Image (AMI) zu erstellen. AMIs erfassen Maschineninformationen wie den Virtualisierungstyp. Sie erstellen außerdem Snapshots für jedes Volume, das an die EC2-Instance angehängt ist, einschließlich ihrer Gerätezuordnungen, sodass sie in derselben Konfiguration wiederhergestellt werden können.
**Anmerkung**
In den meisten Fällen benötigen Red Hat, SUSE und SQL Server AMIs für Windows korrekte Lizenzinformationen, um im AMI vorhanden zu sein. Weitere Informationen finden Sie unter [Grundlegendes zu den AMI-Abrechnungsinformationen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html). Beim Erstellen eines AMI aus einem Snapshot leitet der `RegisterImage`-Vorgang die korrekten Fakturierungsinformationen aus den Metadaten des Snapshots ab. Dazu müssen jedoch die entsprechenden Metadaten vorhanden sein. Um zu überprüfen, ob die richtigen Rechnungsinformationen verwendet wurden, überprüfen Sie das Feld **Plattformdetails** auf dem neuen AMI. Wenn das Feld leer ist oder nicht dem erwarteten Betriebssystemcode entspricht (z. B. Windows, Red Hat, SUSE oder SQL), war die AMI-Erstellung nicht erfolgreich. Sie sollten das AMI verwerfen und den Anweisungen unter [Erstellen eines AMI aus einer Instanz](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami) folgen.
Wenn Sie einen EBS-Snapshot verwenden müssen, um eine Instance wiederherzustellen, erstellen Sie zunächst ein AMI aus einem EBS-Snapshot, der zum Root-Volume für Ihre neue EC2-Instance wird:
1. Wählen Sie auf der Amazon EC2 EC2-Konsole im **Elastic Block Store-Menü** die Option **Snapshots** aus.
1. Suchen Sie nach dem Snapshot, der zur Erstellung des Root-Volumes für Ihre neue EC2-Instance verwendet werden soll, und wählen Sie ihn aus.
1. Wählen Sie **Aktionen** und dann **Create Image from Snapshot aus**.
1. Geben Sie einen Namen für Ihr Bild ein (z. B.`YYYYMMDD-restore-for-i-012345678998765de`) und wählen Sie die entsprechenden Optionen für Ihr neues Bild aus.
1. (Nur Windows, Red Hat, SUSE und SQL Server) Um zu überprüfen, ob die richtigen Fakturierungsinformationen verwendet wurden, überprüfen Sie das Feld **Plattformdetails** auf dem neuen AMI. Wenn das Feld leer ist oder nicht dem erwarteten Betriebssystemcode entspricht (z. B. **Windows** oder **Red Hat**), war die AMI-Erstellung nicht erfolgreich. Sie sollten das AMI verwerfen und den Anweisungen unter [Erstellen eines AMI aus einer Instanz](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami) folgen.
Nachdem das Image erstellt und verfügbar ist, können Sie eine neue EC2-Instance starten, die den EBS-Snapshot für das Root-Volume verwendet.
## Wiederherstellung einer laufenden Instance aus einem AMI
Sie können eine neue Instance aus Ihrem AMI-Backup aufrufen, um eine bestehende, laufende Instance zu ersetzen. Ein Ansatz besteht darin, die bestehende Instance zu beenden, sie offline zu halten, während Sie eine neue Instance von Ihrem AMI aus starten, und alle erforderlichen Updates durchzuführen. Dieser Ansatz reduziert das Risiko von Konflikten, wenn beide Instances gleichzeitig ausgeführt werden. Dieser Ansatz ist akzeptabel, wenn die Dienste, die Ihre Instanz bereitstellt, nicht verfügbar sind oder Sie die Wiederherstellung während eines Wartungsfensters durchführen. Nachdem Sie Ihre neue Instance getestet haben, können Sie alle Elastic IP-Adressen neu zuweisen, die der alten Instance zugewiesen wurden. Anschließend können Sie alle DNS-Einträge (Domain Name Service) so aktualisieren, dass sie auf die neue Instance verweisen.
Wenn Sie jedoch während einer Wiederherstellung die Ausfallzeit Ihrer In-Service-Instance minimieren müssen, sollten Sie erwägen, eine neue Instance von Ihrem AMI-Backup aus zu starten und zu testen. Ersetzen Sie dann die bestehende Instance durch die neue Instance.
Während beide Instanzen ausgeführt werden, müssen Sie verhindern, dass die neue Instanz Kollisionen auf Plattform- oder Anwendungsebene verursacht. Beispielsweise könnten Probleme mit domänengebundenen Windows-Instanzen auftreten, die unter demselben Computernamen ausgeführt werden. SIDs Bei Netzwerkanwendungen und -diensten, für die eindeutige Kennungen erforderlich sind, können ähnliche Probleme auftreten.
Um zu verhindern, dass andere Server und Dienste eine Verbindung zu Ihrer neuen Instance herstellen, bevor sie bereit ist, verwenden Sie Sicherheitsgruppen, um vorübergehend alle eingehenden Verbindungen für Ihre neue Instance zu blockieren, mit Ausnahme Ihrer eigenen IP-Adresse für Zugriffs- und Testzwecke. Sie können ausgehende Verbindungen für die neue Instanz auch vorübergehend blockieren, um zu verhindern, dass Dienste und Anwendungen Verbindungen oder Updates zu anderen Ressourcen initiieren. Wenn die neue Instanz bereit ist, beenden Sie die bestehende Instanz, starten Sie Dienste und Prozesse auf der neuen Instanz und entsperren Sie dann alle eingehenden oder ausgehenden Netzwerkverbindungen, die Sie implementiert haben.