Salin Blob

Operasi menyalin Copy Blob blob ke tujuan dalam akun penyimpanan.

Dalam versi 2012-02-12 dan yang lebih baru, sumber untuk operasi Copy Blob dapat berupa blob yang diterapkan di akun penyimpanan Azure apa pun.

Dimulai dengan versi 2015-02-21, sumber untuk operasi Copy Blob dapat berupa file Azure di akun penyimpanan Azure apa pun.

Nota

Hanya akun penyimpanan yang dibuat pada atau setelah 7 Juni 2012, yang mengizinkan Copy Blob operasi untuk menyalin dari akun penyimpanan lain.

Permohonan

Anda dapat membuat permintaan Copy Blob sebagai berikut. Kami merekomendasikan HTTPS. Ganti myaccount dengan nama akun penyimpanan Anda, mycontainer dengan nama kontainer Anda, dan myblob dengan nama blob tujuan Anda.

Dimulai dengan versi 2013-08-15, Anda dapat menentukan tanda tangan akses bersama (SAS) untuk blob tujuan jika berada di akun yang sama dengan blob sumber. Dimulai dengan versi 2015-04-05, Anda juga dapat menentukan tanda tangan akses bersama untuk blob tujuan jika berada di akun penyimpanan yang berbeda.

URI permintaan metode PUT	Versi HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob	HTTP/1.1

URI untuk layanan penyimpanan yang diemulasi

Saat Anda membuat permintaan terhadap layanan penyimpanan yang diemulasi, tentukan nama host emulator dan port Azure Blob Storage sebagai 127.0.0.1:10000, diikuti dengan nama akun penyimpanan yang diemulasi:

URI permintaan metode PUT	Versi HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob	HTTP/1.1

Untuk informasi selengkapnya, lihat Menggunakan emulator Azurite untuk pengembangan Azure Storage lokal.

URI Parameter

Anda dapat menentukan parameter tambahan berikut pada URI permintaan:

Pengaturan	Deskripsi
timeout	Fakultatif. Parameter timeout dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur batas waktu untuk operasi Blob Storage.

Tajuk permintaan

Tabel berikut ini menjelaskan header permintaan yang diperlukan dan opsional:

Tajuk permintaan	Deskripsi
Authorization	Dibutuhkan. Menentukan skema otorisasi, nama akun, dan tanda tangan. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage.
Date atau x-ms-date	Dibutuhkan. Menentukan Waktu Universal Terkoordinasi (UTC) untuk permintaan tersebut. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage.
x-ms-version	Diperlukan untuk semua permintaan yang diotorisasi. Untuk informasi selengkapnya, lihat Penerapan Versi untuk layanan Azure Storage.
x-ms-meta-name:value	Fakultatif. Menentukan pasangan nama/nilai yang ditentukan pengguna yang terkait dengan blob. Jika tidak ada pasangan nama/nilai yang ditentukan, operasi menyalin metadata dari blob atau file sumber ke blob tujuan. Jika satu atau beberapa pasangan nama/nilai ditentukan, blob tujuan dibuat dengan metadata yang ditentukan, dan metadata tidak disalin dari blob atau file sumber. Dimulai dengan versi 2009-09-19, nama metadata harus mematuhi aturan penamaan untuk pengidentifikasi C# . Untuk informasi selengkapnya, lihat Penamaan dan referensi kontainer, blob, dan metadata.
x-ms-tags	Fakultatif. Mengatur tag yang dikodekan string kueri yang diberikan pada blob. Tag tidak disalin dari sumber salinan. Untuk informasi selengkapnya, lihat Remarks. Didukung dalam versi 2019-12-12 dan yang lebih baru.
x-ms-source-if-modified-since	Fakultatif. Nilai DateTime. Tentukan header kondisional ini untuk menyalin blob hanya jika blob sumber telah dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob sumber belum dimodifikasi, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal). Anda tidak dapat menentukan header ini jika sumbernya adalah file Azure.
x-ms-source-if-unmodified-since	Fakultatif. Nilai DateTime. Tentukan header kondisional ini untuk menyalin blob hanya jika blob sumber belum dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob sumber telah dimodifikasi, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal). Anda tidak dapat menentukan header ini jika sumbernya adalah file Azure.
x-ms-source-if-match	Fakultatif. Sebuah nilai ETag. Tentukan header bersyarat ini untuk menyalin blob sumber hanya jika nilainya ETag cocok dengan nilai yang ditentukan. Jika nilainya tidak cocok, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal). Anda tidak dapat menentukan header ini jika sumbernya adalah file Azure.
x-ms-source-if-none-match	Fakultatif. Sebuah nilai ETag. Tentukan header bersyarat ini untuk menyalin blob hanya jika nilainya ETag tidak cocok dengan nilai yang ditentukan. Jika nilainya identik, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal). Anda tidak dapat menentukan header ini jika sumbernya adalah file Azure.
If-Modified-Since	Fakultatif. Nilai DateTime. Tentukan header kondisional ini untuk menyalin blob hanya jika blob tujuan telah dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob tujuan belum dimodifikasi, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal).
If-Unmodified-Since	Fakultatif. Nilai DateTime. Tentukan header kondisional ini untuk menyalin blob hanya jika blob tujuan belum dimodifikasi sejak tanggal/waktu yang ditentukan. Jika blob tujuan telah dimodifikasi, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal).
If-Match	Fakultatif. Sebuah nilai ETag. Tentukan ETag nilai untuk header bersyarat ini untuk menyalin blob hanya jika nilai yang ditentukan ETag cocok dengan ETag nilai untuk blob tujuan yang ada. Jika nilainya tidak cocok, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal).
If-None-Match	Fakultatif. Nilai ETag , atau karakter pengganti (*). Tentukan ETag nilai untuk header bersyarat ini untuk menyalin blob hanya jika nilai yang ditentukan ETag tidak cocok dengan ETag nilai untuk blob tujuan. Tentukan karakter kartubebas (*) untuk melakukan operasi hanya jika blob tujuan tidak ada. Jika kondisi yang ditentukan tidak terpenuhi, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal).
x-ms-copy-source:name	Dibutuhkan. Menentukan nama blob atau file sumber. Dimulai dengan versi 2012-02-12, nilai ini dapat berupa URL dengan panjang hingga 2 kibibyte (KiB) yang menentukan blob. Nilai harus dikodekan URL seperti yang akan muncul di URI permintaan. Operasi baca pada blob sumber di akun penyimpanan yang sama dapat diotorisasi melalui kunci bersama. Dimulai dengan versi 2017-11-09, Anda juga dapat menggunakan ID Microsoft Entra untuk mengotorisasi operasi baca pada blob sumber. Namun, jika sumbernya adalah blob di akun penyimpanan lain, blob sumber harus bersifat publik, atau akses ke blob tersebut harus diotorisasi melalui tanda tangan akses bersama. Jika blob sumber bersifat publik, tidak diperlukan otorisasi untuk melakukan operasi penyalinan. Dimulai dengan versi 2015-02-21, objek sumber dapat berupa file di Azure Files. Jika objek sumber adalah file yang akan disalin ke blob, maka file sumber harus diotorisasi melalui tanda tangan akses bersama, baik itu berada di akun yang sama atau di akun yang berbeda. Hanya akun penyimpanan yang dibuat pada atau setelah 7 Juni 2012, yang mengizinkan Copy Blob operasi untuk menyalin dari akun penyimpanan lain. Berikut adalah beberapa contoh URL objek sumber: - https://myaccount.blob.core.windows.net/mycontainer/myblob - https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime> - https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime> Ketika objek sumber adalah file di Azure Files, URL sumber menggunakan format berikut. Perhatikan bahwa URL harus menyertakan token SAS yang valid untuk file tersebut. - https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken Dalam versi sebelum 2012-02-12, blob hanya dapat disalin dalam akun yang sama, dan nama sumber dapat menggunakan format berikut: - Blob dalam kontainer bernama: /accountName/containerName/blobName - Rekam jepret dalam kontainer bernama: /accountName/containerName/blobName?snapshot=<DateTime> - Blob dalam wadah root: /accountName/blobName - Rekam jepret dalam wadah root: /accountName/blobName?snapshot=<DateTime>
x-ms-lease-id:<ID>	Diperlukan jika blob tujuan memiliki sewa aktif. ID sewa yang ditentukan untuk header ini harus cocok dengan ID sewa blob tujuan. Jika permintaan tidak menyertakan ID sewa atau ID tidak valid, operasi gagal dengan kode status 412 (Prasyarat Gagal). Jika header ini ditentukan dan blob tujuan saat ini tidak memiliki sewa aktif, operasi gagal dengan kode status 412 (Prasyarat Gagal). Dalam versi 2012-02-12 dan yang lebih baru, nilai ini harus menentukan sewa tak terbatas aktif untuk blob yang disewakan. ID sewa berdurasi terbatas gagal dengan kode status 412 (Prasyarat Gagal).
x-ms-source-lease-id: <ID>	Opsional untuk versi sebelum 2012-02-12 (tidak didukung pada 2012-02-12 dan yang lebih baru). Tentukan header ini untuk melakukan Copy Blob operasi hanya jika ID sewa yang diberikan cocok dengan ID sewa aktif blob sumber. Jika header ini ditentukan dan blob sumber saat ini tidak memiliki sewa aktif, operasi gagal dengan kode status 412 (Prasyarat Gagal).
x-ms-client-request-id	Fakultatif. Menyediakan nilai buram yang dihasilkan klien dengan batas karakter 1 KiB yang dicatat dalam log saat pengelogan dikonfigurasi. Kami sangat menyarankan Anda menggunakan header ini untuk menghubungkan aktivitas sisi klien dengan permintaan yang diterima server.
x-ms-access-tier	Fakultatif. Menentukan tingkat yang akan diatur pada blob target. Header ini hanya untuk blob halaman pada akun premium dengan versi 2017-04-17 dan yang lebih baru. Untuk daftar lengkap tingkat yang didukung, lihat Penyimpanan premium performa tinggi dan disk terkelola untuk VM. Header ini didukung pada versi 2018-11-09 dan yang lebih baru untuk blob blok. Tingkatan blob blok didukung pada akun Blob Storage atau General Purpose v2. Nilai yang valid adalah Hot, , CoolCold, Smart dan Archive. Catatan: tingkatCold didukung untuk versi 2021-12-02 dan yang lebih baru. Smart Tier didukung untuk versi 2026-02-06 dan yang lebih baru, dan saat ini dalam pratinjau publik. Untuk informasi terperinci tentang tingkatan blob blok, lihat Tingkat penyimpanan blob.
x-ms-rehydrate-priority	Fakultatif. Menunjukkan prioritas untuk merehidrasi blob yang diarsipkan. Header ini didukung pada versi 2019-02-02 dan yang lebih baru untuk blob blok. Nilai yang berlaku adalah High atau Standard. Anda dapat mengatur prioritas pada blob hanya sekali. Header ini akan diabaikan pada permintaan berikutnya ke blob yang sama. Prioritas default tanpa header ini adalah Standard.
x-ms-seal-blob	Fakultatif. Didukung pada versi 2019-12-12 atau yang lebih baru. Header ini hanya berlaku untuk menambahkan blob. Ini menyegel blob tujuan setelah operasi penyalinan selesai.
x-ms-immutability-policy-until-date	Versi 2020-06-12 dan yang lebih baru. Menentukan tanggal retensi-sampai yang akan ditetapkan pada blob. Ini adalah tanggal hingga blob dapat dilindungi dari modifikasi atau penghapusan. Ini mengikuti format RFC1123.
x-ms-immutability-policy-mode	Versi 2020-06-12 dan yang lebih baru. Menentukan mode kebijakan kekekalan yang akan diatur pada blob. Nilai yang berlaku adalah unlocked atau locked. Nilai unlocked menunjukkan bahwa pengguna dapat mengubah kebijakan dengan menambah atau mengurangi tanggal retensi-to. Nilai menunjukkan locked bahwa tindakan ini dilarang.
x-ms-legal-hold	Versi 2020-06-12 dan yang lebih baru. Menentukan pembekuan hukum yang akan diatur pada blob. Nilai yang berlaku adalah true atau false.

Operasi ini mendukung x-ms-if-tags header dan x-ms-source-if-tags bersyarat untuk berhasil hanya jika kondisi yang ditentukan terpenuhi. Untuk informasi selengkapnya, lihat Menentukan header kondisional untuk operasi Blob Storage.

Isi dari permintaan

Tidak ada.

Jawaban

Respons mencakup kode status HTTP dan sekumpulan header respons.

Kode status

Dalam versi 2012-02-12 dan yang lebih baru, operasi yang berhasil mengembalikan kode status 202 (Diterima).

Dalam versi sebelum 2012-02-12, operasi yang berhasil mengembalikan kode status 201 (Dibuat).

Untuk informasi tentang kode status, lihat Status dan kode kesalahan.

Tajuk respons

Respons untuk operasi ini mencakup header berikut. Respons juga dapat menyertakan header HTTP standar tambahan. Semua header standar sesuai dengan spesifikasi protokol HTTP/1.1 .

Respons Header	Deskripsi
ETag	Dalam versi 2012-02-12 dan yang lebih baru, jika salinan selesai, header ini berisi ETag nilai blob tujuan. Jika salinan tidak selesai, header berisi ETag nilai blob kosong yang dibuat di awal operasi penyalinan. Dalam versi sebelum 2012-02-12, header ini mengembalikan ETag nilai untuk blob tujuan. Dalam versi 2011-08-18 dan yang lebih baru, nilainya ETag dalam tanda kutip.
Last-Modified	Mengembalikan tanggal/waktu operasi penyalinan ke blob tujuan selesai.
x-ms-request-id	Mengidentifikasi permintaan yang dibuat secara unik. Anda dapat menggunakan header ini untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Memecahkan masalah operasi API.
x-ms-version	Menunjukkan versi Blob Storage yang digunakan untuk menjalankan permintaan. Header ini dikembalikan untuk permintaan yang dibuat terhadap versi 2009-09-19 dan yang lebih baru.
Date	Nilai tanggal/waktu UTC yang menunjukkan waktu layanan mengirim respons.
x-ms-copy-id: <id>	Versi 2012-02-12 dan yang lebih baru. Menyediakan pengidentifikasi string untuk operasi penyalinan ini. Gunakan dengan Get Blob atau Get Blob Properties untuk memeriksa status operasi penyalinan ini, atau teruskan ke Abort Copy Blob untuk membatalkan operasi penyalinan yang tertunda.
x-ms-copy-status: <success ¦ pending>	Versi 2012-02-12 dan yang lebih baru. Menunjukkan status operasi penyalinan, dengan nilai-nilai berikut: - success: Operasi berhasil selesai. - pending: Operasi sedang berlangsung.
x-ms-version-id: <DateTime>	Versi 2019-12-12 dan yang lebih baru. Mengidentifikasi blob secara unik berdasarkan versinya. Anda dapat menggunakan nilai buram ini dalam permintaan berikutnya untuk mengakses versi blob ini.
x-ms-client-request-id	Dapat digunakan untuk memecahkan masalah permintaan dan respons yang sesuai. Nilai header ini sama dengan nilai header x-ms-client-request-id, jika ada dalam permintaan dan nilainya paling banyak 1.024 karakter ASCII yang terlihat. Jika header x-ms-client-request-id tidak ada dalam permintaan, header ini tidak akan ada dalam respons.

Badan respons

Tidak ada.

Contoh tanggapan

Kode berikut adalah contoh respons untuk permintaan menyalin blob:

Response Status:  
HTTP/1.1 202 Accepted  
  
Response Headers:   
Last-Modified: <date>   
ETag: "0x8CEB669D794AFE2"  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-copy-status: pending
x-ms-version-id: <DateTime>  
Date: <date>  
  

Otorisasi

Otorisasi diperlukan saat memanggil operasi akses data apa pun di Azure Storage. Tabel berikut ini menjelaskan bagaimana tujuan dan objek sumber untuk operasi Copy Blob dapat diotorisasi:

Jenis objek	Otorisasi ID Microsoft Entra	Otorisasi Tanda Tangan Akses Bersama (SAS)	Otorisasi Kunci Bersama (atau Kunci Bersama Lite)
Blob tujuan	Ya	Ya	Ya
Blob sumber di akun penyimpanan yang sama	Ya	Ya	Ya
Blob sumber di akun penyimpanan lain	Tidak.	Ya	Tidak.

Jika permintaan menentukan tag dalam x-ms-tags header permintaan, pemanggil harus memenuhi persyaratan otorisasi operasi Atur Tag Blob .

Anda dapat mengotorisasi operasi Copy Blob seperti yang dijelaskan di bawah ini. Perhatikan bahwa blob sumber di akun penyimpanan yang berbeda harus diizinkan secara terpisah melalui token SAS dengan izin Baca (r). Untuk informasi selengkapnya tentang otorisasi blob sumber, lihat detail untuk header x-ms-copy-sourcepermintaan .

Penting

Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk mengotorisasi permintaan ke Azure Storage. MICROSOFT Entra ID menyediakan keamanan yang unggul dan kemudahan penggunaan dibandingkan dengan otorisasi Kunci Bersama.

ID Microsoft Entra (disarankan)

Azure Storage mendukung penggunaan ID Microsoft Entra untuk mengotorisasi permintaan ke data blob. Dengan MICROSOFT Entra ID, Anda dapat menggunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk memberikan izin kepada prinsip keamanan. Prinsip keamanan mungkin pengguna, grup, perwakilan layanan aplikasi, atau identitas terkelola Azure. Prinsip keamanan diautentikasi oleh MICROSOFT Entra ID untuk mengembalikan token OAuth 2.0. Token kemudian dapat digunakan untuk mengotorisasi permintaan terhadap layanan Blob.

Untuk mempelajari selengkapnya tentang otorisasi menggunakan ID Microsoft Entra, lihat Mengotorisasi akses ke blob menggunakan ID Microsoft Entra.

Hak akses

Tercantum di bawah ini adalah tindakan RBAC yang diperlukan untuk pengguna, grup, identitas terkelola, atau perwakilan layanan Microsoft Entra untuk memanggil operasi Copy Blob, dan peran Azure RBAC bawaan yang paling tidak istimewa yang mencakup tindakan ini:

Blob tujuan

• Azure RBAC action:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (untuk menulis ke blob yang ada) atau Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (untuk menulis blob baru ke tujuan)
• Peran bawaan dengan hak istimewa paling sedikit: Kontributor Data Blob Penyimpanan

Blob sumber dalam akun penyimpanan yang sama

• Tindakan Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
• Peran bawaan dengan hak istimewa paling rendah:Pembaca Data Blob Penyimpanan

Untuk mempelajari selengkapnya tentang menetapkan peran menggunakan Azure RBAC, lihat Menetapkan peran Azure untuk akses ke data blob.

Tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan dengan aman ke sumber daya di akun penyimpanan. Dengan SAS, Anda memiliki kontrol terperinci atas bagaimana klien dapat mengakses data. Anda dapat menentukan sumber daya apa yang dapat diakses klien, izin apa yang mereka miliki ke sumber daya tersebut, dan berapa lama SAS valid.

Operasi Copy Blob mendukung tiga jenis tanda tangan akses bersama: delegasi pengguna SAS, layanan SAS, dan akun SAS.

Sebagai praktik terbaik keamanan, kami sarankan Anda menggunakan kredensial Microsoft Entra daripada kunci akun penyimpanan, yang dapat lebih mudah disusupi. Jika desain aplikasi Anda memerlukan tanda tangan akses bersama, gunakan kredensial Microsoft Entra untuk membuat SAS delegasi pengguna, jika memungkinkan.

Ketika akses Kunci Bersama tidak diizinkan untuk akun penyimpanan, token SAS layanan atau token SAS akun tidak akan diizinkan berdasarkan permintaan ke Blob Storage. Untuk mempelajari lebih lanjut, lihat Memahami bagaimana melarang Kunci Bersama memengaruhi token SAS.

Delegasi pengguna SAS

SAS delegasi pengguna diamankan oleh kredensial Microsoft Entra serta izin yang ditentukan untuk SAS.

Memanggil Copy Blob operasi menggunakan token SAS yang didelegasikan ke sumber daya blob memerlukan izin berikut sebagai bagian dari token SAS delegasi pengguna.

Operasi	Jenis objek	Izin bertanda tangan
Salin Blob	Blob tujuan (baru)	Buat (c) atau Tulis (w)
Salin Blob	Blob tujuan (sudah ada)	Tulis (w)
Salin Blob	Blob sumber (dalam akun penyimpanan yang sama)	Baca (r)
Salin Blob	Blob sumber (di akun penyimpanan yang berbeda)	Baca (r)

Untuk mempelajari selengkapnya tentang SAS delegasi pengguna, lihat Membuat delegasi pengguna SAS.

Layanan SAS

SAS layanan diamankan menggunakan kunci akun penyimpanan. SAS layanan mendelegasikan akses ke sumber daya dalam satu layanan Azure Storage, seperti penyimpanan blob.

Memanggil Copy Blob operasi menggunakan token SAS yang didelegasikan ke sumber daya blob memerlukan izin berikut sebagai bagian dari token SAS layanan.

Operasi	Jenis objek	Izin bertanda tangan
Salin Blob	Blob tujuan (baru)	Buat (c) atau Tulis (w)
Salin Blob	Blob tujuan (sudah ada)	Tulis (w)
Salin Blob	Blob sumber (dalam akun penyimpanan yang sama)	Baca (r)
Salin Blob	Blob sumber (di akun penyimpanan yang berbeda)	Baca (r)

Untuk mempelajari selengkapnya tentang layanan SAS, lihat Membuat layanan SAS.

Akun SAS

SAS akun diamankan dengan kunci akun penyimpanan. Akun SAS delegasikan akses ke sumber daya di satu atau beberapa layanan penyimpanan. Semua operasi yang tersedia melalui layanan atau delegasi pengguna SAS juga tersedia melalui akun SAS.

Tabel berikut menunjukkan jenis sumber daya yang ditandatangani dan izin yang ditandatangani untuk ditentukan saat mendelegasikan akses:

Operasi	Jenis objek	Layanan yang ditandatangani	Jenis sumber daya yang ditandatangani	Izin bertanda tangan
Salin Blob	Blob tujuan (baru)	Gumpalan (b)	Objek (o)	Buat (c) atau Tulis (w)
Salin Blob	Blob tujuan (sudah ada)	Gumpalan (b)	Objek (o)	Tulis (w)
Salin Blob	Blob sumber (dalam akun penyimpanan yang sama)	Gumpalan (b)	Objek (o)	Baca (r)
Salin Blob	Blob sumber (di akun penyimpanan yang berbeda)	Gumpalan (b)	Objek (o)	Baca (r)

Untuk mempelajari selengkapnya tentang akun SAS, lihat Membuat akun SAS.

Operasi Copy Blob mendukung otorisasi Kunci Bersama . Otorisasi dengan kunci akun tidak disarankan untuk sebagian besar skenario, karena kurang aman.

Microsoft merekomendasikan untuk melarang otorisasi Kunci Bersama untuk akun penyimpanan jika memungkinkan. Untuk informasi selengkapnya, lihat Mencegah otorisasi dengan Kunci Bersama.

Komentar

Dalam versi 2012-02-12 dan yang lebih baru, operasi dapat Copy Blob selesai secara asinkron. Operasi ini mengembalikan ID salinan yang dapat Anda gunakan untuk memeriksa atau membatalkan operasi penyalinan. Karena sifat asinkron dari operasi penyalinan, Blob Storage menyalin blob dengan upaya terbaik. Layanan Blob menyalin blob ketika sumber daya server tidak digunakan oleh tugas lain, sehingga salinan tidak dijamin akan segera dimulai atau selesai dalam jangka waktu tertentu.

Blob sumber untuk operasi penyalinan dapat berupa blob blok, blob penambahan, blob halaman, atau rekam jepret. Jika blob tujuan sudah ada, blob harus dari jenis blob yang sama dengan blob sumber. Setiap blob tujuan yang ada akan ditimpa. Anda tidak dapat memodifikasi blob tujuan saat operasi penyalinan sedang berlangsung.

Dalam versi 2015-02-21 dan yang lebih baru, sumber untuk operasi penyalinan juga dapat berupa file di Azure Files. Jika sumbernya adalah file, tujuannya harus berupa blob blok.

Beberapa operasi yang tertunda Copy Blob dalam akun dapat diproses secara berurutan. Blob tujuan hanya dapat memiliki satu operasi yang luar biasa Copy Blob . Dengan kata lain, blob tidak dapat menjadi tujuan untuk beberapa operasi yang tertunda Copy Blob . Upaya untuk menyalin blob ke blob tujuan yang sudah memiliki operasi penyalinan tertunda gagal dengan kode status 409 (Konflik).

Hanya akun penyimpanan yang dibuat pada atau setelah 7 Juni 2012, yang mengizinkan Copy Blob operasi untuk menyalin dari akun penyimpanan lain. Upaya untuk menyalin dari akun penyimpanan lain ke akun yang dibuat sebelum 7 Juni 2012 gagal dengan kode status 400 (Permintaan Buruk).

Operasi Copy Blob selalu menyalin seluruh blob atau file sumber. Menyalin rentang byte atau set blok tidak didukung.

Operasi Copy Blob dapat mengambil salah satu bentuk berikut:

• Anda dapat menyalin blob sumber ke blob tujuan yang memiliki nama berbeda. Blob tujuan dapat berupa blob yang ada dari jenis blob yang sama (blok, tambahkan, atau halaman), atau dapat berupa blob baru yang dibuat oleh operasi penyalinan.

• Anda dapat menyalin blob sumber ke blob tujuan yang memiliki nama yang sama, secara efektif menggantikan blob tujuan. Operasi penyalinan semacam itu menghapus blok yang tidak diterapkan dan menimpa metadata blob.

• Anda dapat menyalin file sumber di Azure Files ke blob tujuan. Blob tujuan dapat berupa blob blok yang ada, atau bisa berupa blob blok baru yang dibuat oleh operasi penyalinan. Menyalin dari file ke blob halaman atau menambahkan blob tidak didukung.

• Anda dapat menyalin rekam jepret di atas blob dasarnya. Dengan meningkatkan snapshot ke posisi blob dasar, Anda dapat memulihkan versi blob yang lebih lama.

• Anda dapat menyalin rekam jepret ke blob tujuan yang memiliki nama berbeda. Blob tujuan yang dihasilkan adalah blob yang dapat ditulis dan bukan snapshot.

Saat Anda menyalin dari blob halaman, Blob Storage membuat blob halaman tujuan dengan panjang blob sumber. Awalnya, blob halaman berisi semua nol. Kemudian rentang halaman sumber dihitung, dan rentang yang tidak kosong disalin.

Untuk blob blok atau blob penambahan, Blob Storage membuat blob yang diterapkan dengan panjang nol sebelum kembali dari operasi ini.

Saat Anda menyalin dari blob blok, semua blok yang diterapkan dan ID bloknya disalin. Blok yang tidak diterapkan tidak disalin. Di akhir operasi penyalinan, blob tujuan memiliki jumlah blok yang diterapkan sama dengan sumber.

Saat Anda menyalin dari blob tambahan, semua blok yang diterapkan disalin. Di akhir operasi penyalinan, blob tujuan akan memiliki blok yang dikomitkan lebih sedikit dari atau jumlah yang sama dengan blob sumber.

Untuk semua jenis blob, Anda dapat memanggil Get Blob atau Get Blob Properties menggunakan blob tujuan untuk memeriksa status operasi penyalinan. Blob terakhir akan diterapkan saat operasi penyalinan selesai.

Ketika sumber operasi penyalinan memberikan ETag nilai, setiap perubahan pada sumber saat operasi penyalinan sedang berlangsung akan menyebabkan operasi tersebut gagal. Upaya untuk mengubah blob tujuan saat salinan sedang berlangsung akan gagal dengan kode status 409 (Konflik). Jika blob tujuan memiliki sewa tak terbatas, ID sewa harus diteruskan ke Copy Blob. Sewa dengan durasi terbatas tidak diperbolehkan.

Nilai ETag untuk blob blok berubah saat Copy Blob operasi dimulai dan saat operasi selesai. Nilai ETag untuk blob halaman berubah saat Copy Blob operasi dimulai, dan terus sering berubah selama operasi penyalinan. Konten blob blok terlihat melalui Get perintah hanya setelah operasi penyalinan penuh selesai.

Menyalin properti, tag, dan metadata blob

Saat blob disalin, properti sistem berikut disalin ke blob tujuan yang memiliki nilai yang sama:

• Content-Type

• Content-Encoding

• Content-Language

• Content-Length

• Cache-Control

• Content-MD5

• Content-Disposition

• x-ms-blob-sequence-number (hanya untuk blob halaman)

• x-ms-committed-block-count (hanya untuk blob penambahan, dan hanya untuk versi 2015-02-21)

Daftar blokir yang diterapkan blob sumber juga disalin ke blob tujuan, jika blob adalah blob blok. Blok yang tidak diterapkan tidak disalin.

Blob tujuan selalu berukuran sama dengan blob sumber. Nilai Content-Length header untuk blob tujuan cocok dengan nilai header tersebut untuk blob sumber.

Ketika blob sumber dan blob tujuan sama, Copy Blob menghapus blok yang tidak diterapkan. Jika metadata ditentukan dalam kasus ini, metadata yang ada ditimpa dengan metadata baru.

Jika x-ms-tags header menyediakan tag untuk blob tujuan, mereka harus dikodekan string kueri. Kunci dan nilai tag harus sesuai dengan persyaratan penamaan dan panjang, seperti yang ditentukan dalam Atur Tag Blob.

Header x-ms-tags dapat berisi hingga 2 kilobit tag. Jika Anda memerlukan lebih banyak tag, gunakan operasi.Set Blob Tags

Jika x-ms-tags header tidak menyediakan tag, maka tag tidak disalin dari blob sumber.

Menyalin blob yang disewa

Operasi Copy Blob hanya membaca dari blob sumber, jadi status sewa blob sumber tidak masalah. Namun, operasi menyimpan Copy BlobETag nilai blob sumber saat operasi penyalinan dimulai. Jika nilai ETag berubah sebelum operasi salin selesai, operasi gagal. Anda dapat mencegah perubahan pada blob sumber dengan menyewakannya selama operasi penyalinan.

Jika blob tujuan memiliki sewa tak terbatas aktif, Anda harus menentukan ID sewanya dalam panggilan ke Copy Blob operasi. Jika sewa yang Anda tentukan adalah sewa durasi terbatas aktif, panggilan ini gagal dengan kode status 412 (Prasyarat Gagal). Saat operasi penyalinan tertunda, operasi sewa apa pun pada blob tujuan gagal dengan kode status 409 (Konflik). Sewa tak terbatas pada blob tujuan dikunci dengan cara ini selama operasi penyalinan, baik Anda menyalin ke blob tujuan yang memiliki nama berbeda dari sumber, menyalin ke blob tujuan yang memiliki nama yang sama dengan sumber, atau mempromosikan rekam jepret melalui blob dasarnya.

Jika klien menentukan ID sewa pada blob yang belum ada, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal) untuk permintaan yang dibuat terhadap versi 2013-08-15 dan yang lebih baru. Untuk versi sebelumnya, Blob Storage mengembalikan kode status 201 (Dibuat).

Menyalin rekam jepret blob

Saat blob sumber disalin, rekam jepret atau versi blob sumber apa pun tidak disalin ke tujuan. Saat blob tujuan ditimpa dengan salinan, rekam jepret atau versi apa pun yang terkait dengan blob tujuan tetap utuh di bawah namanya.

Anda dapat melakukan operasi penyalinan untuk mempromosikan rekam jepret melalui blob dasarnya, selama berada di tingkat online (panas, dingin, atau dingin). Dengan cara ini, Anda dapat memulihkan versi blob yang lebih lama. Rekam jepret tetap ada, tetapi tujuannya ditimpa dengan salinan yang dapat dibaca dan ditulis.

Menyalin versi blob

Anda dapat melakukan operasi penyalinan untuk mempromosikan versi melalui blob dasarnya, selama versi tersebut berada di tingkat online (panas, dingin, atau dingin). Dengan cara ini, Anda dapat memulihkan versi blob yang lebih lama. Versinya tetap ada, tetapi tujuannya ditimpa dengan salinan yang dapat dibaca dan ditulis.

Menyalin blob yang diarsipkan

Dimulai dengan versi 2018-11-09, Anda dapat menyalin blob yang diarsipkan ke blob baru dalam akun penyimpanan yang sama. Blob sumber tetap berada di tingkat arsip. Ketika blob sumber adalah blob yang diarsipkan, permintaan harus berisi x-ms-access-tier header, yang menunjukkan tingkat blob tujuan. Blob tujuan harus berada di tingkat online. Anda tidak dapat menyalin ke blob di tingkat arsip.

Dimulai dengan versi 2021-02-12, Anda dapat menyalin blob yang diarsipkan ke tingkat online di akun penyimpanan yang berbeda, selama akun tujuan berada di wilayah yang sama dengan akun sumber.

Permintaan mungkin gagal jika blob sumber sedang direhidrasi.

Untuk informasi terperinci tentang tingkatan di tingkat blob blok, lihat Tingkat penyimpanan blob.

Bekerja dengan operasi penyalinan yang tertunda (versi 2012-02-12 dan yang lebih baru)

Jika Copy Blob operasi selesai secara asinkron, gunakan tabel berikut untuk menentukan langkah berikutnya berdasarkan kode status yang ditampilkan:

Kode status	Makna
202 (Diterima), x-ms-copy-status: berhasil	Operasi salin berhasil diselesaikan.
202 (Diterima), x-ms-copy-status: tertunda	Operasi salin belum selesai. Polling blob tujuan dengan menggunakan Get Blob Properties untuk memeriksa x-ms-copy-status header hingga operasi selesai atau gagal.
4xx, 500, atau 503	Operasi salin gagal.

Selama dan setelah Copy Blob operasi, properti blob tujuan berisi ID Copy Blob salinan operasi dan URL blob sumber. Saat operasi selesai, Blob Storage menulis nilai waktu dan hasil (success, failed, atau aborted) ke properti blob tujuan. Jika operasi memiliki hasil failed, header x-ms-copy-status-description berisi string detail kesalahan.

Operasi Copy Blob yang tertunda memiliki batas waktu dua minggu. Upaya penyalinan yang belum selesai setelah dua minggu habis dan meninggalkan blob kosong dengan x-ms-copy-status bidang diatur ke failed dan x-ms-copy-status-description diatur ke 500 (OperationCancelled). Kesalahan non-fatal terputus-terputus yang dapat terjadi selama operasi penyalinan mungkin menghambat kemajuan operasi tetapi tidak menyebabkannya gagal. Dalam kasus ini, x-ms-copy-status-description menjelaskan kesalahan terputus-putus.

Setiap upaya untuk memodifikasi atau rekam jepret blob tujuan selama operasi penyalinan akan gagal dengan kode status 409 (Konflik), "Salin Blob yang sedang Berlangsung."

Jika Anda memanggil Abort Copy Blob operasi, Anda akan melihat x-ms-copy-status:aborted header. Blob tujuan akan memiliki metadata utuh dan panjang blob 0 byte. Anda dapat mengulangi panggilan asli untuk mencoba operasi penyalinan Copy Blob lagi.

Jika Copy Blob operasi selesai secara sinkron, gunakan tabel berikut untuk menentukan status operasi penyalinan:

Kode status	Makna
202 (Diterima), x-ms-copy-status: berhasil	Operasi salin berhasil diselesaikan.
4xx, 500, atau 503	Operasi salin gagal.

Tingkat ini diwariskan untuk tingkat penyimpanan premium. Untuk blob blok, menimpa blob tujuan akan mewarisi tingkat dari tujuan jika x-ms-access-tier tidak disediakan. Menimpa blob yang diarsipkan akan gagal. Untuk informasi terperinci tentang tingkatan di tingkat blob blok, lihat Tingkat penyimpanan blob.

Penagihan

Permintaan harga dapat berasal dari klien yang menggunakan API Blob Storage, baik secara langsung melalui BLob Storage REST API, atau dari pustaka klien Azure Storage. Permintaan ini mengumpulkan biaya per transaksi. Jenis transaksi memengaruhi bagaimana akun ditagih. Misalnya, transaksi baca bertambah ke kategori penagihan yang berbeda dari transaksi tulis. Tabel berikut ini memperlihatkan kategori penagihan untuk permintaan Copy Blob berdasarkan jenis akun penyimpanan:

Operasi	Jenis akun penyimpanan	Kategori penagihan
Salin Blob (akun tujuan1)	Objek besar biner blok premium Standar tujuan umum versi 2 Standar tujuan umum v1	Operasi tulis
Salin Blob (akun sumber2)	Objek besar biner blok premium Standar tujuan umum versi 2 Standar tujuan umum v1	Membacakan operasi

¹Akun tujuan dikenakan biaya untuk satu transaksi untuk memulai penulisan.
²Ketika objek sumber berada di akun yang berbeda, akun sumber dikenakan satu transaksi untuk setiap permintaan baca ke objek sumber.

Untuk mempelajari tentang harga untuk kategori penagihan yang ditentukan, lihat Harga Azure Blob Storage.

Akun tujuan juga dikenakan biaya transaksi untuk setiap permintaan untuk membatalkan operasi penyalinan (lihat Membatalkan Salin Blob) atau untuk memeriksa status operasi penyalinan (lihat Dapatkan Blob atau Dapatkan Properti Blob).

Selain itu, jika akun sumber dan tujuan berada di wilayah yang berbeda (misalnya, AS Utara dan AS Selatan), bandwidth yang Anda gunakan untuk mentransfer permintaan akan dibebankan ke akun penyimpanan sumber sebagai keluar. Keluar antara akun dalam wilayah yang sama gratis.

Saat Anda menyalin blob sumber ke blob tujuan yang memiliki nama berbeda dalam akun yang sama, Anda menggunakan sumber daya penyimpanan tambahan untuk blob baru. Operasi penyalinan kemudian menghasilkan biaya terhadap penggunaan kapasitas akun penyimpanan untuk sumber daya tambahan tersebut. Namun, jika nama blob sumber dan tujuan sama dalam akun yang sama (misalnya, saat Anda mempromosikan rekam jepret ke blob dasarnya), tidak ada biaya tambahan yang dikenakan, selain metadata salinan tambahan yang disimpan dalam versi 2012-02-12 dan yang lebih baru.

Saat Anda mempromosikan rekam jepret untuk menggantikan blob dasarnya, rekam jepret dan blob dasar menjadi identik. Mereka berbagi blok atau halaman, sehingga operasi penyalinan tidak menghasilkan biaya tambahan terhadap penggunaan kapasitas akun penyimpanan. Namun, jika Anda menyalin rekam jepret ke blob tujuan yang memiliki nama berbeda, operasi tersebut dikenakan biaya tambahan untuk sumber daya penyimpanan yang digunakan blob baru yang dihasilkan. Dua gumpalan yang memiliki nama berbeda tidak dapat berbagi blok atau halaman, meskipun keduanya identik. Untuk informasi selengkapnya tentang skenario biaya rekam jepret, lihat Memahami bagaimana rekam jepret mengumpulkan biaya.

Lihat juga

Mengotorisasi permintaan ke Azure Storage
Status dan kode galat
kode kesalahan Blob Storage
Memahami cara rekam jepret mengakrusikan biaya
Batalkan Penggandaan Blob