Une liste de contrôle de récupération que vous pouvez répéter

Définir la perte et l'interruption acceptables

Notez le dernier point de récupération acceptable et le délai cible pour rétablir un service utile. Ce sont des objectifs applicatifs, pas un SLA PrivacyNodes. Si perdre une heure de données est inacceptable, une copie quotidienne seule ne peut pas atteindre cet objectif. Choisissez une méthode de sauvegarde de base de données cohérente avec votre charge de travail et votre version.

Obtenez une cible jetable, l'artefact applicatif et des identifiants de récupération autorisés via un stockage protégé. Confirmez qui approuve la restauration des données clients et comment l'environnement de test empêche le trafic extérieur. Ne restaurez pas par-dessus la base de données de production en cours d'exécution ou un répertoire existant.

Recenser l'état complet de l'application

Pour l'API de reporting, listez PostgreSQL, les téléversements, les exports non reproductibles, la configuration, les références aux clés de chiffrement, le DNS et les dépendances externes. Distinguez un cache jetable d'une file contenant du travail client à réconcilier. Une image de conteneur décrit le logiciel, pas tout l'état persistant.

Comprendre ce que la sauvegarde inclut

PostgreSQL documente les vidages logiques, les sauvegardes de système de fichiers et l'archivage continu comme des stratégies différentes. Une pg_dump archive couvre une seule base de données ; les rôles et tablespaces à l'échelle du cluster nécessitent une considération distincte. Son client ne peut pas vider un serveur d'une version majeure plus récente. Faites correspondre les versions des outils et la stratégie à l'objectif ; copier un répertoire de données en direct n'est pas automatiquement cohérent.

Inspectez une archive avant de restaurer. Sélectionner une table avec pg_restore n'inclut pas automatiquement toutes ses dépendances. Son --clean option supprime les objets existants ; une restauration en une seule transaction ne peut pas se combiner avec des tâches parallèles. Passez en revue les options pour la base de test vide spécifiquement identifiée.

Référence technique : Sauvegarde et restauration PostgreSQL · PostgreSQL pg_dump · PostgreSQL pg_restore.

Vérifier l'intégrité et restaurer indépendamment

Les vérifications de dépôt et les restaurations fonctionnelles répondent à des questions différentes. La commande ordinaire de restic check ne lit pas chaque paquet de données stocké ; check --read-data ajoute ces lectures et peut consommer une bande passante substantielle. Ni l'une ni l'autre ne prouve que l'instantané contient tout ce dont l'API a besoin.

Sélectionnez un instantané précis et un nouveau répertoire cible. Un latest sans qualification dans un dépôt partagé peut sélectionner une autre charge de travail. Une restauration peut écraser des fichiers et une interruption peut laisser des résultats partiels. Vérifiez d'abord la destination, en laissant les fichiers de production et le dépôt d'origine intacts.

Référence technique : vérifications du dépôt restic · cibles de restauration restic.

Tester le comportement restauré dans l'ordre des dépendances

Recréez l'environnement, restaurez la base de données et les téléversements correspondants, puis démarrez l'API avec des identifiants de staging. Gardez les workers en pause jusqu'à ce que leur backlog et leurs effets de bord soient compris. Désactivez les e-mails de production, les appels de paiement et les webhooks ; utilisez une destination d'export de test et ne consommez jamais la file de production.

Utilisez un compte de test connu pour lire un enregistrement, ouvrir son téléversement, vérifier les restrictions d'accès et exécuter un petit nouvel export. Vérifiez qu'un autre compte de test ne peut pas lire ses données. Comparez le point de récupération sélectionné avec le dernier enregistrement attendu. Consignez le temps de restauration réel après l'exercice ; n'écrivez pas à l'avance un résultat de succès inventé.

Résoudre la propriété des écritures avant un vrai basculement

Pendant un incident, décidez quel système peut accepter les écritures et comment les modifications ultérieures sont réconciliées. Deux copies inscriptibles peuvent diverger. Un exercice documente cette décision sans basculer le trafic réel. Supprimez les données jetables conformément à vos règles de conservation à la fin de l'exercice.

Corrigez les identifiants, dépendances et étapes de validation manquants après chaque répétition. Conservez le runbook en dehors de l'hôte d'origine et assurez-vous qu'un autre mainteneur autorisé peut le trouver. L'option de sauvegarde sélectionnable est distincte de ce processus applicatif ; confirmez la portée et les procédures de restauration dans les faits sur le service. Utilisez le fiche de version pour le déploiement qui suit.