1) Gewählte Strategie

Grundlegend setzen wir auf ein 3-2-1 Backup. Das bedeutet:

• mind. 3 Kopien der Daten
• mind. 2 unterschiedliche Medien
• mind. 1 (physikalisch) externer Standort

2) Gesicherte Daten im Kontext von Q.wiki Now!

Backups beinhalten die gesamte Datenbank (Prozesse, Nutzer, Tenants, etc) sowie alle Anhänge (Dateien) von Q.wiki.

Nicht gesichert wird derzeit der Suchindex (Solr), da dieser flüchtig ist und im Notfall wiederhergestellt werden kann (Neuindizierung).

3) Sicherstellung der Strategie für die zu sichernden Daten

Allgemein werden die Datenbank und die Anhänge separat gesichert. Diese Backups sind dann für weitere 3 Monate vorgehalten.

Die Sicherung des Backups erfüllt die gewählte 3-2-1 Strategie, wie im Folgenden beschrieben:

3.1) Datenbank (Postgresql)

Indirekt wird die 3-2-1 Strategie bereits durch die Verwendung unseres S3 Clusters als Backup Ziel erreicht, vrgl. 4) Verwendeter S3 Storage
 

Realisierung

• Festplatte (PVC, PersistentVolumeClaim):
  • Daten werden durchgehend auf einem, multi-zonalen, nicht flüchtigen Speicher persistiert.
  • erzielt: weitere Kopie
• WAL Archives (WAL, Write Ahead Logs)
  • kontinuierlich werden die WAL Archivs sowohl auf die Festplatte (PVC) geschrieben, als auch in unserem S3 Bucket (offsite) persistiert.
  • erzielt: weitere Kopie, weiteres Medium (S3), weiterer Standort (RXAC, Relaix Aachen)
•  Physical Base Backup:
  • jede 2te Nacht wird eine gesamte Kopie der Datenbank erstellt und in unserem S3 Bucket (offsite) persistiert. Dieses Base-Backup dient u.a. als Ausgangspunkt zur Wiederherstellung aus WAL Archivs.
  • erzielt: weitere Kopie, weiteres Medium (S3), weiterer Standort (RXAC, Relaix Aachen)
• Nächtliche Bucket Replication
  • Durch die Verwendung des S3 Clusters werden die verwendeten S3 Buckets einmal die Nacht in ein GCS Bucket kopiert.
  • erzielt: weitere Kopie, weiteres Medium (GCS, Google Cloud Storage), weiterer Standort (Google, Frankfurt)

Fazit:

• mind. 3 Kopien der Daten:
  1. Festplatte Datenbank-Server 
  2. WAL - S3 Bucket 
  3. Base Backup - S3 Bucket
  4. GCS Bucket
• mind. 2 Medien: 
  1. PVC
  2. S3
  3. GCS (Google Cloud Storage)
• mind. 1 externen Standort:
  1. S3 (RXAC, Relaix Aachen)
  2. GCS (Google, Frankfurt)

3.2) Anhänge (S3 Bucket)

Anhänge werden gemäß der 3-2-1 Strategie gesichert, da diese in unserem S3 Cluster persistiert werden, vrgl. 4) Verwendeter S3 Storage
 

4) Verwendeter S3 Storage

Durch die Verwendung unsere S3 Clusters, unterliegen die dort persistierten Daten automatisch der 3-2-1 Backup Regel, da dieses bereits für unser S3 Cluster erfüllt wird.
 

Realisierung

• S3 File Storage:
  • Daten im S3 werden auf nicht flüchtigem Speicher persistiert
  • erzielt: weitere Kopie, weiteres Medium (NVME, Non-Volatile Memory Express)
• S3 Bucket Replication:
  • jede Nacht werden die S3 Bucket in einen weiteren, externen S3 Bucket, transferiert (geltende AVV werden hier beachtet)
  • erzielt: weitere Kopie, weiteres Medium (externer S3), weiterer Standort
• S3 Cluster Replication:
  • kontinuierlich wird unser S3 Cluster in einen weiteren Brandabschnitt repliziert
  • erzielt: weitere Kopie, weiterer Standort (RXAC Brandabschnitt 2)

Fazit:

• mind. 3 Kopien der Daten:
  1. File Storage auf NVME
  2. Bucket Replicaion
  3. Cluster Replication
• mind. 2 Medien: 
  1. NVME
  2. externer S3
• mind. 1 externen Standort:
  1. S3 (RXAC, Brandabschnitt 1)
  2. S3 (RXAC, Brandabschnitt 2)
  3. externes S3 Bucket