Convalida dei dati e rilevamento delle modifiche

Cloud Storage ti incoraggia a convalidare i dati trasferiti da e verso i tuoi bucket. In questa pagina vengono descritte le best practice per ottenere utilizzando i checksum CRC32C o MD5 e descrive la modifica di rilevamento usato 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 scaricando 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 si verifica per un periodo di tempo prolungato di ora

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.

È possibile eseguire un controllo dell'integrità dei download eseguendo l'hashing dei dati scaricati sulla e confrontando i tuoi risultati con gli hash forniti dal server. Da ignorare dati scaricati con valori hash errati. Devi utilizzare la logica dei nuovi tentativi per evitare loop infiniti potenzialmente costosi.

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 alla il valore calcolato da Cloud Storage. Se non corrisponde, la richiesta viene rifiutato con un errore BadRequestException: 400.

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

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

    • In alternativa, puoi eseguire la convalida lato client dei caricamenti inviando 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 dei caricamenti compositi paralleli, gli utenti devono eseguire una dell'integrità del caricamento di ogni componente, quindi utilizza 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 vengono copiati in o da un servizio Cloud Storage è convalidato. Questo si applica ai 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 caso affermativo, 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, c'è la possibilità che gcloud CLI interrotto al termine del caricamento, ma prima della convalida, lasciando 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 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 dispone di un'ora di modifica del file (mtime) in sorgente o destinazione.

Nei casi in cui l'oggetto pertinente ha un valore mtime sia nell'origine che di destinazione, ad esempio quando l'origine e la destinazione sono file system, Il comando rsync confronta l'oggetto dimensioni e mtime, anziché utilizzare i checksum. Analogamente, se l'origine è un bucket Cloud e la destinazione è file system locale, il comando rsync utilizza l'ora creata per l'origine in sostituzione di mtime e il comando 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 disponibili quando si confrontano oggetti composti con oggetti presso un provider cloud che non supporta CRC32C, perché gli oggetti compositi non hanno checksum MD5.

Passaggi successivi