Extend lessons learnt

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