Validasi data dan deteksi perubahan

Cloud Storage mendorong Anda untuk memvalidasi data yang ditransfer ke dan dari bucket Anda. Halaman ini menjelaskan praktik terbaik untuk menjalankan validasi menggunakan checksum CRC32C atau MD5 dan menjelaskan 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 lebih memilih MD5 dapat menggunakan {i>hash<i} itu, 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 di terbang dan membandingkan hasil Anda dengan {i>checksum<i} yang disediakan oleh server. Namun, perhatikan bahwa {i>checksum<i} yang disediakan server didasarkan pada objek lengkap karena disimpan di Cloud Storage, yang berarti jenis download berikut tidak dapat divalidasi menggunakan {i>hash<i} yang disediakan server:

  • Download yang menjalani transcoding dekompresi, karena {i>checksum<i} yang disediakan server mewakili objek dalam keadaan terkompresi, sementara data yang disajikan telah dihapus kompresinya dan akibatnya {i>hash<i} yang berbeda dengan sejumlah nilai.

  • Respons yang hanya berisi sebagian data objek, yang terjadi saat membuat permintaan range. Cloud Storage merekomendasikan penggunaan rentang hanya permintaan untuk memulai ulang download objek lengkap setelah download menerima offset, karena dalam kasus tersebut Anda dapat menghitung dan memvalidasi {i>checksum<i} ketika pengunduhan lengkap selesai.

Jika Anda dapat memvalidasi download menggunakan {i>checksum<i}, Anda harus membuang yang didownload dengan nilai {i>hash<i} yang salah dan menggunakan logika percobaan ulang yang direkomendasikan untuk mencoba lagi 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 menyediakan checksum menggunakan Header x-goog-hash. XML API juga menerima HTTP standar Header Content-MD5 (lihat spesifikasi).

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

Dalam kasus upload komposit paralel, pengguna harus melakukan pemeriksaan integritas untuk setiap upload komponen, lalu gunakan prakondisi dengan permintaan compose untuk melindunginya dari kondisi race. Permintaan penulisan tidak melakukan validasi sisi server, jadi pengguna yang menginginkan integritas end-to-end pemeriksaan harus melakukan validasi sisi klien pada objek gabungan baru.

Validasi Google Cloud CLI

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

Validasi otomatis ini terjadi setelah objek itu sendiri selesai, jadi objek yang tidak valid terlihat selama 1-3 detik sebelum diidentifikasi dan dihapus. Selain itu, ada kemungkinan bahwa gcloud CLI dapat setelah unggahan selesai tetapi sebelum melakukan validasi, membiarkan objek yang tidak valid tetap di tempatnya. Masalah ini dapat dihindari saat mengupload file tunggal ke Cloud Storage menggunakan validasi sisi server, yang terjadi saat menggunakan tanda --content-md5.

Deteksi perubahan untuk rsync

Perintah gcloud storage rsync juga dapat menggunakan checksum MD5 atau CRC32C untuk menentukan apakah ada perbedaan antara versi objek yang ditemukan pada sumber dan versi yang ditemukan di tujuan. Perintah tersebut membandingkan {i>checksum<i} dalam kasus berikut:

  • Sumber dan tujuannya adalah bucket cloud dan objek memiliki {i>checksum<i} MD5 atau CRC32C di kedua {i>bucket<i}.

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

Jika objek yang relevan memiliki nilai mtime di sumber dan tujuan, seperti ketika sumber dan tujuannya adalah sistem file, Perintah rsync membandingkan objek dan mtime, daripada menggunakan {i>checksum<i}. Demikian pula, jika sumbernya adalah bucket cloud dan tujuannya adalah sistem file lokal, perintah rsync menggunakan waktu yang dibuat untuk sumber sebagai pengganti mtime, dan perintah tidak menggunakan checksum.

Jika mtime atau checksum tidak tersedia, rsync hanya membandingkan ukuran file saat menentukan apakah ada perubahan antara versi sumber suatu objek dan versi tujuannya. Misalnya, baik mtime maupun checksum tersedia saat membandingkan objek gabungan dengan objek di penyedia cloud yang tidak mendukung CRC32C, karena objek komposit tidak memiliki {i>checksum<i} MD5.

Langkah selanjutnya