Praktik terbaik pemulihan bencana dengan Azure File Sync
Untuk Azure File Sync, terdapat tiga area utama yang perlu dipertimbangkan untuk pemulihan bencana: ketersediaan tinggi, perlindungan/pencadangan data, dan redundansi data. Artikel ini mencakup setiap aspek dan membantu Anda memutuskan konfigurasi apa yang akan digunakan untuk solusi pemulihan bencana Anda sendiri.
Dalam penyebaran Azure File Sync, titik akhir cloud selalu berisi salinan lengkap data Anda, sementara server secara lokal dapat dilihat sebagai tembolok sekali pakai untuk data Anda. Jika terjadi bencana pada sisi server, Anda dapat memulihkannya dengan menyediakan server baru, menginstal agen Azure File Sync di atasnya, dan menyiapkannya sebagai titik akhir server baru.
Karena sifatnya yang hibrid, beberapa strategi pencadangan server dan pemulihan bencana tradisional tidak akan bekerja dengan Azure File Sync. Untuk server terdaftar apa pun, Azure File Sync tidak mendukung:
Peringatan
Mengambil salah satu dari tindakan ini dapat menyebabkan masalah pada file berjenjang yang disinkronkan atau rusak, yang pada akhirnya mengakibatkan kehilangan data. Jika Anda telah mengambil salah satu tindakan ini, hubungi dukungan Azure untuk memastikan penyebaran Anda sehat.
- Mentransfer/mengkloning drive disk (volume) dari satu server ke server lain saat titik akhir server masih aktif
- Memulihkan dari pencadangan sistem operasi
- Mengkloning sistem operasi server pada server lain
- Mengembalikan ke titik pemeriksaan mesin virtual sebelumnya
- Memulihkan file berjenjang dari cadangan lokal (pihak ketiga) ke titik akhir server
Ketersediaan tinggi
Ada dua strategi berbeda yang dapat Anda gunakan untuk mencapai ketersediaan tinggi untuk server lokal Anda. Anda dapat mengonfigurasi kluster failover, atau mengonfigurasi server siaga. Faktor penentu antara salah satu konfigurasi adalah seberapa banyak Anda bersedia untuk berinvestasi dalam sistem Anda, dan jika meminimalkan lamanya waktu sistem Anda tidak berfungsi jika bencana sepadan dengan biaya tambahan tersebut.
Untuk kluster failover, Anda tidak perlu mengambil langkah khusus untuk menggunakan Azure File Sync. Untuk server siaga, Anda harus membuat konfigurasi berikut:
Memiliki server sekunder dengan titik akhir server berbeda yang disinkronkan ke grup sinkronisasi yang sama dengan server utama Anda, tetapi jangan aktifkan akses pengguna akhir ke server. Hal ini memungkinkan semua file disinkronkan dari server utama ke server siaga. Anda dapat mempertimbangkan untuk mengaktifkan tingkatan hanya namespace sehingga hanya namespace yang diunduh pada awalnya. Jika server utama Anda gagal, Anda dapat menggunakan DFS-N untuk dengan cepat mengonfigurasi ulang akses pengguna akhir ke server siaga Anda.
Perlindungan/pencadangan data
Melindungi data Anda adalah komponen utama dari solusi pemulihan bencana. Ada dua cara utama untuk melakukan ini dengan berbagi file Azure Anda: Anda dapat mencadangkan data Anda di cloud atau lokal. Kami sangat menyarankan Anda mencadangkan data Anda di cloud karena titik akhir cloud Anda akan berisi salinan lengkap data Anda, sementara titik akhir server mungkin hanya berisi subset data Anda.
Mencadangkan data Anda pada cloud
Anda harus menggunakan Azure Backup sebagai solusi pencadangan cloud Anda. Azure Backup di antaranya menangani penjadwalan pencadangan, retensi, dan pemulihan. Jika mau, Anda dapat secara manual mengambil rekam jepret berbagi dan mengonfigurasi penjadwalan dan solusi retensi Anda sendiri, tetapi ini tidak ideal. Atau Anda dapat menggunakan solusi pihak ketiga untuk langsung mencadangkan file share Azure Anda.
Jika terjadi bencana, Anda dapat memulihkan dari pembagian rekam jepret, yang merupakan titik waktu atas salinan file share Anda yang hanya dapat dibaca. Karena rekam jepret ini bersifat baca-saja, rekam jepret ini tidak akan terpengaruh oleh ransomware. Untuk himpunan data besar di mana operasi pemulihan berbagi penuh membutuhkan waktu lama, Anda dapat mengaktifkan akses pengguna langsung ke rekam jepret sehingga pengguna dapat menyalin data yang mereka butuhkan ke drive lokal mereka saat pemulihan selesai.
Rekam jepret disimpan langsung di berbagi file Azure Anda, tidak peduli apakah Anda membawanya secara manual atau jika Azure Backup membawanya untuk Anda. Jadi, Anda harus mengaktifkan penghapusan sementara untuk melindungi rekam jepret Anda dari penghapusan berbagi file yang tidak disengaja.
Untuk informasi selengkapnya, lihat Tentang pencadangan file share Azure, atau hubungi penyedia pencadangan untuk mengetahui apakah mereka mendukung pencadangan file share Azure.
Mencadangkan data Anda secara lokal
Jika Anda mengaktifkan tingkatan cloud, jangan menerapkan solusi cadangan secara lokal. Dengan cloud tiering diaktifkan, hanya subset data Anda yang akan disimpan secara lokal di server Anda, dan sisa data Anda disimpan di titik akhir cloud Anda. Bergantung pada solusi cadangan apa yang Anda gunakan untuk cadangan lokal, file berjenjang akan menjadi:
- dilewati dan tidak dicadangkan (karena atributnya
FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS), atau - dicadangkan hanya sebagai file berjenjang dan mungkin tidak dapat diakses saat pemulihan karena perubahan dalam berbagi langsung, atau
- ditarik kembali ke disk Anda, yang akan mengakibatkan biaya keluar yang tinggi.
Jika Anda memutuskan untuk menggunakan solusi pencadangan lokal, Anda harus melakukan pencadangan di server di grup sinkronisasi dengan penjenjangan cloud dinonaktifkan. Saat melakukan pemulihan, gunakan opsi pemulihan tingkat volume atau tingkat file. File yang dipulihkan menggunakan opsi pemulihan tingkat file akan disinkronkan ke semua titik akhir dalam grup sinkronisasi, dan file yang ada akan diganti dengan versi yang dipulihkan dari cadangan. Pemulihan tingkat volume tidak akan menggantikan versi file yang lebih baru pada file share Azure atau titik akhir server lainnya.
Layanan Menyalin Bayangan Volume (VSS) (termasuk tab Versi Sebelumnya) didukung pada volume dengan pengaturan tingkat cloud yang diaktifkan. Hal ini memungkinkan Anda untuk melakukan pemulihan layanan mandiri, dan tidak mengandalkan admin untuk melakukan pemulihan bagi Anda. Namun, Anda harus mengaktifkan kompatibilitas versi sebelumnya melalui PowerShell, yang akan meningkatkan biaya penyimpanan rekam jepret Anda. Rekam jepret VSS tidak melindungi terhadap bencana pada titik akhir server itu sendiri, sehingga hanya dapat digunakan bersama pencadangan pada sisi cloud. Untuk detailnya, lihat pemulihan Layanan Mandiri melalui Versi Sebelumnya dan VSS.
Redundansi data
Untuk memastikan solusi pemulihan bencana yang kuat, tambahkan beberapa bentuk redundansi data pada infrastruktur Anda. Ada empat penawaran redundansi untuk Azure Files: Penyimpanan redundan lokal (LRS), penyimpanan redundansi zona (ZRS), penyimpanan geo-redundan (GRS), dan penyimpanan redundan zona geografis (GZRS).
- Penyimpanan yang redundan secara lokal (LRS): Dengan LRS, setiap file disimpan dalam tiga rangkap dalam kluster penyimpanan Azure. Ini melindungi dari hilangnya data karena kesalahan perangkat keras, seperti drive disk yang buruk. Namun, jika bencana seperti kebakaran atau banjir terjadi di dalam pusat data, semua replika akun penyimpanan yang menggunakan LRS mungkin hilang atau tidak dapat dipulihkan.
- Penyimpanan redundan zona (ZRS): Dengan ZRS, tiga salinan dari setiap file akan disimpan, namun salinan ini secara fisik diisolasi di dalam tiga kelompok penyimpanan berbeda pada zona ketersediaan Azure yang berbeda. Zona Ketersediaan adalah lokasi fisik yang unik dalam wilayah Azure. Setiap zona terbuat dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen. Penulisan ke penyimpanan tidak diterima sampai ditulis ke kluster penyimpanan di ketiga zona ketersediaan.
- Penyimpanan geo-redundan (GRS): Dengan GRS, Anda memiliki dua wilayah: wilayah primer dan sekunder. File disimpan dalam tiga rangkap dalam kluster penyimpanan Azure di wilayah primer. Penulisan akan direplikasi secara asinkron ke wilayah sekunder yang ditentukan oleh Microsoft. GRS menyediakan enam salinan data Anda yang tersebar di antara dua wilayah Azure.
- Penyimpanan geo-zona-redundan (GZRS): Anggaplah GZRS sebagai ZRS tetapi dengan geo-redundansi. Dengan GZRS, file akan disimpan dalam tiga rangkap di tiga kluster penyimpanan berbeda di wilayah utama. Semua tulisan kemudian ditiru secara asinkron ke wilayah sekunder yang ditentukan Microsoft.
Untuk solusi pemulihan bencana yang kuat, sebagian besar pelanggan seharusnya mempertimbangkan ZRS. ZRS menambahkan jumlah biaya tambahan setidaknya untuk manfaat redundansi data tambahan, dan merupakan solusi yang paling efisien jika terjadi pemadaman. Jika kebijakan atau persyaratan peraturan organisasi Anda mensyaratkan geo-redundansi untuk data Anda, pertimbangkanlah GRS atau GZRS.
Redundansi geografis
Jika akun penyimpanan Anda dikonfigurasi dengan replikasi GRS atau GZRS, Microsoft akan memulai failover Layanan Sinkronisasi Penyimpanan jika kawasan utama tersebut dianggap tidak dapat dipulihkan secara permanen atau tidak tersedia untuk waktu yang lama. Tidak ada tindakan yang diperlukan dari Anda jika terjadi bencana.
Meskipun Anda dapat meminta failover Storage Sync Service Anda secara manual ke wilayah berpasangan GRS atau GZRS Anda, kami tidak menyarankan untuk melakukan ini di luar pemadaman regional skala besar karena prosesnya tidak mulus dan mungkin dikenakan biaya tambahan. Untuk memulai proses, buka tiket dukungan dan minta agar akun penyimpanan Azure Anda yang berisi file share Azure dan Layanan Sinkronisasi Storage Anda gagal.
Peringatan
Anda harus menghubungi dukungan untuk meminta Layanan Sinkronisasi Penyimpanan Anda di-failover jika Anda memulai proses ini secara manual. Mencoba membuat Storage Sync Service baru menggunakan titik akhir server yang sama di wilayah sekunder dapat mengakibatkan data tambahan tetap berada di akun penyimpanan Anda karena penginstalan Azure File Sync sebelumnya tidak akan dibersihkan.
Setelah failover terjadi, titik akhir server akan beralih untuk disinkronkan dengan titik akhir cloud pada wilayah sekunder secara otomatis. Namun, titik akhir server harus sesuai dengan titik akhir cloud. Ini mungkin mengakibatkan konflik file, karena data di wilayah sekunder mungkin tidak terperangkap ke primer.