# CNPG disaster recovery plan

Liens :
- [Intervention expert CNPG](https://hackmd.io/-JCVI6PfT_2qcjHZcQuK-A)
- [Problématiques CNPG](https://hackmd.io/g2869JZFTISBcOYFVPRzAA)
- [Workshops CNPG](https://hackmd.io/SEmz7p5WSgGCReX_cHowNQ)

## Problèmes d'instabilité cluster

### n replicas tombent

- pod qui plante : replica ou master
- géré tout seul : OK

**Si pas géré auto** :
- kill pvc + replica : par ex quand error de reload de WAL lors de l'init du replica quand on a conservé le volume

1. Suppression du PVC dans k9s
2. La suppression du PVC se met en attente
3. Ceci provisionne un nouveau replica (pod qui pop)
4. Une fois le nouveau pod monté, il faut supprimer l'ancien replica attaché au PVC

### 1 master tombe

- promote automatique (inch'allah)
- doute : une fois qu'un des replicas a été promoted master, je crois qu'il faut supprimer l'ancien master avec la même procédure (pvc + pod)

### 1 master plus un replica tombent (le replica peut etre celui qui est synchro ou celui qui est désynchro)

Problèmes :
- 2 noeuds kubes qui tombent
- ou 1 noeud + problème réseau

observation :
- cas où failover de master entrainant l'apparition de 2 masters simultanés (split brain ?)

deux solutions possibles en fonction des cas :
- en premier lieu : tenter d'effectuer un dump sur le dernier replica vivant
- Les WAL sont valides: repartir WAL et vérifier que les data sont correctes
- Un dump sur le replica: Si les WAL sont compromis, repartir d'un dump (avec perte de données potentielles)
- Le mieux est de comparer les données du WAL et du dump sur le replica
- Si tout ça ne fonctionne pas ... repartir d'un dump nocturne classique

## Mauvaise config

### Backups non/mal configurées

use case :
- backup activées (WAL) mais pb de config :
- mauvais secret
- mauvais S3
- mauvais nom de backup (Kontinuous)

conséquence :
- remplissage du disque
- plante tout

solution : configurer les backups (et créer le bucket sur terraform si besoin)
- secret pas dispo: remettre le secret dans le namespace
- bucket pas dispo: activer l'accès au bucket (attention si le bucket n'est pas dispo les WAL sont écris dans le blockStorage qui peut potentiellement saturer)
- utilisation d'un nom de backup précédent: suppression du cluster, modifier le backupname dans Kontinuous et redéployer le cluster

## Restaurer un cluster

- nouveau nom de backup (on utilise la date)
- en dev/preprod à chaque commit : disable backups + restore sur un bucket s3 de prod (TOFIX -> cdtn et 1000jours)
- CDTN / 1000jours : Les clusters sont détruits a chaque mise en dev et en preprod, pour pouvoir repartir avec une DB issue de la prod (ceci est un bon exemple de comment restaurer un cluster en prod)

## Password modifié (pourquoi ?)

Observation :
- le mot de passe de pg a été modifié et n'est plus celui du secret

Cas :
- cas : enfants du spectacle

Résolution :
- reset password avec la valeur du secret à la mano (faire un ALTER du password dans la DB).