Skip to main content
Un punto de recuperación de CaseBender es PostgreSQL más cada versión exacta de objeto referenciada, la configuración y las claves criptográficas. Un volcado de base de datos o una copia de bucket por sí solos no son un conjunto de recuperación válido.

​
Contenido del conjunto de recuperación

  • una instantánea/volcado de PostgreSQL y el identificador de migración;
  • cada StoredObject finalizado no eliminado en su profileKey, objectKey y providerVersion registrados;
  • SHA-256 y tamaño de cada objeto;
  • perfil de copia de seguridad, clave de objeto de copia de seguridad y versión exacta de la copia de seguridad;
  • versiones de configuración de almacenamiento/identidad/CA;
  • claves de campo, credenciales, integridad de auditoría, autenticación y firma;
  • digests inmutables de imagen de CaseBender y manifiesto de la versión; y
  • marca de tiempo, aprobaciones, versiones de herramientas, RPO/RTO medidos y digest de evidencia.
Cifre el conjunto, restrinja el acceso y almacénelo de forma independiente del dominio de fallo primario. No escriba credenciales ni contenidos de objeto en los registros de copia de seguridad.

​
Capturar un punto de consistencia

Detenga las escrituras de usuario/integración o use un método de instantánea del proveedor/base de datos que garantice un límite de consistencia equivalente. Drene o pause de forma durable los workers. Registre la instantánea/LSN de PostgreSQL y las versiones exactas de objeto antes de reanudar. Genere el inventario de objetos:
El comando ejecuta una transacción de base de datos serializable y rechaza objetos sin versión exacta, SHA-256 o metadatos de tamaño. No copia los bytes; el proceso de copia de seguridad aprobado debe rellenar backupProfileKey, backupObjectKey y backupVersionId para cada entrada del manifiesto. Calcule el hash y proteja el manifiesto completado:

​
Política de copia

Copie primero y retenga el primario. Nunca use una operación de sincronización destructiva como primer paso de copia de seguridad o migración. Verifique los bytes descargándolos y calculando SHA-256; no confíe en los ETag. Preserve todas las versiones históricas requeridas y el estado de retención/retención legal. Una copia ordinaria de objeto puede no preservar ACL específicas del proveedor, CMEK, Object Lock, inmutabilidad, retención legal, retención basada en eventos, metadatos o historial de versiones. Ateste y reproduzca esos controles en el destino.

​
Verificación aislada de restauración

Restaure PostgreSQL en un entorno aislado usando la misma versión compatible de CaseBender. Asegúrese de que la migración de la base de datos del manifiesto y los metadatos de objetos almacenados coincidan y, a continuación, restaure los objetos a un prefijo de verificación dedicado:
El script lee cada versión exacta de la copia de seguridad, verifica el tamaño y el SHA-256, la carga al destino aislado, la descarga y verifica el SHA-256 de nuevo. Escribe el archivo de evidencia con modo 0600. Limpie el prefijo aislado mediante el proceso aprobado consciente de la retención después de la revisión de la evidencia. A continuación, verifique el inicio de sesión, las organizaciones, los casos, la evidencia, los adjuntos, las exportaciones, el estado del escáner, la retención, la retención legal, la integridad de la cadena de auditoría y la autorización. Nunca conecte un ensayo a integraciones de producción.

​
Advertencias por proveedor

​
S3 y Ceph RGW

Capture los ID de versión y todos los delete markers. Object Lock debe existir cuando se crea el bucket y no puede inferirse de un adaptador. Un objeto copiado puede recibir una versión nueva y un estado de retención nuevo. Use la versión exacta del producto certificado y la CA privada durante la restauración.

​
Google Cloud Storage

Capture las generaciones numéricas. Valide el bloqueo de política de retención, la retención de objetos, las retenciones basadas en eventos, el acceso CMEK, el acceso uniforme al bucket y la prevención de acceso público. Los números de generación cambian al copiarse a otro bucket.

​
Azure Blob Storage

Capture los ID de versión de blob. Valide la transferencia segura, el versionado de cuenta/contenedor, las claves de cifrado, la política de inmutabilidad y las retenciones legales. Las versiones restauradas reciben ID específicos del destino.

​
Local o MinIO heredado

El almacenamiento local no es un destino de producción. Preserve tanto las instantáneas de volumen de MinIO heredado como las exportaciones exactas de objeto a nivel de API durante la migración; nunca importe el diseño interno de MinIO como archivos ordinarios.

​
Evidencia de RPO y RTO

Registre:
  • la última transacción de base de datos y versión de objeto incluidas;
  • la primera transacción excluida;
  • la duración de la copia de seguridad, la duración de la restauración, la duración de la validación y el momento de reanudación del servicio;
  • el intervalo real de pérdida de datos (RPO) y la duración de la recuperación (RTO);
  • objetos faltantes, cambiados, ilegibles, retenidos o bloqueados por política; y
  • el resultado del ejercicio de reversión.
Un objetivo de política no es evidencia. Conserve los resultados medidos para cada tren de versión soportado y después de cambios materiales de almacenamiento. Consulte Migración de almacenamiento para la conmutación y la reversión, y Copia de seguridad y recuperación para el conjunto más amplio de recuperación de la instalación.