Pencadangan otomatis di Azure SQL Database

Berlaku untuk:Azure SQL Database

• Azure SQL Database
• Azure SQL Managed Instance

Artikel ini menjelaskan fitur pencadangan otomatis untuk Azure SQL Database.

Untuk mengubah pengaturan pencadangan, lihat Ubah pengaturan. Untuk memulihkan cadangan, lihat Pemulihan menggunakan cadangan database otomatis.

Apa itu cadangan basis data?

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 dikembalikan ke titik waktu tertentu dalam jangka waktu retensi yang telah 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 dan pemulihan yang lama. Dengan menggunakan snapshot, Hyperscale menyediakan pencadangan instan dan kemampuan 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.
• Mencadangkan log transaksi sekitar 10 menit sekali.

Frekuensi pencadangan log transaksi yang tepat bergantung pada ukuran komputasi dan jumlah aktivitas database. Saat Anda memulihkan database, Azure SQL Database menentukan cadangan log penuh, diferensial, dan transaksi mana yang akan 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 bawaan, database baru dalam Azure SQL Database menyimpan cadangan dalam blob penyimpanan geo-redundan yang direplikasi ke wilayah pasangan. 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 menetapkan pengaturan konfigurasi tertentu. Anda dapat mengganti setelan ini. 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 sebagai pengaturan default.
• Opsi lingkungan beban kerja juga mengubah pengaturan awal untuk komputasi, meskipun Anda dapat mengganti pengaturan ini. Jika tidak, opsi Lingkungan beban kerja tidak berdampak pada lisensi atau pengaturan konfigurasi database lainnya.

Untuk memastikan bahwa cadangan Anda tetap berada dalam wilayah yang sama tempat database Anda disebarkan, ubah 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 nanti. Perubahan yang Anda buat pada database yang sudah ada hanya berlaku untuk pencadangan 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 yang paling murah, tetapi tidak disarankan untuk aplikasi yang memerlukan ketahanan terhadap pemadaman regional atau jaminan daya tahan 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.

  

• Penyimpanan Redundan Zona-Geo (GZRS): Penyimpanan redundan zona-geo (GZRS) menggabungkan ketersediaan tinggi yang disediakan oleh redundansi di seluruh zona ketersediaan (ZRS) dengan perlindungan dari pemadaman regional yang disediakan oleh geo-replikasi (GRS). Di GZRS, Azure menyalin cadangan Anda secara sinkron di tiga zona ketersediaan Azure di wilayah utama, dan secara asinkron tiga kali ke satu lokasi fisik di wilayah sekunder yang dipasangkan.

  Microsoft merekomendasikan penggunaan GZRS untuk aplikasi yang membutuhkan konsistensi, durabilitas, dan ketersediaan maksimum, performa yang sangat baik, dan ketahanan untuk pemulihan bencana.

  Hasilnya adalah:

  • Tiga salinan sinkron di seluruh Zona Ketersediaan, di wilayah utama.

  • Tiga salinan sinkron di wilayah berpasangan, disalin secara asinkron dari wilayah utama ke wilayah sekunder.

    Diagram berikut menunjukkan bagaimana data Anda direplikasi dengan GRS atau RA-GRS:

  

Peringatan

• Pemulihan geografis dinonaktifkan segera setelah database diperbarui untuk menggunakan penyimpanan redundan lokal atau redundan zona.
• Diagram redundansi penyimpanan semua menampilkan wilayah dengan beberapa zona ketersediaan (multi-az). Namun, beberapa wilayah hanya menyediakan satu zona ketersediaan dan tidak mendukung ZRS.
• Anda dapat mengatur redundansi penyimpanan cadangan untuk database Hyperscale hanya 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 cadangan

Gunakan 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. Anda hanya dapat memulihkan database yang dihapus di server yang sama tempat Anda membuat database asli. Sebelum Anda menghapus database, Azure SQL Database mengambil cadangan log transaksi akhir untuk mencegah kehilangan data.

• Memulihkan database ke wilayah geografis lain lainnya. Pemulihan geografis membantu 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 cadangan yang direplikasi secara geografis untuk database, Anda dapat mengubah pengaturan ini dengan mengonfigurasi redundansi penyimpanan cadangan.

• Pulihkan database dari cadangan jangka panjang tertentu dari database tunggal atau terkumpul, jika database 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.

Peringatan

Saat memulihkan database dan redundansi penyimpanan cadangan sumber dikonfigurasi sebagai Geo-Zone Redundan Storage (GZRS), database baru mewarisi konfigurasi penyimpanan cadangan sumber jika Anda tidak secara eksplisit menentukan konfigurasi redundansi penyimpanan cadangan. Pewarisan ini berlaku pada operasi pemulihan apa pun, seperti pemulihan ke titik waktu tertentu, penyalinan database, pemulihan geografis, dan pemulihan dari cadangan jangka panjang. Selama operasi ini, jika wilayah Azure target tidak mendukung redundansi penyimpanan cadangan tertentu, operasi pemulihan gagal dengan pesan kesalahan yang sesuai. Anda dapat mengurangi kesalahan ini dengan secara eksplisit menentukan opsi penyimpanan yang tersedia untuk wilayah tersebut.

Pencadangan otomatis pada replika sekunder

Tingkat layanan Business Critical mengambil cadangan otomatis dari replika sekunder. Karena data direplikasi antara proses SQL Server pada setiap simpul, layanan cadangan mengambil cadangan dari replika sekunder yang tidak dapat dibaca. Desain ini memastikan replika utama tetap didedikasikan untuk beban kerja utama Anda, dan replika sekunder yang dapat dibaca didedikasikan untuk beban kerja baca-saja. Pencadangan otomatis di tingkat layanan Business Critical biasanya diambil dari replika sekunder. Jika pencadangan otomatis gagal pada replika sekunder, layanan pencadangan mengambil cadangan dari replika utama.

Pencadangan otomatis pada replika sekunder:

• Diaktifkan secara default.
• Sudah termasuk tanpa biaya tambahan di luar harga tingkat layanan.
• Menghadirkan peningkatan performa dan prediksi ke tingkat layanan Business Critical.

Catatan

Buat tiket dukungan Microsoft untuk menonaktifkan fitur untuk instans Anda.

Memulihkan kemampuan dan fitur

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

Untuk informasi tentang waktu pemulihan, lihat RTO dan RPO.

Properti cadangan	PITR	Pemulihan Geografis	LTR
Jenis pencadangan SQL	Penuh, diferensial, log.	Salinan cadangan PITR terbaru yang direplikasi secara geografis.	Hanya cadangan penuh.
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 dengan sumber.2	Tidak diaktifkan secara default. Retensi dapat berlangsung hingga 10 tahun.
Azure Storage	Redundansi geografis sebagai default. Anda dapat mengonfigurasi penyimpanan zona-redundan atau lokal redundan secara opsional.	Tersedia ketika redundansi penyimpanan cadangan PITR diatur ke redundansi geografis penuh atau redundansi zona geografi (GZRS). Tidak tersedia ketika penyimpanan cadangan PITR adalah zona-redundan atau lokal-redundan.	Redundansi geografis sebagai default. Anda dapat mengonfigurasi penyimpanan redundan zona atau redundan secara lokal.
Mengonfigurasi cadangan sebagai tidak dapat diubah	Tidak didukung	Tidak didukung	Supported
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 didukung3	Tidak didukung3
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 informasi selengkapnya tentang memulihkan database, lihat Memulihkan database dari cadangan. Untuk menjelajahi konfigurasi cadangan dan operasi pemulihan, gunakan contoh berikut.

Operasi	portal Azure	Azure CLI (antarmuka baris perintah Azure)	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

Catatan

Memulihkan database antara tingkat layanan Hyperscale dan tingkat layanan lain dari Azure SQL Database saat ini tidak didukung.

Mengekspor sebuah database

Anda tidak dapat mengunduh atau mengakses cadangan otomatis yang diambil oleh layanan Azure. Azure hanya menggunakan cadangan ini untuk operasi pemulihan.

Untuk mengekspor Azure SQL Database, pertimbangkan alternatif lain.

• Saat Anda perlu mengekspor database untuk pengarsipan atau untuk pindah ke platform lain, ekspor skema dan data database ke file BACPAC . File BACPAC adalah file ZIP dengan ekstensi BACPAC yang berisi metadata dan data dari database. Anda dapat menyimpan file BACPAC di penyimpanan Blob Azure atau di penyimpanan lokal di lokasi lokal. Nantinya, Anda dapat mengimpornya kembali ke Azure SQL Database, Azure SQL Managed Instance, atau instans SQL Server.
• Anda juga dapat Mengimpor atau mengekspor Azure SQL Database menggunakan tautan privat atau Mengimpor atau mengekspor Azure SQL Database tanpa mengizinkan layanan Azure mengakses server.

Penjadwalan pencadangan

Pencadangan penuh pertama dijadwalkan tepat setelah Anda membuat atau memulihkan database baru. 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.

Setelah pencadangan penuh pertama, Azure secara otomatis menjadwalkan dan mengelola semua pencadangan lebih lanjut. Layanan SQL Database menentukan waktu yang tepat dari semua cadangan database karena menyeimbangkan beban kerja sistem secara keseluruhan. Anda tidak dapat mengubah jadwal pekerjaan pencadangan atau menonaktifkannya.

Penting

• Untuk database yang baru, dipulihkan, atau disalin, kemampuan pemulihan ke titik waktu tertentu 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 berlangsung seketika bahkan jika database Hyperscale dibuat dengan data dalam jumlah besar melalui penyalinan atau pemulihan. Untuk informasi selengkapnya, lihat 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, Azure harus menyimpan cadangan log penuh, diferensial, dan transaksi tambahan hingga seminggu lebih lama dari periode retensi yang dikonfigurasi.

Dengan kata lain, untuk setiap titik waktu selama periode retensi, harus ada cadangan lengkap yang lebih tua dari waktu terawal 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.

Azure secara otomatis menghapus cadangan yang tidak lagi diperlukan untuk menyediakan fungsionalitas PITR. Karena pencadangan diferensial dan pencadangan log memerlukan pencadangan penuh sebelumnya agar dapat dipulihkan, Azure membersihkan ketiga jenis pencadangan bersama-sama dalam kumpulan mingguan.

Untuk semua database, termasuk database terenkripsi TDE, Azure mengompresi semua pencadangan penuh dan diferensial untuk mengurangi kompresi dan biaya penyimpanan cadangan. Rasio kompresi cadangan rata-rata adalah tiga hingga empat kali lipat. Namun, itu bisa lebih rendah atau lebih tinggi tergantung pada sifat data dan apakah kompresi data digunakan dalam database.

Penting

Untuk database terenkripsi TDE, Azure tidak mengompresi file cadangan log karena alasan performa. Untuk database yang tidak terenkripsi TDE, cadangan log dikompresi.

Azure SQL Database menghitung total penyimpanan cadangan yang Anda gunakan sebagai nilai kumulatif. Setiap jam, Azure melaporkan nilai ini ke alur penagihan. Sistem pemrosesan bertanggung jawab untuk menggabungkan penggunaan per jam ini dan menghitung total konsumsi Anda pada akhir setiap bulan. Setelah Anda menghapus database, penggunaan berkurang seiring cadangan kedaluwarsa dan dihapus. Setelah semua cadangan dihapus dan PITR tidak lagi dimungkinkan, penagihan berhenti.

Penting

Azure menyimpan cadangan database untuk menyediakan PITR bahkan jika Anda menghapus database. Meskipun menghapus dan membuat ulang database dapat menghemat biaya penyimpanan dan komputasi, database dapat meningkatkan biaya penyimpanan cadangan. Alasannya adalah Azure menyimpan cadangan untuk setiap database yang dihapus, setiap kali Anda menghapusnya.

Memantau konsumsi

Untuk database vCore di Azure SQL Database, panel pemantauan database melaporkan penyimpanan yang digunakan setiap jenis cadangan (penuh, diferensial, dan log) 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

Anda tidak dikenakan biaya untuk konsumsi penyimpanan cadangan hingga ukuran data maksimum untuk database. Untuk mengurangi konsumsi penyimpanan cadangan Anda, pertimbangkan beberapa teknik penyetelan berikut:

• 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 kelebihan biaya penyimpanan cadangan yang terus-menerus tinggi, pertimbangkan untuk meningkatkan 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 lokal yang redundan jika memungkinkan (misalnya, lingkungan pengembangan/pengujian).

Retensi Pencadangan

Azure SQL Database menyediakan retensi cadangan jangka pendek dan jangka panjang. Retensi jangka pendek memungkinkan PITR terjadi dalam periode retensi untuk basis data. 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 mengizinkan PITR dalam tujuh hari terakhir secara default. Azure SQL Database membuat cadangan penuh, diferensial, dan log secara teratur untuk memastikan bahwa database dapat dipulihkan ke titik waktu mana pun selama periode retensi database tersebut.

Anda dapat mengonfigurasi pencadangan diferensial untuk terjadi 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 nanti. Jika Anda mengubah opsi redundansi cadangan pada database yang ada, cadangan baru menggunakan opsi redundansi baru. Azure tidak memindahkan atau menyalin salinan cadangan yang dibuat dengan opsi redundansi jangka pendek sebelumnya. Azure meninggalkannya di akun penyimpanan asli hingga periode retensi berakhir, yang dapat 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 penggunaan penyimpanan cadangan, cadangan yang disimpan untuk memungkinkan 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, Azure menyimpan cadangan dengan cara yang sama untuk database online dengan periode retensi tertentu. Anda tidak dapat mengubah periode retensi cadangan untuk database yang dihapus.

Penting

Jika Anda menghapus server Azure SQL yang logis, Anda juga menghapus semua database di server logis tersebut. Anda tidak dapat memulihkan database yang dihapus. Anda tidak dapat memulihkan server logis yang dihapus. Tetapi jika Anda mengonfigurasi retensi jangka panjang untuk database, cadangan LTR tidak akan dihapus. Anda kemudian dapat menggunakan cadangan tersebut untuk memulihkan database di server logis yang berbeda dalam langganan yang sama, ke titik waktu ketika cadangan LTR diambil. Untuk informasi selengkapnya, lihat 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 Anda mengonfigurasi kebijakan LTR, Azure secara otomatis menyalin cadangan penuh ke kontainer penyimpanan yang berbeda setiap minggu.

Untuk memenuhi berbagai persyaratan kepatuhan, pilih periode retensi yang berbeda untuk pencadangan penuh mingguan, bulanan, dan tahunan. Frekuensi tergantung pada kebijakan. Misalnya, pengaturan W=0, M=1 membuat salinan LTR setiap bulan. Untuk informasi selengkapnya tentang LTR, lihat Retensi jangka panjang.

Memperbarui redundansi penyimpanan cadangan untuk database yang ada menerapkan perubahan hanya untuk 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. Gunakan 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 telah dipulihkan, kemudian perbarui database setelah dibuat. Anda perlu menentukan tujuan tingkat layanan yang ditargetkan saat memulihkan dari cadangan LTR.

Anda dapat mengaktifkan retensi jangka panjang 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. Hubungi dukungan Microsoft untuk mengaktifkan retensi pencadangan jangka panjang." Dalam hal ini, hubungi dukungan Microsoft dan buat tiket dukungan untuk menyelesaikannya.

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. Anda membayar penyimpanan cadangan berdasarkan gigabyte yang digunakan per bulan, dengan tarif yang sama untuk semua cadangan.

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 menyediakan penyimpanan data 4 TB, Anda mendapatkan ruang penyimpanan cadangan gratis 4 TB. Jika Anda menggunakan total 5,8 TB ruang penyimpanan cadangan, faktur Azure hanya menampilkan 1,8 TB, karena Anda hanya membayar untuk kelebihan penyimpanan cadangan yang Anda gunakan.

Model DTU

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

Dalam model DTU, Anda membayar biaya penyimpanan cadangan LTR untuk database dan kumpulan elastis berdasarkan jumlah penyimpanan aktual yang dikonsumsi oleh cadangan LTR.

Model vCore

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

Jika Anda menghapus database, konsumsi penyimpanan cadangan secara bertahap berkurang seiring bertambahnya usia cadangan lama dan dihapus. Karena pencadangan diferensial dan pencadangan log memerlukan pencadangan penuh sebelumnya agar dapat dipulihkan, Azure membersihkan ketiga jenis pencadangan bersama-sama dalam kumpulan mingguan. Setelah semua cadangan dihapus, penagihan akan berhenti.

Database hyperscale menggunakan metode yang berbeda untuk menghitung biaya penyimpanan cadangan. Untuk informasi selengkapnya, lihat Biaya penyimpanan cadangan Hyperscale.

Untuk database tunggal, Anda mendapatkan jumlah penyimpanan cadangan yang sama dengan ukuran penyimpanan data maksimum untuk database tanpa biaya tambahan. Persamaan berikut 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, Anda mendapatkan jumlah penyimpanan cadangan yang sama dengan penyimpanan data maksimum untuk ukuran penyimpanan kumpulan 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

Anda membayar total penyimpanan cadangan yang dapat ditagih, jika ada, dalam gigabyte per bulan sesuai dengan redundansi penyimpanan cadangan. 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 mengakumulasi 744 GB penyimpanan cadangan dan jumlah ini tetap konstan sepanjang bulan penuh karena database benar-benar tidak digunakan. 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 retensi database yang tidak aktif yang sama meningkat dari 7 hari menjadi 14 hari di pertengahan bulan. Peningkatan ini menghasilkan total penggandaan penyimpanan cadangan menjadi 1.488 GB. SQL Database melaporkan penggunaan 1 GB selama jam 1 hingga 372 (paruh pertama bulan ini). Ini melaporkan penggunaan sebagai 2 GB untuk jam 373 hingga 744 (paruh kedua bulan ini). Penggunaan ini digabungkan menjadi tagihan akhir sebesar 1.116 GB per bulan.

Skenario tagihan cadangan yang sebenarnya lebih kompleks. Karena tingkat perubahan dalam database bergantung pada beban kerja dan bervariasi dari waktu ke waktu, ukuran setiap cadangan diferensial dan log juga 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 backup diferensial 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 dilakukan pembuatan ulang indeks disertakan:

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

Untuk skenario terakhir pada database yang lebih besar, Azure melakukan pengoptimalan dengan membuat cadangan penuh alih-alih cadangan diferensial jika cadangan diferensial akan berukuran terlalu besar. Pengoptimalan ini mengurangi ukuran semua cadangan diferensial hingga pencadangan penuh berikut.

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 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.

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

Penting

Meteran hanya terlihat untuk alat penghitung yang saat ini sedang digunakan. Jika penghitung tidak tersedia, kemungkinan kategori saat ini tidak digunakan. Misalnya, penghitung penyimpanan tidak terlihat untuk sumber daya yang tidak menggunakan penyimpanan. Jika tidak ada konsumsi penyimpanan cadangan PITR atau LTR, pengukur ini tidak terlihat.

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

Cadangan terenkripsi

Jika Anda mengenkripsi database dengan menggunakan TDE, cadangan secara otomatis dienkripsi saat tidak aktif, 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

Azure SQL Database secara otomatis menangani jenis kerusakan data tertentu dengan menggunakan teknik bawaan saat diperlukan, tanpa kehilangan data. Di Azure SQL Database, SQL Database Engine melakukan verifikasi halaman selama pencadangan yang dikelola layanan dan selama setiap operasi pemulihan. Setiap masalah yang ditemukan selama pemeriksaan integritas mengakibatkan pemberitahuan kepada tim teknik.

Sebagai lapisan perlindungan ekstra, Anda dapat menguji pemulihan cadangan dan menjalankan pemeriksaan integritas. Untuk informasi selengkapnya, lihat Integritas data di Azure SQL Database.

Semua cadangan basis data menggunakan opsi CHECKSUM untuk memberikan integritas tambahan pada cadangan.

Proteksi cadangan

Langganan Azure milik Microsoft mengelola cadangan Azure SQL Database dengan menggunakan akun Azure Storage internal yang aman. Anda tidak dapat mengakses cadangan ini secara eksternal, sehingga mereka memberikan isolasi dan perlindungan data yang kuat. Dalam Microsoft, hanya layanan backend yang dapat mengakses, membuat, menyalin, atau memulihkan cadangan ini. Para insinyur Microsoft, termasuk pengembang, tidak memiliki akses tetap. Untuk meminimalkan paparan dan memaksimalkan keamanan, Microsoft hanya dapat memperoleh akses Just-In-Time (JIT) di bawah kontrol audit yang ketat jika benar-benar diperlukan untuk memecahkan masalah pelanggan tertentu.

Cadangan dihapus secara otomatis setelah periode retensi berakhir.

Kepatuhan melalui retensi cadangan

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

Saat Anda memigrasikan database dari tingkat layanan berbasis DTU ke tingkat layanan berbasis vCore, migrasi mempertahankan retensi PITR untuk memastikan bahwa kebijakan pemulihan data aplikasi Anda tidak disusupi.

Catatan

Untuk langkah-langkah menghapus data pribadi di cadangan Azure SQL Database untuk mendukung kewajiban Anda berdasarkan GDPR, lihat Mengubah pengaturan pencadangan otomatis. 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 Anda di satu wilayah Azure, Anda dapat menerapkan pencadangan zona redundan atau redundan 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 tetap sesuai dengan 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 di tingkat organisasi, tetapkan kebijakan ke langganan dengan menggunakan portal Azure atau Azure PowerShell.

Misalnya, jika Anda mengaktifkan kebijakan "Azure SQL DB harus menghindari penggunaan cadangan GRS", pengguna tidak dapat membuat database dengan penyimpanan default sebagai penyimpanan redundan global. Kebijakan ini mencegah pengguna menggunakan GRS dan mengembalikan pesan kesalahan "Mengonfigurasi jenis akun penyimpanan cadangan ke 'Standard_RAGRS' gagal selama pembuatan atau pembaruan Database."

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

Penting

Kebijakan Azure tidak diterapkan 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 Ubah 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.
• Referensi konfigurasi yang dapat dimodifikasi untuk Azure SQL Database