Gewählte Strategie
Wir setzen auf das 3-2-1-Backup-Konzept. Das bedeutet:
- Mindestens 3 Kopien der Daten
- Mindestens 2 unterschiedliche Speichermedien
- Mindestens 1 physisch externer Standort
Gesicherte Daten
Backups umfassen die gesamte Datenbank (Prozesse, Nutzer, Mandanten etc.) sowie alle Anhänge (Dateien) aus Q.wiki.
Der Suchindex (Solr) wird nicht gesichert, da er flüchtig ist und im Notfall durch eine Neuindizierung wiederhergestellt werden kann.
Umsetzung der Backup-Strategie
Datenbank und Anhänge werden separat gesichert. Alle Backups werden für 3 Monate vorgehalten.
Die 3-2-1-Strategie wird für beide Datenkategorien wie folgt erfüllt:
Datenbank (PostgreSQL)
Die 3-2-1-Strategie wird indirekt bereits durch die Nutzung unseres S3-Clusters als Backup-Ziel erreicht (siehe Abschnitt „Verwendeter S3-Storage").
Realisierung
- Festplatte (PVC – PersistentVolumeClaim)
- Daten werden kontinuierlich auf einem multi-zonalen, nicht flüchtigen Speicher persistiert.
- Erreicht: weitere Datenkopie
- WAL-Archive (Write Ahead Logs)
- WAL-Archive werden kontinuierlich sowohl auf die Festplatte (PVC) als auch in unseren S3-Bucket (offsite) geschrieben.
- Erreicht: weitere Datenkopie · weiteres Medium (S3) · weiterer Standort (RXAC, Relaix Aachen)
- Physical Base Backup
- Jede zweite Nacht wird eine vollständige Kopie der Datenbank erstellt und in unserem S3-Bucket (offsite) gespeichert. Dieses Base-Backup dient als Ausgangspunkt für die Wiederherstellung aus WAL-Archiven.
- Erreicht: weitere Datenkopie · weiteres Medium (S3) · weiterer Standort (RXAC, Relaix Aachen)
- Nächtliche Bucket-Replikation
- Die S3-Buckets werden einmal pro Nacht in ein GCS-Bucket kopiert.
- Erreicht: weitere Datenkopie · weiteres Medium (GCS – Google Cloud Storage) · weiterer Standort (Google, Frankfurt)
Zusammenfassung
| Kriterium | Umsetzung |
|---|---|
| ≥ 3 Datenkopien | 1. Festplatte (DB-Server) · 2. WAL – S3-Bucket · 3. Base Backup – S3-Bucket · 4. GCS-Bucket |
| ≥ 2 Speichermedien | 1. PVC · 2. S3 · 3. GCS (Google Cloud Storage) |
| ≥ 1 externer Standort | 1. S3 (RXAC, Relaix Aachen) · 2. GCS (Google, Frankfurt) |
Anhänge (S3-Bucket)
Anhänge werden gemäß der 3-2-1-Strategie gesichert, da sie in unserem S3-Cluster persistiert werden (siehe Abschnitt „Verwendeter S3-Storage").
Verwendeter S3-Storage
Durch die Nutzung unseres S3-Clusters unterliegen alle dort gespeicherten Daten automatisch der 3-2-1-Backup-Regel.
Realisierung
- S3 File Storage
- Daten werden auf nicht flüchtigem Speicher persistiert.
- Erreicht: weitere Datenkopie · weiteres Medium (NVMe – Non-Volatile Memory Express)
- S3-Bucket-Replikation
- Jede Nacht werden die S3-Buckets in einen weiteren, externen S3-Bucket übertragen. Geltende Auftragsverarbeitungsverträge (AVV) werden dabei berücksichtigt.
- Erreicht: weitere Datenkopie · weiteres Medium (externer S3) · weiterer Standort
- S3-Cluster-Replikation
- Unser S3-Cluster wird kontinuierlich in einen weiteren Brandabschnitt repliziert.
- Erreicht: weitere Datenkopie · weiterer Standort (RXAC, Brandabschnitt 2)
Zusammenfassung
| Kriterium | Umsetzung |
|---|---|
| ≥ 3 Datenkopien | 1. File Storage auf NVMe · 2. Bucket-Replikation · 3. Cluster-Replikation |
| ≥ 2 Speichermedien | 1. NVMe · 2. Externer S3 |
| ≥ 1 externer Standort | 1. S3 (RXAC, Brandabschnitt 1) · 2. S3 (RXAC, Brandabschnitt 2) · 3. Externes S3-Bucket |
War dieser Artikel hilfreich?
Das ist großartig!
Vielen Dank für das Feedback
Leider konnten wir nicht helfen
Vielen Dank für das Feedback
Feedback gesendet
Wir wissen Ihre Bemühungen zu schätzen und werden versuchen, den Artikel zu korrigieren