Amazon EC2 Backup und Recovery mit Snapshots und AMIs - AWS Präskriptive Leitlinien

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.

Amazon EC2 Backup und Recovery 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. 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 folgen.

Sie können es verwenden AMIs , um neue Instances mit vorkonfigurierter Software und Daten zu starten. Sie können AMIs sie 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 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 Backups erstellen AMIs , die als Instance-Backups dienen sollen, müssen Sie im Rahmen Ihres Wiederherstellungsprozesses eine EC2 Instance über das AMI 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. 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. Informationen zum Wiederherstellen des Snapshots finden Sie unter Erstellen eines Volumes aus einem Snapshot. Sie können das AWS Management Console 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.

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.

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.

Sie können über die EC2 Amazon-Konsole in derselben Region, in der Sie den Snapshot erstellt haben, einen Wiederherstellungsvorgang ausführen, einen Snapshot löschen oder die 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 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.

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 optimieren.

Ü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 Langzeitdaten. 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 AWS Knowledge Center.

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.

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 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 derzeit keine Snapshots und unterstützt. AMIs