Convalida dei dati e rilevamento delle modifiche

Cloud Storage ti incoraggia a convalidare i dati trasferiti da e verso i tuoi bucket. Questa pagina descrive le best practice per eseguire verifiche utilizzando i checksum CRC32C o MD5 e descrive l'algoritmo di rilevamento delle modifiche utilizzato dal comando gcloud storage rsync.

Proteggiti dal danneggiamento dei dati utilizzando hash

Esistono diversi modi in cui i dati possono essere danneggiati durante il caricamento o il download dal cloud:

  • Errori di memoria su computer client o server oppure router lungo il percorso
  • Bug software (ad es. in una libreria utilizzata dai clienti)
  • Modifiche al file di origine quando un caricamento avviene su un periodo di tempo prolungato

Cloud Storage supporta due tipi di hash che puoi utilizzare per controllare l'integrità dei tuoi dati: CRC32C e MD5. CRC32C è il metodo di convalida consigliato per eseguire i controlli di integrità. I clienti che preferiscono MD5 possono usare questo hash, ma gli hash MD5 non sono supportati per tutti gli oggetti.

Convalida lato client

Puoi eseguire un controllo dell'integrità dei dati scaricati eseguendo l'hashing dei dati nella e confrontare i risultati con i checksum forniti dal server. Tuttavia, tieni presente che i checksum forniti dal server si basino sull'oggetto completo, così come archiviati in Cloud Storage, il che significa che i seguenti tipi di download non possono essere convalidati utilizzando gli hash forniti dal server:

  • Download sottoposti a transcodifica decompressiva, a causa del il checksum fornito dal server rappresenta l'oggetto nello stato compresso, mentre ai dati pubblicati è stata rimossa la compressione e, di conseguenza, viene rimosso un hash diverso valore.

  • Una risposta contenente solo una porzione dei dati oggetto, che si verifica quando effettui una richiesta range. Cloud Storage consiglia di utilizzare le richieste di intervallo solo per riavviare il download di un oggetto completo dopo l'ultimo offset ricevuto, perché in questo caso puoi calcolare e convalidare il checksum al termine del download completo.

Se puoi convalidare il download utilizzando i checksum, devi ignorare i dati scaricati con valori hash errati e utilizzare la logica di ripetizione consigliata per riprovare a inviare la richiesta.

Convalida lato server

Cloud Storage esegue la convalida lato server nei seguenti casi:

  • Quando esegui una richiesta di copia o riscrittura in Cloud Storage.

  • Quando fornisci l'hash MD5 o CRC32C previsto di un oggetto in una richiesta di caricamento. Cloud Storage crea l'oggetto solo se l'hash fornito corrisponde al valore calcolato da Cloud Storage. Se non corrisponde, la richiesta viene rifiutata con un errore BadRequestException: 400.

    • Nelle richieste API JSON applicabili, fornisci i checksum come parte della risorsa oggetti.

    • Nelle richieste API XML applicabili, fornisci i checksum utilizzando l'intestazione x-goog-hash. L'API XML accetta anche l'intestazione Content-MD5 HTTP standard (consulta la specifica).

    • In alternativa, puoi eseguire la convalida lato client dei caricamenti di inviare una richiesta per i metadati dell'oggetto caricato, confrontando l'hash dell'oggetto caricato al valore previsto, eliminando in caso di mancata corrispondenza. Questo metodo è utile se l'oggetto MD5 o L'hash CRC32C non è noto all'inizio del caricamento.

Nel caso di caricamenti compositi paralleli, gli utenti devono eseguire un controllo di integrità per ogni caricamento del componente e poi utilizzare le precondizioni con le richieste di composizione per proteggersi dalle condizioni di gara. Componi richieste non eseguono la convalida lato server, quindi gli utenti che vogliono un'integrità end-to-end controllo deve eseguire la convalida lato client del nuovo oggetto composito.

Convalida di Google Cloud CLI

Per Google Cloud CLI, i dati sono stati copiati in o da un servizio Cloud Storage è convalidato. Questo vale per i comandi cp, mv e rsync. Se il checksum dei dati di origine non corrisponde al checksum dei dati di destinazione la gcloud CLI elimina la copia non valida e stampa un messaggio di avviso. Questo accade molto raramente. In questo caso, devi riprovare a eseguire l'operazione.

Questa convalida automatica avviene dopo che l'oggetto stesso è stato finalizzato, quindi gli oggetti non validi sono visibili per 1-3 secondi prima di essere identificati eliminati. Inoltre, è possibile che gcloud CLI vengainterrotto al termine del caricamento, ma prima dell'esecuzione della convalida, lasciandoinvariato l'oggetto non valido. Questi problemi possono essere evitati durante il caricamento singoli file in Cloud Storage utilizzando la convalida lato server, che si verifica quando si utilizza il flag --content-md5.

Rilevamento delle modifiche per rsync

Il comando gcloud storage rsync può anche utilizzare i checksum MD5 o CRC32C per determinare se esiste una differenza tra la versione di un oggetto trovata all'origine e la versione trovata nella destinazione. Il comando confronta i checksum nei seguenti casi:

  • L'origine e la destinazione sono entrambi bucket cloud e l'oggetto ha un Checksum MD5 o CRC32C in entrambi i bucket.

  • L'oggetto non ha un'ora di modifica del file (mtime) nella tabella di origine o di destinazione.

Nei casi in cui l'oggetto pertinente abbia un valore mtime sia nella destinazione che nella fonte, ad esempio quando la destinazione e la fonte sono file system, il comando rsync confronta le dimensioni e mtime degli oggetti anziché utilizzare i checksum. Analogamente, se l'origine è un bucket cloud e la destinazione è un sistema di file locale, il comando rsync utilizza l'ora di creazione dell'oggetto di origine come sostituto di mtime e non utilizza i checksum.

Se non sono disponibili né mtime né i checksum, rsync confronta solo le dimensioni dei file quando determini se c'è una variazione tra la versione di origine di un oggetto e la versione di destinazione. Ad esempio, né mtime né i checksum sono disponibili quando si confrontano oggetti compositi con oggetti di un provider cloud che non supporta CRC32C, perché gli oggetti compositi non hanno checksum MD5.

Passaggi successivi