Pencadangan otomatis - Azure SQL Database & SQL Managed Instance

BERLAKU UNTUK: Azure SQL Database Azure SQL Managed Instance

Catatan

Artikel ini memberikan langkah-langkah tentang cara menghapus data privat dari perangkat atau layanan dan dapat digunakan untuk mendukung kewajiban Anda berdasarkan GDPR. Untuk informasi umum tentang GDPR, lihat bagian GDPR di Pusat Kepercayaan Microsoft dan bagian GDPR di portal Kepercayaan Layanan.

Apa itu pencadangan database?

Pencadangan database adalah bagian penting dari setiap kelangsungan bisnis dan strategi pemulihan bencana karena melindungi Anda dari kerusakan dan penghapusan data. Dengan pencadangan ini, database dapat dipulihkan ke titik waktu dalam periode retensi yang dikonfigurasi. Jika aturan perlindungan data Anda mengharuskan cadangan Anda tersedia untuk jangka waktu yang lama (hingga 10 tahun), Anda dapat mengonfigurasi retensi jangka panjang untuk database tunggal dan gabungan.

Pencadangan dan pemulihan penting

Database di Azure SQL Managed Instance dan database non-Hyperscale di Azure SQL Database menggunakan teknologi mesin SQL Server untuk mencadangkan dan memulihkan data. Database Hyperscale memiliki arsitektur unik dan memanfaatkan teknologi berbeda untuk pencadangan dan pemulihan. Untuk mempelajari selengkapnya, lihat Pencadangan Hyperscale dan redundansi penyimpanan.

Frekuensi pencadangan

Baik Azure SQL Database maupun Azure SQL Managed Instance menggunakan teknologi SQL Server untuk membuat pencadangan penuh setiap minggu, pencadangan diferensial setiap 12-24 jam, dan pencadangan log setiap 5 hingga 10 menit. Frekuensi pencadangan log didasarkan pada ukuran komputasi dan jumlah aktivitas database.

Saat Anda memulihkan database, layanan menentukan pencadangan penuh, diferensial, dan log mana yang perlu dipulihkan.

Database Hyperscale menggunakan teknologi pencadangan snapshot.

Redundansi penyimpanan cadangan

Secara default, SQL Database dan SQL Managed Instance menyimpan data dalam blob penyimpanan geo-redundan yang direplikasi ke wilayah yang dipasangkan. Redundansi geo membantu melindungi dari pemadaman yang berdampak pada penyimpanan cadangan di wilayah utama dan memungkinkan Anda agar dapat memulihkan server Anda ke wilayah yang berbeda jika terjadi bencana.

Opsi untuk mengonfigurasi redundansi penyimpanan cadangan memberikan fleksibilitas dalam memilih antara blob penyimpanan redundansi lokal, redundansi zona, atau redundansi geo. Untuk memastikan bahwa data Anda tetap berada di wilayah yang sama dengan tempat penyebaran instans terkelola atau database di Azure SQL Database disebarkan, Anda dapat mengubah redundansi penyimpanan cadangan geo-redundan default dan mengonfigurasi blob penyimpanan redundan secara lokal atau zona-redundan untuk keperluan pencadangan. Mekanisme redundansi penyimpanan menyimpan beberapa salinan data Anda sehingga terlindungi dari peristiwa yang terencana dan tidak terencana, termasuk kegagalan perangkat keras sementara, pemadaman jaringan atau listrik, atau bencana alam besar. Redundansi penyimpanan cadangan yang dikonfigurasi diterapkan pada pengaturan retensi cadangan jangka pendek yang digunakan untuk pemulihan titik waktu (PITR) dan pencadangan retensi jangka panjang yang digunakan untuk pencadangan jangka panjang (LTR).

Untuk Azure SQL Database, redundansi penyimpanan cadangan dapat dikonfigurasi pada saat pembuatan database atau dapat diperbarui untuk database yang sudah ada; perubahan yang dilakukan pada database yang sudah ada hanya berlaku untuk pencadangan di masa mendatang. Setelah redundansi penyimpanan cadangan dari database yang ada diperbarui, mungkin diperlukan waktu hingga 48 jam agar perubahan diterapkan. Pemulihan lokasi geografis dinonaktifkan segera setelah database diperbarui untuk menggunakan penyimpanan redundan lokal atau zona. Untuk database Hyperscale, opsi redundansi penyimpanan yang dipilih akan digunakan untuk masa pakai database untuk redundansi penyimpanan data dan redundansi penyimpanan cadangan. Pelajari selengkapnya di Pencadangan hyperscale dan redundansi penyimpanan.

Penting

Penyimpanan redundan zona saat ini hanya tersedia di wilayah tertentu.

Penggunaan pencadangan

Anda bisa menggunakan pencadangan ini untuk:

• Pemulihan database yang sudah ada pada titik waktu tertentu - Pulihkan database yang sudah ada ke titik waktu sebelumnya dalam periode penyimpanan dengan menggunakan portal Microsoft Azure, Azure PowerShell, Azure CLI, atau REST API. Untuk SQL Database, operasi ini membuat database baru di server yang sama dengan database asli, tetapi menggunakan nama yang berbeda untuk menghindari penimpaan database asli. Setelah pemulihan selesai, Anda bisa menghapus database asli. Sebagai alternatif, Anda bisa mengganti nama database asli, lalu mengganti nama database yang dipulihkan menjadi nama database asli. Demikian pula, untuk SQL Managed Instance, operasi ini membuat salinan database pada instans terkelola yang sama atau berbeda di langganan yang sama dan wilayah yang sama.
• Pemulihan database yang dihapus pada titik waktu tertentu - Pulihkan database yang dihapus ke waktu penghapusan atau ke titik waktu mana pun dalam periode penyimpanan. Database yang dihapus hanya dapat dipulihkan di server yang sama atau di instans terkelola tempat database asli dibuat. Saat menghapus database, layanan mengambil cadangan log akhir sebelum penghapusan untuk mencegah kehilangan data.
• Pemulihan geografis - Memulihkan database ke wilayah geografis lain. Dengan pemulihan geografis, Anda dapat melakukan pemulihan dari bencana geografis ketika database atau cadangan di wilayah utama tidak dapat diakses. Pemulihan ini membuat database baru di server atau instans terkelola yang ada, di wilayah Azure mana pun.

  Penting

  Pemulihan geo hanya tersedia untuk database atau Azure SQL Database atau instans terkelola yang dikonfigurasi dengan penyimpanan cadangan geo-redundan. Jika saat ini Anda tidak menggunakan cadangan replika-geografis untuk database, Anda dapat mengubahnya dengan mengonfigurasi redundansi penyimpanan cadangan.

• Pemulihan dari pencadangan jangka panjang - Pulihkan database dari cadangan jangka panjang tertentu dari database tunggal atau database gabungan, jika database telah dikonfigurasi dengan kebijakan penyimpanan jangka panjang (LTR). LTR memungkinkan Anda memulihkan database versi lama dengan menggunakan portal Microsoft Azure, Azure CLI, atau Azure PowerShell untuk memenuhi permintaan kepatuhan atau menjalankan aplikasi versi lama. Untuk mengetahui informasi selengkapnya, lihat Retensi jangka panjang.

Catatan

Di Azure Storage, istilah replikasi mengacu pada penyalinan blob dari satu lokasi ke lokasi lain. Di SQL, replikasi database mengacu pada berbagai teknologi yang digunakan untuk menjaga beberapa database sekunder disinkronkan dengan database utama.

Memulihkan kemampuan dan fitur Azure SQL Database dan Azure SQL Managed Instance

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

Properti Pencadangan	Pemulihan ke titik waktu tertentu (PITR)	Pengembalian geografis	Pemulihan pencadangan jangka panjang
Jenis pencadangan SQL	Penuh, Diferensial, Log	Salinan cadangan PITR yang direplikasi	Hanya pencadangan penuh
Tujuan Titik Pemulihan (RPO)	5-10 menit, berdasarkan ukuran komputasi dan jumlah aktivitas database.	Hingga 1 jam, berdasarkan replikasi geografis.*	Satu minggu (atau kebijakan pengguna).
Tujuan Waktu Pemulihan (RTO)	Durasi pemulihan biasanya memerlukan waktu <12 jam, tetapi bisa lebih lama tergantung pada ukuran dan aktivitas. Lihat Pemulihan.	Durasi pemulihan biasanya memerlukan waktu <12 jam, tetapi bisa lebih lama tergantung pada ukuran dan aktivitas. Lihat Pemulihan.	Durasi pemulihan biasanya memerlukan waktu <12 jam, tetapi bisa lebih lama tergantung pada ukuran dan aktivitas. Lihat Pemulihan.
Retensi	7 hari secara default, Hingga 35 hari	Diaktifkan secara default, sama seperti sumber.**	Tidak diaktifkan secara default, Retensi Hingga 10 tahun.
Penyimpanan Azure	Redundansi geo secara default. Dapat mengonfigurasi penyimpanan redundan zona atau redundan lokal.	Tersedia saat redundansi penyimpanan cadangan PITR diatur ke redundan geo. Tidak tersedia ketika penyimpanan cadangan PITR adalah zona atau penyimpanan redundan lokal.	Redundansi geo secara default. Dapat mengonfigurasi penyimpanan redundan zona atau lokal.
Penggunaan untuk pembuatan database baru di wilayah yang sama	Didukung	Didukung	Didukung
Penggunaan untuk pembuatan database baru di wilayah lain	Tidak Didukung	Didukung di wilayah Azure mana pun	Didukung di wilayah Azure mana pun
Penggunaan untuk pembuatan database baru di Langganan lain	Tidak Didukung	Tidak Didukung***	Tidak Didukung***
Pemulihan melalui portal Microsoft Azure	Ya	Ya	Ya
Pemulihan melalui PowerShell	Ya	Ya	Ya
Pemulihan melalui Azure CLI	Ya	Ya	Ya

* Untuk aplikasi penting bisnis yang memerlukan ukuran database yang besar dan harus memastikan kelangsungan bisnis, gunakan Grup failover otomatis.

** Semua cadangan PITR disimpan pada penyimpanan redundansi geografis secara default. Karena alasan tersebut, pemulihan lokasi geografis diaktifkan secara default.

*** Penanganan masalah adalah memulihkan ke server baru dan menggunakan Resource Move 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 menggunakan contoh berikut:

Operasi	portal Microsoft Azure	Azure CLI	Azure PowerShell
Mengubah retensi cadangan	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL
Mengubah retensi cadangan jangka panjang	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL
Memulihkan database dari titik waktu tertentu	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL
Memulihkan database yang terhapus	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL	SQL Database Instans Terkelola SQL
Memulihkan database dari penyimpanan blob Azure			Instans Terkelola SQL

Penjadwalan pencadangan

Pencadangan penuh pertama dijadwalkan segera setelah database baru dibuat atau dipulihkan. Pencadangan ini biasanya selesai dalam waktu 30 menit, tetapi bisa memakan waktu lebih lama jika database berukuran besar. Misalnya, pencadangan awal dapat memakan waktu lebih lama pada database yang dipulihkan atau salinan database, yang biasanya lebih besar dari database baru. Setelah pencadangan penuh pertama, semua pencadangan lebih lanjut dijadwalkan dan dikelola secara otomatis. Waktu yang tepat untuk semua pencadangan database ditentukan oleh SQL Database atau layanan SQL Managed Instance agar menyeimbangkan beban kerja sistem secara keseluruhan. Anda tidak bisa mengubah jadwal tugas pencadangan atau menonaktifkannya. Hyperscale menggunakan mekanisme penjadwalan pencadangan yang berbeda, lihat Penjadwalan pencadangan Hyperscale untuk detail selengkapnya.

Penting

Untuk database baru, yang dipulihkan, atau salinan, kemampuan pemulihan ke titik waktu tertentu tersedia sejak pencadangan log awal yang mengikuti pencadangan lengkap awal dibuat.

Konsumsi penyimpanan cadangan

Dengan teknologi pencadangan dan pemulihan SQL Server, memulihkan database ke titik waktu tertentu membutuhkan serangkaian pencadangan tanpa gangguan yang terdiri dari satu cadangan lengkap, satu cadangan diferensial yang bersifat opsional, dan satu atau beberapa cadangan log. Jadwal pencadangan Azure SQL Database dan Azure SQL Managed Instance mencakup satu pencadangan penuh setiap minggu. Oleh karena itu, untuk mengaktifkan PITR dalam seluruh periode retensi, sistem harus menyimpan cadangan log tambahan penuh, diferensial, dan cadangan log hingga seminggu lebih lama dari periode retensi yang dikonfigurasi.

Dengan kata lain, untuk setiap titik waktu selama periode retensi, harus ada pencadangan penuh yang lebih lama dari waktu terdahulu periode retensi, serta rantai cadangan log diferensial dan transaksi yang tidak terganggu dari pencadangan penuh itu sampai pencadangan lengkap berikutnya. Database Hyperscale menggunakan mekanisme penjadwalan pencadangan yang berbeda, untuk detail selengkapnya lihat Penjadwalan pencadangan Hyperscale dan untuk detail selengkapnya tentang cara memantau biaya penyimpanan, lihat Biaya penyimpanan cadangan Hyperscale.

Catatan

Untuk menyediakan PITR, cadangan tambahan disimpan hingga seminggu lebih lama dari periode retensi yang dikonfigurasi. Penyimpanan cadangan dibebankan pada tingkat yang sama untuk semua cadangan.

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, cadangan dikompresi untuk mengurangi kompresi dan biaya penyimpanan cadangan. Rasio kompresi cadangan rata-rata adalah 3-4 kali, tetapi dapat lebih rendah atau lebih tinggi secara signifikan tergantung pada sifat data dan apakah kompresi data digunakan dalam database atau tidak.

SQL Database dan SQL Managed Instance menghitung total penyimpanan cadangan yang Anda gunakan sebagai nilai kumulatif. Setiap jam, nilai ini dilaporkan ke alur penagihan Azure, yang 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 dihentikan.

Penting

Cadangan database dipertahankan untuk menyediakan PITR meskipun database tersebut telah dihapus. Meskipun menghapus dan membuat ulang database dapat menghemat biaya penyimpanan dan komputasi, hal tersebut dapat meningkatkan biaya penyimpanan cadangan, karena layanan mempertahankan cadangan untuk setiap database yang dihapus, setiap kali dihapus.

Memantau konsumsi

Untuk database vCore di Azure SQL Database, penyimpanan yang digunakan oleh setiap jenis cadangan (penuh, diferensial, dan log) dilaporkan pada panel pemantauan database sebagai metrik terpisah. Diagram berikut menunjukkan cara memantau konsumsi penyimpanan cadangan untuk database tunggal. Fitur ini saat ini tidak tersedia untuk instans terkelola.

Instruksi tentang cara memantau penggunaan di Hyperscale dapat ditemukan di Penggunaan cadangan pemantauan Hyperscale

Menyempurnakan konsumsi penyimpanan cadangan

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

• Kurangi periode retensi cadangan ke titik seminimal mungkin untuk kebutuhan Anda.
• Hindari melakukan operasi tulis besar, seperti membangun kembali indeks, lebih sering daripada yang Anda butuhkan.
• Untuk operasi beban data yang besar, pertimbangkan menggunakan indeks penyimpan kolom dan mengikuti praktik terbaik, dan/atau mengurangi jumlah indeks non-kluster.
• 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, bukan tabel permanen dalam logika aplikasi, untuk menyimpan hasil sementara dan/atau data sementara.
• Gunakan penyimpanan cadangan redundan lokal jika memungkinkan (misalnya lingkungan pengembangan/pengujian)

Rentensi pencadangan

Azure SQL Database dan Azure SQL Managed Instance menyediakan retensi cadangan jangka pendek dan jangka panjang. Cadangan retensi jangka pendek memungkinkan Point-In-Time-Restore/Pemulihan Setiap Saat (PITR) dengan periode retensi untuk database, sementara retensi jangka panjang menyediakan cadangan untuk berbagai persyaratan kepatuhan.

Retensi jangka pendek

Untuk semua database baru yang dipulihkan dan yang disalin, Azure SQL Database dan Azure SQL Managed Instance mempertahankan cadangan yang memadai untuk memungkinkan PITR dalam 7 hari terakhir secara default. Cadangan penuh, diferensial, dan log reguler diambil untuk memastikan database dapat dipulihkan pada suatu waktu dalam periode retensi yang ditentukan untuk database atau instans terkelola. Selain itu, untuk Azure SQL Database, cadangan diferensial dapat dikonfigurasi ke frekuensi 12 jam atau 24 jam.

Catatan

Frekuensi cadangan diferensial 24 jam dapat meningkatkan waktu yang diperlukan untuk memulihkan database.

Kecuali untuk database tingkat Dasar, Anda dapat mengubah periode retensi cadangan sesuai dengan setiap database aktif dalam rentang 1-35 hari. Seperti yang dijelaskan di Konsumsi penyimpanan cadangan, cadangan yang disimpan untuk mengaktifkan PITR mungkin berusia lebih lama dari periode retensi. Khusus untuk Azure SQL Managed Instance, Anda dapat mengatur tingkat retensi cadangan PITR setelah database dihapus dalam rentang 0-35 hari.

Catatan

Retensi cadangan jangka pendek selama 1-35 hari untuk database Hyperscale sekarang dalam Pratinjau. Untuk mempelajari selengkapnya, tinjau Mengelola retensi cadangan di Hyperscale.

Jika Anda menghapus database, sistem tetap menyimpan cadangan dengan cara yang sama seperti database daring dengan periode penyimpanan spesifiknya. Anda tidak bisa mengubah periode retensi cadangan untuk database yang dihapus.

Penting

Jika Anda menghapus server atau instans terkelola, semua database di server atau instans terkelola tersebut juga akan dihapus dan tidak dapat dipulihkan. Anda tidak dapat memulihkan server atau instans terkelola yang dihapus. Tetapi jika Anda telah mengonfigurasi retensi jangka panjang (LTR) untuk database atau instans terkelola, cadangan retensi jangka panjang tidak dihapus. Ia dapat digunakan untuk memulihkan database di server atau instans terkelola yang berbeda dalam langganan yang sama ke titik waktu ketika cadangan retensi jangka panjang diambil.

Retensi cadangan untuk tujuan PITR dalam 1-35 hari terakhir terkadang disebut retensi cadangan jangka pendek. Jika perlu menyimpan cadangan lebih lama dari periode retensi jangka pendek maksimum 35 hari, Anda dapat mengaktifkan retensi jangka panjang.

Retensi jangka panjang

Untuk SQL Database dan SQL Managed Instance, Anda dapat mengonfigurasi retensi jangka (LTR) panjang cadangan penuh hingga 10 tahun di penyimpanan Azure Blob. Setelah kebijakan LTR dikonfigurasi, pencadangan penuh secara otomatis disalin ke kontainer penyimpanan yang berbeda setiap minggu. Untuk memenuhi persyaratan kepatuhan yang berbeda, Anda dapat memilih periode retensi yang berbeda untuk pencadangan mingguan, bulanan, dan/atau tahunan. Konsumsi penyimpanan bergantung pada frekuensi dan periode retensi cadangan LTR yang dipilih. Anda dapat menggunakan kalkulator harga LTR untuk memperkirakan biaya penyimpanan LTR.

Penting

Memperbarui redundansi penyimpanan cadangan untuk Azure SQL Database yang ada hanya berlaku untuk cadangan mendatang yang diambil untuk database. Semua cadangan LTR yang ada untuk database akan terus berada di blob penyimpanan yang ada dan cadangan baru akan disimpan pada jenis blob penyimpanan yang diminta.

Untuk mengetahui informasi selengkapnya tentang LTR, lihat Retensi cadangan jangka panjang.

Biaya penyimpanan cadangan

Harga untuk penyimpanan cadangan bervariasi dan bergantung pada model pembelian (DTU atau vCore), opsi redundansi penyimpanan cadangan yang dipilih, dan juga wilayah Anda. Penyimpanan cadangan dibebankan untuk konsumsi per GB/bulan. Untuk mengetahui harga, lihat halaman harga Azure SQL Database dan halaman harga SQL Managed Instance.

Untuk informasi model pembelian vCore dan DTU lebih lanjut, lihat Memilih antara model pembelian vCore dan DTU.

Catatan

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

Model DTU

Dalam model DTU, tidak ada biaya tambahan untuk penyimpanan cadangan untuk database dan kumpulan elastis. Harga penyimpanan cadangan adalah bagian dari database atau harga kumpulan.

Model vCore

Untuk database tunggal di SQL Database, penyimpanan cadangan yang berukuran 100 persen sama dengan penyimpanan data maksimum untuk database akan disediakan tanpa biaya tambahan. Untuk kumpulan database elastis dan instans terkelola, penyimpanan cadangan yang berukuran 100 persen sama dengan penyimpanan data maksimum untuk kumpulan atau ukuran penyimpanan instans maksimum, masing-masing, disediakan tanpa biaya tambahan.

Untuk database tunggal, persamaan ini digunakan untuk menghitung total penggunaan penyimpanan cadangan yang dapat dikenai tagihan:

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

Untuk database yang dikumpulkan, total ukuran penyimpanan cadangan yang dapat ditagih diagregasi di tingkat kumpulan dan dihitung sebagai berikut:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

Untuk database terkelola, total ukuran penyimpanan cadangan yang dapat ditagih diagregasi di tingkat kumpulan 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 dikenakan biaya, jika ada, akan dikenakan biaya dalam GB/bulan sesuai tingkat redundansi penyimpanan cadangan yang digunakan. Konsumsi penyimpanan cadangan ini akan bergantung pada beban kerja dan ukuran database individual, kumpulan database elastis, 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.

Rumus yang digunakan untuk menghitung biaya penyimpanan cadangan untuk database Hyperscale dapat ditemukan di Biaya penyimpanan cadangan Hyperscale.

SQL Database dan SQL Managed Instance menghitung total penyimpanan cadangan yang dapat ditagih sebagai nilai kumulatif di semua file cadangan. Setiap jam, nilai ini dilaporkan ke alur tagihan Azure, yang 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, tagihan akan dihentikan.

Sebagai contoh sederhana, asumsikan database telah mengumpulkan penyimpanan cadangan sebesar 744 GB dan jumlah ini tetap konstan sepanjang satu bulan penuh karena database benar-benar diam. Untuk mengonversi konsumsi penyimpanan kumulatif ini menjadi penggunaan per jam, bagi jumlah tersebut dengan 744,0 (31 hari per bulan *24 jam per hari). SQL Database akan melaporkan ke alur tagihan Azure bahwa database mengonsumsi 1 GB cadangan PITR setiap jam, pada tingkat konstan. Tagihan Azure akan menggabungkan konsumsi ini dan menunjukkan penggunaan 744 GB untuk keseluruhan bulan. Biaya akan didasarkan pada tarif jumlah/GB/bulan di wilayah Anda.

Sekarang, contoh yang lebih kompleks. 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 Database akan melaporkan penggunaan 1 GB untuk jam 1 hingga 372 (paruh pertama bulan). Penggunaan akan dilaporkan sebagai 2 GB selama jam 373 hingga 744 (paruh kedua bulan). Penggunaan ini akan dikumpulkan ke tagihan akhir sebesar 1.116 GB/bulan.

Skenario tagihan cadangan yang sebenarnya lebih kompleks. Karena tingkat perubahan dalam database bergantung pada beban kerja dan bervariasi seiring waktu, ukuran setiap cadangan diferensial dan log akan bervariasi juga, sehingga konsumsi penyimpanan cadangan per jam berfluktuasi. Selain itu, setiap cadangan diferensial berisi semua perubahan yang dilakukan dalam database sejak cadangan penuh terakhir, sehingga ukuran total semua cadangan diferensial secara bertahap meningkat selama seminggu. Setelahnya, ukurannya turun tajam sekali setelah set cadangan penuh, diferensial, dan log yang lebih lama menua. Misalnya, jika aktivitas penulisan berat seperti pembangunan kembali indeks telah dijalankan tepat setelah pencadangan lengkap selesai, maka modifikasi yang dilakukan oleh indeks membangun kembali akan dimasukkan dalam cadangan log yang diambil selama durasi pembangunan kembali. Ini juga dilakukan di cadangan diferensial berikutnya dan di setiap cadangan diferensial yang diambil sampai cadangan lengkap berikutnya terjadi. Untuk skenario terakhir dalam database yang lebih besar, pengoptimalan dalam layanan akan membuat cadangan penuh, bukan cadangan diferensial, jika cadangan diferensial akan terlalu besar sebaliknya. Hal ini mengurangi ukuran semua cadangan diferensial hingga cadangan penuh berikutnya.

Anda dapat memantau total konsumsi penyimpanan cadangan untuk setiap jenis cadangan (penuh, diferensial, log) dari waktu ke waktu seperti yang dijelaskan di Memantau konsumsi.

Redundansi penyimpanan cadangan

Redundansi penyimpanan cadangan berdampak pada biaya pencadangan dengan cara berikut:

• harga redundan lokal = x
• harga redundan-zona = 1,25x
• harga redundan-geo = 2x

Untuk mengetahui detail selengkapnya terkait harga penyimpanan cadangan, kunjungi halaman harga Azure SQL Database dan halaman harga Azure SQL Managed Instance.

Penting

Redundansi penyimpanan pencadangan untuk Hyperscale hanya dapat diatur selama pembuatan database. Pengaturan ini tidak dapat dimodifikasi setelah sumber daya tersedia. Proses Penyalinan database dapat digunakan untuk memperbarui pengaturan redundansi penyimpanan cadangan untuk database Hyperscale yang sudah ada. Pelajari selengkapnya di Pencadangan hyperscale dan redundansi penyimpanan.

Biaya pemantauan

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

1. Tambahkan filter untuk Nama layanan.
2. Dalam daftar drop-down, pilih database sql untuk database tunggal atau kumpulan database elastis, atau pilih instan terkelola sql untuk instans terkelola.
3. Tambahkan filter lain untuk subkategori Meter.
4. Untuk memantau biaya pencadangan PITR, dalam daftar drop-down pilih penyimpanan cadangan pitr kumpulan elastis/tunggal untuk database tunggal atau kumpulan database elastis, atau pilih penyimpanan cadangan pitr instans terkelola untuk instans terkelola. Meter hanya akan muncul jika terdapat konsumsi.
5. Untuk memantau biaya pencadangan LTR, dalam daftar drop-down pilih penyimpanan cadangan ltr untuk database tunggal atau kumpulan database elastis, atau pilih penyimpanan cadangan ltr - instans terkelola sql untuk instans terkelola. Meter hanya akan muncul jika terdapat konsumsi.

Subkategori Penyimpanan dan komputasi mungkin juga membuat Anda tertarik, tetapi kedua subkategori tidak terkait dengan biaya penyimpanan cadangan.

Penting

Meter hanya terlihat untuk penghitung yang saat ini sedang digunakan. Jika penghitung tidak tersedia, kemungkinan kategori tersebut saat ini tidak digunakan. Misalnya, penghitung instans terkelola tidak akan tersedia untuk pelanggan yang tidak memiliki instans terkelola yang disebarkan. Demikian juga, penghitung penyimpanan tidak akan terlihat untuk sumber daya yang tidak mengonsumsi penyimpanan. Misalnya, jika tidak ada konsumsi penyimpanan cadangan PITR atau LTR, meter ini tidak akan ditampilkan.

Untuk informasi lebih lanjut, lihat Manajemen biaya Azure SQL Database.

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 mengetahui informasi selengkapnya tentang TDE, lihat Enkripsi Data Transparan dengan SQL Database & SQL Managed Instance.

Integritas cadangan

Secara berkelanjutan, tim teknik Azure SQL secara otomatis menguji pemulihan cadangan database otomatis. (Pengujian ini saat ini tidak tersedia di SQL Managed Instance. Anda harus menjadwalkan DBCC CHECKDB di database Anda di SQL Managed Instance, dijadwalkan di sekitar beban kerja Anda.)

Saat pemulihan waktu tertentu, database juga mendapatkan pemeriksaan integritas DBCC CHECKDB.

Setiap masalah yang ditemukan selama pemeriksaan integritas akan menghasilkan peringatan bagi tim teknik. Untuk mengetahui informasi selengkapnya, lihat Integritas Data di SQL Database.

Semua pencadangan database diambil dengan opsi CHECKSUM untuk memberikan integritas pencadangan tambahan.

Kepatuhan

Saat memigrasikan database Anda dari tingkat layanan berbasis DTU ke tingkat layanan berbasis vCore, penyimpanan PITR dipertahankan untuk memastikan bahwa kebijakan pemulihan data aplikasi Anda tidak terganggu. 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 ini memberikan langkah-langkah tentang cara menghapus data privat dari perangkat atau layanan dan dapat digunakan untuk mendukung kewajiban Anda berdasarkan GDPR. Untuk informasi umum tentang GDPR, lihat bagian GDPR di Pusat Kepercayaan Microsoft dan bagian GDPR di portal Kepercayaan Layanan.

Mengubah kebijakan retensi jangka pendek

Anda dapat mengubah periode retensi cadangan PITR default dengan menggunakan portal Microsoft Azure, PowerShell, atau REST API. Contoh-contoh berikut menggambarkan cara mengubah retensi PITR menjadi 28 hari dan cadangan diferensial menjadi interval 24 jam.

Peringatan

Jika Anda mengurangi periode retensi saat ini, Anda akan kehilangan kemampuan untuk melakukan pemulihan ke titik waktu yang lebih lama dari periode retensi baru. Cadangan yang tidak lagi diperlukan untuk menyediakan PITR dalam periode retensi baru akan dihapus. Jika mengurangi periode retensi saat ini, Anda tidak langsung mendapatkan kemampuan untuk melakukan pemulihan ke titik waktu yang lebih lama dari periode retensi baru. Anda mendapatkan kemampuan tersebut seiring waktu, karena sistem mulai mempertahankan cadangan lebih lama.

Catatan

API ini hanya akan memengaruhi periode retensi PITR. Jika Anda mengonfigurasi LTR untuk database Anda, database tidak akan terpengaruh. Untuk mengetahui informasi cara mengubah periode retensi LTR, lihat Retensi jangka panjang.

Mengubah kebijakan retensi jangka pendek menggunakan portal Microsoft Azure

Untuk mengubah periode retensi cadangan PITR untuk database aktif dengan menggunakan portal Microsoft Azure, buka server atau instans terkelola dengan database yang periode retensinya ingin Anda ubah. Pilih Cadangan di panel kiri, lalu pilih tab Kebijakan penyimpanan. Pilih database yang retensi cadangan PITR-nya ingin Anda ubah. Lalu pilih Konfigurasikan retensi dari bilah tindakan.

SQL Database

Instans Terkelola SQL

Ubah kebijakan penyimpanan jangka pendek menggunakan Azure CLI

Persiapkan lingkungan Anda untuk Azure CLI.

• Gunakan lingkungan Bash di Azure Cloud Shell. Untuk informasi lebih lanjut, lihat Mulai Cepat Azure Cloud Shell - Bash.

  

• Jika Anda lebih memilih untuk menjalankan perintah referensi CLI secara lokal, pasang Azure CLI. Jika Anda menjalankan pada Windows atau macOS, pertimbangkan untuk menjalankan Azure CLI dalam kontainer Docker. Untuk informasi lebih lanjut, lihat Cara menjalankan Azure CLI di kontainer Docker.

  • Jika Anda menggunakan instalasi lokal, masuk ke Azure CLI dengan menggunakan perintah login az. Untuk menyelesaikan proses autentikasi, ikuti langkah-langkah yang ditampilkan di terminal Anda. Untuk opsi masuk tambahan, lihat Masuk dengan Azure CLI.

  • Saat diminta, instal ekstensi saat pertama kali menggunakan Azure CLI. Untuk informasi selengkapnya tentang ekstensi, lihat Menggunakan ekstensi dengan Azure CLI.

  • Jalankan versi az untuk menemukan versi dan pustaka dependen yang diinstal. Untuk meningkatkan ke versi terbaru, jalankan peningkatan az.

SQL Database

Ubah retensi cadangan PITR dan frekuensi cadangan diferensial untuk Azure SQL Database aktif dengan menggunakan contoh berikut.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

Instans Terkelola SQL

Gunakan contoh berikut untuk mengubah retensi cadangan PITR dari database tunggal aktif di SQL Managed Instance.

# Set new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --name mymanageddb \
    --retention-days 1 \

Gunakan contoh berikut untuk mengubah retensi cadangan PITR untuk database yang semuanya aktif dalam SQL Managed Instance.

# Set new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --retention-days 1 \

Mengubah kebijakan retensi jangka pendek menggunakan PowerShell

Catatan

Artikel ini menggunakan modul Azure Az PowerShell, yang merupakan modul PowerShell yang direkomendasikan untuk berinteraksi dengan Azure. Untuk mulai menggunakan modul Az PowerShell, lihat Menginstal Azure PowerShell. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Penting

Modul PowerShell Azure Resource Manager masih didukung oleh SQL Database dan SQL Managed Instance, tetapi semua pengembangan di masa mendatang dikhususkan untuk modul Az.Sql. Untuk mengetahui informasi selengkapnya, lihat AzureRM.Sql. Argumen untuk perintah dalam modul Az dan AzureRm bersifat identik secara substansial.

SQL Database

Untuk mengubah retensi cadangan PITR untuk Azure SQL Database aktif, gunakan contoh PowerShell berikut ini.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

Instans Terkelola SQL

Untuk mengubah retensi cadangan PITR untuk database tunggal yang aktif di SQL Managed Instance, gunakan contoh PowerShell berikut.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase -RetentionDays 1

Untuk mengubah retensi cadangan PITR untuk semua database yang aktif di SQL Managed Instance, gunakan contoh PowerShell berikut.

# SET new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
Get-AzSqlInstanceDatabase -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 1

Untuk mengubah retensi cadangan PITR untuk database tunggal yang dihapus di SQL Managed Instance, gunakan contoh PowerShell berikut.

# SET new PITR backup retention on an individual deleted database
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database.
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

Untuk mengubah retensi cadangan PITR untuk semua database yang dihapus di SQL Managed Instance, gunakan contoh PowerShell berikut.

# SET new PITR backup retention for ALL deleted databases
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

Retensi nol (0) hari akan menunjukkan bahwa cadangan segera dihapus dan tidak lagi disimpan untuk database yang dihapus. Setelah retensi cadangan PITR dikurangi untuk database yang dihapus, retensi cadangan tidak dapat lagi ditingkatkan.

Mengubah kebijakan retensi jangka pendek menggunakan REST API

Permintaan di bawah ini memperbarui periode retensi hingga 28 hari dan juga menetapkan frekuensi cadangan diferensial hingga 24 jam.

SQL Database

Permintaan Sampel

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview

Isi Permintaan

{ 
    "properties":{
        "retentionDays":28,
        "diffBackupIntervalInHours":24
  }
}

Respons Sampel:

{ 
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28,
    "diffBackupIntervalInHours":24
  }
}

Untuk mengetahui informasi selengkapnya, lihat REST API Retensi Cadangan.

Instans Terkelola SQL

Permintaan sampel

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

Isi permintaan

{
  "properties":{
    "retentionDays":28
  }
}

Respons sampel

Kode status: 200

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

Untuk mengetahui informasi selengkapnya, lihat REST API Retensi Cadangan.

Pencadangan Hyperscale dan redundansi penyimpanan

Database Hyperscale di Azure SQL Database menggunakan arsitektur unik dengan tingkat penyimpanan dan kinerja komputasi yang sangat skalabel.

Cadangan Hyperscale berbasis snapshot dan hampir spontan. Log yang dihasilkan disimpan dalam penyimpanan Azure jangka panjang untuk periode retensi cadangan. Arsitektur Hyperscale tidak menggunakan cadangan database penuh atau cadangan log dan oleh karena itu, frekuensi cadangan, biaya penyimpanan, penjadwalan, penyimpanan dan redundansi serta kemampuan pemulihan yang dijelaskan di bagian sebelumnya dari artikel ini tidak berlaku.

Pencadangan dan pemulihan performa Hyperscale

Pemisahan penyimpanan dan komputasi memungkinkan Hyperscale untuk menekan operasi pencadangan dan pemulihan ke lapisan penyimpanan untuk mengurangi beban pemrosesan pada replika komputasi utama. Akibatnya, pencadangan database tidak memengaruhi kinerja node komputasi utama.

Operasi pencadangan dan pemulihan untuk database Hyperscale cepat terlepas dari ukuran data karena penggunaan snapshot penyimpanan. Database dapat dipulihkan ke titik waktu mana pun dalam periode retensi cadangannya. Pemulihan Titik Tepat Waktu (PITR) dicapai dengan kembali ke file snapshot, dan karenanya bukan ukuran operasi data. Pemulihan database Hyperscale di wilayah Azure yang sama adalah operasi yang konstan, dan bahkan database beberapa terabyte dapat dipulihkan dalam hitungan menit, daripada hitungan jam atau hari. Pembuatan database baru dengan memulihkan cadangan yang ada atau menyalin database juga memanfaatkan fitur ini: membuat salinan database untuk tujuan pengembangan atau pengujian, bahkan database multi-terabyte, dapat dilakukan dalam hitungan menit dalam wilayah yang sama ketika jenis penyimpanan yang sama digunakan.

Retensi cadangan Hyperscale

Retensi cadangan jangka pendek (STR) default untuk database Hyperscale adalah 7 hari; kebijakan retensi jangka panjang (LTR) saat ini tidak didukung.

Catatan

Retensi cadangan jangka pendek hingga 35 hari untuk database Hyperscale sekarang dalam pratinjau.

Penjadwalan pencadangan Hyperscale

Tidak ada cadangan log transaksional yang lengkap, berbeda, dan tradisional untuk database Hyperscale. Sebagai gantinya, snapshot penyimpanan reguler dari file data diambil. Log transaksi yang dihasilkan disimpan apa adanya untuk periode retensi yang dikonfigurasi. Pada waktu pemulihan, catatan log transaksi yang relevan diterapkan ke snapshot penyimpanan yang dipulihkan, menghasilkan database yang konsisten secara transaksional tanpa kehilangan data pada titik waktu yang ditentukan dalam periode retensi.

Biaya penyimpanan cadangan Hyperscale

Biaya penyimpanan cadangan Hyperscale bergantung pada pilihan wilayah dan redundansi penyimpanan cadangan. Biaya penyimpanan cadangan Hyperscale juga tergantung pada jenis beban kerja. Beban kerja yang melakukan banyak penulisan lebih cenderung sering mengubah halaman data, yang menghasilkan snapshot penyimpanan yang lebih besar. Beban kerja semacam ini juga menghasilkan lebih banyak log transaksi, yang berkontribusi pada biaya pencadangan secara keseluruhan. Penyimpanan cadangan dikenakan biaya per GB/bulan yang digunakan, untuk detail harga lihat halaman Harga Azure SQL Database.

Untuk Hyperscale, penyimpanan cadangan yang dapat ditagih dihitung sebagai berikut:

Total billable backup storage size = (Data backup storage size + Log backup storage size)

Ukuran penyimpanan data tidak termasuk dalam cadangan yang dapat ditagih karena sudah ditagih sebagai penyimpanan database yang dialokasikan.

Database Hyperscale yang dihapus menimbulkan biaya cadangan untuk mendukung pemulihan ke titik waktu sebelum penghapusan. Untuk database Hyperscale yang dihapus, penyimpanan cadangan yang dapat ditagih dihitung sebagai berikut:

Total billable backup storage size for deleted Hyperscale database = (Data storage size + Data backup size + Log backup storage size) * (remaining backup retention period after deletion/configured backup retention period)

Ukuran penyimpanan data disertakan dalam rumus karena penyimpanan database yang dialokasikan tidak ditagih secara terpisah untuk database yang dihapus. Untuk database yang dihapus, data disimpan setelah penghapusan untuk mengaktifkan pemulihan selama periode retensi cadangan yang dikonfigurasi. Penyimpanan cadangan yang dapat ditagih untuk database yang dihapus berkurang secara bertahap seiring waktu setelah dihapus. Penyimpanan cadangan yang dapat ditagih menjadi nol ketika cadangan tidak lagi dipertahankan, dan pemulihan tidak lagi tersedia. Tetapi, jika penghapusan permanen dan cadangan tidak lagi diperlukan, untuk mengoptimalkan biaya Anda dapat mengurangi retensi sebelum menghapus database.

Penggunaan cadangan pemantauan hyperscale

Di Hyperscale, ukuran penyimpanan pencadangan data (ukuran cadangan snapshot), ukuran penyimpanan data (ukuran database) dan ukuran penyimpanan cadangan log (ukuran cadangan log transaksi) dilaporkan melalui metrik Azure Monitor.

Untuk melihat metrik cadangan dan penyimpanan data di portal Microsoft Azure, ikuti langkah-langkah berikut: :

1. Buka database Hyperscale yang ingin Anda pantau cadangan dan metrik penyimpanan datanya.
2. Pilih halaman Metrik di bagian Pemantauan.

3. Dari daftar drop-down Metrik, pilih metrik Penyimpanan Pencadangan Data dan Penyimpanan Cadangan Log dengan aturan agregasi yang sesuai.

Mengurangi penggunaan penyimpanan cadangan

Penggunaan penyimpanan cadangan untuk database Hyperscale bergantung pada periode retensi, pilihan wilayah, redundansi penyimpanan cadangan, dan jenis beban kerja. Pertimbangkan beberapa teknik penyetelan berikut untuk mengurangi penggunaan penyimpanan cadangan Anda untuk database Hyperscale:

• Kurangi periode retensi cadangan ke titik seminimal mungkin untuk kebutuhan Anda.
• Hindari melakukan operasi yang sering melakukan penulisan, seperti pemeliharaan indeks, lebih sering dari yang Anda perlukan. Untuk rekomendasi pemeliharaan indeks, lihat Mengoptimalkan pemeliharaan indeks untuk meningkatkan performa kueri dan mengurangi penggunaan sumber daya.
• Untuk operasi pemuatan data yang besar, pertimbangkan untuk menggunakan pemadatan data jika perlu.
• Gunakan database tempdb sebagai ganti tabel permanen dalam logika aplikasi Anda untuk menyimpan hasil sementara dan/atau data sementara.
• Gunakan penyimpanan cadangan yang redundan secara lokal atau redundan zona saat kemampuan pemulihan geo tidak diperlukan (misalnya: lingkungan pengembangan/pengujian).

Redundansi penyimpanan Hyperscale berlaku untuk penyimpanan data dan penyimpanan cadangan

Hyperscale mendukung redundansi penyimpanan yang dapat dikonfigurasi. Saat membuat database Hyperscale, Anda dapat memilih jenis penyimpanan pilihan Anda: penyimpanan geo-redundan akses baca (RA-GRS), penyimpanan zona-redundan (ZRS), atau penyimpanan standar Azure penyimpanan redundan lokal (LRS). Opsi redundansi penyimpanan yang dipilih digunakan selama masa pakai database untuk redundansi penyimpanan data dan redundansi penyimpanan cadangan.

Pertimbangkan redundansi penyimpanan dengan hati-hati saat Anda membuat database Hyperscale

Redundansi penyimpanan cadangan untuk Hyperscale hanya dapat diatur selama pembuatan database. Pengaturan ini tidak dapat dimodifikasi setelah sumber daya tersedia. Geo-restore hanya tersedia ketika penyimpanan geo-redundan (RA-GRS) telah dipilih untuk redundansi penyimpanan cadangan. Proses Penyalinan database dapat digunakan untuk memperbarui pengaturan redundansi penyimpanan cadangan untuk database Hyperscale yang sudah ada. Menyalin database ke jenis penyimpanan yang berbeda akan menjadi ukuran-of-data operasi. Temukan contoh kode dalam mengonfigurasi redundansi penyimpanan cadangan.

Penting

Penyimpanan redundan zona saat ini hanya tersedia di wilayah tertentu.

Memulihkan database Hyperscale ke wilayah lain

Jika Anda perlu untuk memulihkan database Hyperscale di Azure SQL Database ke wilayah selain database yang saat ini dihosting, sebagai bagian dari operasi pemulihan bencana atau latihan, relokasi, atau alasan lain, metode utamanya adalah melakukan pemulihan geo database. Ini melibatkan langkah-langkah yang sama persis dengan apa yang akan Anda gunakan untuk memulihkan database lain di SQL Database ke wilayah yang berbeda:

1. Buat server di wilayah target jika Anda belum memiliki server yang sesuai di sana. Server ini harus dimiliki oleh langganan yang sama dengan server asli (sumber).
2. Ikuti instruksi dalam topik di halaman pemulihan geo tentang memulihkan database di Azure SQL Database dari pencadangan otomatis.

Catatan

Karena sumber dan target berada di wilayah terpisah, database tidak dapat berbagi penyimpanan rekam jepret dengan database sumber seperti dalam pemulihan non-geo, yang selesai dengan cepat terlepas dari ukuran database. Dalam kasus pemulihan geo database Hyperscale, itu akan menjadi operasi ukuran data, bahkan jika target berada di wilayah yang dipasangkan dari penyimpanan yang direplikasi geo. Oleh karena itu, pemulihan geo akan memakan waktu yang sebanding dengan ukuran database yang dipulihkan. Jika target berada di wilayah yang dipasangkan, transfer data akan dilakukan di dalam suatu wilayah, yang akan lebih cepat secara signifikan daripada transfer data lintas wilayah, tetapi masih akan menjadi operasi ukuran data.

Jika dingingkan, Anda dapat menyalin database ke wilayah yang berbeda juga. Pelajari tentang Salinan Database untuk Hyperscale.

Mengonfigurasi redundansi penyimpanan cadangan

Redundansi penyimpanan cadangan untuk database di Azure SQL Database dapat dikonfigurasi pada saat pembuatan database atau dapat diperbarui untuk database yang sudah ada; perubahan yang dilakukan pada database yang sudah ada hanya berlaku untuk pencadangan di masa mendatang. Nilai defaultnya adalah penyimpanan geo-redundan. Untuk perbedaan harga antara penyimpanan cadangan redundan lokal, redundan zona, dan redundan lokasi geografis, lihat halaman harga instans terkelola. Redundansi storage untuk database Hyperscale adalah unik: pelajari lebih lanjut di cadangan Hyperscale dan redundansi penyimpanan.

Untuk SQL Managed Instance, redundansi penyimpanan cadangan diatur pada tingkat instans, dan diterapkan untuk semua database terkelola yang dimiliki. Langkah ini dapat dikonfigurasi pada saat pembuatan instans atau diperbarui untuk instans yang sudah ada; perubahan redundansi penyimpanan cadangan akan memicu pencadangan penuh baru per database dan perubahan tersebut akan berlaku untuk semua pencadangan di masa mendatang. Jenis redundansi penyimpanan default adalah geo-redundansi (RA-GRS).

Mengonfigurasi redundansi menggunakan portal Microsoft Azure

SQL Database

Di portal Microsoft Azure, Anda dapat mengonfigurasi redundansi penyimpanan cadangan di panel Buat SQL Database. Opsi ini tersedia di bagian Redundansi Penyimpanan Cadangan.

Instans Terkelola SQL

Di portal Microsoft Azure, selama pembuatan instans, opsi default untuk redundansi penyimpanan cadangan adalah redundansi geo. Opsi untuk mengubahnya terletak di panel Komputasi + penyimpanan yang dapat diakses dari opsi Konfigurasi Instans Terkelola pada tab Dasar.

Temukan opsi untuk memilih redundansi penyimpanan cadangan di panel Komputasi + penyimpanan.

Guna mengubah opsi Redundansi penyimpanan cadangan untuk instans yang sudah ada, masuk ke panel Komputasi + penyimpanan, pilih opsi cadangan baru dan pilih Terapkan. Untuk saat ini, perubahan ini hanya akan diterapkan untuk pencadangan PITR, sedangkan pencadangan LTR akan mempertahankan jenis redundansi penyimpanan lama. Waktu untuk melakukan perubahan redundansi cadangan bergantung pada ukuran semua database di dalam sebuah instans terkelola. Mengubah redundansi cadangan akan membutuhkan waktu lebih lama untuk instans yang memiliki database besar. Anda dapat mengombinasikan operasi perubahan redundansi penyimpanan cadangan dengan operasi UpdateSLO. Gunakan panel Pemberitahuan portal Microsoft Azure untuk menampilkan status operasi perubahan.

Konfigurasikan redundansi penyimpanan cadangan dengan menggunakan Azure CLI

SQL Database

Untuk mengonfigurasi redundansi penyimpanan saat membuat database baru, Anda dapat menentukan parameter --backup-storage-redundancy dengan perintah az sql db create. Nilai yang memungkinkan adalah Geo, Zone, dan Local. Secara default, semua database di Azure SQL Database menggunakan penyimpanan geo-redundan untuk cadangan. Pemulihan geografis dinonaktifkan jika database dibuat atau diperbarui dengan penyimpanan cadangan redundan lokal atau zona.

Contoh ini membuat database di tingkat layanan Tujuan Umum dengan redundansi cadangan lokal:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

Pertimbangkan opsi konfigurasi --backup-storage-redundancy dengan hati-hati saat membuat database Hyperscale. Redundansi Storage hanya dapat ditentukan selama proses pembuatan database untuk database Hyperscale. Opsi redundansi penyimpanan yang dipilih akan digunakan untuk masa pakai database, baik untuk redundansi penyimpanan data dan redundansi penyimpanan cadangan. Pelajari selengkapnya di Pencadangan hyperscale dan redundansi penyimpanan.

Database Hyperscale yang ada dapat bermigrasi ke redundansi penyimpanan yang berbeda menggunakan salinan database atau pemulihan titik waktu: kode sampel untuk menyalin database Hyperscale berikut di bagian ini.

Contoh ini membuat database di tingkat layanan Hyperscale dengan redundansi Zona:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier Hyperscale \
    --backup-storage-redundancy Zone

Untuk informasi selengkapnya, lihat buat az sql db dan perbarui az sql db.

Kecuali untuk database tingkat Hyperscale dan Basic, Anda dapat memperbarui pengaturan redundansi penyimpanan cadangan untuk database yang ada dengan parameter --backup-storage-redundancy dan perintah az sql db update. Kemungkinan diperlukan waktu hingga 48 jam agar perubahan pada database diterapkan. Beralih dari penyimpanan cadangan redundan lokasi geografis ke penyimpanan lokal atau redundan zona akan menonaktifkan pemulihan lokasi geografis.

Contoh kode ini mengubah redundansi penyimpanan cadangan menjadi Local.

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

Anda tidak dapat memperbarui redundansi penyimpanan cadangan database Hyperscale secara langsung. Namun, Anda dapat mengubahnya menggunakan perintah salin database dengan parameter --backup-storage-redundancy. Contoh ini menyalin database Hyperscale ke database baru menggunakan perangkat keras Gen5 dan dua vCore. Database baru memiliki redundansi cadangan yang diatur menjadi Zone.

az sql db copy \
    --resource-group myresourcegroup \ 
    --server myserver 
    --name myHSdb 
    --dest-resource-group mydestresourcegroup 
    --dest-server destdb 
    --dest-name myHSdb 
    --service-objective HS_Gen5_2 
    --read-replicas 0 
    --backup-storage-redundancy Zone

Untuk detail sintaks, lihat salin az sql db. Untuk gambaran umum salinan database, kunjungi Salin salinan database yang konsisten secara transaksional di Azure SQL Database.

Instans Terkelola SQL

Mengonfigurasi redundansi penyimpanan cadangan tidak tersedia untuk SQL Managed Instance saat menggunakan Azure CLI. Untuk informasi selengkapnya, lihat opsi portal Microsoft Azure atau PowerShell.

Mengonfigurasi redundansi menggunakan PowerShell

SQL Database

Untuk mengonfigurasi redundansi penyimpanan cadangan saat membuat database baru, Anda dapat menentukan parameter -BackupStorageRedundancy dengan cmdlet New-AzSqlDatabase. Nilai yang memungkinkan adalah Geo, Zone, dan Local. Secara default, semua database di Azure SQL Database menggunakan penyimpanan geo-redundan untuk cadangan. Pemulihan lokasi geografis dinonaktifkan jika database dibuat dengan penyimpanan cadangan lokal atau redundan zona.

Contoh ini membuat database di tingkat layanan Tujuan Umum dengan redundansi cadangan lokal:

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Local

Pertimbangkan opsi konfigurasi --backup-storage-redundancy dengan hati-hati saat membuat database Hyperscale. Redundansi Storage hanya dapat ditentukan selama proses pembuatan database untuk database Hyperscale. Opsi redundansi penyimpanan yang dipilih akan digunakan untuk masa pakai database, baik untuk redundansi penyimpanan data dan redundansi penyimpanan cadangan. Pelajari selengkapnya di Pencadangan hyperscale dan redundansi penyimpanan.

Database yang ada dapat bermigrasi ke redundansi penyimpanan yang berbeda menggunakan salinan database atau pemulihan titik waktu: kode sampel untuk menyalin database Hyperscale berikut di bagian ini.

Contoh ini membuat database di tingkat layanan Hyperscale dengan redundansi Zona:

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "Hyperscale" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Zone

Untuk detail detial selengkapnya, buka New-AzSqlDatabase.

Kecuali untuk database tingkat Hyperscale dan Basic, Anda dapat menggunakan parameter -BackupStorageRedundancy dengan cmdlet Set-AzSqlDatabase untuk memperbarui pengaturan redundansi penyimpanan cadangan untuk database yang sudah ada. Kemungkinan nilainya adalah Geo, Zona, dan Lokal. Kemungkinan diperlukan waktu hingga 48 jam agar perubahan pada database diterapkan. Beralih dari penyimpanan cadangan redundan lokasi geografis ke penyimpanan lokal atau redundan zona akan menonaktifkan pemulihan lokasi geografis.

Contoh kode ini mengubah redundansi penyimpanan cadangan menjadi Local.

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local

Untuk mengetahui detail selengkapnya, buka Set-AzSqlDatabase

Redundansi penyimpanan cadangan dari database Hyperscale yang ada tidak dapat diperbarui. Namun, Anda dapat menggunakan perintah salin database untuk membuat salinan database dan menggunakan parameter -BackupStorageRedundancy untuk memperbarui redundansi penyimpanan cadangan. Contoh ini menyalin database Hyperscale ke database baru menggunakan perangkat keras Gen5 dan dua vCore. Database baru memiliki redundansi cadangan yang diatur menjadi Zone.

# Change the backup storage redundancy for Database01 to zone-redundant. 
New-AzSqlDatabaseCopy -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "HSSourceDB" -CopyResourceGroupName "DestResourceGroup" -CopyServerName "DestServer" -CopyDatabaseName "HSDestDB" -Vcore 2 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone

Untuk detail sintaks, buka New-AzSqlDatabaseCopy.

Untuk gambaran umum salinan database, kunjungi Salin salinan database yang konsisten secara transaksional di Azure SQL Database.

Catatan

Untuk menggunakan parameter -BackupStorageRedundancy dengan pemulihan database, salinan database, atau operasi sekunder pembuatan, gunakan Azure PowerShell versi Az.Sql 2.11.0.

Instans Terkelola SQL

Untuk mengonfigurasi redundansi penyimpanan cadangan selama pembuatan instans terkelola, Anda dapat menentukan parameter -BackupStoageRedundancy. Kemungkinan nilainya adalah Geo, Zona, dan Lokal.

New-AzSqlInstance -Name managedInstance2 -ResourceGroupName ResourceGroup01 -Location westcentralus -AdministratorCredential (Get-Credential) -SubnetId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/resourcegroup01/providers/Microsoft.Network/virtualNetworks/vnet_name/subnets/subnet_name" -LicenseType LicenseIncluded -StorageSizeInGB 1024 -VCore 16 -Edition "GeneralPurpose" -ComputeGeneration Gen4 -BackupStorageRedundancy Geo

Untuk informasi lebih lanjut, lihat New-AzSqlInstance.

Menggunakan Kebijakan Azure untuk memberlakukan redundansi penyimpanan cadangan

Jika Anda memiliki persyaratan residensi data yang mengharuskan Anda untuk menyimpan semua data dalam satu wilayah Azure, sebaiknya berlakukan pencadangan redundan zona atau lokal untuk SQL Database atau Managed Instance 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 sesuai dengan standar perusahaan dan perjanjian tingkat layanan Anda. Untuk mengetahui informasi selengkapnya, lihat Gambaran Umum Azure Policy.

Kebijakan redundansi penyimpanan cadangan bawaan

Mengikuti kebijakan bawaan baru ditambahkan, yang dapat ditetapkan pada tingkat grup langganan atau sumber daya untuk memblokir pembuatan database atau instans baru dengan penyimpanan cadangan geo-berlebihan.

SQL Database harus menghindari penggunaan redundansi cadangan GRS

SQL Managed Instances harus menghindari penggunaan redundansi cadangan GRS

Daftar lengkap definisi kebijakan bawaan untuk SQL Database dan SQL Managed Instance dapat ditemukan di sini.

Untuk memberlakukan persyaratan residensi data pada tingkat organisasi, kebijakan ini dapat ditetapkan ke langganan. Setelah kebijakan ini ditetapkan pada tingkat langganan, pengguna dalam langganan yang diberikan tidak akan dapat membuat database atau instans terkelola dengan penyimpanan cadangan redundan lokasi geografis melalui portal Microsoft Azure atau Azure PowerShell.

Penting

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

Pelajari cara menetapkan kebijakan menggunakan portal Microsoft Azure atau Azure PowerShell

Langkah berikutnya

• Pencadangan database adalah bagian penting dari setiap kelangsungan bisnis dan strategi pemulihan bencana karena melindungi data Anda dari kerusakan dan penghapusan data yang tidal disengaja. Untuk mempelajari solusi kelangsungan bisnis SQL Database lainnya, lihat Gambaran umum kelangsungan bisnis.
• Untuk mengetahui informasi terkait cara mengonfigurasi, mengelola, dan melakukan pemulihan dari penyimpanan jangka panjang pencadangan otomatis di penyimpanan Azure Blob menggunakan portal Microsoft Azure, lihat Mengelola penyimpanan cadangan jangka panjang menggunakan portal Microsoft Azure.
• Untuk mengetahui informasi terkait cara mengonfigurasi, mengelola, dan melakukan pemulihan dari penyimpanan jangka panjang pencadangan otomatis di penyimpanan Azure Blob menggunakan PowerShell, lihat Mengelola penyimpanan cadangan jangka panjang menggunakan PowerShell.
• Dapatkan informasi selengkapnya tentang cara memulihkan database ke titik waktu menggunakan portal Microsoft Azure.
• Dapatkan informasi selengkapnya tentang cara memulihkan database ke titik waktu menggunakan PowerShell.
• Untuk mempelajari semua hal terkait konsumsi penyimpanan cadangan pada Azure SQL Managed Instance, lihat Penjelasan konsumsi penyimpanan cadangan pada Instans Terkelola.
• Untuk mempelajari cara menyempurnakan retensi penyimpanan cadangan dan biaya untuk Azure SQL Managed Instance, lihat Menyempurnakan biaya penyimpanan cadangan pada Instans Terkelola.