From f640a29b159cd72778ee9e772709d9d0ff3eefe2 Mon Sep 17 00:00:00 2001 From: Dominik George <dominik.george@teckids.org> Date: Fri, 19 Jul 2024 23:21:39 +0200 Subject: [PATCH] Extend lessons learnt --- .../2024/07/2024-07-19_downtime-bericht/index.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) 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 60f1abd5..9b4692d3 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 -- GitLab