Convalida dei dati e rilevamento delle modifiche

Cloud Storage ti incoraggia a convalidare i dati che trasferisci nei e dai 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.

Proteggere dai danni ai dati utilizzando gli hash

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

  • Errori di memoria sui computer client o server o sui 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 verificare l'integrità degli tuoi dati: CRC32C e MD5. CRC32C è il metodo di convalida consigliato per eseguire i controlli di integrità. I clienti che preferiscono MD5 possono utilizzare questo hash, ma gli hash MD5 non sono supportati per tutti gli oggetti.

Convalida lato client

Puoi eseguire un controllo di integrità dei dati scaricati sottoponendoli ad hashing al volo e confrontando i risultati con i checksum forniti dal server. Tieni però presente che i checksum forniti dal server si basano sull'oggetto completo così come è memorizzato in Cloud Storage, il che significa che i seguenti tipi di download non possono essere convalidati utilizzando gli hash forniti dal server:

  • I download sottoposti a transcodifica decompressiva, perché il controllo di somma fornito dal server rappresenta l'oggetto nel suo stato compresso, mentre i dati serviti hanno la compressione rimossa e, di conseguenza, un valore di hash diverso.

  • Una risposta che contiene solo una parte dei dati dell'oggetto, che si verifica quando viene effettuata 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 inviando una richiesta per i metadati dell'oggetto caricato, confrontando il valore hash dell'oggetto caricato con il valore previsto ed eliminando l'oggetto in caso di mancata corrispondenza. Questo metodo è utile se l'hash MD5 o CRC32C dell'oggetto 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. Le richieste di composizione non eseguono la convalida lato server, pertanto gli utenti che vogliono un controllo di integrità end-to-end devono eseguire la convalida lato client sul nuovo oggetto composito.

Convalida di Google Cloud CLI

Per Google Cloud CLI, i dati copiati in o da un bucket Cloud Storage vengono convalidati. Questo vale per i comandi cp, mv e rsync. Se il controllo di somma dei dati di origine non corrisponde a quello dei dati di destinazione, gcloud CLI elimina la copia non valida e stampa un messaggio di avviso. Questo accade molto raramente. In questo caso, dovresti riprovare a eseguire l'operazione.

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

Modificare il rilevamento 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 quella trovata nella destinazione. Il comando confronta i checksum nei seguenti casi:

  • La sorgente e la destinazione sono entrambi bucket cloud e l'oggetto ha un controllo MD5 o CRC32C in entrambi i bucket.

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

Nei casi in cui l'oggetto pertinente abbia un valore mtime sia nella destinazione sia nella sorgente, ad esempio quando la sorgente e la destinazione 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 per determinare se esiste una differenza 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