Validasi data dan deteksi perubahan

Cloud Storage menyarankan Anda untuk memvalidasi data yang ditransfer ke dan dari bucket. Halaman ini menjelaskan praktik terbaik untuk melakukan validasi menggunakan checksum CRC32C atau MD5 dan menjelaskan algoritma deteksi perubahan yang digunakan oleh perintah gcloud storage rsync.

Melindungi dari kerusakan data menggunakan hash

Ada berbagai penyebab kerusakan data saat mengupload ke atau mendownload dari Cloud:

  • Error memori pada komputer klien atau server, atau router di sepanjang jalur
  • Bug software (misalnya, di library yang digunakan pelanggan)
  • Perubahan pada file sumber saat upload terjadi dalam jangka waktu yang lebih panjang

Cloud Storage mendukung dua jenis hash yang dapat Anda gunakan untuk memeriksa integritas data: CRC32C dan MD5. CRC32C adalah metode validasi yang direkomendasikan untuk melakukan pemeriksaan integritas. Pelanggan yang memilih MD5 dapat menggunakan hash tersebut, tetapi hash MD5 tidak didukung untuk semua objek.

Validasi sisi klien

Anda dapat melakukan pemeriksaan integritas untuk data yang didownload dengan melakukan hashing pada data dengan cepat dan membandingkan hasilnya dengan checksum yang disediakan server. Namun, perlu diperhatikan bahwa checksum yang disediakan server didasarkan pada objek lengkap seperti yang disimpan di Cloud Storage, yang berarti jenis download berikut tidak dapat divalidasi menggunakan hash yang disediakan server:

  • Download yang mengalami transkode dekompresi, karena checksum yang disediakan server mewakili objek dalam status terkompresi, sedangkan data yang ditayangkan telah menghapus kompresi sehingga nilai hash-nya berbeda.

  • Respons yang hanya berisi sebagian data objek, yang terjadi saat membuat permintaan range. Cloud Storage merekomendasikan penggunaan permintaan rentang hanya untuk memulai ulang download objek lengkap setelah offset terakhir diterima, karena dalam hal ini Anda dapat menghitung dan memvalidasi checksum saat download lengkap selesai.

Jika Anda dapat memvalidasi download menggunakan checksum, Anda harus menghapus data yang didownload dengan nilai hash yang salah dan menggunakan logika percobaan ulang yang direkomendasikan untuk mencoba ulang permintaan.

Validasi sisi server

Cloud Storage melakukan validasi sisi server dalam kasus berikut:

  • Saat Anda membuat permintaan penyalinan atau penulisan ulang dalam Cloud Storage.

  • Saat memberikan hash MD5 atau CRC32C yang diharapkan dari objek dalam permintaan upload. Cloud Storage hanya membuat objek jika hash yang Anda berikan cocok dengan nilai yang dihitung Cloud Storage. Jika tidak cocok, permintaan akan ditolak dengan error BadRequestException: 400.

    • Dalam permintaan JSON API yang berlaku, Anda menyediakan checksum sebagai bagian dari resource objek.

    • Dalam permintaan XML API yang berlaku, Anda memberikan checksum menggunakan header x-goog-hash. XML API juga menerima header Content-MD5 HTTP standar (lihat spesifikasi).

    • Atau, Anda dapat melakukan validasi sisi klien atas upload dengan mengajukan permintaan untuk metadata objek yang diupload, membandingkan nilai hash objek yang diupload dengan nilai yang diharapkan, dan menghapus objek jika ada ketidakcocokan. Metode ini berguna jika hash MD5 atau CRC32C objek tidak diketahui di awal upload.

Dalam kasus upload gabungan paralel, pengguna harus melakukan pemeriksaan integritas untuk setiap upload komponen, lalu menggunakan prasyarat dengan permintaan compose untuk melindungi dari kondisi race. Permintaan Compose tidak melakukan validasi sisi server, sehingga pengguna yang menginginkan pemeriksaan integritas menyeluruh harus melakukan validasi sisi klien pada objek gabungan baru.

Validasi Google Cloud CLI

Untuk Google Cloud CLI, data yang disalin ke atau dari bucket Cloud Storage akan divalidasi. Hal ini berlaku untuk perintah cp, mv, dan rsync. Jika checksum data sumber tidak cocok dengan checksum data tujuan, gcloud CLI akan menghapus salinan yang tidak valid dan mencetak pesan peringatan. Ini sangat jarang terjadi. Jika ya, Anda harus mencoba kembali operasi tersebut.

Validasi otomatis ini terjadi setelah objek tersebut selesai, sehingga objek yang tidak valid akan terlihat selama 1-3 detik sebelum diidentifikasi dan dihapus. Selain itu, ada kemungkinan gcloud CLI dapat terganggu setelah upload selesai, tetapi sebelum melakukan validasi, sehingga objek yang tidak valid tetap pada tempatnya. Masalah ini dapat dihindari saat mengupload file tunggal ke Cloud Storage menggunakan validasi sisi server, yang terjadi saat menggunakan flag --content-md5.

Mengubah deteksi untuk rsync

Perintah gcloud storage rsync juga dapat menggunakan checksum MD5 atau CRC32C untuk menentukan apakah ada perbedaan antara versi objek yang ditemukan di sumber dan versi yang ditemukan di tujuan. Perintah ini membandingkan checksum dalam kasus berikut:

  • Sumber dan tujuan adalah bucket cloud dan objek memiliki checksum MD5 atau CRC32C di kedua bucket.

  • Objek tidak memiliki waktu modifikasi file (mtime) di sumber atau tujuan.

Jika objek yang relevan memiliki nilai mtime di sumber dan tujuan, seperti saat sumber dan tujuan adalah sistem file, perintah rsync akan membandingkan ukuran objek dan mtime, bukan menggunakan checksum. Demikian pula, jika sumbernya adalah bucket cloud dan tujuannya adalah sistem file lokal, perintah rsync menggunakan waktu yang dibuat untuk objek sumber sebagai pengganti mtime, dan perintah tersebut tidak menggunakan checksum.

Jika mtime atau checksum tidak tersedia, rsync hanya membandingkan ukuran file saat menentukan apakah ada perubahan antara versi sumber objek dan versi tujuan. Misalnya, mtime maupun checksum tidak tersedia saat membandingkan objek gabungan dengan objek di penyedia cloud yang tidak mendukung CRC32C, karena objek gabungan tidak memiliki checksum MD5.

Langkah selanjutnya