Mencadangkan file dan aplikasi di Azure Stack Hub

Pertimbangkan situasi di mana Azure Stack Hub menghosting komputer virtual (VM) yang menjalankan beban kerja pengguna. Ada kebutuhan untuk mencadangkan dan memulihkan file dan aplikasi beban kerja. Artikel arsitektur referensi ini menjelaskan pendekatan yang memberikan solusi yang dioptimalkan untuk aktivitas pencadangan dan pemulihan.

Sistem

Unduh file Visio arsitektur ini.

Alur kerja

Komponen cloud mencakup layanan berikut:

• Langganan Azure yang menghosting semua sumber daya cloud yang disertakan dalam solusi ini.
• Penyewa Microsoft Entra yang terkait dengan langganan Azure. Ini menyediakan autentikasi perwakilan keamanan Microsoft Entra untuk mengotorisasi akses ke sumber daya Azure.
• Vault Azure Recovery Services di wilayah Azure yang paling dekat dengan pusat data lokal yang menghosting penyebaran Azure Stack Hub.

Bergantung pada kriteria yang disajikan dalam artikel ini, komponen cloud juga dapat menyertakan layanan berikut:

• Sirkuit Azure ExpressRoute yang menghubungkan pusat data lokal dan wilayah Azure yang menghosting vault Azure Recovery Services. Sirkuit dikonfigurasi untuk memiliki peering Microsoft untuk mengakomodasi ukuran cadangan yang lebih besar.

• Layanan Impor/Ekspor Azure, untuk mengaktifkan pencadangan offline MABS ke Azure.

  Catatan

  Mulai 08/20, cadangan offline MABS ke Azure yang menggunakan Azure Data Box sedang dalam pratinjau.

Bergantung pada penggunaan layanan Azure Import/Export untuk pencadangan offline MABS ke Azure, solusi ini mungkin juga memiliki akun Azure Storage di wilayah Azure yang sama dengan brankas Recovery Services.

Komponen lokal mencakup layanan berikut:

• Sistem terintegrasi Azure Stack Hub dalam model penyebaran terhubung yang menjalankan pembaruan saat ini (2002 per Agustus 2020), dan terletak di dalam pusat data lokal pelanggan.

• VM Windows Server 2016 atau Windows Server 2019 yang dihosting oleh sistem terintegrasi Azure Stack Hub dan yang menjalankan Rilis Pembaruan MABS v3 (UR) 1.

• VM Azure Stack Hub dengan agen perlindungan MABS, yang mengelola pencadangan dan pemulihan dari VM MABS Azure Stack Hub. Agen perlindungan MABS melacak perubahan beban kerja yang dilindungi, dan mentransfer perubahan ke penyimpanan data MABS. Agen perlindungan juga mengidentifikasi data di komputer lokalnya yang dapat dilindungi dan berperan dalam proses pemulihan.

• Agen Microsoft Azure Recovery Services (MARS) yang diinstal di server yang menjalankan MABS. Agen mengintegrasikan vault MABS dan Azure Recovery Services.

  Catatan

  Agen MARS juga disebut sebagai agen Azure Backup.

Komponen

• Azure Stack Hub
• Microsoft Entra ID
• Akun penyimpanan Azure
• Azure ExpressRoute

Alternatif

Solusi yang direkomendasikan yang dijelaskan dalam artikel ini bukan satu-satunya cara untuk menyediakan fungsionalitas pencadangan dan pemulihan ke beban kerja pengguna yang berjalan di Azure Stack Hub. Pelanggan memiliki opsi lain, termasuk:

• Pencadangan dan pemulihan lokal dengan menggunakan fitur Windows Server Backup yang disertakan dalam sistem operasi Windows Server. Pengguna kemudian dapat menyalin cadangan lokal ke penyimpanan jangka panjang. Pendekatan ini mendukung pencadangan konsisten aplikasi dengan mengandalkan penyedia VSS Windows, tetapi meningkatkan penggunaan ruang disk lokal dan biaya pemeliharaan cadangan.
• Pencadangan dan pemulihan dengan menggunakan Azure Backup dengan agen MARS yang diinstal secara lokal. Pendekatan ini meminimalkan penggunaan ruang disk lokal dan mengotomatiskan proses pengunggahan cadangan ke penyimpanan berbasis cloud. Namun, pendekatan ini tidak mendukung pencadangan konsisten aplikasi.
• Cadangkan dan pulihkan dengan menggunakan solusi cadangan yang diinstal di pusat data yang sama tetapi di luar Azure Stack Hub. Pendekatan ini memudahkan skenario yang melibatkan model penyebaran terputus Azure Stack Hub.
• Pencadangan dan pemulihan tingkat Azure Stack Hub dengan menggunakan snapshot disk. Pendekatan ini mengharuskan VM yang sedang dicadangkan dihentikan, yang biasanya bukan opsi yang layak untuk beban kerja yang penting bagi bisnis, tetapi dapat diterima dalam beberapa skenario.

Detail skenario

Pencadangan dan pemulihan adalah komponen penting dari setiap kelangsungan bisnis yang komprehensif dan strategi pemulihan bencana. Merancang dan menerapkan pendekatan pencadangan yang konsisten dan andal di lingkungan hibrid sangat menantang, tetapi dapat sangat disederhanakan dengan mengintegrasikan dengan layanan Microsoft Azure. Ini tidak hanya berlaku untuk beban kerja yang berjalan pada infrastruktur lokal tradisional, tetapi juga untuk yang dihosting oleh penyedia cloud publik dan privat pihak ketiga. Namun, manfaat integrasi dengan layanan Azure terbukti ketika lingkungan hibrid menggabungkan penawaran portofolio Azure Stack, termasuk Azure Stack Hub.

Meskipun salah satu kekuatan utama Azure Stack Hub adalah mendukung model platform-as-a-service (PaaS), ini juga membantu pelanggan memodernisasi beban kerja infrastruktur sebagai layanan (IaaS) yang ada. Beban kerja tersebut dapat mencakup berbagi file, database Microsoft SQL Server, farm Microsoft SharePoint, dan kluster Microsoft Server Exchange. Memigrasikannya ke VM yang berjalan pada kluster hiperkonvergensi dan sangat tangguh yang memiliki model administratif dan pemrograman yang konsisten dengan Microsoft Azure menghasilkan overhead manajemen dan pemeliharaan yang diminimalkan.

Untuk menerapkan pencadangan file dan aplikasi yang berjalan di VM Azure Stack Hub, Microsoft merekomendasikan pendekatan hibrid yang bergantung pada kombinasi komponen cloud dan lokal untuk memberikan solusi pencadangan yang dapat diskalakan, berkinerja, tangguh, aman, mudah dikelola, dan hemat biaya. Komponen utama solusi ini adalah Microsoft Azure Backup Server (MABS) v3, yang merupakan bagian dari penawaran Azure Backup. MABS mengandalkan infrastruktur Azure Stack Hub untuk sumber daya penyimpanan komputasi, jaringan, dan jangka pendek, dan menggunakan penyimpanan berbasis Azure untuk berfungsi sebagai penyimpanan cadangan jangka panjang. Pendekatan ini meminimalkan atau menghilangkan kebutuhan untuk mempertahankan media cadangan fisik seperti kaset.

Fungsi inti

Solusi yang diusulkan mendukung fungsionalitas berikut pada VM Azure Stack Hub yang menjalankan Windows Server 2019, 2016, 2012 R2, 2012, 2008 R2 SP1 (64-bit dengan Windows Management Framework 4.0), 2008 SP2 (64-bit dengan Windows Management Framework 4.0), dan Windows 10 (64-bit):

• Pencadangan dan pemulihan volume, Resilient File System (ReFS) dan New Technology File System (NTFS), berbagi, folder, file, dan status sistem.

• Pencadangan dan pemulihan SQL Server 2019, 2017, 2016 (dengan paket layanan (SPs) yang diperlukan, dan instans 2014 (dengan SP yang diperlukan) dan database mereka.

• Pencadangan dan pemulihan server dan database Exchange Server 2019 dan Exchange Server 2016, termasuk server dan database mandiri dalam grup ketersediaan database (DAG).

• Pemulihan kotak surat individual dan database kotak surat dalam DAG.

• Pencadangan dan pemulihan farm SharePoint 2019 dan SharePoint 2016 (dengan SP terbaru) dan konten server web front-end.

• Pemulihan database SharePoint 2019 dan SharePoint 2016, aplikasi web, file, item daftar, dan komponen pencarian.

  Catatan

  Untuk menyebarkan sistem operasi klien Windows 10 di Azure Stack Hub, Anda harus memiliki lisensi Windows per pengguna atau telah membelinya melalui Hoster Multi-Penyewa yang Memenuhi Syarat (QMTH).

MABS mengimplementasikan skema cadangan disk-ke-disk-to-cloud (D2D2C), dengan cadangan utama disimpan secara lokal di server yang menghosting penginstalan MABS. Cadangan lokal kemudian disalin ke vault Azure Site Recovery. Disk lokal berfungsi sebagai penyimpanan jangka pendek, sedangkan brankas menyediakan penyimpanan jangka panjang.

Proses pencadangan terdiri dari empat tahap berikut:

1. Anda menginstal agen perlindungan MABS di komputer yang ingin Anda lindungi, dan menambahkannya ke grup perlindungan.
2. Anda menyiapkan perlindungan untuk komputer atau aplikasinya, termasuk pencadangan ke disk lokal MABS untuk penyimpanan jangka pendek dan ke Azure untuk penyimpanan jangka panjang. Sebagai bagian dari penyiapan, tentukan jadwal pencadangan untuk kedua jenis cadangan.
3. Beban kerja yang dilindungi mencadangkan ke disk MABS lokal sesuai dengan jadwal yang Anda tentukan.
4. Cadangan lokal yang disimpan di disk MABS dicadangkan ke vault Azure Recovery Services oleh agen MARS yang berjalan di server MABS.

Prasyarat

Menerapkan solusi yang direkomendasikan tergantung pada memenuhi prasyarat berikut:

• Akses ke langganan Azure, dengan izin yang cukup untuk menyediakan vault Azure Recovery Services di wilayah Azure yang paling dekat dengan pusat data lokal yang menghosting penyebaran Azure Stack Hub.

• Domain Active Directory Domain Services (AD DS) yang dapat diakses dari VM Azure Stack Hub yang akan menghosting instans MABS.

• VM yang dihosting Azure Stack Hub yang akan menjalankan instans MABS, memenuhi prasyarat yang tercantum di Menginstal Azure Backup Server di Azure Stack dan dengan konektivitas keluar ke URL yang tercantum dalam dukungan jaringan DPM/MABS.

  Catatan

  Ruang disk tambahan dan pertimbangan performa untuk MABS dijelaskan secara lebih rinci nanti di artikel ini.

  Catatan

  Untuk memvalidasi apakah VM yang menghosting MABS memiliki konektivitas ke layanan Azure Backup, Anda dapat menggunakan cmdlet Get-DPMCloudConnection (termasuk dalam modul Azure Backup Server PowerShell).

  Catatan

  MABS juga membutuhkan instans lokal SQL Server. Untuk detail mengenai persyaratan SQL Server, lihat Menginstal dan meningkatkan Azure Backup Server.

Jenis data

Dari perspektif MABS, ada dua tipe data yang perlu dipertimbangkan:

• Data file adalah data yang biasanya berada di server file (seperti file Microsoft Office, file teks, atau file media), dan yang perlu dilindungi sebagai file datar.
• Data aplikasi adalah data yang ada di server aplikasi (seperti grup penyimpanan Exchange, database SQL Server, atau farm SharePoint) dan yang mengharuskan MABS untuk mengetahui persyaratan aplikasi yang sesuai.

Jenis Cadangan

Baik Anda melindungi data file atau data aplikasi, perlindungan dimulai dengan membuat replika sumber data di penyimpanan lokal instans MABS. Replika disinkronkan atau diperbarui secara berkala sesuai dengan pengaturan yang Anda konfigurasi. Metode yang digunakan MABS untuk menyinkronkan replika tergantung pada jenis data yang dilindungi. Jika replika dianggap tidak konsisten, MABS melakukan pemeriksaan konsistensi, yang merupakan verifikasi replika blok demi blok terhadap sumber data.

Untuk volume atau berbagi file di server, setelah pencadangan lengkap awal, agen perlindungan MABS menggunakan filter volume dan mengubah jurnal untuk menentukan file yang telah berubah. Kemudian melakukan prosedur checksum agar file tersebut hanya menyinkronkan blok yang diubah. Selama sinkronisasi, perubahan ini ditransfer ke MABS dan kemudian diterapkan ke replika, sehingga menyinkronkan replika dengan sumber data.

Jika replika menjadi tidak konsisten dengan sumber datanya, MABS menghasilkan peringatan yang menentukan komputer dan sumber data yang terpengaruh. Untuk mengatasi masalah ini, Anda dapat memperbaiki replika dengan memulai sinkronisasi dengan pemeriksaan konsistensi pada replika. Selama pemeriksaan konsistensi, MABS melakukan verifikasi blok demi blok dan memperbaiki replika untuk mengembalikannya ke konsistensi dengan sumber data. Anda dapat menjadwalkan pemeriksaan konsistensi harian untuk grup perlindungan atau memulai pemeriksaan konsistensi secara manual.

Pada interval reguler yang dapat Anda konfigurasikan, MABS membuat titik pemulihan untuk sumber data yang dilindungi. Titik pemulihan adalah versi data yang dapat dipulihkan.

Untuk data aplikasi, setelah replika dibuat oleh MABS, perubahan pada blok volume milik file aplikasi dilacak oleh filter volume. Bagaimana perubahan ditransfer ke server MABS bergantung pada aplikasi dan jenis sinkronisasi. Operasi yang diberi label sinkronisasi di MABS Administrator Console dianalogikan dengan cadangan bertahap, dan menciptakan refleksi data aplikasi yang konsisten dan akurat secara transaksional saat dikombinasikan dengan replika.

Selama jenis sinkronisasi yang diberi label express full backup di MABS Administrator Console, rekam jepret Volume Shadow Copy Service (VSS) lengkap dibuat, tetapi hanya blok yang diubah yang ditransfer ke server MABS.

Setiap cadangan penuh ekspres menciptakan titik pemulihan untuk data aplikasi. Jika aplikasi mendukung pencadangan bertahap, setiap sinkronisasi juga membuat titik pemulihan. Proses sinkronisasi bergantung pada aplikasi:

• Untuk data Exchange, sinkronisasi mentransfer rekam jepret VSS bertambah bertahap dengan menggunakan penulis Exchange VSS. Titik pemulihan dibuat untuk setiap sinkronisasi dan untuk setiap pencadangan penuh ekspres.
• Database SQL Server yang dikirim melalui log, yang dalam mode baca-saja, atau yang menggunakan model pemulihan sederhana, tidak mendukung pencadangan bertambah bertahap. Titik pemulihan hanya dibuat untuk setiap pencadangan penuh ekspres. Untuk semua database SQL Server lainnya, sinkronisasi mentransfer cadangan log transaksi, dengan titik pemulihan yang dibuat untuk setiap sinkronisasi bertambah bertahap dan mengekspresikan pencadangan penuh. Log transaksi adalah catatan seri dari semua transaksi yang telah dilakukan terhadap database sejak log transaksi terakhir dicadangkan.
• Server SharePoint tidak mendukung pencadangan tambahan. Titik pemulihan hanya dibuat untuk setiap pencadangan penuh ekspres.

Sinkronisasi inkremental membutuhkan lebih sedikit waktu daripada yang diperlukan untuk melakukan pencadangan penuh ekspres. Namun, waktu yang diperlukan untuk memulihkan data meningkat saat jumlah sinkronisasi meningkat. Ini karena MABS harus memulihkan cadangan penuh terakhir dan kemudian memulihkan dan menerapkan semua sinkronisasi bertambah bertahap hingga titik waktu yang ditentukan untuk pemulihan.

Untuk mengaktifkan waktu pemulihan yang lebih cepat, MABS secara teratur melakukan pencadangan penuh ekspres, yang memperbarui replika untuk menyertakan blok yang diubah. Selama pencadangan penuh ekspres, MABS mengambil rekam jepret replika sebelum memperbarui replika dengan menggunakan blok yang diubah. Untuk mengaktifkan RPO yang lebih sering dan mengurangi jendela kehilangan data, MABS juga melakukan sinkronisasi inkremental dalam waktu antara dua pencadangan penuh ekspres.

Seperti halnya perlindungan data file, jika replika menjadi tidak konsisten dengan sumber datanya, MABS menghasilkan peringatan yang menentukan server dan sumber data yang terpengaruh. Untuk mengatasi inkonsistensi, Anda dapat memperbaiki replika dengan memulai sinkronisasi dengan pemeriksaan konsistensi pada replika. Selama pemeriksaan konsistensi, MABS melakukan verifikasi blok demi blok replika dan memperbaikinya agar kembali konsistensi dengan sumber data. Anda dapat menjadwalkan pemeriksaan konsistensi harian untuk grup perlindungan atau memulai pemeriksaan konsistensi secara manual.

Kebijakan perlindungan

Komputer atau beban kerjanya menjadi terlindungi ketika Anda menginstal perangkat lunak agen perlindungan MABS di komputer dan menambahkan data komputer atau beban kerjanya ke grup perlindungan. Grup perlindungan digunakan untuk mengonfigurasi dan mengelola perlindungan sumber data di komputer. Grup perlindungan adalah kumpulan sumber data yang memiliki konfigurasi perlindungan yang sama. Konfigurasi perlindungan adalah kumpulan pengaturan yang umum untuk grup perlindungan, seperti nama grup perlindungan, kebijakan perlindungan, alokasi penyimpanan, dan metode pembuatan replika.

MABS menyimpan replika terpisah setiap anggota grup perlindungan dalam kumpulan penyimpanan. Anggota grup perlindungan dapat berisi sumber data seperti:

• Volume, berbagi, atau folder di server file atau kluster server.
• Grup penyimpanan dari server Exchange atau kluster server.
• Database instans SQL Server atau kluster server.

Untuk setiap grup perlindungan, Anda mengonfigurasi kebijakan perlindungan yang didasarkan pada tujuan pemulihan Anda untuk grup perlindungan tersebut. Tujuan pemulihan mewakili persyaratan perlindungan data yang sesuai dengan RTO dan RPO organisasi Anda. Dalam MABS, parameter tersebut didefinisikan berdasarkan kombinasi parameter berikut:

• Periode retensi jangka pendek. Ini menentukan durasi retensi data cadangan di penyimpanan MABS lokal.

• Sinkronisasi dan frekuensi titik pemulihan. Ini sesuai langsung dengan toleransi kehilangan data, yang pada gilirannya mencerminkan RPO organisasi Anda. Ini juga menentukan frekuensi MABS menyinkronkan replika lokalnya dengan sumber data yang dilindungi dengan mengumpulkan perubahan data. Anda dapat mengatur frekuensi sinkronisasi ke interval apa pun antara 15 menit dan 24 jam. Anda juga dapat memilih untuk menyinkronkan tepat sebelum titik pemulihan dibuat, bukan pada jadwal waktu yang ditentukan.

• Jadwal titik pemulihan jangka pendek. Ini menetapkan banyaknya titik pemulihan yang akan dibuat di penyimpanan lokal untuk grup perlindungan. Untuk perlindungan file, pilih hari dan waktu yang diinginkan untuk mendapatkan titik pemulihan. Untuk perlindungan data aplikasi yang mendukung pencadangan bertambah bertahap, frekuensi sinkronisasi menentukan jadwal titik pemulihan.

• Jadwal pencadangan penuh ekspres. Ini adalah jadwal titik pemulihan untuk perlindungan data aplikasi yang tidak mendukung pencadangan bertambah bertahap dan mendukung pencadangan penuh ekspres.

• Jadwal pencadangan online. Ini menentukan frekuensi pembuatan salinan cadangan lokal di vault Azure Recovery Services yang terkait dengan instans MABS lokal. Anda dapat menjadwalkan setiap hari, mingguan, bulanan, atau tahunan, dengan frekuensi maksimum yang diizinkan dari dua cadangan per hari. MABS secara otomatis membuat titik pemulihan untuk pencadangan online dengan menggunakan replika lokal terbaru, tanpa mentransfer data baru dari sumber data yang dilindungi.

  Catatan

  Vault Layanan Pemulihan mendukung sebanyak 9.999 titik pemulihan.

• Kebijakan penyimpanan online. Ini menentukan periode waktu di mana pencadangan harian, mingguan, bulanan, dan tahunan dipertahankan di vault Azure Site Recovery yang terkait dengan instans MABS lokal.

  Catatan

  Untuk melindungi konten sumber data terbaru secara online, buat titik pemulihan baru di disk lokal sebelum membuat titik pemulihan online.

  Catatan

  Secara default, vault Azure Recovery Services adalah geo-redundan, yang berarti bahwa cadangan apa pun yang disalin ke penyimpanannya secara otomatis direplikasi ke wilayah Azure yang merupakan bagian dari pasangan wilayah yang telah ditentukan sebelumnya. Anda dapat mengubah pengaturan replikasi menjadi redundan secara lokal jika itu cukup untuk kebutuhan ketahanan Anda dan jika Anda perlu meminimalkan biaya penyimpanan. Namun, Anda harus mempertimbangkan untuk mempertahankan pengaturan default. Opsi ini tidak dapat diubah jika vault berisi item yang dilindungi.

  Catatan

  Untuk daftar pasangan wilayah Azure, lihat Kelangsungan bisnis dan pemulihan bencana (BCDR): Wilayah Berpasangan Azure.

Menguji pemulihan

Selain strategi pencadangan yang dirancang dan diimplementasikan secara optimal, sama pentingnya untuk menentukan, mendokumentasikan, dan menguji proses pemulihan untuk setiap jenis beban kerja yang dilindungi. Meskipun MABS menyediakan pemeriksaan konsistensi bawaan yang secara otomatis memverifikasi integritas cadangan data, pengujian pemulihan harus menjadi bagian dari prosedur operasi rutin. Pengujian memvalidasi pemulihan dengan memeriksa status beban kerja yang dipulihkan. Hasil pengujian harus tersedia untuk pemilik beban kerja.

Secara umum, pengujian pemulihan cenderung menantang karena membutuhkan lingkungan yang sangat mirip dengan yang menghosting beban kerja yang dilindungi. Azure Stack Hub, dengan DevOps dan infrastruktur bawaannya sebagai kemampuan kode, sangat menyederhanakan mengatasi tantangan ini.

Peran dan tanggung jawab

Merencanakan dan menerapkan pencadangan dan pemulihan beban kerja berbasis Azure Stack Hub biasanya melibatkan interaksi di antara banyak pemangku kepentingan:

• Operator Azure Stack Hub. Operator Azure Stack Hub mengelola infrastruktur Azure Stack Hub, dengan memastikan bahwa sumber daya komputasi, penyimpanan, dan jaringan cukup untuk menerapkan solusi pencadangan dan pemulihan yang komprehensif, dan menyediakan sumber daya ini untuk penyewa. Operator tersebut juga berkolaborasi dengan pemilik aplikasi dan data untuk membantu menentukan pendekatan optimal guna menyebarkan beban kerjanya ke Azure Stack Hub.
• Administrator Azure. Administrator Azure mengelola sumber daya Azure yang diperlukan untuk menerapkan solusi pencadangan hibrid.
• Administrator Microsoft Entra. Administrator Microsoft Entra mengelola sumber daya Microsoft Entra, termasuk objek pengguna dan grup yang digunakan untuk menyediakan, mengonfigurasi, dan mengelola sumber daya Azure.
• Staf IT penyewa Azure Stack Hub. Pemangku kepentingan ini merancang, mengimplementasikan, dan mengelola MABS, termasuk pencadangan dan pemulihan MABS.
• Pengguna Azure Stack Hub. Pengguna ini menyediakan persyaratan RPO dan RTO dan mengajukan permintaan untuk mencadangkan dan memulihkan data dan aplikasi.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keandalan.

Azure Stack Hub membantu meningkatkan ketersediaan beban kerja karena ketahanan yang melekat pada infrastrukturnya. Anda dapat lebih meningkatkan ketersediaan dengan merancang dan menerapkan solusi yang memperluas cakupan perlindungan beban kerja. Ini adalah nilai tambah yang disediakan MABS. Dalam konteks MABS yang berjalan di Azure Stack Hub, ada dua aspek ketersediaan yang perlu dieksplorasi secara lebih rinci:

• Ketersediaan MABS dan penyimpanan datanya
• Ketersediaan kemampuan pemulihan point-in-time beban kerja yang dilindungi MABS

Anda perlu mempertimbangkan keduanya saat mengembangkan strategi pencadangan yang didorong oleh tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). RTO dan RPO mewakili persyaratan kelangsungan yang ditetapkan oleh fungsi bisnis dalam organisasi. RPO menunjuk periode waktu yang mewakili kehilangan data maksimum yang dapat diterima karena insiden yang membuat data tidak tersedia untuk satu waktu. RTO menunjuk durasi waktu maksimum yang dapat diterima untuk mengembalikan akses ke fungsi bisnis setelah insiden yang membuat fungsi tidak tersedia.

Ketersediaan MABS dan penyimpanan datanya kontingen pada ketersediaan VM yang menghosting penginstalan MABS dan penyimpanan lokal dan berbasis cloudnya. Azure Stack Hub VM sangat tersedia berdasarkan desain. Jika ada kegagalan MABS, Anda memiliki kemampuan untuk memulihkan item yang dilindungi Azure Backup dari VM Azure Stack Hub lainnya yang menghosting MABS. Namun, perhatikan bahwa untuk server yang menghosting MABS untuk memulihkan cadangan yang dilakukan dengan menggunakan MABS yang berjalan di server lain, kedua server harus terdaftar dengan vault Azure Site Recovery yang sama.

Kemampuan pemulihan titik waktu dari beban kerja yang dilindungi MABS sangat bergantung pada jenis data, cadangannya, dan kebijakan perlindungannya. Untuk memahami dependensi ini, konsep ini harus dijelaskan secara lebih rinci.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Mengelola data dan aplikasi pengguna dalam skenario hibrid menjamin pertimbangan keamanan tambahan. Pertimbangan ini dapat dikelompokkan dalam kategori berikut:

• Enkripsi cadangan
• Perlindungan brankas Azure Recovery Services

MABS dan Azure Backup memberlakukan enkripsi cadangan saat tidak aktif dan saat transit:

• Enkripsi saat tidak aktif. Selama penginstalan MABS, pengguna menyediakan frasa sandi. Frase sandi ini kemudian digunakan untuk mengenkripsi semua cadangan sebelum diunggah ke vault Azure Recovery Services. Dekripsi terjadi hanya setelah cadangan diunduh dari brankas. Frase sandi hanya tersedia untuk pengguna yang membuatnya dan ke agen MARS yang diinstal secara lokal. Sangat penting untuk memastikan bahwa frase sandi disimpan di lokasi yang aman, karena berfungsi sebagai mekanisme otorisasi saat melakukan pemulihan berbasis cloud di server MABS selain tempat pencadangan berlangsung.
• Enkripsi saat transit. MABS v3 mengandalkan protokol Keamanan Lapisan Transportasi (TLS) versi 1.2 untuk melindungi koneksinya ke Azure.

Vault Azure Recovery Services menawarkan mekanisme yang lebih melindungi cadangan online, termasuk:

• Kontrol akses berbasis peran Azure (Azure RBAC). Azure RBAC memungkinkan pendelegasian dan pemisahan tanggung jawab sesuai dengan prinsip hak istimewa yang paling sedikit. Ada tiga peran bawaan terkait Azure Backup yang membatasi akses ke operasi manajemen cadangan:
  • Kontributor Cadangan. Menyediakan akses untuk membuat dan mengelola cadangan, kecuali untuk menghapus vault Layanan Pemulihan dan mendelegasikan akses ke orang lain.
  • Operator Cadangan. Menyediakan akses yang setara dengan Kontributor Cadangan, kecuali untuk menghapus cadangan dan mengelola kebijakan pencadangan.
  • Pembaca Cadangan. Menyediakan akses untuk memantau operasi pengelolaan cadangan.
• Kunci Sumber Daya Azure. Anda dapat membuat dan menetapkan kunci baca-saja dan menghapus ke vault Azure Site Recovery untuk mengurangi risiko vault diubah atau dihapus secara tidak sengaja atau berbahaya.
• Penghapusan sementara. Penghapusan sementara membantu melindungi brankas dan data cadangan dari penghapusan yang tidak disengaja atau berbahaya. Dengan penghapusan sementara, jika pengguna menghapus item cadangan, data yang sesuai disimpan selama 14 hari, memungkinkan pemulihannya tanpa kehilangan data selama periode tersebut. Retensi data cadangan 14 hari dalam status penghapusan sementara tidak dikenakan biaya apa pun. Penghapusan sementara diaktifkan secara default.
• Perlindungan operasi sensitif keamanan. Vault Azure Recovery Services secara otomatis menerapkan lapisan autentikasi lain setiap kali operasi sensitif terhadap keamanan, seperti mengubah frasa sandi, dicoba. Validasi tambahan ini membantu memastikan bahwa hanya pengguna yang berwenang yang melakukan operasi ini.
• Pemantauan dan peringatan aktivitas mencurigakan. Azure Backup menyediakan pemantauan bawaan dan pemberitahuan peristiwa sensitif keamanan yang terkait dengan operasi Azure Backup. Laporan cadangan memfasilitasi pelacakan penggunaan, audit cadangan dan pemulihan, dan mengidentifikasi tren pencadangan utama.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Saat mempertimbangkan biaya solusi cadangan yang dijelaskan dalam artikel ini, ingatlah untuk memperhitungkan komponen lokal dan berbasis cloud. Harga komponen lokal ditentukan oleh model harga Azure Stack Hub. Seperti halnya Azure, Azure Stack Hub menawarkan pengaturan bayar sesuai penggunaan yang tersedia melalui perjanjian perusahaan dan program Penyedia Solusi Cloud. Pengaturan ini mencakup harga bulanan per VM Windows Server. Jika Anda dapat menggunakan lisensi Windows Server yang ada, Anda dapat secara signifikan mengurangi biaya tersebut ke harga VM dasar. MABS mengandalkan SQL Server sebagai penyimpanan datanya, tetapi tidak ada biaya lisensi yang terkait dengan menjalankan instans SQL Server tersebut jika hanya digunakan untuk MABS.

Ada biaya terkait Azure untuk penggunaan sumber daya berikut:

• Azure Backup. Harga untuk Azure Backup sebagian besar ditentukan oleh jumlah beban kerja yang dilindungi dan ukuran cadangan data (sebelum kompresi dan enkripsi) untuk masing-masing beban kerja. Biaya juga dipengaruhi oleh pilihan antara penyimpanan redundan lokal (LRS) dan penyimpanan geo-redundan (GRS) untuk replikasi konten brankas Azure Recovery Services. Untuk detailnya, lihat Harga Azure Backup.
• Azure ExpressRoute. Harga Azure ExpressRoute didasarkan pada salah satu dari dua model:
  • Data tidak terbatas. Ini adalah biaya bulanan dengan semua transfer data masuk dan keluar yang disertakan.
  • Paket data terukur. Ini adalah biaya bulanan dengan semua transfer data masuk gratis dan transfer data keluar yang dikenakan biaya per gigabyte.
• Azure Import/Export. Biaya untuk Azure Import/Export mencakup biaya per perangkat tetap untuk penanganan perangkat.
• Azure Storage. Saat Anda menggunakan Azure Import/Export, tarif Azure Storage standar dan biaya transaksi berlaku.

Tanpa ExpressRoute, Anda mungkin harus memperhitungkan peningkatan penggunaan bandwidth koneksi internet Anda untuk pencadangan dan pemulihan. Biaya akan bervariasi tergantung pada banyak faktor, termasuk area geografis, penggunaan bandwidth saat ini, dan penyedia layanan internet.

Keunggulan operasional

Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.

Keterkelolaan

Salah satu faktor utama yang memengaruhi yang memengaruhi strategi pencadangan dan pemulihan Anda adalah konfigurasi grup perlindungan dan kriteria yang Anda gunakan untuk memutuskan beban kerja yang dilindungi mana yang harus termasuk dalam grup yang dilindungi yang sama. Seperti yang dijelaskan sebelumnya dalam artikel ini, grup perlindungan adalah kumpulan sumber data seperti volume, berbagi, atau penyimpanan data aplikasi yang memiliki pengaturan pencadangan dan pemulihan umum. Saat menentukan grup perlindungan, Anda perlu menentukan:

• Sumber data, seperti server dan beban kerja yang ingin Anda lindungi.
• Penyimpanan cadangan, termasuk pengaturan perlindungan jangka pendek dan jangka panjang.
• Titik pemulihan, yang merupakan titik waktu asal data yang dicadangkan dapat dipulihkan.
• Ruang disk yang dialokasikan, yang merupakan jumlah ruang disk dari kumpulan penyimpanan yang dialokasikan untuk cadangan.
• Replikasi awal, yang merupakan metode yang digunakan untuk pencadangan awal sumber data. Metode ini dapat berupa transfer online (melalui jaringan) atau transfer offline (seperti melalui layanan Impor/Ekspor Azure).
• Metode pemeriksaan konsistensi, yang merupakan metode verifikasi integritas cadangan data.

Metode berikut sering digunakan untuk memutuskan beban kerja yang dilindungi mana yang harus termasuk dalam grup yang dilindungi yang sama:

• Dengan komputer. Metode ini menggabungkan semua sumber data untuk komputer ke dalam grup perlindungan yang sama.
• Dengan beban kerja. Metode ini memisahkan file dan setiap jenis data aplikasi ke dalam grup perlindungan yang berbeda. Namun, memulihkan server yang meng-host beberapa beban kerja mungkin memerlukan beberapa pemulihan dari grup perlindungan yang berbeda.
• Dengan RPO dan RTO. Metode ini mengelompokkan sumber data dengan RPO serupa. kontrol RPO dengan mengatur frekuensi sinkronisasi untuk grup perlindungan, yang menentukan jumlah potensi kehilangan data (diukur dalam waktu) selama gangguan tak terduga. Dalam skenario yang dijelaskan dalam artikel ini, Anda mengontrol RTO dengan mengatur periode retensi dalam penyimpanan jangka pendek. Ini menentukan periode di mana cadangan dapat dipulihkan dari penyimpanan jangka pendek lokal, bukan dari penyimpanan jangka panjang berbasis cloud. Mencadangkan dari penyimpanan jangka pendek lokal menghasilkan pemulihan yang lebih cepat.
• Dengan karakteristik data. Metode ini memperkirakan frekuensi perubahan data, tingkat pertumbuhan data, atau persyaratan penyimpanannya sebagai kriteria pengelompokan.

Saat menamai grup perlindungan, gunakan nama unik dan bermakna. Nama dapat berupa kombinasi karakter alfanumerik dan spasi hingga 64 karakter.

Saat membuat grup perlindungan, Anda memilih metode untuk membuat replika awal. Replikasi awal menyalin semua data yang dipilih untuk perlindungan ke server yang menghosting MABS, lalu menyalinnya ke vault Azure Site Recovery. Kedua salinan diperiksa untuk konsistensi. MABS dapat membuat replika secara otomatis melalui jaringan, tetapi Anda dapat membuat replika secara manual dengan mencadangkan, mentransfer, dan memulihkan data secara offline.

Untuk informasi tentang memilih metode pembuatan replika, lihat Replikasi awal melalui jaringan. Artikel ini memiliki tabel yang memberikan perkiraan berapa lama waktu yang dibutuhkan MABS untuk membuat replika secara otomatis melalui jaringan untuk berbagai ukuran data dan kecepatan jaringan yang dilindungi.

Proses penyemaian offline mendukung penggunaan layanan Azure Import/Export, yang dapat mentransfer data ke akun Azure Storage dengan menggunakan disk SATA. Kemampuan ini dapat digunakan ketika pencadangan online terlalu lambat karena jumlah data cadangan atau kecepatan koneksi jaringan ke Azure.

Alur kerja seeding offline memiliki langkah-langkah berikut:

1. Anda menyalin data cadangan awal ke satu atau beberapa disk SATA dengan menggunakan alat AzureOfflineBackupDiskPrep.
2. Alat ini secara otomatis menghasilkan pekerjaan Impor Azure dan aplikasi Microsoft Entra dalam langganan yang menghosting akun Azure Storage target dan vault Azure Recovery Services. Aplikasi ini menyediakan Azure Backup dengan akses aman dan tercakup ke Azure Import Service, seperti yang diperlukan oleh proses penyemaian offline.
3. Anda mengirim disk ke pusat data Azure yang menghosting akun Azure Storage target.
4. Staf pusat data Azure menyalin data dari disk ke akun Azure Storage.
5. Alur kerja ini memicu salinan dari akun Azure Storage ke brankas Azure Recovery Services.

DevOps

Meskipun pencadangan dan pemulihan dianggap sebagai bagian dari operasi TI, ada beberapa pertimbangan khusus DevOps yang layak dimasukkan ke dalam strategi pencadangan yang komprehensif. Azure Stack Hub memfasilitasi penyebaran otomatis berbagai beban kerja, termasuk aplikasi dan layanan berbasis VM. Anda dapat menggunakan kemampuan ini untuk menyederhanakan penyebaran MABS ke VM Azure Stack Hub, yang menyederhanakan penyiapan awal dalam skenario multipenyewa. Dengan menggabungkan templat Azure Resource Manager, ekstensi VM, dan modul DPM PowerShell, dimungkinkan untuk mengotomatiskan konfigurasi MABS, termasuk penyiapan grup perlindungan, pengaturan retensi, dan jadwal pencadangannya. Dalam semangat praktik terbaik DevOps, Anda harus menyimpan templat dan skrip di fasilitas kontrol sumber, dan mengonfigurasi penyebarannya dengan menggunakan alur. Praktik ini membantu meminimalkan waktu pemulihan jika infrastruktur yang diperlukan untuk memulihkan file dan data aplikasi harus dibuat ulang.

Efisiensi kinerja

Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Gambaran umum pilar efisiensi performa.

Saat Anda berencana untuk menyebarkan MABS di Azure Stack Hub, Anda perlu mempertimbangkan jumlah pemrosesan, penyimpanan, dan sumber daya jaringan yang dialokasikan ke VM yang menghosting penyebaran. Microsoft merekomendasikan untuk mengalokasikan CPU quad-core 2,33 gigahertz (GHz) untuk memenuhi kebutuhan pemrosesan MABS, dan sekitar 10 GB ruang disk untuk mengakomodasi biner penginstalan. Persyaratan penyimpanan lainnya dapat dikategorikan sebagai berikut:

• Ruang disk untuk cadangan. Rekomendasi umum untuk ruang disk cadangan adalah mengalokasikan kumpulan penyimpanan ruang disk yang setara dengan sekitar 1,5 kali ukuran semua data yang akan dicadangkan. Setelah disk dipasang ke VM, MABS mengelola manajemen volume dan ruang disk. Jumlah disk yang dapat Anda lampirkan ke VM tergantung pada ukurannya.

  Catatan

  Anda tidak boleh menyimpan cadangan secara lokal selama lebih dari lima hari. Cadangan yang lebih lama dari lima hari harus dibongkar ke brankas Azure Site Recovery.

• Ruang disk untuk lokasi cache agen MARS. Pertimbangkan untuk menggunakan drive C pada VM yang menghosting penginstalan MABS.

• Ruang disk untuk area penahapan lokal selama pemulihan. Pertimbangkan untuk menggunakan drive D sementara pada VM yang menghosting penginstalan MABS.

Untuk menyediakan penyimpanan untuk VM yang menghosting penginstalan MABS, gunakan disk terkelola di tingkat performa Premium. Karakteristik performa yang diharapkan adalah 2.300 operasi I/O per detik (IOPS) dan 145 MB/dtk per disk. Tidak seperti Azure, tidak ada jaminan performa untuk Azure Stack Hub.

Untuk mendapatkan perkiraan penyimpanan yang lebih akurat yang diperlukan untuk mengakomodasi pencadangan beban kerja berbasis Azure Stack Hub, pertimbangkan untuk menggunakan Kalkulator Ukuran VM Azure Stack untuk MABS, yang tersedia dari Unduhan Microsoft. Kalkulator diimplementasikan sebagai buku kerja Microsoft Excel yang memiliki makro yang memperoleh informasi ukuran Azure Stack Hub optimal yang didasarkan pada sejumlah parameter yang Anda berikan. Parameter ini meliputi:

• Detail sumber yang menyertakan daftar VM yang akan dilindungi, termasuk untuk masing-masing:
  • Ukuran data yang dilindungi
  • Jenis beban kerja (Windows Server, SharePoint, atau SQL Server)
• Periode retensi data, dalam hari

Setiap jenis beban kerja adalah, secara default, terkait dengan tingkat perubahan harian yang telah ditentukan sebelumnya (atau churn). Anda dapat menyesuaikan nilai-nilai ini jika tidak mencerminkan pola penggunaan di lingkungan Anda.

Kalkulator Ukuran Azure Stack VM untuk MABS menggunakan informasi yang Anda tentukan untuk diberikan:

• Perkiraan ukuran VM Azure Stack Hub yang menghosting penginstalan MABS.
• Perkiraan jumlah ruang disk MABS yang diperlukan untuk menghosting data yang dicadangkan.
• Jumlah total disk masing-masing 1 terabyte (TB).
• Tingkat IOPS yang tersedia untuk penggunaan MABS.
• Perkiraan waktu untuk menyelesaikan pencadangan awal. Perkiraan didasarkan pada ukuran total data yang dilindungi dan pada IOPS yang tersedia untuk penggunaan MABS.
• Perkiraan waktu untuk menyelesaikan pencadangan harian. Perkiraan didasarkan pada ukuran total churn harian dan pada IOPS yang tersedia untuk penggunaan MABS.

Jika Anda membuat grup perlindungan dengan menggunakan antarmuka grafis MABS, setiap kali Anda menambahkan sumber data ke grup perlindungan, MABS menghitung alokasi ruang disk lokal yang didasarkan pada tujuan pemulihan jangka pendek yang Anda tentukan. Anda kemudian dapat memutuskan berapa banyak ruang yang akan dialokasikan di kumpulan penyimpanan untuk replika dan titik pemulihan untuk setiap sumber data dalam grup. Anda perlu memastikan bahwa ada cukup ruang pada disk lokal server yang dilindungi untuk jurnal perubahan. MABS menyediakan alokasi ruang default untuk anggota grup perlindungan. Untuk detail mengenai alokasi ruang default untuk komponen MABS yang berbeda, lihat Menyebarkan dokumentasi grup perlindungan.

Pertimbangkan untuk menggunakan alokasi ruang default kecuali Anda tahu bahwa alokasi tersebut tidak memenuhi kebutuhan Anda. Mengesampingkan alokasi default dapat menghasilkan alokasi ruang yang terlalu sedikit atau terlalu besar. Alokasi ruang yang terlalu sedikit untuk titik pemulihan dapat mencegah MABS menyimpan titik pemulihan yang cukup untuk memenuhi tujuan periode retensi. Alokasi ruang yang terlalu banyak menghabiskan kapasitas disk. Setelah membuat grup perlindungan, jika mengalokasikan ruang yang terlalu sedikit untuk sumber data, Anda dapat meningkatkan alokasi untuk replika dan volume titik pemulihan untuk setiap sumber data. Jika Anda mengalokasikan terlalu banyak ruang untuk grup perlindungan, Anda dapat menghapus sumber data dari grup perlindungan dan menghapus replika. Kemudian tambahkan sumber data ke grup perlindungan dengan alokasi yang lebih kecil.

Setelah penyebaran, jika Anda perlu menyesuaikan perkiraan ukuran VM Azure Stack Hub yang menghosting MABS untuk mengakomodasi perubahan dalam persyaratan pemrosesan atau penyimpanan, Anda memiliki tiga opsi:

• Menerapkan penyekalaan vertikal. Ini mengharuskan Anda memodifikasi jumlah dan jenis sumber daya prosesor, memori, dan disk dari VM Azure Stack Hub yang menghosting MABS.
• Menerapkan penskalaan horizontal. Ini memerlukan provisi atau deprovisi VM Azure Stack Hub yang telah diinstal MABS agar sesuai dengan tuntutan pemrosesan beban kerja yang dilindungi.
• Memodifikasi kebijakan perlindungan. Ini mengharuskan perubahan parameter kebijakan perlindungan, termasuk rentang retensi, jadwal titik pemulihan, dan mengekspresikan jadwal pencadangan penuh.

Jika Anda memilih untuk secara otomatis menambah volume, MABS akan mengurangi volume cadangan saat data produksi bertambah. Jika tidak, MABS membatasi penyimpanan cadangan hingga ukuran sumber data dalam grup perlindungan.

Ada dua opsi utama untuk menyesuaikan bandwidth yang tersedia:

• Memperbesar ukuran VM. Untuk VM Azure Stack Hub, ukurannya menentukan bandwidth jaringan maksimum. Namun, tidak ada jaminan bandwidth. Sebagai gantinya, VM dapat menggunakan jumlah bandwidth yang tersedia hingga batas yang ditentukan oleh ukurannya.
• Tingkatkan throughput sakelar uplink. Sistem Azure Stack Hub mendukung berbagai pengalihan perangkat keras yang menawarkan beberapa pilihan kecepatan uplink. Setiap simpul kluster Azure Stack Hub memiliki dua uplink ke pengalihan dalam rak untuk toleransi kesalahan. Sistem ini mengalokasikan setengah dari kapasitas uplink untuk infrastruktur penting, dan sisanya adalah kapasitas bersama untuk layanan Azure Stack dan semua lalu lintas pengguna. Sistem yang disebarkan dengan kecepatan yang lebih cepat memiliki lebih banyak bandwidth yang tersedia untuk lalu lintas cadangan.

Meskipun dimungkinkan untuk memisahkan lalu lintas jaringan dengan melampirkan adaptor jaringan kedua ke server, semua lalu lintas VM Azure Stack Hub ke internet berbagi uplink yang sama. Adaptor jaringan virtual kedua tidak memisahkan lalu lintas di tingkat transportasi fisik.

Untuk mengakomodasi ukuran cadangan yang lebih besar, Anda dapat mempertimbangkan untuk menggunakan Azure ExpressRoute dengan peering Microsoft untuk menyambungkan antara jaringan virtual Azure Stack Hub dan vault Azure Recovery Services. Azure ExpressRoute memperluas jaringan lokal ke cloud Microsoft melalui koneksi privat yang disediakan oleh penyedia konektivitas. Anda dapat membeli sirkuit ExpressRoute untuk berbagai bandwidth, dari 50 Mbps hingga 10 Gbps.

Ringkasan

Azure Stack Hub adalah penawaran unik yang berbeda dalam banyak aspek dari platform virtualisasi lainnya. Dengan demikian, ini menjamin pertimbangan khusus sehubungan dengan strategi kelangsungan bisnis untuk beban kerja yang berjalan pada VM-nya. Menggunakan layanan Azure menyederhanakan strategi desain dan implementasi. Dalam artikel ini, kami menjelajahi menggunakan MABS untuk mencadangkan data file dan aplikasi di VM Azure Stack Hub dalam model penyebaran yang terhubung. Pendekatan ini memungkinkan pelanggan untuk mendapatkan manfaat dari ketahanan dan pengelolaan Azure Stack Hub, dan dari kehadiran hyperscale dan global cloud Azure.

Solusi pencadangan yang dijelaskan di sini berfokus secara eksklusif pada data file dan aplikasi di VM Azure Stack Hub. Ini hanya bagian dari strategi kelangsungan bisnis keseluruhan yang harus memperhitungkan berbagai skenario lain yang memengaruhi ketersediaan beban kerja. Beberapa contohnya adalah: kegagalan perangkat keras dan perangkat lunak yang dilokalkan, pemadaman sistem, peristiwa bencana, dan bencana skala besar.

Langkah berikutnya

• Panduan - Mencadangkan Akun Storage di Azure Stack
• Panduan - Pencadangan VM di Azure Stack Hub menggunakan Commvault
• Mencadangkan beban kerja Cloud dan Lokal ke Cloud
• Menginstal Azure Backup Server
• Mencadangkan file dan aplikasi di Azure Stack
• Mencadangkan farm SharePoint di Azure Stack
• Mencadangkan SQL Server di Azure Stack

Sumber daya terkait

Panduan hibrid terkait:

• Desain arsitektur hibrid
• Opsi hibrid Azure
• Pertimbangan desain aplikasi hibrid

Arsitektur terkait:

• Pemulihan Bencana untuk VM Azure Stack Hub
• Mencadangkan aplikasi dan data lokal ke cloud