Bagikan melalui

Pencadangan berkelanjutan dengan pemulihan tepat waktu di Azure Cosmos DB

BERLAKU UNTUK: NoSQL MongoDB Gremlin Meja

Fitur pemulihan point-in-time Azure Cosmos DB membantu dalam beberapa skenario mencakup:

  • Memulihkan dari operasi tulis atau hapus yang tidak disengaja dalam kontainer.
  • Memulihkan akun, database, atau kontainer yang dihapus.
  • Memulihkan ke wilayah mana pun (di mana cadangan ada) pada titik pemulihan waktu.

Azure Cosmos DB melakukan pencadangan data di latar belakang tanpa menggunakan throughput (RUs) tambahan yang disediakan atau memengaruhi performa dan ketersediaan database Anda. Pencadangan berkelanjutan diambil di setiap wilayah di mana akun tersebut ada. Misalnya, akun dapat memiliki wilayah tulis di US Barat dan membaca wilayah di US Timur dan US Timur 2. Wilayah replika ini kemudian dapat dicadangkan ke akun Azure Storage jarak jauh di setiap wilayah masing-masing. Secara otomatis, setiap wilayah menyimpan cadangan di akun penyimpanan yang redundan secara lokal. Jika wilayah mengaktifkan zona ketersediaan , maka cadangan disimpan di akun penyimpanan zona-redundan.

Diagram yang mengilustrasikan cara kontainer dicadangkan di beberapa wilayah.

Jendela waktu yang tersedia untuk pemulihan (juga dikenal sebagai periode retensi) adalah nilai yang lebih rendah dari dua opsi berikut: 30 hari dan 7 hari.

Opsi yang dipilih tergantung pada tingkat pencadangan berkelanjutan yang dipilih. Titik waktu untuk pemulihan dapat menjadi tanda waktu apa pun dalam periode retensi tidak lebih jauh dari titik ketika sumber daya dibuat. Dalam mode konsistensi yang kuat, pencadangan yang dilakukan di wilayah penulisan lebih terkini jika dibandingkan dengan wilayah baca. Wilayah baca bisa mengalami lag karena jaringan atau masalah sementara lainnya. Saat melakukan pemulihan, Anda bisa mendapatkan tanda waktu terbaru yang dapat dipulihkan untuk sumber daya tertentu di wilayah tertentu. Mengacu pada tanda waktu terbaru yang dapat dipulihkan membantu mengonfirmasi cadangan sumber daya hingga tanda waktu yang diberikan, dan dapat memulihkan di wilayah tersebut.

Saat ini, Anda dapat memulihkan konten akun Azure Cosmos DB (API untuk NoSQL atau MongoDB, API untuk Tabel, API untuk Gremlin) pada titik waktu tertentu ke akun lain. Anda dapat melakukan operasi pemulihan ini melalui portal Microsoft Azure, azure CLI, Azure PowerShell, atau templat Azure Resource Manager.

Redundansi penyimpanan cadangan

Secara default, Azure Cosmos DB menyimpan data cadangan mode berkelanjutan dalam blob penyimpanan yang berlebihan secara lokal. Untuk wilayah yang memiliki zona redundansi dikonfigurasi, cadangan disimpan dalam blob penyimpanan zona-redundan. Dalam mode pencadangan berkelanjutan, Anda tidak dapat memperbarui redundansi penyimpanan cadangan.

Berbagai cara untuk memulihkan

Mode pencadangan berkelanjutan mendukung dua cara untuk memulihkan kontainer dan database yang dihapus. Mereka dapat dipulihkan ke akun baru atau ke akun yang sudah ada. Pilihan antara kedua mode ini tergantung pada skenarionya. Dalam kebanyakan kasus, lebih disukai untuk memulihkan kontainer dan database yang dihapus ke akun yang ada. Ini menghindari biaya transfer data yang diperlukan saat memulihkan ke akun baru. Untuk skenario di mana modifikasi data yang tidak disengaja dilakukan, memulihkan ke akun baru bisa menjadi opsi yang disukai.

Apa yang dipulihkan ke akun baru?

Dalam keadaan stabil, semua mutasi yang dilakukan pada akun sumber (termasuk database, kontainer, dan item) dicadangkan secara asinkron dalam waktu 100 detik. Jika media cadangan Azure Storage tidak berfungsi atau tidak tersedia, mutasi tetap ada secara lokal hingga media tersedia. Kemudian, mutasi dipaksa keluar untuk mencegah hilangnya ketepatan operasi yang dapat dipulihkan.

Anda dapat memilih untuk memulihkan kombinasi kontainer throughput yang disediakan, database throughput bersama, atau seluruh akun. Tindakan pemulihan memulihkan semua data dan properti indeksnya ke akun baru. Proses pemulihan memastikan bahwa semua data yang dipulihkan dalam akun, database, atau kontainer dijamin konsisten hingga waktu pemulihan yang ditentukan. Durasi pemulihan tergantung pada jumlah data yang perlu dipulihkan. Pengaturan konsistensi akun database yang baru dipulihkan sama dengan pengaturan konsistensi akun database sumber.

Catatan

Dengan mode pencadangan berkelanjutan, cadangan diambil di setiap wilayah di mana akun Azure Cosmos DB Anda tersedia. Cadangan yang diambil untuk setiap akun wilayah secara default memiliki redundansi lokal, dan akan menjadi redundansi zona jika akun Anda mengaktifkan fitur zona ketersediaan untuk wilayah tersebut. Tindakan pemulihan selalu memulihkan data ke akun baru.

Apa yang tidak dipulihkan?

Konfigurasi berikut ini tidak dipulihkan setelah pemulihan titik waktu:

  • Subset kontainer di bawah database throughput bersama tidak dapat dipulihkan. Seluruh database dapat dipulihkan secara keseluruhan.
  • Firewall, jaringan virtual, kontrol akses berbasis peran bidang data, atau pengaturan titik akhir privat.
  • Semua wilayah dari akun sumber.
  • Prosedur, pemicu, UDF tersimpan.
  • Penetapan kontrol akses berbasis peran.

Anda dapat menambahkan konfigurasi ini ke akun yang dipulihkan setelah pemulihan selesai.

Tanda waktu yang dapat dipulihkan untuk akun live

Untuk memulihkan akun live Azure Cosmos DB yang tidak dihapus, sebaiknya selalu mengidentifikasi tanda waktu terbaru yang dapat dipulihkan untuk kontainer. Kemudian Anda dapat menggunakan stempel waktu ini untuk memulihkan akun ke versi terbarunya.

Skenario pemulihan

Fitur pemulihan titik waktu mendukung skenario berikut. Skenario 1 hingga 3 menunjukkan cara memicu pemulihan jika tanda waktu pemulihan diketahui sebelumnya. Namun, mungkin ada skenario di mana Anda tidak tahu waktu pasti penghapusan atau kerusakan yang tidak disengaja. Skenario 4 dan 5 menunjukkan cara menemukan tanda waktu pemulihan menggunakan API umpan peristiwa baru pada database atau kontainer yang dapat dipulihkan.

Diagram yang memperlihatkan peristiwa siklus hidup dengan tanda waktu untuk akun yang dapat dipulihkan.

  • Skenario 1 - Pulihkan akun yang dihapus: Semua akun yang dihapus yang bisa Anda pulihkan terlihat dari panel Pulihkan . Misalnya, jika Akun A dihapus pada tanda waktu T3. Dalam hal ini tanda waktu tepat sebelum T3, lokasi, nama akun target, grup sumber daya, dan nama akun target cukup untuk dipulihkan dari portal Microsoft Azure, PowerShell, atau CLI.

    Peristiwa siklus hidup dengan tanda waktu untuk database dan kontainer yang dapat di-restorable.

  • Skenario 2 - Memulihkan data akun di wilayah tertentu: Misalnya, jika Akun A ada di dua wilayah US Timur dan AS Barat pada tanda waktu T3. Jika Anda memerlukan salinan akun A di AS Barat, Anda dapat melakukan pemulihan titik waktu dari portal Microsoft Azure, PowerShell, atau CLI dengan US Barat sebagai lokasi target.

  • Skenario 3 - Pulihkan dari operasi tulis atau hapus yang tidak disengaja dalam kontainer dengan tanda waktu pemulihan yang diketahui: Misalnya, jika Anda tahu bahwa konten Kontainer 1 dalam Database 1 dimodifikasi secara tidak sengaja pada tanda waktu T3. Anda dapat melakukan pemulihan titik waktu dari portal Microsoft Azure, PowerShell, atau CLI ke akun lain pada tanda waktu T3 untuk memulihkan status kontainer yang diinginkan.

  • Skenario 4 - Pulihkan akun ke titik waktu sebelumnya sebelum penghapusan database yang tidak disengaja: Di portal Microsoft Azure, Anda bisa menggunakan panel umpan peristiwa untuk menentukan kapan database dihapus dan menemukan waktu pemulihan. Demikian pula, dengan Azure CLI dan PowerShell, Anda dapat menemukan peristiwa penghapusan database dengan menghitung umpan peristiwa database dan kemudian memicu perintah pemulihan dengan parameter yang diperlukan.

  • Skenario 5 - Memulihkan akun ke titik waktu sebelumnya sebelum penghapusan atau modifikasi properti kontainer yang tidak disengaja: Di portal Microsoft Azure, Anda dapat menggunakan panel umpan peristiwa untuk menentukan kapan kontainer dibuat, dimodifikasi, atau dihapus untuk menemukan waktu pemulihan. Demikian pula, dengan Azure CLI dan PowerShell, Anda dapat menemukan peristiwa kontainer dengan menghitung umpan peristiwa kontainer dan kemudian memicu perintah pemulihan dengan parameter yang diperlukan.

Izin

Azure Cosmos DB memungkinkan Anda mengisolasi dan membatasi izin pemulihan untuk akun cadangan berkelanjutan ke peran tertentu atau utama. Untuk mempelajari selengkapnya, lihat Mengelola izin untuk memulihkan akun Azure Cosmos DB.

Memahami pemulihan akun tulis multi-wilayah

Penulisan yang dilakukan di wilayah hub segera dikonfirmasi dan dicadangkan secara asinkron dalam waktu 100 detik. Di akun multi-tulis, setiap mutasi yang dilakukan di wilayah satelit dikirim ke wilayah hub untuk konfirmasi. Wilayah hub memeriksa untuk melihat apakah ada resolusi konflik yang diperlukan, menetapkan tanda waktu resolusi konflik setelah menyelesaikan konflik, dan mengirim kembali dokumen ke wilayah satelit. Wilayah satelit hanya mencadangkan dokumen setelah konfirmasi diterima dari hub. Singkatnya, proses pemulihan hanya memulihkan dokumen yang dikonfirmasi oleh wilayah pusat berdasarkan titik waktu pemulihan.

Apa yang terjadi untuk pemulihan untuk akun tulis multi-wilayah?

  • Mutasi yang belum dikonfirmasi oleh tanda waktu pemulihan tidak dipulihkan.
  • Koleksi dengan kebijakan resolusi konflik kustom diatur ulang ke penulis terakhir yang menang berdasarkan tanda waktu.

Catatan

Pemulihan dari wilayah satelit lebih lambat dibandingkan dengan pemulihan di wilayah hub untuk akun multi-wilayah untuk menyelesaikan penulisan tentatif lokal seperti yang dikonfirmasi atau mengambil tindakan untuk mengembalikannya.

Untuk mempelajari selengkapnya tentang memahami tanda waktu di akun yang diaktifkan multi-tulis, lihat Memahami tanda waktu.

Contoh skenario: Dengan akun dengan wilayah multi-tulis yang memiliki dua wilayah, yaitu AS Timur dan AS Barat, di mana AS Timur adalah wilayah hub, pertimbangkan urutan peristiwa berikut:

  • T1: Klien menulis dokumen Doc1 ke Wilayah AS Timur (Karena Wilayah AS Timur adalah hub, penulisan segera dikonfirmasi)

  • T2: Klien menulis dokumen Doc2 ke US Barat

  • T3: AS Barat mengirim Doc2 ke AS Timur untuk konfirmasi

  • T4: AS Timur menerima Doc2, mengonfirmasi dokumen dan mengirim Doc2 kembali ke AS Barat

  • T5: AS Barat menerima Doc2 yang dikonfirmasi

Dalam skenario ini, jika tanda waktu pemulihan yang disediakan adalah T3 untuk wilayah hub sebagai sumber, hanya Doc1 yang akan dipulihkan. Doc2 belum dikonfirmasi oleh hub T3. Hanya jika tanda waktu pemulihan lebih dari T4, doc2 akan dipulihkan karena pemulihan di T4 di satelit hanya berisi doc1 karena doc2 belum dikonfirmasi.

Harga

Akun Azure Cosmos DB dengan cadangan 30 hari berkelanjutan memiliki biaya bulanan tambahan untuk menyimpan cadangan. Baik tingkat 30 hari maupun 7 hari dari penagihan balik berkelanjutan untuk memulihkan data Anda. Biaya pemulihan ditambahkan setiap kali operasi pemulihan dimulai. Jika Anda mengonfigurasi akun dengan pencadangan berkelanjutan tetapi tidak memulihkan data, hanya biaya penyimpanan cadangan yang disertakan dalam tagihan Anda.

Contoh berikut didasarkan pada harga untuk akun Azure Cosmos DB yang disebarkan di AS Barat. Harga dan perhitungan bervariasi, tergantung wilayah yang Anda gunakan, lihat halaman harga Azure Cosmos DB untuk informasi harga terbaru.

  • Semua akun yang diaktifkan dengan kebijakan pencadangan berkelanjutan selama 30 hari dikenakan biaya bulanan untuk penyimpanan cadangan yang dihitung sebagai berikut:

    $0.20/GB * Ukuran data dalam GB dalam akun * Jumlah wilayah

  • Setiap pemanggilan API pemulihan dikenakan biaya satu kali. Biaya adalah fungsi dari jumlah data yang dipulihkan:

    $0,15/GB * Ukuran data dalam GB

Misalnya, jika Anda memiliki 1 TB data di dua wilayah:

  • Biaya penyimpanan cadangan dihitung sebagai 1000 * 0,20 * 2 = $400 per bulan

  • Biaya pemulihan dihitung sebagai 1000 * 0,15 = $150 per pemulihan

Petunjuk / Saran

Untuk informasi selengkapnya tentang mengukur penggunaan data akun Azure Cosmos DB Anda saat ini, lihat Menjelajahi wawasan Azure Monitor Azure Cosmos DB. Tingkat 7 hari berkelanjutan tersebut tidak dikenakan biaya untuk cadangan data.

Tingkat 30 hari berkelanjutan vs tingkat 7 hari

  • Periode retensi untuk satu tingkat adalah 30 hari dibandingkan dengan 7 hari untuk tingkat lain.
  • Tingkat retensi 30 hari dikenakan biaya untuk penyimpanan cadangan. Tingkat retensi tujuh hari tidak dipungut biaya.
  • Pemulihan selalu dibebankan di salah satu tingkatan

Waktu untuk aktif

  • Proses pemulihan default memulihkan semua properti kontainer termasuk konfigurasi TTL-nya secara default. Ini dapat mengakibatkan penghapusan data jika pemulihan dilakukan tanpa menonaktifkan TTL. Untuk mencegah penghapusan, teruskan parameter untuk menonaktifkan TTL di PowerShell (-DisableTtl $true) atau cli (--disable-ttl True) saat melakukan pemulihan.

Kunci yang dikelola pelanggan

Lihat Bagaimana kunci yang dikelola pelanggan memengaruhi pencadangan berkelanjutan untuk mempelajari:

  • Cara mengonfigurasi akun Azure Cosmos DB Anda saat menggunakan kunci yang dikelola pelanggan dengan pencadangan berkala.
  • Bagaimana kunci yang dikelola pelanggan memengaruhi pencadangan?

Batasan saat ini

Fungsi pemulihan titik waktu saat ini memiliki batasan berikut:

  • API Azure Cosmos DB untuk SQL, MongoDB, Gremlin, dan Tabel yang didukung untuk pencadangan berkelanjutan. API untuk Cassandra tidak didukung sekarang.

  • Azure Synapse Link untuk akun database yang menggunakan mode pencadangan berkelanjutan umumnya tersedia. Kebalikan dari situasi tersebut, mode pencadangan berkelanjutan untuk akun dengan Synapse Link, berada dalam pratinjau publik. Saat ini, pelanggan yang menonaktifkan Synapse Link dari kontainer tidak dapat bermigrasi ke pencadangan berkelanjutan. Dan penyimpanan analitis tidak disertakan dalam cadangan. Untuk mempelajari selengkapnya, lihat pencadangan penyimpanan analitis.

  • Akun yang dipulihkan dibuat di wilayah yang sama di mana akun sumber Anda berada. Anda tidak dapat memulihkan akun ke wilayah di mana akun sumber tidak ada.

  • Jendela pemulihan hanya 30 hari untuk tingkat 30 hari berkelanjutan dan tujuh hari untuk tingkat 7 hari berkelanjutan. Tingkatan ini dapat dialihkan, tetapi jumlah aktual (7 atau 30) tidak dapat diubah. Selain itu, jika Anda beralih dari tingkat 30 hari ke tingkat 7 hari, ada potensi kehilangan data pada hari di luar ketujuh.

  • Cadangan tidak secara otomatis tahan terhadap bencana alam. Wilayah lain harus secara eksplisit ditambahkan untuk ketahanan akun dan cadangan.

  • Jangan memodifikasi atau menghapus kebijakan (IAM) Manajemen Identitas & Akses ketika sedang berlangsung pemulihan. Kebijakan ini memberikan izin bagi akun untuk mengubah jaringan virtual, konfigurasi firewall apa pun.

  • Akun Azure Cosmos DB untuk MongoDB dengan pencadangan berkelanjutan tidak mendukung pembuatan indeks unik pada koleksi yang sudah ada. Untuk akun seperti itu, indeks unik harus dibuat bersamaan dengan pembuatan koleksi mereka, yang harus dan hanya dapat dilakukan menggunakan perintah ekstensi untuk membuat koleksi.

  • Setelah memulihkan, ada kemungkinan bahwa untuk koleksi tertentu indeks yang konsisten mungkin sedang dibangun kembali. Anda dapat memeriksa status operasi pembangunan kembali melalui properti IndexTransformationProgress.

  • Indeks unik di API untuk MongoDB tidak dapat ditambahkan, diperbarui, atau dihilangkan saat Anda membuat akun mode pencadangan berkelanjutan. Mereka juga tidak dapat dimodifikasi saat Anda memigrasikan akun dari mode berkala ke berkelanjutan.

  • Mode pemulihan berkelanjutan mungkin tidak memulihkan pengaturan throughput yang valid sesuai dengan titik waktu pemulihan.

Langkah berikutnya

  • Last updated on