diff --git a/content/blog/2024/07/2024-07-19_downtime-bericht/index.md b/content/blog/2024/07/2024-07-19_downtime-bericht/index.md index 60f1abd56239085572718eabf6370bf6c99a7c80..9b4692d3edb78407153cbf0627c3e501cec04b2b 100644 --- a/content/blog/2024/07/2024-07-19_downtime-bericht/index.md +++ b/content/blog/2024/07/2024-07-19_downtime-bericht/index.md @@ -302,12 +302,23 @@ Insbesondere seien aber folgende Punkte hervorzuheben: Architektur bereits Datenintegrität im Kern enthält, eine ernsthafte Alternative sein * Beim Recovery von PostgreSQL aus WAL-Archiven sollte direkt beachtet werden, korrupte Segmente, die nach einem Katastrophenfall angefallen sind, nicht mit zu recovern -* +* Es sollte einen dokumentierten Mechanismus geben, um Kernkomponenten wie das SSO unabhängig + von anderen Diensten zu starten Zum Vorgehen unserer Datenbank-Restoration möchten wir außerdem anmerken, dass die von uns ausgeführten manuellen Reparaturarbeiten eine gute Kenntnis der entsprechenden Anwendung erfordern. Die Gefahr von weiterem Datenverlust ist hoch. +Einige Entscheidungen, die wir gezielt für unsere Infrastruktur getroffen hatten, haben +sich aber auch als sehr hilfreich und weitsichtig herausgestellt: + +* Alle Anwendungen haben ihre Nutzdaten ausschließlich im PostgreSQL-Cluster sowie + entweder in einem *CephFS*-Volume oder im *S3-Object-Storage*. Dadurch waren keine + Nutzdaten auerhalb von PostgreSQL betroffen. +* Backups werden zwar (noch) im selben Rack, jedoch auf vollständig getrennte Hardware + und auf einfachen Storage gemacht. So stellen Komplexitäten wie die von Ceph keine + Risiken für das Backup dar. + ## Weitere Tätigkeiten und Aussicht nach dem Ausfall Nachdem der Ausfall weitestgehend behoben war, konnten wir den Ausbau des Storages