Skip to main content
Un point de reprise CaseBender est PostgreSQL plus chaque version exacte d’objet référencée, la configuration et les clés cryptographiques. Un dump de base de données ou une copie de bucket, à eux seuls, ne constituent pas un ensemble de reprise valide.

​
Contenu de l’ensemble de reprise

  • un instantané/dump PostgreSQL et un identifiant de migration ;
  • chaque StoredObject finalisé non supprimé à son profileKey, objectKey et providerVersion enregistrés ;
  • SHA-256 et taille pour chaque objet ;
  • profil de sauvegarde, clé d’objet de sauvegarde et version exacte de sauvegarde ;
  • versions de configuration de stockage/identité/CA ;
  • clés de champ, d’identifiants, d’intégrité d’audit, d’authentification et de signature ;
  • digests d’image CaseBender immuables et manifeste de version ; et
  • horodatage, approbations, versions d’outils, RPO/RTO mesurés et digest de preuves.
Chiffrez l’ensemble, restreignez l’accès et stockez-le indépendamment du domaine de défaillance primaire. N’écrivez pas d’identifiants ni de contenus d’objets dans les journaux de sauvegarde.

​
Capturer un point de cohérence

Mettez au repos les écritures utilisateur/intégration ou utilisez une méthode d’instantané fournisseur/base de données qui garantit une frontière de cohérence équivalente. Videz ou mettez en pause durablement les workers. Enregistrez l’instantané/LSN PostgreSQL et les versions exactes des objets avant de reprendre. Générez l’inventaire d’objets :
La commande exécute une transaction de base de données sérialisable et refuse les objets sans version exacte, SHA-256 ou métadonnées de taille. Elle ne copie pas les octets ; le processus de sauvegarde approuvé doit renseigner backupProfileKey, backupObjectKey et backupVersionId pour chaque entrée du manifeste. Hachez et protégez le manifeste terminé :

​
Politique de copie

Copiez d’abord et conservez le primaire. N’utilisez jamais une opération de synchronisation destructive comme première étape de sauvegarde ou de migration. Vérifiez les octets en téléchargeant et en calculant le SHA-256 ; ne vous fiez pas aux ETags. Préservez toutes les versions historiques requises et l’état de rétention/conservation. Une copie d’objet ordinaire peut ne pas préserver l’ACL spécifique au fournisseur, CMEK, Object Lock, l’immuabilité, la conservation légale, la conservation événementielle, les métadonnées ou l’historique de versions. Attestez et reproduisez ces contrôles à la destination.

​
Vérification de restauration isolée

Restaurez PostgreSQL dans un environnement isolé en utilisant la même version CaseBender compatible. Assurez-vous que la migration de base de données du manifeste et les métadonnées d’objets stockés correspondent, puis restaurez les objets vers un préfixe de vérification dédié :
Le script lit chaque version de sauvegarde exacte, vérifie la taille et le SHA-256, téléverse vers la cible isolée, la retélécharge et vérifie à nouveau le SHA-256. Il écrit le fichier de preuves avec le mode 0600. Nettoyez le préfixe isolé via le processus approuvé tenant compte de la rétention après revue des preuves. Vérifiez ensuite la connexion, les organisations, les dossiers, les preuves, les pièces jointes, les exports, l’état du scanner, la rétention, la conservation légale, l’intégrité de la chaîne d’audit et l’autorisation. Ne connectez jamais une répétition aux intégrations de production.

​
Mises en garde des fournisseurs

​
S3 et Ceph RGW

Capturez les ID de version et tous les marqueurs de suppression. Object Lock doit exister à la création du bucket et ne peut pas être inféré à partir d’un adaptateur. Un objet copié peut recevoir une nouvelle version et un nouvel état de rétention. Utilisez la version produit certifiée exacte et la CA privée pendant la restauration.

​
Google Cloud Storage

Capturez les générations numériques. Validez le verrouillage de politique de rétention, la rétention d’objet, les conservations événementielles, l’accès CMEK, l’accès uniforme aux buckets et la prévention d’accès public. Les numéros de génération changent lors de la copie vers un autre bucket.

​
Azure Blob Storage

Capturez les ID de version de blob. Validez le transfert sécurisé, le versioning de compte/conteneur, les clés de chiffrement, la politique d’immuabilité et les conservations légales. Les versions restaurées reçoivent des ID spécifiques à la destination.

​
Local ou MinIO héritage

Le stockage local n’est pas une cible de production. Préservez à la fois les instantanés de volume MinIO héritage et les exports d’objets exacts au niveau API pendant la migration ; n’importez jamais la disposition interne MinIO comme fichiers ordinaires.

​
Preuves RPO et RTO

Enregistrez :
  • la dernière transaction de base de données et version d’objet incluses ;
  • la première transaction exclue ;
  • la durée de sauvegarde, la durée de restauration, la durée de validation et l’heure de reprise de service ;
  • l’intervalle réel de perte de données (RPO) et la durée de reprise (RTO) ;
  • les objets manquants, modifiés, illisibles, conservés ou bloqués par politique ; et
  • le résultat de l’exercice de rollback.
Une cible de politique n’est pas une preuve. Conservez les résultats mesurés pour chaque train de versions supporté et après les changements matériels de stockage. Voir Migration du stockage pour la bascule et le rollback et Sauvegarde et reprise pour l’ensemble de reprise plus large de l’installation.