Bagikan melalui

Pencadangan otomatis di Azure SQL Managed Instance

  • Artikel

Berlaku untuk: Azure SQL Managed Instance

Artikel ini menjelaskan fitur pencadangan otomatis untuk Azure SQL Managed Instance.

Untuk mengubah pengaturan pencadangan, lihat Mengubah pengaturan. Untuk memulihkan cadangan, lihat Memulihkan menggunakan cadangan database otomatis.

Apa itu pencadangan database otomatis?

Pencadangan database adalah bagian penting dari setiap kelangsungan bisnis dan strategi pemulihan bencana karena membantu melindungi data Anda dari kerusakan atau penghapusan. Dengan Azure SQL Managed Instance, cadangan mesin database SQL Server dikelola secara otomatis oleh Microsoft, dan disimpan di akun penyimpanan Azure yang dikelola Microsoft.

Gunakan cadangan ini untuk memulihkan database Anda ke titik waktu tertentu dalam periode retensi yang dikonfigurasi, hingga 35 hari. Namun, jika aturan perlindungan data Anda mengharuskan cadangan Anda tersedia untuk waktu yang lama (hingga 10 tahun), Anda dapat mengonfigurasi kebijakan retensi jangka panjang (LTR) per setiap database.

Frekuensi pencadangan

Azure SQL Managed Instance membuat:

Frekuensi pencadangan log transaksi tergantung pada ukuran komputasi dan jumlah aktivitas database. Log transaksi diambil kira-kira setiap 10 menit, tetapi dapat bervariasi. Saat Anda memulihkan database, layanan menentukan cadangan log penuh, diferensial, dan transaksi mana yang perlu dipulihkan, dalam urutan masing-masing.

Perhatian

Pencadangan penuh otomatis dimulai seminggu sekali berdasarkan jadwal yang ditentukan oleh Microsoft. Pencadangan yang dimulai pengguna memiliki prioritas atas pencadangan penuh otomatis, sehingga pencadangan khusus salinan yang berjalan lama dapat memengaruhi waktu pencadangan penuh otomatis berikutnya.

Redundansi penyimpanan cadangan

Secara default, Azure SQL Managed Instance menyimpan cadangan dalam blob penyimpanan geo-redundan yang direplikasi ke wilayah yang dipasangkan. Redundansi geografis membantu melindungi dari pemadaman yang memengaruhi penyimpanan cadangan di wilayah utama. Ini juga memungkinkan Anda untuk memulihkan instans Anda ke wilayah yang berbeda jika terjadi bencana.

Mekanisme redundansi penyimpanan menyimpan beberapa salinan data Anda sehingga terlindungi dari peristiwa yang direncanakan dan tidak direncanakan. Peristiwa tersebut mungkin termasuk kegagalan perangkat keras sementara, pemadaman jaringan atau listrik, atau bencana alam besar-besaran.

Untuk memastikan bahwa cadangan Anda tetap berada di wilayah yang sama tempat database Anda disebarkan, Anda dapat mengubah redundansi penyimpanan cadangan dari penyimpanan geo-redundan default ke jenis penyimpanan lain yang menyimpan data Anda di wilayah tersebut. Untuk mempelajari selengkapnya tentang redundansi penyimpanan, lihat Redundansi data.

Anda dapat mengonfigurasi redundansi penyimpanan cadangan saat membuat instans, dan Anda dapat memperbaruinya di lain waktu di tingkat instans. Perubahan yang Anda buat pada instans yang ada hanya berlaku untuk cadangan di masa mendatang. Setelah Anda memperbarui redundansi penyimpanan cadangan instans yang ada, mungkin perlu waktu hingga 24 jam agar perubahan diterapkan. Perubahan yang dilakukan pada redundansi penyimpanan cadangan hanya berlaku untuk cadangan jangka pendek. Kebijakan retensi jangka panjang mewarisi opsi redundansi cadangan jangka pendek saat kebijakan dibuat. Opsi redundansi bertahan untuk pencadangan jangka panjang meskipun opsi redundansi untuk cadangan jangka pendek kemudian berubah.

Catatan

Mengubah redundansi cadangan adalah operasi manajemen pembaruan yang memulai failover.

Anda dapat memilih salah satu redundansi penyimpanan berikut untuk cadangan:

  • Penyimpanan redundan lokal (LRS): Menyalin cadangan Anda secara sinkron tiga kali dalam satu lokasi fisik di wilayah utama. LRS adalah opsi replikasi paling murah, tetapi kami tidak merekomendasikannya untuk aplikasi yang membutuhkan ketersediaan atau durabilitas tinggi.

    Diagram memperlihatkan opsi penyimpanan redundan lokal (LRS).

  • Penyimpanan zona redundan (ZRS): Menyalin cadangan Anda secara sinkron di tiga zona ketersediaan Azure di wilayah utama. Saat ini tersedia di wilayah tertentu.

    Diagram memperlihatkan opsi penyimpanan zona redundan (ZRS).

  • Penyimpanan geo-redundan (GRS): Menyalin cadangan Anda secara sinkron tiga kali dalam satu lokasi fisik di wilayah utama dengan menggunakan LRS. Kemudian menyalin data Anda secara asinkron tiga kali ke satu lokasi fisik di wilayah sekunder yang dipasangkan .

    Hasilnya adalah:

    • Tiga salinan sinkron di wilayah utama dalam satu zona ketersediaan.
    • Tiga salinan sinkron di wilayah yang dipasangkan dalam satu zona ketersediaan yang disalin dari wilayah utama ke wilayah sekunder secara asinkron.

    Diagram memperlihatkan opsi penyimpanan geo-redundan (GRS).

  • Penyimpanan geo-zona-redundan (GZRS): Menggabungkan ketersediaan tinggi yang disediakan oleh redundansi di seluruh zona ketersediaan dengan perlindungan dari pemadaman regional yang disediakan oleh replikasi geografis. Data dalam akun GZRS disalin di tiga zona ketersediaan Azure di wilayah utama. Data juga direplikasi ke wilayah geografis sekunder untuk perlindungan dari bencana regional. Di wilayah tersebut, Anda juga memiliki tiga salinan sinkron dalam satu zona ketersediaan yang disalin dari wilayah utama ke wilayah sekunder secara asinkron.

    Diagram memperlihatkan opsi penyimpanan geo-zona-redundan (GZRS).

Peringatan

  • Pemulihan geografis dinonaktifkan segera setelah database diperbarui untuk menggunakan penyimpanan redundan secara lokal atau zona-redundan.
  • Diagram redundansi penyimpanan semua menampilkan wilayah dengan beberapa zona ketersediaan (multi-az). Namun, ada beberapa wilayah yang hanya menyediakan satu zona ketersediaan dan tidak mendukung ZRS atau GZRS.

Penggunaan pencadangan

Anda bisa menggunakan pencadangan ini untuk:

  • Pulihkan database yang sudah ada ke titik waktu sebelumnya dalam periode retensi dengan menggunakan portal Azure, Azure PowerShell, Azure CLI, atau REST API. Operasi ini membuat database baru pada instans yang sama dengan database asli atau instans yang berbeda dalam langganan dan wilayah yang sama. Ini menggunakan nama yang berbeda untuk menghindari penimpaan database asli. Anda juga dapat menggunakan portal Azure untuk memulihkan cadangan database point-in-time Anda ke instans dalam langganan yang berbeda dari instans sumber Anda.

    Setelah pemulihan selesai, Anda bisa menghapus database asli. Atau, Anda dapat mengganti nama database asli dan mengganti nama database yang dipulihkan menjadi nama database asli.

  • Pulihkan database yang dihapus ke titik waktu dalam periode retensi, termasuk waktu penghapusan. Anda dapat memulihkan database yang dihapus ke instans terkelola yang sama tempat cadangan diambil, atau instans lain dalam langganan yang sama atau berbeda ke instans sumber. Sebelum Anda menghapus database, layanan mengambil cadangan log transaksi akhir untuk mencegah kehilangan data.

  • Memulihkan database ke wilayah geografis lain lainnya. Dengan geo-restore, Anda dapat melakukan pemulihan dari bencana geografis ketika database atau pencadangan di wilayah utama tidak dapat diakses. Ini membuat database baru pada instans terkelola yang ada di wilayah Azure mana pun.

    Penting

    Pemulihan geografis hanya tersedia untuk database yang dikonfigurasi dengan penyimpanan cadangan geo-redundan. Jika saat ini Anda tidak menggunakan pencadangan geo-replikasi untuk database, Anda dapat mengubahnya dengan mengonfigurasi redundansi penyimpanan pencadangan.

  • Pulihkan database dari cadangan database jangka panjang, jika database memiliki kebijakan LTR yang dikonfigurasi. LTR memungkinkan Anda memulihkan versi database yang lebih lama dengan menggunakan portal Azure, Azure CLI, atau Azure PowerShell untuk memenuhi permintaan kepatuhan atau menjalankan versi lama aplikasi. Untuk informasi selengkapnya, tinjau halaman Gambaran umum retensi jangka panjang.

Memulihkan kemampuan dan fitur

Tabel ini meringkas kemampuan dan fitur pemulihan titik waktu (PITR), pemulihan geografis, dan retensi jangka panjang.

Properti pencadangan PITR Pemulihan Geo LTR
Jenis pencadangan SQL Pencadangan log penuh, diferensial, dan transaksi. Salinan pencadangan PITR yang direplikasi. Pencadangan penuh saja.
Tujuan titik pemulihan (RPO) Sekitar 10 menit, berdasarkan ukuran komputasi dan jumlah aktivitas database. Hingga 1 jam, berdasarkan geo-replikasi. 1 Satu minggu (atau kebijakan pengguna).
Tujuan waktu pemulihan (RTO) Pemulihan biasanya memakan waktu kurang dari 12 jam tetapi bisa memakan waktu lebih lama, tergantung pada ukuran dan aktivitas. Lihat Pemulihan. Pemulihan biasanya memakan waktu kurang dari 12 jam tetapi bisa memakan waktu lebih lama, tergantung pada ukuran dan aktivitas. Lihat Pemulihan. Pemulihan biasanya memakan waktu kurang dari 12 jam tetapi bisa memakan waktu lebih lama, tergantung pada ukuran dan aktivitas. Lihat Pemulihan.
Retensi 1 hingga 35 hari. Diaktifkan secara default, sama seperti sumber. 2 Tidak diaktifkan secara default. Retensi hingga 10 tahun.
Penyimpanan Azure Redundansi geo secara default. Anda dapat secara opsional mengonfigurasi penyimpanan zona-redundan atau redundan secara lokal. Tersedia saat redundansi penyimpanan pencadangan PITR diatur ke geo-redundan. Tidak tersedia saat penyimpanan cadangan PITR redundan zona atau redundan secara lokal. Redundansi geo secara default. Anda dapat mengonfigurasi penyimpanan redundan zona atau redundan secara lokal.
Mengonfigurasi cadangan sebagai tidak dapat diubah Tidak didukung Tidak didukung Tidak didukung
Memperbarui kebijakan3 Harus cocok, atau ditingkatkan Harus cocok, atau ditingkatkan Harus cocok, atau ditingkatkan
Memulihkan database baru di wilayah yang sama Didukung Didukung Didukung
Memulihkan database baru di wilayah lain Tidak didukung Didukung di wilayah Azure mana pun Didukung di wilayah Azure mana pun
Memulihkan database baru di langganan lain Didukung Tidak didukung 4 Tidak didukung 4
Memulihkan melalui portal Azure Ya Ya Ya
Memulihkan melalui PowerShell Ya Ya Ya
Memulihkan melalui Azure CLI Ya Ya Ya

1 Untuk aplikasi penting bisnis yang memerlukan database besar dan harus memastikan kelangsungan bisnis, lihat grup failover.
2 Semua cadangan PITR disimpan pada penyimpanan geo-redundan secara default, yang berarti pemulihan geografis diaktifkan secara default.
3 Cadangan database yang diambil dari instans yang dikonfigurasi dengan kebijakan pembaruan SQL Server 2022 dapat dipulihkan ke instans yang dikonfigurasi dengan kebijakan pembaruan SQL Server 2022 atau Always-to-date. Cadangan database yang diambil dari instans yang dikonfigurasi dengan kebijakan pembaruan Always-to-date hanya dapat dipulihkan ke instans yang juga dikonfigurasi dengan kebijakan pembaruan Always-to-date.
4 Solusinya adalah memulihkan ke server baru dan menggunakan Pemindahan Sumber Daya untuk memindahkan server ke langganan lain.

Memulihkan database dari cadangan

Untuk melakukan pemulihan, lihat Memulihkan database dari cadangan. Anda dapat mencoba konfigurasi cadangan dan memulihkan operasi dengan menggunakan contoh berikut.

Operasi portal Microsoft Azure Azure CLI Azure PowerShell
Mengubah retensi cadangan SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Mengubah retensi cadangan jangka panjang SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Memulihkan database dari titik waktu tertentu SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Memulihkan database yang terhapus SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Memulihkan database dari Azure Blob Storage SQL Managed Instance

Jadwal pencadangan otomatis

Azure SQL Managed Instance secara otomatis mengelola cadangan dengan membuat cadangan log penuh, diferensial, dan transaksi. Proses ini diatur oleh jadwal internal.

Pencadangan awal

  • Database baru: Segera setelah database dibuat, dipulihkan, atau mengalami perubahan redundansi cadangan, pencadangan penuh pertama dimulai. Pencadangan ini biasanya selesai dalam waktu 30 menit, meskipun mungkin perlu waktu lebih lama untuk database yang lebih besar.

  • Database yang dipulihkan: Durasi pencadangan awal untuk database yang dipulihkan bervariasi dan bergantung pada ukuran database. Database atau salinan database yang dipulihkan, yang sering lebih besar, mungkin memerlukan lebih banyak waktu untuk pencadangan awal.

Penting

Pencadangan penuh pertama untuk database baru lebih diprioritaskan daripada cadangan database lain, jadi ini adalah cadangan pertama yang diambil selama jendela pencadangan penuh pertama. Jika jendela pencadangan penuh sudah aktif dan database lain sedang dicadangkan, pencadangan penuh pertama untuk database baru diambil segera setelah pencadangan penuh database lain selesai.

Pencadangan penuh terjadwal

  • Jadwal Mingguan: Sistem menetapkan jendela pencadangan penuh mingguan untuk seluruh instans.
  • Jendela Pencadangan Penuh: Ini adalah periode yang ditentukan ketika pencadangan penuh dilakukan. Meskipun sistem bertujuan untuk menyelesaikan pencadangan penuh dalam jendela ini, jika perlu, pencadangan dapat berlanjut di luar waktu yang dijadwalkan sampai selesai.
  • Penjadwalan Adaptif: Algoritma cadangan mengevaluasi dampak jendela cadangan pada beban kerja sekitar seminggu sekali, menggunakan penggunaan CPU dan throughput I/O sebagai indikator. Tergantung pada beban kerja minggu sebelumnya, jendela pencadangan penuh dapat disesuaikan.
  • Konfigurasi Pengguna: Sangat penting untuk dicatat bahwa pengguna tidak dapat mengubah atau menonaktifkan jadwal pencadangan.

Penting

Untuk database baru, dipulihkan, atau disalin, kemampuan pemulihan titik waktu (PITR) menjadi tersedia setelah pencadangan log transaksi awal selesai setelah pencadangan penuh awal.

Konsumsi penyimpanan cadangan

Dengan teknologi pencadangan dan pemulihan SQL Server, memulihkan database ke titik waktu memerlukan rantai cadangan yang tidak terganggu. Rantai itu terdiri dari satu cadangan penuh, secara opsional satu cadangan diferensial, dan satu atau beberapa cadangan log transaksi.

Jadwal pencadangan Azure SQL Managed Instance mencakup satu pencadangan penuh setiap minggu. Untuk menyediakan PITR dalam seluruh periode retensi, sistem harus menyimpan cadangan log penuh, diferensial, dan transaksi tambahan hingga seminggu lebih lama dari periode retensi yang dikonfigurasi.

Dengan kata lain, untuk titik waktu apa pun selama periode retensi, harus ada cadangan penuh yang lebih lama dari waktu terlama periode retensi. Juga harus ada rantai cadangan log diferensial dan transaksi yang tidak terganggu dari cadangan penuh tersebut hingga pencadangan penuh berikutnya.

Cadangan yang tidak lagi diperlukan untuk menyediakan fungsionalitas PITR akan dihapus secara otomatis. Karena cadangan diferensial dan cadangan log memerlukan pencadangan penuh sebelumnya untuk dapat dipulihkan, ketiga jenis cadangan akan dihapus secara menyeluruh bersama-sama dalam set mingguan.

Untuk semua database, termasuk database terenkripsi TDE, semua pencadangan penuh dan diferensial dikompresi, untuk mengurangi kompresi dan biaya penyimpanan cadangan. Rasio kompresi cadangan rata-rata adalah 3 hingga 4 kali. Namun, dapat secara signifikan lebih rendah atau lebih tinggi tergantung pada sifat data dan apakah kompresi data digunakan dalam database.

Penting

Untuk database terenkripsi TDE, file cadangan log tidak dikompresi karena alasan performa. Pencadangan log untuk database yang tidak dienkripsi TDE dikompresi.

Azure SQL Managed Instance menghitung total penyimpanan cadangan yang Anda gunakan sebagai nilai kumulatif. Setiap jam, nilai ini dilaporkan ke alur penagihan Azure. Alur bertanggung jawab untuk menggabungkan penggunaan per jam ini untuk menghitung konsumsi Anda pada akhir setiap bulan. Setelah database dihapus, konsumsi akan berkurang seiring usia pencadangan bertambah dan dihapus. Setelah semua cadangan dihapus dan PITR tidak lagi dimungkinkan, penagihan berhenti.

Penting

Cadangan untuk database yang dihapus disimpan untuk pemulihan titik waktu (PITR), yang dapat meningkatkan biaya penyimpanan saat cadangan disimpan meskipun database dihapus. Untuk mengurangi biaya, Anda dapat mengatur periode retensi cadangan menjadi 0 hari, tetapi hanya untuk database yang dihapus. Untuk database reguler, periode retensi minimum adalah 1 hari.

Menyempurnakan konsumsi penyimpanan cadangan

Konsumsi penyimpanan cadangan hingga ukuran data maksimum untuk database tidak dikenakan biaya. Konsumsi penyimpanan cadangan berlebih tergantung pada beban kerja dan ukuran maksimum database individual. Pertimbangkan beberapa teknik penyetelan berikut untuk mengurangi konsumsi penyimpanan cadangan Anda:

  • Kurangi periode retensi cadangan database hingga minimum untuk kebutuhan Anda.
  • Hindari melakukan operasi tulis besar, seperti membangun kembali indeks, lebih sering daripada yang Anda butuhkan.
  • Untuk operasi pemuatan data besar, pertimbangkan untuk menggunakan indeks penyimpan kolom berkluster dan mengikuti praktik terbaik terkait. Pertimbangkan juga untuk mengurangi jumlah indeks nonclustered.
  • Dalam tingkat layanan Tujuan Umum, penyimpanan data yang disediakan lebih murah daripada harga penyimpanan cadangan. Jika Anda memiliki biaya penyimpanan cadangan berlebih yang terus-menerus tinggi, sebaiknya tingkatkan penyimpanan data untuk menghemat penyimpanan cadangan.
  • Gunakan tempdb alih-alih tabel permanen dalam logika aplikasi Anda untuk menyimpan hasil sementara atau data sementara.
  • Gunakan penyimpanan cadangan yang berlebihan secara lokal jika memungkinkan (misalnya, lingkungan dev/test).

Retensi Pencadangan

Azure SQL Managed Instance menyediakan retensi cadangan jangka pendek dan jangka panjang. Retensi jangka pendek memungkinkan PITR dalam periode retensi untuk database. Retensi jangka panjang menyediakan cadangan untuk berbagai persyaratan kepatuhan.

Retensi jangka pendek

Untuk semua database baru, dipulihkan, dan disalin, Azure SQL Managed Instance mempertahankan cadangan yang memadai untuk memungkinkan PITR dalam 7 hari terakhir secara default. Konfigurasi ini dapat diubah dalam rentang 1 hingga 35 hari. Layanan ini mengambil pencadangan penuh, diferensial, dan log reguler untuk memastikan bahwa database dapat di memulihkan ke titik waktu mana pun dalam periode retensi yang ditentukan untuk database atau instans terkelola.

Anda dapat menentukan opsi redundansi penyimpanan cadangan untuk STR saat membuat instans, lalu mengubahnya nanti. Jika Anda mengubah opsi redundansi cadangan setelah instans dibuat, cadangan baru akan menggunakan opsi redundansi baru. Salinan cadangan yang dibuat dengan opsi redundansi STR sebelumnya tidak dipindahkan atau disalin. Mereka ditinggalkan di akun penyimpanan asli hingga periode retensi kedaluwarsa. Seperti yang dijelaskan dalam Konsumsi penyimpanan Cadangan, cadangan yang disimpan untuk mengaktifkan PITR mungkin lebih lama dari periode retensi untuk memastikan pemulihan data yang tepat.

Jika Anda menghapus database, sistem menyimpan cadangan dengan cara yang sama seperti database online dengan periode retensi khususnya. Namun, untuk database yang dihapus, periode retensi diperbarui dari 1-35 hari menjadi 0-35 hari, sehingga memungkinkan untuk menghapus cadangan secara manual. Jika Anda perlu menyimpan cadangan lebih lama dari periode retensi jangka pendek maksimum 35 hari, Anda dapat mengaktifkan retensi jangka panjang.

Penting

Jika Anda menghapus instans terkelola, semua database di instans terkelola tersebut juga akan dihapus dan tidak dapat dipulihkan. Anda tidak dapat memulihkan instans terkelola yang dihapus. Tetapi jika Anda telah mengonfigurasi retensi jangka panjang untuk instans terkelola, cadangan LTR tidak akan dihapus. Anda kemudian dapat menggunakan cadangan tersebut untuk memulihkan database ke instans terkelola yang berbeda dalam langganan yang sama, ke titik waktu ketika cadangan LTR diambil. Untuk mempelajari lebih lanjut, tinjau Memulihkan cadangan jangka panjang.

Retensi jangka panjang (LTR)

Dengan SQL Managed Instance, Anda dapat mengonfigurasi penyimpanan cadangan LTR penuh hingga 10 tahun di Azure Blob Storage. Setelah kebijakan LTR dikonfigurasi, pencadangan penuh secara otomatis disalin ke kontainer penyimpanan yang berbeda.

Untuk memenuhi persyaratan kepatuhan yang berbeda, Anda dapat memilih periode retensi yang berbeda untuk pencadangan mingguan, bulanan, dan/atau tahunan. Frekuensi tergantung pada kebijakan. Misalnya, pengaturan W=0, M=1, Y=0 akan membuat salinan LTR bulanan. Untuk informasi selengkapnya tentang LTR, lihat Retensi jangka panjang.

Redundansi penyimpanan cadangan LTR di Azure SQL Managed Instance diwarisi dari redundansi penyimpanan cadangan yang digunakan oleh STR pada saat kebijakan LTR ditentukan. Anda tidak dapat mengubahnya, bahkan jika redundansi penyimpanan cadangan STR berubah di masa mendatang.

Konsumsi penyimpanan bergantung pada frekuensi dan periode retensi cadangan LTR yang dipilih. Anda dapat menggunakan kalkulator harga LTR untuk memperkirakan biaya penyimpanan LTR.

Biaya penyimpanan cadangan

Azure SQL Managed Instance menghitung total penyimpanan cadangan yang dapat ditagih sebagai nilai kumulatif di semua file cadangan. Setiap jam, nilai ini dilaporkan ke alur penagihan Azure. Alur menggabungkan penggunaan per jam ini untuk mendapatkan konsumsi penyimpanan cadangan Anda pada akhir setiap bulan.

Jika database dihapus, konsumsi penyimpanan cadangan akan berkurang secara bertahap seiring usia pencadangan yang lebih lama bertambah dan dihapus. Karena cadangan diferensial dan cadangan log memerlukan pencadangan penuh sebelumnya untuk dapat dipulihkan, ketiga jenis cadangan akan dihapus secara menyeluruh bersama-sama dalam set mingguan. Setelah semua cadangan dihapus, penagihan akan berhenti.

Harga untuk penyimpanan cadangan bervariasi. Ini tergantung pada opsi redundansi penyimpanan cadangan yang Anda pilih dan wilayah Anda. Penyimpanan cadangan dibebankan berdasarkan gigabyte yang digunakan per bulan, pada tingkat yang sama untuk semua cadangan.

Redundansi penyimpanan cadangan memengaruhi biaya pencadangan dengan cara berikut:

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2
  • Geo-zone-redundant price = published price x 3.4

Untuk harga, tinjau halaman harga Azure SQL Managed Instance.

Catatan

Faktur Azure hanya memperlihatkan konsumsi penyimpanan cadangan berlebih, bukan seluruh konsumsi penyimpanan cadangan. Misalnya, dalam skenario hipotetis, jika Anda telah menyediakan penyimpanan data 4 TB, Anda akan mendapatkan ruang penyimpanan cadangan gratis sebesar 4 TB. Jika Anda menggunakan total ruang penyimpanan cadangan 5,8 TB, faktur Azure hanya menampilkan 1,8 TB, karena Anda hanya dikenakan biaya untuk penyimpanan cadangan berlebih yang telah Anda gunakan.

Untuk instans terkelola, ukuran total penyimpanan cadangan yang dapat ditagih dikumpulkan pada tingkat instans dan dihitung sebagai berikut:

Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage

Total penyimpanan cadangan yang dapat ditagih, jika ada, dibebankan dalam gigabyte per bulan untuk setiap wilayah, sesuai dengan tingkat redundansi penyimpanan cadangan yang telah Anda gunakan. Konsumsi penyimpanan cadangan tergantung pada beban kerja dan ukuran database individual dan instans terkelola. Database yang banyak dimodifikasi memiliki diferensial dan cadangan log yang lebih besar karena ukuran cadangan ini sebanding dengan jumlah perubahan data. Oleh karena itu, database tersebut akan dikenai biaya cadangan yang lebih tinggi.

Sebagai contoh yang disederhanakan, asumsikan bahwa database telah mengumpulkan 744 GB penyimpanan cadangan dan bahwa jumlah ini tetap konstan sepanjang bulan penuh karena database benar-benar menganggur. Untuk mengonversi konsumsi penyimpanan kumulatif ini menjadi penggunaan per jam, bagi dengan 744,0 (31 hari per bulan kali 24 jam per hari). SQL Managed Instance melaporkan ke alur penagihan Azure bahwa database menggunakan cadangan PITR 1 GB setiap jam, pada tingkat konstanta. Penagihan Azure menggabungkan konsumsi ini dan menunjukkan penggunaan 744 GB selama sebulan penuh. Biaya didasarkan pada tarif untuk gigabyte per bulan di wilayah Anda.

Berikut adalah contoh lain. Misalkan database diam yang sama retensinya meningkat dari 7 hari menjadi 14 hari di pertengahan bulan. Peningkatan ini menghasilkan total penggandaan penyimpanan cadangan menjadi 1.488 GB. SQL Managed Instance akan melaporkan penggunaan 1 GB selama jam 1 hingga 372 (paruh pertama bulan ini). Penggunaan akan dilaporkan sebagai 2 GB selama jam 373 hingga 744 (paruh kedua bulan). Penggunaan ini akan diagregasi ke tagihan akhir sebesar 1.116 GB per bulan. Biaya retensi tidak langsung meningkat. Mereka meningkat secara bertahap setiap hari, karena cadangan tumbuh sampai mencapai periode retensi maksimum 14 hari.

Skenario tagihan cadangan yang sebenarnya lebih kompleks. Karena tingkat perubahan dalam database tergantung pada beban kerja dan bervariasi dari waktu ke waktu, ukuran setiap diferensial dan cadangan log juga akan bervariasi. Konsumsi penyimpanan cadangan per jam berfluktuasi sesuai.

Setiap cadangan diferensial juga berisi semua perubahan yang dilakukan dalam database sejak pencadangan penuh terakhir. Jadi, ukuran total semua cadangan diferensial secara bertahap meningkat selama seminggu. Kemudian turun tajam setelah set pencadangan penuh, diferensial, dan log yang lebih lama kehabisan usia.

Misalnya, asumsikan bahwa aktivitas tulis yang berat, seperti pembangunan ulang indeks, berjalan tepat setelah pencadangan penuh selesai. Modifikasi yang dibuat ulang indeks kemudian akan disertakan:

  • Dalam cadangan log transaksi yang diambil selama durasi pembangunan ulang.
  • Di cadangan diferensial berikutnya.
  • Dalam setiap cadangan diferensial yang diambil sampai pencadangan penuh berikutnya terjadi.

Untuk mengurangi ukuran semua cadangan diferensial, cadangan diferensial yang terlalu besar yang melebihi 750 GB dan menjadi sama dengan 75% dari ukuran database dipromosikan ke cadangan penuh, jika pencadangan penuh terakhir diambil lebih dari 24 jam yang lalu.

Memantau biaya

Untuk memahami biaya penyimpanan cadangan, buka Cost Management + Billing di portal Azure. Pilih Cost Management, lalu pilih Analisis biaya. Pilih langganan yang diinginkan untuk Cakupan, lalu filter untuk periode waktu dan layanan yang Anda minati sebagai berikut:

  1. Tambahkan filter untuk Nama layanan.

  2. Di daftar dropdown, pilih instans terkelola sql untuk instans terkelola.

  3. Tambahkan filter lain untuk subkategori Meter.

  4. Untuk memantau biaya pencadangan PITR, dalam daftar dropdown, pilih penyimpanan cadangan pitr instans terkelola. Meter muncul hanya jika konsumsi penyimpanan cadangan ada.

    Untuk memantau biaya pencadangan LTR, dalam daftar dropdown, pilih instans terkelola sql - penyimpanan cadangan ltr. Meter muncul hanya jika konsumsi penyimpanan cadangan ada.

Subkataan Penyimpanan dan komputasi mungkin juga menarik minat Anda, tetapi tidak terkait dengan biaya penyimpanan cadangan.

Cuplikan layar yang memperlihatkan analisis biaya penyimpanan cadangan.

Penting

Meteran hanya terlihat untuk penghitung yang saat ini sedang digunakan. Jika penghitung tidak tersedia, kemungkinan kategori saat ini tidak digunakan. Misalnya, penghitung instans terkelola tidak akan ada untuk pelanggan yang tidak memiliki instans terkelola yang disebarkan. Demikian juga, penghitung penyimpanan tidak akan terlihat untuk sumber daya yang tidak menggunakan penyimpanan. Jika tidak ada konsumsi penyimpanan cadangan PITR atau LTR, meteran ini tidak akan terlihat.

Cadangan terenkripsi

Jika database Anda dienkripsi dengan TDE, cadangan secara otomatis dienkripsi saat tidak digunakan, termasuk cadangan LTR. Semua database baru di Azure SQL dikonfigurasi dengan TDE yang diaktifkan secara default. Untuk informasi selengkapnya tentang TDE, lihat Enkripsi data transparan dengan SQL Managed Instance.

Microsoft bertanggung jawab penuh untuk menyimpan dan memutar kunci untuk database dengan kunci yang dikelola layanan (SMK). Cadangan, baik PITR atau LTR, yang diambil dari instans yang mengaktifkan TDE dengan SMK dapat dipulihkan oleh Microsoft.

Pencadangan otomatis yang disimpan di akun penyimpanan yang dikelola Azure secara otomatis dienkripsi oleh penyimpanan Azure. Pelajari selengkapnya tentang enkripsi Azure Storage untuk data tidak aktif.

Integritas cadangan

Semua pencadangan database diambil dengan opsi CHECKSUM untuk memberikan integritas pencadangan tambahan. Pengujian otomatis pencadangan database otomatis oleh tim teknik Azure SQL saat ini tidak tersedia untuk Azure SQL Managed Instance. Jadwalkan pemulihan cadangan pengujian dan DBCC CHECKDB pada database Anda di SQL Managed Instance di sekitar beban kerja Anda.

Meskipun sistem tidak memverifikasi integritas cadangan, masih ada perlindungan bawaan dari cadangan Anda yang memperingatkan Microsoft jika ada masalah dengan layanan cadangan. Selain itu, Microsoft mendukung Anda jika terjadi masalah dengan cadangan, seperti jika pencadangan penuh tidak diambil, layanan cadangan macet, cadangan log keluar dari SLA, atau jika perangkat keras atau perangkat lunak cadangan rusak.

Menggunakan Kebijakan Azure untuk memberlakukan redundansi penyimpanan cadangan

Jika Anda memiliki persyaratan residensi data yang mengharuskan Anda menyimpan semua data dalam satu wilayah Azure, Anda mungkin ingin menerapkan pencadangan redundan zona atau redundan secara lokal untuk instans terkelola SQL Anda dengan menggunakan Azure Policy.

Azure Policy adalah layanan yang dapat Anda gunakan untuk membuat, menetapkan, dan mengelola kebijakan yang menerapkan aturan ke sumber daya Azure. Azure Policy membantu Anda menjaga sumber daya ini mematuhi standar perusahaan dan perjanjian tingkat layanan Anda. Untuk mengetahui informasi selengkapnya, lihat Gambaran Umum Azure Policy.

Kebijakan redundansi penyimpanan cadangan bawaan

Untuk menerapkan persyaratan residensi data pada tingkat organisasi, Anda dapat menetapkan kebijakan ke langganan dengan menggunakan portal Azure atau Azure PowerShell. Misalnya, jika Anda menetapkan kebijakan bawaan berikut di tingkat grup langganan atau sumber daya, pengguna dalam langganan tidak akan dapat membuat instans terkelola dengan penyimpanan cadangan geo-redundan melalui portal Azure atau Azure PowerShell: SQL Managed Instances harus menghindari penggunaan redundansi cadangan GRS.

Untuk daftar lengkap definisi kebijakan bawaan untuk SQL Managed Instance, tinjau referensi kebijakan.

Penting

Kebijakan Azure tidak diberlakukan saat Anda membuat database melalui T-SQL. Untuk menerapkan residensi data saat Anda membuat database dengan menggunakan T-SQL, gunakan LOCAL atau ZONE sebagai input ke parameter BACKUP_STORAGE_REDUNDANCY dalam pernyataan CREATE DATABASE.

Kepatuhan

Jika retensi default tidak memenuhi persyaratan kepatuhan, Anda dapat mengubah periode retensi PITR. Untuk mengetahui informasi selengkapnya, lihat Mengubah periode retensi cadangan PITR.

Catatan

Artikel Ubah pengaturan pencadangan otomatis menyediakan langkah-langkah tentang cara menghapus data pribadi dari perangkat atau layanan dan dapat digunakan untuk mendukung kewajiban Anda berdasarkan GDPR. Untuk informasi umum tentang GDPR, lihat bagian GDPR dari Pusat Kepercayaan Microsoft dan bagian GDPR dari portal Kepercayaan Layanan.

Langkah berikutnya