Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini menjelaskan cara layanan Azure Backup melakukan pencadangan mesin virtual (VM) di Azure.
Azure Backup menyediakan cadangan independen dan terisolasi untuk melindungi terhadap kerusakan data yang tidak disengaja pada VM Anda. Cadangan disimpan dalam brankas Layanan Pemulihan dengan pengelolaan titik pemulihan yang terintegrasi. Konfigurasi dan skala mudah, pencadangan dioptimalkan, dan Anda dapat dengan mudah memulihkan sesuai kebutuhan.
Sebagai bagian dari proses pencadangan, sebuah snapshot dibuat, dan data ditransfer ke vault Layanan Pemulihan tanpa memengaruhi beban kerja produksi. Snapshot menyediakan tingkat konsistensi yang berbeda, seperti yang dijelaskan di sini. Anda dapat memilih cadangan konsisten aplikasi/file yang berbasis agen atau cadangan konsisten crash tanpa agen dalam kebijakan cadangan.
Azure Backup juga memiliki penawaran khusus untuk beban kerja basis data seperti SQL Server dan SAP HANA yang menyadari beban kerja, menawarkan RPO (recovery point objective) 15 menit, dan memungkinkan cadangan serta pemulihan basis data individu.
Sekarang Anda juga dapat mencadangkan mesin virtual Anda dengan Azure Backup di Azure Extended Zones (pratinjau). Azure Extended Zones (pratinjau) menyediakan ketahanan yang ditingkatkan dengan mendistribusikan sumber daya ke berbagai lokasi fisik dalam satu wilayah Azure. Pendekatan ini meminimalkan dampak potensi kegagalan untuk infrastruktur penting. Dengan menggunakan Zona Yang Diperluas, organisasi Anda dapat mencapai ketersediaan dan toleransi kesalahan yang lebih tinggi untuk aplikasi mereka. Pelajari cara mencadangkan VM Azure di Zona Diperluas Azure (pratinjau).
Proses pencadangan
Inilah cara Azure Backup menyelesaikan pencadangan untuk VM Azure:
Untuk VM Azure yang dipilih untuk pencadangan, Azure Backup memulai pekerjaan pencadangan sesuai dengan jadwal pencadangan yang Anda tentukan.
Jika Anda telah memilih pencadangan yang konsisten pada aplikasi atau sistem file, VM perlu memiliki ekstensi pencadangan yang terpasang untuk mengoordinasikan proses pengambilan gambar.
Jika Anda memilih cadangan konsisten crash, tidak diperlukan agen di VM.
Selama cadangan pertama, ekstensi cadangan diinstal pada VM jika VM berjalan.
- Untuk VM Windows, ekstensi VMSnapshot diinstal.
- Untuk VM Linux, ekstensi VMSnapshotLinux diinstal.
Untuk VM Windows yang sedang berjalan, Azure Backup berkoordinasi dengan Windows Volume Shadow Copy Service (VSS) untuk mengambil snapshot VM yang konsisten dengan aplikasi.
- Secara default, Pencadangan melakukan pencadangan VSS penuh.
- Jika Backup tidak dapat mengambil snapshot yang konsisten dengan aplikasi, maka akan mengambil snapshot yang konsisten dengan file dari penyimpanan dasar, karena tidak ada penulisan aplikasi yang terjadi saat VM dihentikan.
Untuk VM Linux, Backup mengambil cadangan file yang konsisten. Untuk mendapatkan snapshot yang konsisten dengan aplikasi, Anda perlu menyesuaikan skrip pra/pasca secara manual.
Untuk VM Windows, Microsoft Visual C++ 2015 Redistributable (x64) versi 14.40.33810.0 diinstal, pengaktifan Volume Shadow Copy Service (VSS) diubah menjadi otomatis, dan Layanan Windows IaaSVmProvider ditambahkan.
Setelah Backup mengambil snapshot, ia mentransfer data ke kubah.
- Pencadangan dioptimalkan dengan mencadangkan setiap disk VM secara paralel.
- Untuk setiap disk yang sedang dicadangkan, Azure Backup membaca blok pada disk dan mengidentifikasi dan mentransfer hanya blok data yang berubah (delta) sejak cadangan sebelumnya.
- Data snapshot mungkin tidak segera disalin ke penyimpanan cadangan. Mungkin akan memerlukan beberapa jam pada waktu sibuk. Waktu cadangan total untuk sebuah VM akan kurang dari 24 jam untuk kebijakan cadangan harian.
Enkripsi cadangan VM Azure
Ketika Anda melakukan pencadangan VM Azure dengan Azure Backup, VM dienkripsi saat tidak aktif dengan Storage Service Encryption (SSE). Azure Backup juga dapat mencadangkan mesin virtual Azure yang dienkripsi menggunakan Enkripsi Disk Azure.
| Enkripsi | Rincian | Dukungan |
|---|---|---|
| Selatan-Tenggara | Dengan SSE, Azure Storage menyediakan enkripsi saat data tidak aktif dengan secara otomatis mengenkripsi data sebelum menyimpannya. Azure Storage juga mendekripsi data sebelum mengambilnya. Azure Backup mendukung pencadangan Mesin Virtual (VM) dengan dua jenis Enkripsi Layanan Penyimpanan. |
Azure Backup menggunakan SSE untuk enkripsi saat tidak aktif dari Azure VM. |
| Azure Disk Encryption | Azure Disk Encryption mengenkripsi cakram OS dan data untuk mesin virtual Azure. Enkripsi Disk Azure berintegrasi dengan kunci enkripsi BitLocker (BEK), yang dijaga keamanannya di brankas kunci sebagai rahasia. Enkripsi Disk Azure juga terintegrasi dengan kunci enkripsi kunci Azure Key Vault (KEK). |
Azure Backup mendukung pencadangan VM Azure yang dikelola dan tidak dikelola, yang dienkripsi hanya dengan BEK, atau dengan BEK bersama dengan KEK. Baik BEKs maupun KEKs dicadangkan dan dienkripsi. Karena KEK dan BEK telah di-backup, pengguna dengan izin yang diperlukan dapat memulihkan kunci dan rahasia kembali ke gudang kunci jika diperlukan. Pengguna ini juga dapat memulihkan VM yang terenkripsi. Kunci dan rahasia terenkripsi tidak dapat dibaca oleh pengguna yang tidak sah atau oleh Azure. |
Untuk Azure VM yang dikelola dan tidak dikelola, Backup mendukung baik VM yang dienkripsi hanya dengan BEK maupun VM yang dienkripsi dengan BEK bersama dengan KEK.
BEK (rahasia) dan KEK (kunci) yang dicadangkan telah dienkripsi. Data tersebut hanya dapat dibaca dan digunakan oleh pengguna yang berwenang ketika dikembalikan ke penyimpanan kunci. Baik pengguna yang tidak berwenang, maupun Azure, tidak dapat membaca atau menggunakan kunci atau rahasia yang dicadangkan.
BEKs juga dicadangkan. Jadi, jika BEK hilang, pengguna yang berwenang dapat memulihkan BEK ke dalam key vault dan memulihkan VM yang terenkripsi. Hanya pengguna dengan tingkat izin yang diperlukan dapat mencadangkan dan memulihkan VM yang dienkripsi atau kunci dan rahasia.
Pembuatan cuplikan
Azure Backup mengambil cuplikan sesuai dengan jadwal pencadangan.
Jika Anda telah memilih pencadangan yang konsisten dengan aplikasi atau sistem file, VM perlu memiliki ekstensi pencadangan yang terpasang untuk mengkoordinasikan proses snapshot. Untuk pencadangan yang konsisten dengan crash multi-disk tanpa agen, agen VM tidak diperlukan untuk rekam jepret.
Windows VMs: Untuk Windows VM, layanan Pencadangan berkoordinasi dengan VSS untuk mengambil cuplikan disk VM yang konsisten dengan aplikasi. Secara default, Azure Backup melakukan pencadangan VSS penuh (ia memangkas log dari aplikasi seperti SQL Server pada saat pencadangan untuk mendapatkan pencadangan konsisten pada level aplikasi). Jika Anda menggunakan basis data SQL Server pada cadangan Azure VM, maka Anda dapat mengubah pengaturan untuk mengambil cadangan VSS Copy (untuk menjaga log). Untuk informasi lebih lanjut, lihat artikel ini.
Linux VMs: Untuk mengambil snapshot yang konsisten dengan aplikasi dari VM Linux, gunakan kerangka kerja pre-script dan post-script Linux untuk menulis skrip kustom Anda sendiri guna memastikan konsistensi.
- Azure Backup hanya memanggil skrip pra/pasca yang ditulis oleh Anda.
- Jika skrip pra dan skrip pasca berhasil dijalankan, Azure Backup menandai titik pemulihan sebagai konsisten aplikasi. Namun, ketika Anda menggunakan skrip kustom, Anda pada akhirnya bertanggung jawab atas konsistensi aplikasi.
- Pelajari lebih lanjut tentang cara mengonfigurasi skrip.
Catatan
Proses rekam jepret dimulai dengan memanggil ekstensi cadangan (berbasis agen), menggunakan alat seperti VSS untuk Windows atau membekukan linux untuk memastikan konsistensi data. Ketika konsisten, Kumpulan Titik Pemulihan memantau ekstensi dan memulai pembuatan snapshot. Setelah itu, metadata diperbarui dengan jalur titik pemulihan dan mengonfirmasi detail untuk menyelesaikan proses pencadangan untuk restorasi.
Konsistensi cuplikan
Tabel berikut menjelaskan berbagai jenis konsistensi rekam jepret:
| Snapshot | Rincian | Pemulihan | Pertimbangan |
|---|---|---|---|
| Konsistensi Aplikasi | Ini adalah pengaturan bawaan dalam kebijakan cadangan VM. Cadangan konsisten-aplikasi menangkap konten memori dan operasi I/O yang tertunda. Rekam jepret yang konsisten dengan aplikasi menggunakan penulis VSS (atau skrip pra/posting untuk Linux) untuk memastikan konsistensi data aplikasi sebelum pencadangan terjadi. | Saat Anda memulihkan VM dengan rekam jepret yang konsisten dengan aplikasi, VM akan di-boot. Tidak ada kerusakan atau kehilangan data. Aplikasi dimulai dalam keadaan konsisten. | Windows: Seluruh penulis VSS berhasil Linux: Skrip prakonfigurasi/pascakonfigurasi telah dikonfigurasi dan dijalankan dengan sukses |
| Sistem file konsisten | Ini adalah pengaturan bawaan dalam kebijakan cadangan VM. Pencadangan yang konsisten dengan sistem file memberikan konsistensi dengan mengambil rekam jepret semua file secara bersamaan. |
Ketika Anda memulihkan VM dengan snapshot yang konsisten dengan sistem file, VM akan menyala. Tidak ada kerusakan atau kehilangan data. Aplikasi perlu menerapkan mekanisme perbaikan mereka sendiri untuk memastikan bahwa data yang dipulihkan konsisten. | Windows: Beberapa penulis VSS gagal Linux: Default (jika skrip pra/pasca tidak dikonfigurasi atau gagal) |
| Konsisten terhadap kegagalan | Snapshot konsisten terhadap crash adalah pengaturan opsional dalam kebijakan pemulihan cadangan VM. Azure Backup juga melakukan pencadangan crash-consistent jika VM tidak berjalan selama pencadangan dan ketika pencadangan konsisten aplikasi/berkas gagal. Data yang sudah ada di disk pada saat operasi pencadangan akan diambil dan dicadangkan; data dalam cache host yang dapat dibaca/tulis tidak dicadangkan. |
Dimulai dengan proses boot VM diikuti oleh pemeriksaan disk untuk memperbaiki kesalahan kerusakan. Data di dalam memori atau operasi penulisan yang belum ditransfer ke disk sebelum terjadi kerusakan akan hilang. Aplikasi menerapkan verifikasi data mereka sendiri. Misalnya, sebuah aplikasi basis data dapat menggunakan log transaksinya untuk verifikasi. Jika log transaksi memiliki entri yang tidak ada dalam basis data, perangkat lunak basis data akan membatalkan transaksi hingga data tersebut konsisten. | Ketika Anda memilih pencadangan aplikasi/sistem file dan VM dalam keadaan dimatikan (dihentikan/dialokasikan kembali) dan saat snapshot dicoba ulang. Anda telah memilih cadangan konsisten saat terjadi crash tanpa agen |
Catatan
Jika status penyediaan adalah berhasil, Azure Backup melakukan pencadangan yang konsisten dengan sistem file. Jika status penyediaan adalah tidak tersedia atau gagal, pencadangan yang konsisten setelah crash akan dilakukan. Jika status penyediaan adalah membuat atau menghapus, itu berarti Azure Backup sedang mencoba kembali operasi tersebut.
Pertimbangan Backup dan Pemulihan
| Pertimbangan | Rincian |
|---|---|
| Diska | Backup disk VM dilakukan secara paralel. Misalnya, jika VM memiliki empat disk, layanan Backup mencoba mencadangkan keempat disk secara paralel. Cadangan bersifat inkremental (hanya data yang berubah). |
| Penjadwalan | Untuk mengurangi lalu lintas cadangan, cadangkan VM yang berbeda pada waktu yang berbeda dalam sehari dan pastikan waktu tidak tumpang tindih. Mencadangkan VM secara bersamaan menyebabkan kemacetan lalu lintas. |
| Menyiapkan cadangan | Perlu diingat waktu yang diperlukan untuk menyiapkan cadangan. Waktu persiapan mungkin termasuk menginstal atau memperbarui ekstensi cadangan dan memicu rekam jepret sesuai dengan jadwal pencadangan. |
| Transfer data | Pertimbangkan waktu yang dibutuhkan oleh Azure Backup untuk mengidentifikasi perubahan bertahap sejak cadangan sebelumnya. Dalam cadangan inkremental, Azure Backup menentukan perubahan dengan menghitung checksum dari blok. Jika sebuah blok diubah, itu akan ditandai untuk ditransfer ke brankas. Layanan menganalisis blok yang diidentifikasi untuk mencoba meminimalkan jumlah data yang akan ditransfer lebih lanjut. Setelah evaluasi semua blok yang diubah selesai, Azure Backup mentransfer perubahan tersebut ke brankas. Mungkin ada jeda waktu antara pengambilan snapshot dan penyalinan ke penyimpanan. Pada waktu sibuk, dibutuhkan waktu hingga delapan jam agar rekam jepret ditransfer ke vault. Waktu pencadangan untuk VM akan kurang dari 24 jam untuk pencadangan harian. |
| Pencadangan awal | Waktu total pencadangan untuk pencadangan tambahan adalah kurang dari 24 jam, yang mungkin tidak terjadi untuk pencadangan pertama. Waktu yang dibutuhkan untuk pencadangan awal akan bergantung pada ukuran data dan kapan pencadangan diproses. |
| Pulihkan antrean | Azure Backup memproses pekerjaan pemulihan dari beberapa akun penyimpanan secara bersamaan, dan menempatkan permintaan pemulihan dalam antrean. |
| Pulihkan salinan | Selama proses pemulihan, data disalin dari tempat penyimpanan ke akun penyimpanan. Waktu pemulihan total bergantung pada operasi I/O per detik (IOPS) dan throughput dari akun penyimpanan. Untuk mengurangi waktu penyalinan, pilih akun penyimpanan yang tidak terbebani dengan penulisan dan pembacaan aplikasi lain. |
Catatan
Azure Backup sekarang memungkinkan Anda untuk mencadangkan VM Azure Anda beberapa kali sehari menggunakan kebijakan yang ditingkatkan. Dengan kemampuan ini, Anda juga dapat menentukan durasi di mana pekerjaan pencadangan Anda akan dimulai dan menyelaraskan jadwal pencadangan dengan jam kerja ketika ada pembaruan yang sering pada Mesin Virtual Azure. Pelajari selengkapnya.
Kinerja Pencadangan
Beberapa skenario umum ini dapat mempengaruhi total waktu pencadangan:
- Menambahkan disk baru ke VM Azure yang terlindungi: Jika sebuah VM sedang dalam proses pencadangan bertahap dan sebuah disk baru ditambahkan, waktu pencadangan akan bertambah. Waktu pencadangan total mungkin berlangsung lebih dari 24 jam karena replikasi awal dari disk baru, bersama dengan replikasi delta dari disk yang sudah ada.
- Disk terfragmentasi: Operasi pencadangan lebih cepat saat perubahan disk bersebelahan. Jika perubahan tersebar dan terfragmentasi di seluruh disk, pencadangan akan menjadi lebih lambat.
- Perubahan disk: Jika disk yang dilindungi dan sedang menjalani pencadangan inkremental memiliki perubahan harian lebih dari 200 GB, proses pencadangan dapat memakan waktu lama (lebih dari delapan jam) untuk selesai.
- Versi Cadangan: Versi terbaru dari Cadangan (dikenal sebagai versi Pemulihan Instan) menggunakan proses yang lebih dioptimalkan daripada perbandingan checksum untuk mengidentifikasi perubahan. Namun, jika Anda menggunakan Instant Restore dan telah menghapus snapshot cadangan, pencadangan beralih ke perbandingan checksum. Dalam kasus ini, operasi pencadangan akan melebihi 24 jam (atau gagal).
Pulihkan kinerja
Beberapa skenario umum ini dapat memengaruhi total waktu pemulihan:
- Waktu pemulihan total bergantung pada operasi Input/output per detik (IOPS) dan throughput dari akun penyimpanan.
- Waktu pemulihan total dapat terpengaruh jika akun penyimpanan target dibebani dengan operasi baca dan tulis aplikasi lainnya. Untuk meningkatkan operasi pemulihan, pilih akun penyimpanan yang tidak dipenuhi dengan data aplikasi lainnya.
Praktik terbaik
Saat Anda mengonfigurasi cadangan VM, kami menyarankan untuk mengikuti praktik berikut:
- Modifikasi waktu jadwal default yang diatur dalam kebijakan. Misalnya, jika waktu default dalam kebijakan adalah pukul 00:00, tingkatkan waktu beberapa menit sehingga sumber daya digunakan secara optimal.
- Jika Anda memulihkan VM dari satu vault, kami sangat merekomendasikan agar Anda menggunakan akun penyimpanan general-purpose v2 yang berbeda untuk memastikan bahwa akun penyimpanan target tidak mengalami pembatasan. Sebagai contoh, setiap VM harus memiliki akun penyimpanan yang berbeda. Sebagai contoh, jika 10 VM dipulihkan, gunakan 10 akun penyimpanan yang berbeda.
- Untuk pencadangan VM yang menggunakan penyimpanan premium dengan Pemulihan Instan, kami merekomendasikan mengalokasikan 50% ruang kosong dari total ruang penyimpanan yang dialokasikan, yang diperlukan hanya untuk pencadangan pertama. Ruang kosong 50% bukanlah persyaratan untuk pencadangan setelah pencadangan pertama selesai.
- Batas jumlah cakram per akun penyimpanan relatif terhadap seberapa besar cakram tersebut diakses oleh aplikasi yang berjalan pada VM (Virtual Machine) berbasis infrastruktur sebagai layanan (IaaS). Sebagai praktik umum, jika ada 5 hingga 10 disk atau lebih pada satu akun penyimpanan, imbangi beban dengan memindahkan beberapa disk ke akun penyimpanan terpisah.
- Untuk memulihkan VM dengan disk terkelola menggunakan PowerShell, berikan parameter tambahan TargetResourceGroupName untuk menentukan grup sumber daya tempat disk terkelola akan dipulihkan, Pelajari lebih lanjut di sini.
Biaya pencadangan
Azure VM yang dicadangkan dengan Azure Backup tunduk pada harga Azure Backup.
Penagihan tidak dimulai sampai pencadangan berhasil pertama selesai. Pada titik ini, penagihan untuk penyimpanan dan VM yang terlindungi dimulai. Penagihan tetap berlanjut selama ada data cadangan untuk VM yang disimpan di lemari penyimpanan. Jika Anda menghentikan perlindungan untuk VM, tetapi data cadangan untuk VM masih ada di brankas, penagihan akan tetap berlanjut.
Penagihan untuk VM tertentu berhenti hanya jika perlindungan dihentikan dan semua data cadangan dihapus. Ketika perlindungan berhenti dan tidak ada pekerjaan pencadangan yang aktif, ukuran cadangan VM terakhir yang berhasil menjadi ukuran instance terlindungi yang digunakan untuk tagihan bulanan.
Jika Anda memilih pencadangan konsisten aplikasi berbasis agen atau konsisten sistem file, perhitungan ukuran instance yang dilindungi didasarkan pada ukuran aktual dari VM. Ukuran VM adalah jumlah dari semua data dalam VM, tidak termasuk penyimpanan sementara. Harga didasarkan pada data aktual yang disimpan pada disk data, bukan pada ukuran maksimum yang didukung untuk setiap disk data yang dilampirkan ke VM.
Catatan
Untuk pencadangan tanpa agen yang konsisten dengan crash, Anda saat ini dikenakan biaya untuk 0,5 instance terlindungi (PI) per VM selama pratinjau.
Demikian pula, tagihan penyimpanan cadangan didasarkan pada jumlah data yang disimpan di Azure Backup, yang merupakan jumlah dari data sebenarnya di setiap titik pemulihan.
Misalnya, ambil mesin virtual berukuran A2-Standard yang memiliki dua disk data tambahan dengan ukuran maksimum masing-masing 32 TB. Tabel berikut menunjukkan data sebenarnya yang disimpan pada masing-masing disk ini.
| Diska | Ukuran maksimum | Data yang ada |
|---|---|---|
| disk sistem operasi | 32 Terabyte | 17 GB |
| Disk lokal/sementara | 135 GB | 5 GB (tidak disertakan untuk pencadangan) |
| Disk data 1 | 32 Terabyte | 30 GB |
| Disk data 2 | 32 Terabyte | 0 GB |
Ukuran aktual VM dalam hal ini adalah 17 GB + 30 GB + 0 GB = 47 GB. Ukuran contoh terlindungi (47 GB) ini menjadi dasar untuk tagihan bulanan. Seiring bertambahnya jumlah data di VM, ukuran instance yang dilindungi yang digunakan untuk penagihan akan berubah sesuai.