Optimalkan strategi pencadangan SQL Server - AWS Bimbingan Preskriptif
Gambaran UmumPencadangan tingkat server menggunakan snapshot yang diaktifkan VSSSQLPencadangan server menggunakan AWS BackupPencadangan tingkat basis dataRekomendasi pengoptimalan biayaSumber daya tambahan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Optimalkan strategi pencadangan SQL Server

Gambaran Umum

Sebagian besar organisasi mencari solusi yang tepat untuk melindungi data mereka di Server SQL di Amazon EC2 untuk memenuhi persyaratan mereka saat ini untuk tujuan titik pemulihan (RPO), jumlah waktu maksimum yang dapat diterima sejak pencadangan terakhir, dan tujuan waktu pemulihan (RTO), penundaan maksimum yang dapat diterima antara gangguan layanan dan pemulihan layanan. Jika Anda menjalankan SQL Server pada EC2 instance, Anda memiliki beberapa opsi untuk membuat cadangan data Anda dan memulihkan data Anda. Strategi Backup untuk melindungi data untuk Server SQL di Amazon EC2 meliputi:

Anda memiliki opsi penyimpanan berikut untuk cadangan asli tingkat basis data:

Bagian ini melakukan hal berikut:

  • Menyoroti fitur untuk membantu Anda menghemat ruang penyimpanan

  • Membandingkan biaya antara opsi penyimpanan backend yang berbeda

  • Menyediakan tautan ke dokumentasi mendalam untuk membantu mengimplementasikan rekomendasi ini

Pencadangan tingkat server menggunakan snapshot yang diaktifkan VSS

Arsitektur snapshots yang VSS diaktifkan menggunakan AWS Systems Manager Run Command untuk menginstal VSS agen pada instance SQL Server Anda. Anda juga dapat menggunakan Run Command untuk memanggil seluruh alur kerja sistem operasi pembilasan dan buffer aplikasi ke disk, menjeda operasi I/O, mengambil point-in-time snapshot volume, dan kemudian melanjutkan I/O. EBS

Perintah Jalankan ini membuat snapshot otomatis dari semua EBS volume yang dilampirkan ke instance target. Anda juga memiliki opsi untuk mengecualikan volume root, karena file database pengguna biasanya disimpan pada volume lain. Jika Anda melakukan stripe beberapa EBS volume untuk membuat sistem file tunggal untuk file SQL Server, Amazon EBS juga mendukung snapshot multivolume yang konsisten dengan crash menggunakan satu perintah. API Untuk informasi selengkapnya tentang snapshot yang VSSdiaktifkan dengan konsisten aplikasi, lihat Membuat EBS snapshot yang VSS konsisten dengan aplikasi dalam dokumentasi Amazon. EC2

Diagram berikut menunjukkan arsitektur untuk pencadangan tingkat server menggunakan VSS snapshot -enabled.

VSS-mengaktifkan arsitektur snapshot

Pertimbangkan manfaat berikut menggunakan snapshot VSS yang diaktifkan:

  • Snapshot pertama instans DB berisi data untuk instans DB penuh. Snapshot berikutnya dari instans DB yang sama bersifat inkremental, yang berarti hanya data yang telah berubah setelah snapshot terbaru Anda disimpan.

  • EBSsnapshot memberikan point-in-time pemulihan.

  • Anda dapat mengembalikan ke EC2 instance SQL Server baru dari snapshot.

  • Jika instance dienkripsi menggunakan Amazon EBS atau jika database dienkripsi dalam instance yang digunakanTDE, instance atau database tersebut secara otomatis dipulihkan dengan enkripsi yang sama.

  • Anda dapat menyalin backup Lintas wilayah otomatis Anda.

  • Ketika Anda mengembalikan EBS volume dari snapshot, itu menjadi segera tersedia bagi aplikasi untuk mengaksesnya. Ini berarti bahwa Anda dapat segera membawa SQL Server online setelah memulihkan satu atau lebih EBS volume yang mendasarinya dari snapshot.

  • Secara default, volume yang dipulihkan mengambil blok yang mendasari dari Amazon S3 saat pertama kali aplikasi mencoba membacanya. Ini berarti bahwa mungkin ada lag dalam kinerja setelah EBS volume dipulihkan dari snapshot. Volume akhirnya menyusul kinerja nominal. Namun, Anda dapat menghindari lag tersebut dengan menggunakan snapshot snapshot-restore () FSR cepat.

  • Anda dapat menggunakan manajemen siklus hidup untuk EBS snapshot.

Pertimbangkan batasan berikut menggunakan snapshot VSS yang diaktifkan:

  • Anda tidak dapat melakukan point-in-time pemulihan lintas wilayah dengan snapshot terenkripsi untuk instance Server. SQL

  • Anda tidak dapat membuat snapshot terenkripsi dari instance yang tidak terenkripsi.

  • Anda tidak dapat memulihkan database individual karena snapshot diambil pada tingkat EBS volume.

  • Anda tidak dapat mengembalikan instance ke dirinya sendiri.

  • Sebuah snapshot dari instans DB harus dienkripsi dengan menggunakan kunci AWS Key Management Service (AWS KMS) yang sama dengan instans DB.

  • Penyimpanan I/O ditangguhkan selama sepersekian detik (sekitar 10 milidetik) selama proses pencadangan snapshot.

SQLPencadangan server menggunakan AWS Backup

Anda dapat menggunakan AWS Backupuntuk memusatkan dan mengotomatiskan perlindungan data di seluruh. Layanan AWS AWS Backup menawarkan solusi berbasis kebijakan yang hemat biaya, dikelola sepenuhnya, yang menyederhanakan perlindungan data dalam skala besar. AWS Backup juga membantu Anda mendukung kewajiban kepatuhan peraturan Anda dan memenuhi tujuan kelangsungan bisnis Anda. Bersama dengan AWS Organizations, AWS Backup Anda dapat menerapkan kebijakan perlindungan data (backup) secara terpusat untuk mengonfigurasi, mengelola, dan mengatur aktivitas pencadangan di seluruh organisasi dan sumber daya Anda. Akun AWS

Diagram berikut menunjukkan arsitektur solusi cadangan dan pemulihan untuk SQL Server EC2 dengan menggunakan AWS Backup.

AWS Backup arsitektur

Pertimbangkan manfaat pencadangan SQL Server berikut dengan menggunakan AWS Backup:

  • Anda dapat mengotomatiskan penjadwalan cadangan, manajemen retensi, dan manajemen siklus hidup.

  • Anda dapat memusatkan strategi pencadangan di seluruh organisasi, mencakup beberapa akun dan. Wilayah AWS

  • Anda dapat memusatkan pemantauan aktivitas pencadangan dan peringatan di seluruh. Layanan AWS

  • Anda dapat menerapkan backup lintas wilayah untuk perencanaan pemulihan bencana.

  • Solusinya mendukung pencadangan lintas akun.

  • Anda dapat melakukan backup aman dengan enkripsi cadangan sekunder.

  • Semua backup mendukung enkripsi dengan menggunakan kunci AWS KMS enkripsi.

  • Solusinya bekerja denganTDE.

  • Anda dapat mengembalikan ke titik pemulihan tertentu dari AWS Backup konsol.

  • Anda dapat mencadangkan seluruh instance SQL Server, yang mencakup semua database SQL Server.

Pencadangan tingkat basis data

Pendekatan ini menggunakan fungsionalitas cadangan Microsoft SQL Server asli. Anda dapat mengambil backup database individual pada instance SQL Server dan mengembalikan database individual.

Masing-masing opsi ini untuk pencadangan dan pemulihan SQL Server asli juga mendukung yang berikut:

  • Kompresi dan cadangan beberapa file

  • Pencadangan penuh, diferensial, dan T-log

  • TDE-database terenkripsi

SQLPencadangan asli server dan pulihkan ke Amazon S3

SQLServer di Amazon EC2 mendukung pencadangan dan pemulihan asli untuk database SQL Server. Anda dapat mengambil cadangan database SQL Server Anda dan kemudian memulihkan file cadangan ke database yang ada atau ke EC2 instance SQL Server baru, Amazon RDS untuk SQL Server, atau server lokal.

Storage Gateway adalah layanan penyimpanan cloud hybrid yang menyediakan aplikasi lokal dengan akses ke penyimpanan cloud yang hampir tidak terbatas. Anda dapat menggunakan Storage Gateway untuk mencadangkan database Microsoft SQL Server langsung ke Amazon S3, mengurangi jejak penyimpanan lokal dan menggunakan Amazon S3 untuk penyimpanan yang tahan lama, terukur, dan hemat biaya.

Diagram berikut menunjukkan arsitektur solusi backup dan restore asli yang menggunakan Storage Gateway dan Amazon S3.

Storage Gateway dan arsitektur Amazon S3

Pertimbangkan manfaat berikut menggunakan backup SQL Server asli dengan Storage Gateway:

  • Anda dapat memetakan gateway penyimpanan sebagai berbagi file Server Message Block (SMB) pada EC2 instance dan mengirim cadangan ke Amazon S3.

  • Cadangan langsung masuk ke bucket S3 atau melalui cache file Storage Gateway.

  • Backup multi-file didukung.

Pertimbangkan batasan cadangan asli berikut menggunakan Storage Gateway:

Untuk informasi selengkapnya tentang cara mengatur Storage Gateway, lihat backup Store SQL Server di Amazon S3 AWS Storage Gateway menggunakan postingan di Blog. AWS

SQLPencadangan asli server ke EBS volume

Anda dapat mengambil cadangan asli dari database SQL Server Anda dan menyimpan file dalam EBS volume Amazon. Amazon EBS adalah layanan penyimpanan blok yang sangat berkinerja tinggi. EBSvolume elastis, yang mendukung enkripsi. Mereka dapat dilepaskan dan dilampirkan ke sebuah EC2 instance. Anda dapat mencadangkan SQL Server pada EC2 instance pada jenis EBS volume yang sama atau pada jenis EBS volume yang berbeda. Salah satu keuntungan dari membuat cadangan ke EBS volume yang berbeda adalah penghematan biaya.

Diagram berikut menunjukkan arsitektur cadangan asli ke EBS volume.

Arsitektur EBS volume Amazon

Pertimbangkan manfaat berikut menggunakan cadangan asli SQL Server ke EBS volume:

  • Anda dapat mengambil backup database individual pada EC2 instance SQL Server dan memulihkan database individual alih-alih harus mengembalikan instance lengkap.

  • Backup multi-file didukung.

  • Anda dapat menjadwalkan pekerjaan cadangan dengan menggunakan Agen SQL SQL Server dan mesin kerja Server.

  • Anda bisa mendapatkan manfaat kinerja melalui pilihan perangkat keras Anda. Misalnya, Anda dapat menggunakan volume penyimpanan st1 untuk mencapai throughput yang lebih tinggi.

Pertimbangkan batasan berikut menggunakan cadangan asli ke EBS volume:

  • Anda harus memindahkan cadangan secara manual ke Amazon S3 dari volume. EBS

  • Untuk cadangan besar, Anda harus mengelola ruang disk di Amazon. EC2

  • Pada EC2 contoh, EBS throughput Amazon bisa menjadi hambatan.

  • Penyimpanan tambahan diperlukan untuk menyimpan cadangan di Amazon. EBS

SQLPencadangan asli server ke Amazon FSx untuk Windows File Server

Amazon FSx untuk Windows File Server adalah sistem file Windows asli yang dikelola sepenuhnya yang menawarkan penyimpanan hingga 64 TB yang dirancang untuk memberikan kinerja yang cepat, dapat diprediksi, dan konsisten. AWS memperkenalkan dukungan asli untuk penyebaran sistem file Multi-AZ FSx untuk Windows File Server. Dukungan asli membuatnya lebih mudah untuk menyebarkan penyimpanan file Windows AWS dengan ketersediaan tinggi dan redundansi di beberapa Availability Zone. AWS juga memperkenalkan dukungan untuk berbagi file SMB Continuously Available (CA). Anda dapat menggunakan FSx untuk Windows File Server sebagai penyimpanan cadangan untuk database SQL Server.

Diagram berikut menunjukkan arsitektur cadangan SQL Server asli FSx untuk Windows File Server.

FSxuntuk arsitektur cadangan Windows File Server

Pertimbangkan manfaat berikut menggunakan cadangan SQL Server asli FSx untuk Windows File Server:

  • Anda dapat mencadangkan database SQL Server Anda ke berbagi FSx file Amazon.

  • Anda dapat mengambil backup database individual pada instance SQL Server dan memulihkan database individual alih-alih harus mengembalikan instance lengkap.

  • Cadangan multi-bagian didukung.

  • Anda dapat menjadwalkan pekerjaan cadangan dengan menggunakan Agen SQL Server dan mesin pekerjaan.

  • Instans memiliki bandwidth jaringan yang lebih tinggi dibandingkan dengan AmazonEBS.

Pertimbangkan batasan berikut menggunakan cadangan SQL Server asli FSx untuk Windows File Server:

  • Anda harus memindahkan cadangan secara manual ke Amazon S3 dari FSx Amazon AWS Backup dengan menggunakan atau. AWS DataSync

  • Pencadangan besar mungkin memerlukan overhead tambahan untuk manajemen ruang disk di Amazon. FSx

  • EC2throughput jaringan instance bisa menjadi hambatan.

  • Penyimpanan tambahan diperlukan untuk menyimpan cadangan FSx untuk Windows File Server.

SQLPencadangan server ke Amazon FSx untuk NetApp ONTAP

Snapshot dengan FSx for ONTAP selalu konsisten crash, tetapi mereka mengharuskan Anda untuk diam (atau menjeda I/O dari) database Anda untuk membuat snapshot yang konsisten dengan aplikasi. Anda dapat menggunakan NetApp SnapCenter (alat orkestrasi dengan plug-in untuk aplikasi tertentu, termasuk SQL Server) dengan FSx untuk ONTAP membuat snapshot yang konsisten aplikasi dan melindungi, mereplikasi, dan mengkloning database Anda tanpa biaya tambahan.

NetApp SnapCenter

NetApp SnapCenter adalah platform terpadu untuk perlindungan data yang konsisten aplikasi. SnapCenter mengacu pada snapshot sebagai cadangan. Panduan ini mengadopsi konvensi penamaan yang sama. SnapCenter menyediakan satu panel kaca untuk mengelola pencadangan, pemulihan, dan klon yang konsisten aplikasi. Anda menambahkan SnapCenter plug-in untuk aplikasi database spesifik Anda untuk membuat backup yang konsisten aplikasi. SnapCenter Plug-in untuk SQL Server menyediakan fungsionalitas berikut yang menyederhanakan alur kerja perlindungan data Anda.

  • Opsi Backup dan Restore dengan perincian untuk backup penuh dan log

  • Pemulihan dan pemulihan di tempat ke lokasi alternatif

Untuk informasi selengkapnya SnapCenter, lihat Lindungi beban kerja SQL Server Anda menggunakan NetApp SnapCenter Amazon FSx untuk NetApp ONTAP posting di Blog AWS Penyimpanan.

Optimalisasi biaya untuk backup

Opsi berikut dapat membantu Anda mengurangi biaya penyimpanan cadangan SQL Server. AWS

  • Aktifkan kompresi SQL Server selama pembuatan file cadangan dan kirim file sekecil mungkin ke penyimpanan. Misalnya, rasio kompresi 3:1 menunjukkan bahwa Anda menghemat sekitar 66 persen pada ruang disk. Untuk query pada kolom ini, Anda dapat menggunakan SQL pernyataan Transact- berikut:SELECT backup_size/compressed_backup_size FROM msdb..backupset;.

  • Untuk cadangan yang masuk ke bucket S3, aktifkan kelas penyimpanan Amazon S3 Intelligent-Tiering untuk mengurangi biaya penyimpanan hingga 30 persen. 

  • Untuk cadangan untuk Windows File Server atau FSx untukONTAP, gunakan Availability Zone tunggal FSx untuk penghematan biaya 50 persen (dibandingkan dengan menggunakan beberapa Availability Zone). Untuk informasi harga, lihat Harga Amazon FSx untuk Windows File Server dan Amazon FSx untuk NetApp ONTAP Harga.

  • Opsi paling efisien untuk SQL Server 2022 adalah pencadangan langsung ke Amazon S3. Anda dapat menghemat biaya tambahan dengan menghindari Storage Gateway.

Hasil tes benchmark untuk backup

Bagian ini membandingkan opsi berikut dari sudut pandang biaya dan kinerja untuk database sampel 1 TB, berdasarkan hasil pengujian benchmark kinerja pada solusi cadangan yang tercakup dalam panduan ini.

  • EC2spesifikasi instance - r5d.8xlarge dengan edisi Pengembang Windows Server 2019 dan Server 2019 SQL

  • Spesifikasi basis data - ukuran 1 TB dengan TDE dinonaktifkan

Pengujian dilakukan dengan instance r5d.8xlarge dan database SQL Server 1 TB sebagai sumbernya. Sistem sumber dikonfigurasi sesuai dengan praktik terbaik, dan database sumber berisi empat file data (masing-masing 250 GB) dan satu file log (50 GB) yang tersebar di volume gp3 yang terpisah. BACKUPPerintah asli SQL Server termasuk menulis ke 10 file cadangan, menggunakan kompresi untuk mengoptimalkan kinerja cadangan dan mengurangi jumlah data yang dikirim di seluruh jaringan dan ditulis ke target. Dalam semua kasus uji, kinerja penyimpanan adalah hambatan.

Ada berbagai kemungkinan konfigurasi yang hampir tak ada habisnya untuk jenis pengujian ini. Tes ini berfokus pada pengoptimalan kinerja, biaya, skalabilitas, dan kasus penggunaan dunia nyata. Tabel berikut menunjukkan metrik kinerja yang diambil untuk opsi target cadangan.

Opsi Backup Tingkat Durasi lari (Appx) Tingkat Backup Biaya USD per bulan*
Cadangan asli ke EBS st1 lokalHDD, 2 TB Basis Data 00:30:46 mnt 554, 7 Mbps $92,16
Cadangan asli ke EBS SSD gp3 lokal, 2 TB Basis Data 00:22:00 mnt 512 Mbps $193,84
Cadangan asli FSx untuk Server File WindowsHDD, throughput 2 TB @512 Mbps Basis Data 00:20:58 mnt 814,0 Mbps $1.146
Cadangan asli FSx untuk Server File WindowsSSD, throughput 2 TB @512 Mbps Basis Data 00:20:00 mnt 814,0 Mbps $1,326
Cadangan asli ke S3 File Gateway m6i.4xlarge (16 vCPU, 64 GB) dengan 2 TB gp3 Basis Data 00:23:20 mnt 731,5 Mbps $470.42
EBSVSSsnapshot EBSVolume

00:00:02 dtk

00:00:53 dtk

 Cuplikan N/A $51
AWS Backup (AMIcadangan) AMI

00:00:04 dtk

00:08:00 mnt

 Cuplikan N/A $75
Pencadangan SQL Server Asli langsung ke Amazon S3 (SQLServer 2022) Basis Data 00:12:00 mnt 731,5 Mbps 50 TB/Bulan Pertama, $0,023 per GB $23,55 per bulan
Cadangan asli ke FSx for ONTAP (menggunakan SnapCenter) Basis Data – – $440,20

Tabel sebelumnya mengasumsikan hal berikut:

  • Transfer data dan biaya Amazon S3 tidak termasuk.

  • Harga penyimpanan sudah termasuk dalam harga instans.

  • Biaya berbasis di us-east-1 Wilayah.

  • Throughput dan IOPS tumbuh sebesar 10 persen dengan beberapa cadangan yang memiliki tingkat perubahan keseluruhan 10 persen selama sebulan.

Hasil pengujian menunjukkan bahwa opsi tercepat adalah cadangan database SQL Server asli FSx untuk Windows File Server. Cadangan ke Storage Gateway dan EBS volume yang terpasang secara lokal adalah opsi yang lebih hemat biaya tetapi memiliki kinerja yang lebih lambat. Untuk pencadangan tingkat server (AMI), sebaiknya gunakan AWS Backup untuk kinerja, biaya, dan pengelolaan yang optimal.

Rekomendasi pengoptimalan biaya

Memahami solusi yang mungkin untuk mencadangkan SQL Server di Amazon EC2 adalah kunci untuk melindungi data Anda, memastikan bahwa Anda memenuhi kebutuhan cadangan, dan menempatkan rencana untuk memulihkan dari peristiwa penting. Berbagai cara untuk mencadangkan dan memulihkan instans dan database SQL Server Anda yang dieksplorasi di bagian ini dapat membantu Anda menyusun strategi pencadangan dan pemulihan yang melindungi data Anda dan memenuhi persyaratan organisasi Anda.

Bagian ini mencakup opsi cadangan berikut:

  • Kompresi

  • Amazon S3 Intelligent-Tiering

  • Zona Ketersediaan Tunggal

  • Backup ke URL

Panduan yang diberikan untuk masing-masing opsi ini adalah tingkat tinggi. Jika Anda ingin menerapkan salah satu rekomendasi ini di organisasi Anda, kami sarankan Anda menghubungi tim akun Anda. Tim kemudian dapat terlibat dengan Microsoft Specialist SA untuk memimpin percakapan. Anda juga dapat menghubungi dengan mengirim email ke optimize-microsoft@amazon.com.

Singkatnya, kami merekomendasikan yang berikut:

  • Jika Anda menggunakan SQL Server 2022, mencadangkan ke Amazon S3 adalah opsi yang paling hemat biaya.

  • Jika Anda menggunakan SQL Server 2019 dan edisi SQL Server sebelumnya, pertimbangkan untuk membuat cadangan ke Storage Gateway yang didukung oleh Amazon S3 sebagai opsi yang paling hemat biaya.

Kompresi

Tujuan kompresi adalah untuk memiliki lebih sedikit penyimpanan yang dikonsumsi oleh setiap cadangan, yang bermanfaat untuk berbagai opsi penyimpanan. Anda harus mengaktifkan kompresi untuk cadangan SQL Server di tingkat instance SQL Server. Contoh berikut menunjukkan cara menambahkan kata kunci kompresi dengan database cadangan:

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE)

Amazon S3 Intelligent-Tiering

Untuk pencadangan yang masuk ke bucket Amazon S3, Anda dapat mengaktifkan Amazon S3 Intelligent-Tiering sebagai kelas penyimpanan Amazon S3 File Gateway Anda. Ini dapat mengurangi biaya penyimpanan hingga 30 persen. Anda kemudian memasang S3 File Gateway ke SQL server Anda dengan menggunakan berbagi SMB file yang dapat diintegrasikan dengan domain Active Directory Anda. Ini memberi Anda kontrol akses untuk berbagi, kemampuan untuk memanfaatkan akun layanan yang ada, dan akses ke Amazon S3 menggunakan protokol file fokus Microsoft yang umum. Untuk akun yang mungkin tidak memiliki konektivitas langsung ke pengontrol domain, Anda dapat menggunakan Konektor Direktori Aktif untuk memfasilitasi komunikasi dengan Active Directory lokal atau di cloud. Untuk mengkonfigurasi pengaturan Direktori Aktif pada gateway, Anda harus menentukan Konektor Direktori Aktif IPs untuk pengontrol domain untuk permintaan proxy ke Active Directory.

Diagram berikut menunjukkan arsitektur untuk solusi berdasarkan S3 Intelligent-Tiering.

Arsitektur Tingkat Cerdas S3

Secara default, file cadangan yang ditulis ke bucket S3 menggunakan tingkat Standar. Untuk mengonversi file cadangan dari tingkat Standar ke S3 Intelligent-Tiering, Anda harus membuat aturan siklus hidup. Anda juga dapat menggunakan AWS Management Consoleuntuk mengaktifkan S3 Intelligent-Tiering. Untuk informasi selengkapnya, lihat Memulai Menggunakan Amazon S3 Intelligent-Tiering dalam dokumentasi. AWS

Zona Ketersediaan Tunggal

Untuk membuat sistem file Zona Ketersediaan Tunggal, pilih opsi Single-AZ saat Anda membuat sistem file FSx untuk Windows File Server. Amazon FSx juga mengambil cadangan yang sangat tahan lama (disimpan di Amazon S3) dari sistem file Anda setiap hari menggunakan Windows Volume Shadow Copy Service, dan memungkinkan Anda untuk mengambil cadangan tambahan kapan saja. Ingatlah beberapa masalah dengan menggunakan Zona Ketersediaan Tunggal. Misalnya, berbagi SMB file menjadi tidak dapat diakses jika Availability Zone yang terpengaruh di mana sistem file disediakan turun selama berjam-jam pada suatu waktu. Jika Anda memerlukan akses ke data, Anda harus memulihkannya dari cadangan di Availability Zone yang tersedia dalam Wilayah sumber. Untuk informasi selengkapnya, lihat bagian Gunakan Zona Ketersediaan tunggal pada panduan ini.

Backup ke URL

Untuk SQL Server 2022, URL fitur pencadangan ke memungkinkan pencadangan langsung ke Amazon S3. Ini adalah pendekatan pencadangan ideal untuk SQL Server 2022 yang berjalan AWS saat Anda mendapatkan set fitur lengkap Amazon S3 di lapisan penyimpanan dan menghapus biaya AWS Storage Gateway alat yang diperlukan di versi sebelumnya untuk memfasilitasi fungsionalitas ini. Ada dua biaya utama yang perlu dipertimbangkan saat menerapkan fitur ini: biaya transfer data dan kelas penyimpanan S3 yang dipilih. Jika Anda menginginkan kemampuan pemulihan bencana asli Amazon S3, maka Anda harus memperhitungkan bahwa Replikasi Lintas Wilayah menimbulkan biaya keluar data lintas wilayah. Untuk mempelajari lebih lanjut tentang cara mengonfigurasi opsi ini, lihat database Backup SQL Server ke posting Amazon S3 di Microsoft AWS Workloads di blog.

Sumber daya tambahan