Pencadangan otomatis di Azure SQL Database

Berlaku untuk:Azure SQL Database

• Azure SQL Database
• Instans Terkelola Azure SQL

Artikel ini menjelaskan fitur pencadangan otomatis untuk Azure SQL Database.

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

Apa itu pencadangan database?

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

Untuk tingkat layanan selain Hyperscale, Azure SQL Database menggunakan teknologi mesin SQL Server untuk mencadangkan dan memulihkan data. Database Hyperscale menggunakan pencadangan dan pemulihan berdasarkan rekam jepret penyimpanan. Dengan teknologi pencadangan SQL Server tradisional, database yang lebih besar memiliki waktu pencadangan/pemulihan yang lama. Dengan penggunaan rekam jepret, Hyperscale menyediakan kemampuan pencadangan instan dan pemulihan cepat terlepas dari ukuran database. Untuk mempelajari lebih lanjut, lihat Pencadangan Hyperscale.

Frekuensi pencadangan

Azure SQL Database membuat:

• Pencadangan penuh setiap minggu.
• Cadangan diferensial setiap 12 atau 24 jam.
• Log transaksi mencadangkan sekitar setiap 10 menit.

Frekuensi pasti pencadangan log transaksi didasarkan pada ukuran komputasi dan jumlah aktivitas database. Saat Anda memulihkan database, layanan menentukan pencadangan penuh, diferensial, dan log mana yang perlu dipulihkan.

Arsitektur Hyperscale tidak memerlukan pencadangan penuh, diferensial, atau log. Untuk mempelajari lebih lanjut, lihat Pencadangan Hyperscale.

Redundansi penyimpanan cadangan

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

Secara default, database baru di Azure SQL Database 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 database Anda di wilayah yang berbeda jika terjadi pemadaman regional.

portal Azure menyediakan opsi lingkungan Beban Kerja yang membantu menyiapkan beberapa pengaturan konfigurasi. Pengaturan ini dapat ditimpa. Opsi ini hanya berlaku untuk halaman Buat portal SQL Database .

• Memilih lingkungan beban kerja pengembangan mengatur opsi redundansi penyimpanan Cadangan untuk menggunakan penyimpanan redundan secara lokal. Penyimpanan yang berlebihan secara lokal menimbulkan lebih sedikit biaya dan sesuai untuk lingkungan praproduksi yang tidak memerlukan redundansi penyimpanan zona atau replikasi geografis.
• Memilih lingkungan beban kerja Produksi mengatur redundansi penyimpanan Cadangan ke penyimpanan geo-redundan, default.
• Opsi Lingkungan beban kerja juga mengubah pengaturan awal untuk komputasi, meskipun ini dapat ditimpa. Jika tidak, opsi Lingkungan beban kerja tidak berdampak pada lisensi atau pengaturan konfigurasi database lainnya.

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. Redundansi penyimpanan cadangan yang dikonfigurasi diterapkan ke cadangan retensi jangka pendek (STR) dan cadangan LTR. Untuk mempelajari selengkapnya tentang redundansi penyimpanan, lihat Redundansi data.

Anda dapat mengonfigurasi redundansi penyimpanan cadangan saat membuat database, dan Anda dapat memperbaruinya di lain waktu. Perubahan yang Anda buat pada database yang sudah ada hanya berlaku untuk cadangan di masa mendatang. Setelah Anda memperbarui redundansi penyimpanan cadangan database yang ada, perubahan mungkin memerlukan waktu hingga 48 jam untuk diterapkan.

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 penyimpanan paling murah, tetapi kami tidak merekomendasikannya untuk aplikasi yang memerlukan ketahanan terhadap pemadaman regional atau jaminan durabilitas data yang tinggi.

  

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

  

• 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.
  • Tiga salinan sinkron di wilayah berpasangan yang disalin dari wilayah utama ke wilayah sekunder secara asinkron.

  

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.
• Redundansi penyimpanan cadangan untuk database Hyperscale hanya dapat diatur selama pembuatan. Anda tidak dapat mengubah pengaturan ini setelah sumber daya diprovisikan. Untuk memperbarui pengaturan redundansi penyimpanan cadangan untuk database Hyperscale yang ada dengan waktu henti minimum, gunakan replikasi geografis aktif. Atau, Anda dapat menggunakan salinan database. Pelajari selengkapnya di Pencadangan hyperscale dan redundansi penyimpanan.

Penggunaan pencadangan

Anda dapat menggunakan cadangan yang dibuat secara otomatis dalam skenario berikut:

• Pulihkan database yang sudah ada ke titik waktu dalam periode retensi dengan menggunakan portal Azure, Azure PowerShell, Azure CLI, atau REST API. 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 dapat secara opsional menghapus database asli dan mengganti nama database yang dipulihkan menjadi nama database asli. Atau, alih-alih menghapus database asli, Anda dapat mengganti namanya , lalu mengganti nama database yang dipulihkan menjadi nama database asli.

• Pulihkan database yang dihapus ke titik waktu dalam periode retensi, termasuk waktu penghapusan. Database yang dihapus hanya dapat dipulihkan di server yang sama tempat Anda membuat database asli. Sebelum Anda menghapus database, layanan mengambil cadangan log transaksi akhir untuk mencegah kehilangan data.

• Memulihkan database ke wilayah geografis lain lainnya. Pemulihan geografis memungkinkan Anda memulihkan dari pemadaman regional saat Anda tidak dapat mengakses database atau cadangan di wilayah utama. Ini membuat database baru di server yang sudah 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 jangka panjang tertentu dari database tunggal atau terkumpul, jika database telah dikonfigurasi dengan kebijakan LTR. 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 aplikasi yang lebih lama. Untuk mengetahui informasi selengkapnya, lihat Retensi jangka panjang.

Memulihkan kemampuan dan fitur

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

Properti cadangan	PITR	Pemulihan Geo	LTR
Jenis pencadangan SQL	Penuh, diferensial, log.	Salinan cadangan PITR yang direplikasi secara geografis terbaru.	Hanya pencadangan penuh.
Tujuan titik pemulihan (RPO)	10 menit, berdasarkan ukuran komputasi dan jumlah aktivitas database.	Hingga 1 jam, berdasarkan replikasi geografis.*	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	7 hari secara default, dapat dikonfigurasi antara 1 dan 35 hari (kecuali database Dasar, yang dapat dikonfigurasi antara 1 dan 7 hari).	Diaktifkan secara default, sama seperti sumber.**	Tidak diaktifkan secara default. Retensi hingga 10 tahun.
Azure Storage	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
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	Tidak didukung	Tidak didukung***	Tidak didukung***
Memulihkan melalui portal Azure	Ya	Ya	Ya
Memulihkan melalui PowerShell	Ya	Ya	Ya
Memulihkan melalui Azure CLI	Ya	Ya	Ya

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

** Semua cadangan PITR disimpan pada penyimpanan geo-redundan secara default, sehingga pemulihan geografis diaktifkan secara default.

Solusinya adalah memulihkan ke server baru dan menggunakan Pemindahan Sumber Daya untuk memindahkan server ke langganan lain, atau menggunakan salinan database lintas langganan.

Memulihkan database dari cadangan

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

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

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 ketika database 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 dari semua cadangan database ditentukan oleh layanan SQL Database karena menyeimbangkan beban kerja sistem secara keseluruhan. Anda tidak dapat mengubah jadwal pekerjaan pencadangan atau menonaktifkannya.

Penting

• Untuk database baru, dipulihkan, atau disalin, kemampuan pemulihan titik waktu menjadi tersedia ketika cadangan log transaksi awal yang mengikuti pencadangan penuh awal dibuat.
• Database Hyperscale dilindungi segera setelah pembuatan, tidak seperti database lain di mana pencadangan awal membutuhkan waktu. Perlindungan segera terjadi bahkan jika database Hyperscale dibuat dengan sejumlah besar data melalui penyalinan atau pemulihan. Untuk mempelajari lebih lanjut, tinjau Pencadangan otomatis Hyperscale.

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.

Azure SQL Database menjadwalkan 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.

Database Hyperscale menggunakan mekanisme penjadwalan cadangan yang berbeda. Untuk informasi selengkapnya, lihat Penjadwalan cadangan Hyperscale.

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 Database 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 database dipertahankan untuk menyediakan PITR meskipun database tersebut telah dihapus. Meskipun menghapus dan membuat ulang database dapat menghemat biaya penyimpanan dan komputasi, itu dapat meningkatkan biaya penyimpanan cadangan. Alasannya adalah bahwa layanan mempertahankan cadangan untuk setiap database yang dihapus, setiap kali dihapus.

Memantau konsumsi

Untuk database vCore di Azure SQL Database, penyimpanan yang digunakan setiap jenis cadangan (penuh, diferensial, dan log) dilaporkan pada panel pemantauan database sebagai metrik terpisah. Cuplikan layar berikut menunjukkan cara memantau konsumsi penyimpanan cadangan untuk satu database.

Untuk petunjuk tentang cara memantau konsumsi di Hyperscale, lihat Memantau konsumsi cadangan Hyperscale.

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 hingga minimum untuk kebutuhan Anda.
• Hindari melakukan operasi tulis besar, seperti pembangunan ulang 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 Database 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 Database mempertahankan cadangan yang memadai untuk memungkinkan PITR dalam 7 hari terakhir secara default. 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.

Pencadangan diferensial dapat dikonfigurasi untuk terjadi baik sekali dalam 12 jam atau sekali dalam 24 jam. Frekuensi pencadangan diferensial 24 jam dapat meningkatkan waktu yang diperlukan untuk memulihkan database, dibandingkan dengan frekuensi 12 jam. Dalam model vCore, frekuensi default untuk pencadangan diferensial adalah sekali dalam 12 jam. Dalam model DTU, frekuensi default adalah sekali dalam 24 jam.

Anda dapat menentukan opsi redundansi penyimpanan cadangan untuk STR saat membuat database, lalu mengubahnya di lain waktu. Jika Anda mengubah opsi redundansi cadangan setelah database Anda 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 sampai periode retensi berakhir, yang bisa 1 hingga 35 hari.

Anda dapat mengubah periode retensi cadangan untuk setiap database aktif dalam rentang 1 hingga 35 hari, kecuali untuk database Dasar, yang dapat dikonfigurasi dari 1 hingga 7 hari. Seperti yang dijelaskan dalam konsumsi penyimpanan Cadangan, cadangan yang disimpan untuk mengaktifkan PITR mungkin lebih lama dari periode retensi. Jika Anda perlu menyimpan cadangan lebih lama dari periode retensi jangka pendek maksimum 35 hari, Anda dapat mengaktifkan retensi jangka panjang.

Jika Anda menghapus database, sistem menyimpan cadangan dengan cara yang sama seperti database online dengan periode retensi khususnya. Anda tidak dapat mengubah periode retensi cadangan untuk database yang dihapus.

Penting

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

Retensi jangka panjang

Untuk SQL Database, Anda dapat mengonfigurasi cadangan retensi jangka panjang penuh (LTR) hingga 10 tahun di Azure Blob Storage. 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. Frekuensi tergantung pada kebijakan. Misalnya, pengaturan W=0, M=1 akan membuat salinan LTR setiap bulan. Untuk informasi selengkapnya tentang LTR, lihat Retensi jangka panjang.

Memperbarui redundansi penyimpanan cadangan untuk database yang ada hanya menerapkan perubahan pada cadangan berikutnya yang diambil di masa mendatang dan bukan untuk cadangan yang ada. Semua cadangan LTR yang ada untuk database terus berada di blob penyimpanan yang ada. Cadangan baru direplikasi berdasarkan redundansi penyimpanan cadangan yang dikonfigurasi.

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

Saat memulihkan database Hyperscale dari cadangan LTR, properti skala baca dinonaktifkan. Untuk mengaktifkan, baca skala pada database yang dipulihkan, perbarui database setelah dibuat. Anda perlu menentukan tujuan tingkat layanan target saat memulihkan dari cadangan LTR.

Retensi jangka panjang dapat diaktifkan untuk database Hyperscale yang dibuat atau dimigrasikan dari tingkat layanan lain. Jika Anda mencoba mengaktifkan LTR untuk database Hyperscale yang belum didukung, Anda menerima kesalahan berikut: "Terjadi kesalahan saat mengaktifkan retensi cadangan jangka panjang untuk database ini. Silakan hubungi dukungan Microsoft untuk mengaktifkan retensi cadangan jangka panjang." Dalam hal ini, hubungi dukungan Microsoft dan buat tiket dukungan untuk mengatasi hal ini.

Biaya penyimpanan cadangan

Harga untuk penyimpanan cadangan bervariasi dan tergantung pada model pembelian Anda (DTU atau vCore), opsi redundansi penyimpanan cadangan yang dipilih, dan wilayah. 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

Untuk harga, lihat halaman harga Azure SQL Database.

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.

Model DTU

Dalam model DTU, untuk database dan kumpulan elastis tidak ada biaya tambahan untuk penyimpanan cadangan PITR untuk retensi default 7 hari dan seterusnya. Harga penyimpanan cadangan PITR adalah bagian dari database atau harga kumpulan.

Penting

Dalam model DTU, database dan kumpulan elastis dikenakan biaya untuk penyimpanan cadangan LTR berdasarkan penyimpanan aktual yang digunakan oleh cadangan LTR.

Model vCore

Azure SQL Database 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.

Biaya penyimpanan cadangan dihitung secara berbeda untuk database Hyperscale. Untuk informasi selengkapnya, lihat Biaya penyimpanan cadangan Hyperscale.

Untuk database tunggal, jumlah penyimpanan cadangan sama dengan 100 persen dari ukuran penyimpanan data maksimum untuk database disediakan tanpa biaya tambahan. Persamaan berikut digunakan untuk menghitung total penggunaan penyimpanan cadangan yang dapat ditagih:

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

Untuk kumpulan elastis, jumlah penyimpanan cadangan sama dengan 100 persen dari penyimpanan data maksimum untuk ukuran penyimpanan kumpulan disediakan tanpa biaya tambahan. Untuk database terkumpul, ukuran total penyimpanan cadangan yang dapat ditagih dikumpulkan pada 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

Total penyimpanan cadangan yang dapat ditagih, jika ada, dibebankan dalam gigabyte per bulan sesuai dengan tingkat redundansi penyimpanan cadangan yang telah Anda gunakan. Konsumsi penyimpanan cadangan ini tergantung pada beban kerja dan ukuran database individual, kumpulan 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 memiliki biaya pencadangan 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 Database 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 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 diagregasi ke tagihan akhir sebesar 1.116 GB per bulan.

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 skenario terakhir dalam database yang lebih besar, pengoptimalan dalam layanan membuat pencadangan penuh alih-alih cadangan diferensial jika cadangan diferensial akan terlalu besar jika tidak. 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 transaksi) dari waktu ke waktu, seperti yang dijelaskan dalam Konsumsi monitor.

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 database sql untuk database tunggal atau kumpulan database elastis.

3. Tambahkan filter lain untuk subkategori Meter.

4. Untuk memantau biaya pencadangan PITR, dalam daftar dropdown, pilih penyimpanan cadangan pitr kumpulan tunggal/elastis untuk database tunggal atau kumpulan database elastis. Meter muncul hanya jika konsumsi penyimpanan cadangan ada.

   Untuk memantau biaya pencadangan LTR, dalam daftar dropdown, pilih penyimpanan cadangan ltr untuk database tunggal atau kumpulan database elastis. Meter muncul hanya jika konsumsi penyimpanan cadangan ada.

Subkataan Penyimpanan dan komputasi mungkin juga menarik minat Anda, tetapi tidak terkait dengan 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 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.

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 informasi selengkapnya tentang TDE, lihat Enkripsi data transparan dengan SQL Database.

Integritas cadangan

Secara berkelanjutan, tim teknik Azure SQL secara otomatis menguji pemulihan cadangan database otomatis. Saat pemulihan waktu tertentu, database juga mendapatkan pemeriksaan integritas DBCC CHECKDB.

Setiap masalah yang ditemukan selama pemeriksaan integritas mengakibatkan pemberitahuan kepada tim teknik. Untuk 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 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.

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 database 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, pengguna dalam langganan tidak akan dapat membuat database dengan penyimpanan cadangan geo-redundan melalui portal Azure atau Azure PowerShell: SQL Database harus menghindari penggunaan redundansi cadangan GRS.

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

Penting

Kebijakan Azure tidak diberlakukan saat Anda membuat database melalui T-SQL. Untuk menentukan 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.

Konten terkait

• Untuk mempelajari tentang solusi kelangsungan bisnis SQL Database lainnya, lihat Gambaran umum kelangsungan bisnis.
• Untuk mengubah pengaturan pencadangan, lihat Mengubah pengaturan.
• Untuk memulihkan cadangan, lihat Memulihkan dengan menggunakan cadangan atau Memulihkan database ke titik waktu dengan menggunakan PowerShell.
• Untuk informasi tentang cara mengonfigurasi, mengelola, dan memulihkan dari retensi jangka panjang pencadangan otomatis di Azure Blob Storage, lihat Mengelola retensi cadangan jangka panjang.
• Untuk Azure SQL Managed Instance, lihat Pencadangan otomatis untuk SQL Managed Instance.