Daten sind einer Ihrer wertvollsten Vermögenswerte, und ihr Verlust kann für Ihre Organisation katastrophal sein. OpenSearch bietet robuste Mechanismen für Backup und Recovery Ihrer Daten und gewährleistet damit die Geschäftskontinuität auch bei unerwarteten Ereignissen. In diesem Kapitel erfahren Sie, wie Sie umfassende Backup- und Recovery-Strategien implementieren, die Ihre Daten schützen und gleichzeitig die Systemleistung aufrechterhalten.
Stellen Sie sich Snapshots in OpenSearch wie eine Momentaufnahme Ihrer Daten zu einem bestimmten Zeitpunkt vor. Genau wie ein Foto den exakten Zustand einer Szene erfasst, speichert ein Snapshot den exakten Zustand Ihrer Indizes, einschließlich ihrer Daten, Mappings und Einstellungen. Sehen wir uns an, wie das im Detail funktioniert.
Bevor wir Snapshots erstellen können, benötigen wir einen Speicherort für sie. OpenSearch unterstützt verschiedene Repository-Typen, jeder mit eigenen Vorteilen. Richten wir beispielsweise ein Repository mit Amazon S3 ein:
PUT /_snapshot/backup_repository
{
"type": "s3",
"settings": {
"bucket": "my-opensearch-backups",
"region": "us-west-2",
"compress": true,
"chunk_size": "256mb",
"base_path": "snapshots",
"canned_acl": "private"
}
}Diese Konfiguration erstellt ein sicheres, effizientes Repository für unsere Snapshots. Die gewählten Einstellungen optimieren sowohl Sicherheit als auch Performance:
Sobald unser Repository konfiguriert ist, können wir unseren ersten Snapshot erstellen. Beginnen wir mit einem einfachen Beispiel:
PUT /_snapshot/backup_repository/snapshot_1
{
"indices": "products,orders,customers",
"ignore_unavailable": true,
"include_global_state": true,
"metadata": {
"taken_by": "system",
"taken_because": "daily_backup",
"timestamp": "2024-01-14T00:00:00Z"
}
}Dieser Befehl erstellt einen Snapshot mit wichtigen Eigenschaften:
Manuelle Snapshots sind nützlich, aber automatisierte Backups gewährleisten konsistenten Datenschutz. Implementieren wir eine umfassende Backup-Strategie.
Zunächst definieren wir eine Policy, die unseren Backup-Prozess automatisiert:
PUT /_slm/policy/daily_backup_policy
{
"schedule": "0 0 1 * * ?", // Ausführung um 1 Uhr morgens täglich
"name": "<daily-snap-{now/d}>",
"repository": "backup_repository",
"config": {
"indices": ["*"],
"ignore_unavailable": true,
"include_global_state": true,
"metadata": {
"backup_type": "daily",
"retention_days": 30
}
},
"retention": {
"expire_after": "30d",
"min_count": 5,
"max_count": 50
}
}Diese Policy implementiert mehrere Best Practices:
Die Überwachung Ihrer Backups ist entscheidend. Hier ist eine Implementierung eines umfassenden Backup-Monitorings:
PUT _plugins/_alerting/monitors/backup_monitor
{
"type": "monitor",
"name": "Backup Status Monitor",
"enabled": true,
"schedule": {
"period": {
"interval": 1,
"unit": "HOURS"
}
},
"inputs": [
{
"search": {
"indices": [".slm-history-*"],
"query": {
"bool": {
"must": [
{
"range": {
"start_time": {
"gte": "now-24h"
}
}
},
{
"term": {
"policy": "daily_backup_policy"
}
},
{
"term": {
"success": false
}
}
]
}
}
}
}
],
"triggers": [
{
"name": "Backup-Fehler-Alert",
"severity": "High",
"condition": {
"script": {
"source": "ctx.results[0].hits.total.value > 0"
}
},
"actions": [
{
"name": "Ops-Team benachrichtigen",
"destination_id": "ops_slack",
"message_template": {
"source": "Backup-Fehler erkannt für daily_backup_policy. Bitte sofort untersuchen."
}
}
]
}
]
}Recovery-Prozeduren müssen gut dokumentiert und getestet sein. Betrachten wir verschiedene Recovery-Szenarien und ihre Implementierungen.
Wenn Sie einen gesamten Cluster wiederherstellen müssen, folgen Sie diesen Schritten:
# Schritt 1: Snapshot-Verfügbarkeit prüfen
GET /_snapshot/backup_repository/snapshot_1
# Schritt 2: Indizes schließen, falls sie existieren
POST /products,orders,customers/_close
# Schritt 3: Aus Snapshot wiederherstellen
POST /_snapshot/backup_repository/snapshot_1/_restore
{
"indices": "products,orders,customers",
"include_global_state": true,
"include_aliases": true,
"ignore_unavailable": true,
"rename_pattern": "(.+)",
"rename_replacement": "restored_$1",
"index_settings": {
"index.number_of_replicas": 0
}
}
# Schritt 4: Wiederherstellungsfortschritt überwachen
GET /_recoveryFür granularere Recovery-Anforderungen können wir die Point-in-Time-Funktionalität nutzen:
# Schritt 1: Point-in-Time-ID erstellen
POST /products/_pit
{
"keep_alive": "1h"
}
# Schritt 2: PIT-ID in der Recovery verwenden
POST /products/_clone/products_recovered
{
"settings": {
"index.number_of_replicas": 0
},
"aliases": {
"products_current": {}
}
}Ein umfassender Disaster Recovery Plan beinhaltet mehrere Komponenten. Implementieren wir die wichtigsten Elemente:
Hier ein Skript zur Messung der Recovery-Zeit:
def measure_recovery_time(snapshot_name, indices):
"""
Misst die Zeit, die für die Wiederherstellung bestimmter Indizes benötigt wird.
Args:
snapshot_name: Name des wiederherzustellenden Snapshots
indices: Liste der wiederherzustellenden Indizes
Returns:
Dictionary mit Recovery-Metriken
"""
start_time = time.time()
# Recovery starten
recovery_response = client.snapshot.restore(
repository="backup_repository",
snapshot=snapshot_name,
body={
"indices": ",".join(indices),
"include_global_state": False
}
)
# Recovery-Fortschritt überwachen
while True:
recovery_status = client.indices.recovery(index=",".join(indices))
if all(shard["stage"] == "DONE"
for index in recovery_status.values()
for shard in index["shards"]):
break
time.sleep(10)
end_time = time.time()
return {
"total_time": end_time - start_time,
"indices_recovered": len(indices),
"snapshot_name": snapshot_name
}Implementieren Sie regelmäßige Recovery-Tests, um sicherzustellen, dass Ihre Backup-Strategie funktioniert:
PUT _plugins/_alerting/monitors/recovery_test_monitor
{
"type": "monitor",
"name": "Wöchentlicher Recovery-Test",
"enabled": true,
"schedule": {
"period": {
"interval": 1,
"unit": "WEEKS"
}
},
"inputs": [
{
"search": {
"indices": ["test_recovery_results*"],
"query": {
"range": {
"timestamp": {
"gte": "now-7d"
}
}
}
}
}
],
"triggers": [
{
"name": "Recovery-Test erforderlich",
"severity": "High",
"condition": {
"script": {
"source": "ctx.results[0].hits.total.value == 0"
}
},
"actions": [
{
"name": "Recovery-Test initiieren",
"destination_id": "recovery_test_webhook",
"message_template": {
"source": "Wöchentlicher Recovery-Test ist fällig. Bitte Testprozedur einleiten."
}
}
]
}
]
}Backup- und Recovery-Operationen können die Cluster-Performance beeinflussen. Implementieren wir Strategien, um diese Auswirkungen zu minimieren:
Konfigurieren Sie Throttling, um Backup-Geschwindigkeit und Cluster-Performance auszubalancieren:
PUT /_cluster/settings
{
"persistent": {
"indices.recovery.max_bytes_per_sec": "40mb",
"indices.recovery.max_concurrent_file_chunks": 2,
"indices.recovery.max_concurrent_operations": 1
}
}Planen Sie Backups während Zeiten geringer Auslastung:
PUT /_slm/policy/backup_window_policy
{
"schedule": "0 0 2 * * ?", // 2 Uhr morgens täglich
"name": "<nightly-backup-{now/d}>",
"repository": "backup_repository",
"config": {
"indices": ["*"],
"ignore_unavailable": true,
"include_global_state": true,
"metadata": {
"backup_type": "nightly",
"retention_days": 30
}
},
"retention": {
"expire_after": "30d",
"min_count": 7,
"max_count": 30
}
}Bei der Implementierung von Backup- und Recovery-Strategien sollten Sie diese Grundprinzipien beachten:
Tests und Validierung:
Performance-Management:
Sicherheitsaspekte: