Skip to main content
Un punto di recovery CaseBender è PostgreSQL più ogni versione esatta di oggetto referenziata, la configurazione e le chiavi crittografiche. Un dump del database o una copia del bucket da soli non costituiscono un set di recovery valido.

​
Contenuti del set di recovery

  • uno snapshot/dump PostgreSQL e l’identificatore di migrazione;
  • ogni StoredObject finalizzato non eliminato al suo profileKey, objectKey e providerVersion registrati;
  • SHA-256 e dimensione per ciascun oggetto;
  • profilo di backup, chiave oggetto di backup e versione esatta di backup;
  • versioni di configurazione di storage/identità/CA;
  • chiavi di campo, credenziali, audit-integrity, autenticazione e firma;
  • digest immutabili delle immagini CaseBender e manifesto della release; e
  • timestamp, approvazioni, versioni degli strumenti, RPO/RTO misurati e digest delle evidenze.
Crittografa il set, limita l’accesso e conservalo in modo indipendente dal dominio di guasto primario. Non scrivere credenziali o contenuti degli oggetti nei log di backup.

​
Acquisisci un punto di consistenza

Metti in quiescenza le write di utenti/integrazioni oppure usa un metodo di snapshot provider/database che garantisca un confine di consistenza equivalente. Svuota o metti in pausa in modo persistente i worker. Registra lo snapshot/LSN PostgreSQL e le versioni esatte degli oggetti prima di riprendere. Genera l’inventory degli oggetti:
Il comando esegue una transazione di database serializable e rifiuta gli oggetti senza metadata di versione esatta, SHA-256 o dimensione. Non copia i byte; il processo di backup approvato deve popolare backupProfileKey, backupObjectKey e backupVersionId per ogni voce del manifesto. Calcola l’hash e proteggi il manifesto completato:

​
Policy di copia

Copia prima e conserva il primario. Non usare mai un’operazione di sincronizzazione distruttiva come primo passo di backup o migrazione. Verifica i byte scaricando e calcolando SHA-256; non fare affidamento sugli ETag. Preserva tutte le versioni storiche richieste e lo stato di retention/hold. Una copia oggetto ordinaria potrebbe non preservare ACL specifici del provider, CMEK, Object Lock, immutabilità, legal hold, hold basato su eventi, metadata o cronologia delle versioni. Attesta e riproduci tali controlli nella destinazione.

​
Verifica di ripristino isolata

Ripristina PostgreSQL in un ambiente isolato usando la stessa release CaseBender compatibile. Assicurati che la migrazione del database del manifesto e i metadata degli oggetti memorizzati coincidano, quindi ripristina gli oggetti su un prefisso di verifica dedicato:
Lo script legge ciascuna versione esatta di backup, verifica dimensione e SHA-256, carica sul target isolato, lo scarica e verifica di nuovo SHA-256. Scrive il file di evidenze con modalità 0600. Pulisci il prefisso isolato attraverso il processo approvato consapevole della retention dopo la revisione delle evidenze. Quindi verifica login, organizzazioni, casi, evidenze, allegati, export, stato dello scanner, retention, legal hold, integrità della catena di audit e autorizzazione. Non connettere mai una prova alle integrazioni di produzione.

​
Avvertenze sui provider

​
S3 e Ceph RGW

Acquisisci gli ID di versione e tutti i delete marker. Object Lock deve esistere quando il bucket viene creato e non può essere inferito da un adapter. Un oggetto copiato può ricevere una nuova versione e uno stato di retention. Usa la versione esatta del prodotto certificato e la CA privata durante il ripristino.

​
Google Cloud Storage

Acquisisci le generation numeriche. Valida il lock della retention-policy, la object retention, gli hold basati su eventi, l’accesso CMEK, l’accesso uniforme al bucket e la prevenzione dell’accesso pubblico. I numeri di generation cambiano quando vengono copiati in un altro bucket.

​
Azure Blob Storage

Acquisisci gli ID di versione dei blob. Valida il trasferimento sicuro, il versioning di account/container, le chiavi di crittografia, la policy di immutabilità e i legal hold. Le versioni ripristinate ricevono ID specifici della destinazione.

​
Local o MinIO legacy

Lo storage local non è un target di produzione. Conserva sia gli snapshot del volume MinIO legacy sia gli export esatti degli oggetti a livello API durante la migrazione; non importare mai il layout interno di MinIO come file ordinari.

​
Evidenze RPO e RTO

Registra:
  • ultima transazione di database inclusa e versione dell’oggetto;
  • prima transazione esclusa;
  • durata del backup, durata del ripristino, durata della validazione e tempo di ripresa del servizio;
  • intervallo effettivo di perdita dati (RPO) e durata del recovery (RTO);
  • oggetti mancanti, modificati, illeggibili, in hold o bloccati da policy; e
  • esito dell’esercizio di rollback.
Un target di policy non è evidenza. Conserva i risultati misurati per ogni train di release supportato e dopo modifiche sostanziali allo storage. Vedi Migrazione dello storage per cutover e rollback e Backup e recovery per il più ampio set di recovery dell’installazione.