Memigrasikan data secara offline ke Azure File Sync dengan Azure Data Box

Artikel migrasi ini adalah salah satu dari beberapa yang berlaku untuk kata kunci Azure File Sync dan Azure Data Box. Periksa apakah artikel ini berlaku untuk skenario Anda:

• Sumber data: Windows Server 2012 R2 atau yang lebih baru tempat Azure File Sync akan diinstal dan mengarah ke set file asli.
• Rute migrasi: Windows Server 2012 R2 atau terbaru ⇒ Data Box ⇒ berbagi file Azure ⇒ sinkronkan dengan lokasi file asli di Windows Server
• File caching lokal: Ya, tujuan akhirnya adalah penyebaran Azure File Sync yang menyinkronkan file dari lokasi asalnya saat ini.

Menggunakan Azure Data Box adalah jalur yang layak untuk memindahkan data massal dari Windows Server lokal Anda untuk memisahkan berbagi file Azure, lalu secara opsional, tambahkan Azure File Sync di server sumber asli.

Ada berbagai jalur migrasi yang tersedia untuk Anda, tetapi penting untuk mengikuti yang benar:

• Data Anda berada di Windows Server 2012 R2 atau yang lebih baru dan Anda berencana untuk menginstal AFS ke server tersebut dan menyinkronkan lokasi aslinya. Dalam skenario ini, Anda tidak ingin mengunggah semua file dan menggunakan Data Box sebagai gantinya, lalu menggunakan sinkronisasi file untuk perubahan yang sedang berlangsung. Jika ini adalah skenario Anda, maka artikel ini menjelaskan jalur migrasi Anda.
• Anda memiliki data pada sumber di mana Anda tidak akan atau tidak dapat menginstal AFS. Misalnya NAS (Network Attached Storage) atau server lainnya. Anda lebih suka membuat server baru yang kosong dan menggunakan Azure File Sync di server itu. Jika itu adalah skenario Anda, maka ini bukan panduan migrasi yang tepat untuk Anda. Lebih baik lihat: Memigrasikan dari NAS melalui Data Box ke Azure File Sync atau temukan panduan terbaik untuk skenario Anda di halaman gambaran umum migrasi.
• Untuk semua skenario lainnya, periksa tabel panduan migrasi berbagi file Azure. Halaman gambaran umum ini memberikan titik awal yang baik untuk semua skenario migrasi.

Gambaran umum migrasi

Proses migrasi terdiri dari beberapa fase. Anda perlu:

• Menyebarkan akun penyimpanan dan berbagi file.
• Menyebarkan satu atau beberapa perangkat Azure Data Box untuk memindahkan data dari Windows Server 2012 R2 atau yang lebih baru.
• Mengonfigurasi Azure File Sync dengan pengunggahan otoritatif.

Bagian yang berikut menjelaskan fase dari proses migrasi secara terperinci.

Kiat

Jika Anda kembali ke artikel ini, gunakan navigasi di sisi kanan layar untuk langsung ke fase migrasi tempat Anda berhenti sebelumnya.

Fase 1: Tentukan berapa banyak berbagi file Azure yang Anda butuhkan

Dengan panduan migrasi ini, Anda harus terus menggunakan penyimpanan terpasang langsung (DAS) lokal yang berisi file Anda. Data Box akan diumpankan dari lokasi tersebut dan Azure File Sync juga akan disiapkan di lokasi yang sama. NAS (Network Attached Storage) tidak berfungsi dengan jalur migrasi ini.

Anda menentukan apa yang disinkronkan dengan menyiapkan grup sinkronisasi Azure File Sync yang masing-masing menentukan lokasi set file disinkronkan. Setiap grup sinkronisasi memiliki setidaknya satu lokasi server, yang disebut titik akhir server dan satu berbagi file Azure, yang disebut titik akhir cloud.

Anda dapat menyinkronkan jalur sub dari satu set file ke berbagi file Azure masing-masing. Untuk melakukannya, perlu penyiapan beberapa grup sinkronisasi untuk mencakup satu set file sepenuhnya. Bagian selanjutnya menjelaskan pilihan Anda. Jika Anda perlu merestrukturisasi data Anda, Anda harus melakukannya terlebih dahulu sebagai langkah pertama. Sebelum melanjutkan dengan panduan ini, pesan Data Box atau menyiapkan sinkronisasi.

Perhatian

Penting sekali bahwa struktur file dan folder Anda harus sesuai dengan yang Anda inginkan untuk jangka panjang sebelum memulai migrasi. Hindari restrukturisasi folder yang tidak perlu selama migrasi. Ini akan mengurangi efek positif dari menggunakan Azure Data Box dalam transportasi massal dan awal file ke Azure.

Dalam langkah ini, Anda akan menentukan berapa banyak berbagi file Azure yang Anda butuhkan. Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure.

Anda mungkin memiliki lebih banyak folder pada volume yang saat ini Anda bagikan secara lokal sebagai berbagi SMB kepada pengguna dan aplikasi Anda. Cara termudah untuk menggambarkan skenario ini adalah membayangkan sebuah saham lokal yang dihubungkan 1:1 dengan Azure file share. Jika Anda memiliki jumlah pembagian yang cukup kecil, di bawah 30 untuk satu instans Windows Server, kami merekomendasikan pemetaan 1:1.

Jika Anda memiliki lebih dari 30 share, memetakan share lokal 1:1 menjadi Azure file share seringkali tidak perlu. Pertimbangkan opsi berikut.

Berbagi pengelompokan

Misalnya, jika departemen sumber daya manusia (SDM) Anda memiliki 15 pembagian, Anda mungkin mempertimbangkan untuk menyimpan semua data SDM dalam satu berbagi file Azure. Menyimpan beberapa pembagian lokal dalam satu berbagi file Azure tidak mencegah Anda membuat 15 pembagian SMB biasa pada instans Windows Server lokal Anda. Ini hanya berarti bahwa Anda mengatur folder akar dari 15 pembagian ini sebagai subfolder di bawah folder umum. Anda kemudian menyinkronkan folder umum ini ke berbagi file Azure. Dengan begitu, hanya satu penyimpanan file Azure di cloud yang dibutuhkan untuk grup berbagi lokal ini.

Sinkronisasi volume

Azure File Sync mendukung sinkronisasi akar volume ke berbagi file Azure. Jika Anda menyinkronkan root volume, semua subfolder dan file akan masuk ke berbagi file Azure yang sama.

Menyinkronkan akar volume tidak selalu merupakan opsi terbaik. Ada manfaat untuk menyinkronkan beberapa lokasi. Misalnya, melakukannya membantu menjaga jumlah item lebih rendah per lingkup sinkronisasi. Kami menguji berbagi file Azure dan Azure File Sync dengan 100 juta item (file dan folder) per berbagi. Tetapi standar terbaik adalah mencoba mempertahankan jumlah di bawah 20 juta atau 30 juta dalam satu saham. Menyiapkan Azure File Sync dengan jumlah item yang lebih rendah tidak hanya bermanfaat untuk sinkronisasi file. Jumlah item yang lebih rendah juga menguntungkan skenario seperti ini:

• Pemindaian awal konten cloud dapat diselesaikan lebih cepat, yang pada gilirannya mengurangi penantian hingga ruang nama muncul di server yang diaktifkan untuk Azure File Sync.
• Pemulihan di sisi cloud dari snapshot berbagi berkas Azure akan lebih cepat.
• Pemulihan bencana server lokal dapat mempercepat secara signifikan.
• Perubahan yang dilakukan secara langsung di berbagi file Azure (di luar sinkronisasi) dapat dideteksi dan disinkronkan lebih cepat.

Kiat

Jika Anda tidak tahu berapa banyak file dan folder yang Anda miliki, lihat alat TreeSize dari JAM Software GmbH.

Pendekatan terstruktur untuk peta penyebaran

Sebelum Anda menerapkan penyimpanan cloud di langkah selanjutnya, penting untuk membuat peta antara folder lokal dan berbagi file Azure. Pemetaan ini akan menginformasikan berapa banyak dan sumber daya grup sinkronisasi mana dari Azure File Sync yang akan Anda provisikan. Grup sinkronisasi mengikat berbagi file Azure dan folder di server Anda bersama-sama dan membuat koneksi sinkronisasi.

Untuk memutuskan berapa banyak berbagi file Azure yang Anda butuhkan, tinjau batasan dan praktik terbaik berikut. Melakukannya akan membantu Anda mengoptimalkan peta Anda.

• Server tempat agen Azure File Sync dipasang dapat disinkronkan dengan hingga 30 share file Azure.

• Berbagi file Azure disebarkan di akun penyimpanan. Pengaturan itu menjadikan akun penyimpanan sebagai target skala untuk angka performa seperti IOPS dan throughput.

  Perhatikan batasan IOPS akun penyimpanan saat menyebarkan berbagi file Azure. Idealnya, Anda harus memetakan berbagi file 1:1 dengan akun penyimpanan. Namun, ini mungkin tidak selalu dimungkinkan karena berbagai batasan dan pembatasan, baik dari organisasi Anda maupun dari Azure. Ketika tidak mungkin hanya memiliki satu berbagi file yang diletakkan dalam satu akun penyimpanan, pertimbangkanlah mana berbagi file yang akan sangat aktif dan mana yang kurang aktif untuk memastikan agar berbagi file yang paling aktif tidak ditempatkan dalam akun penyimpanan yang sama.

  Jika Anda berencana untuk mengangkat aplikasi ke Azure yang akan menggunakan berbagi file Azure secara asli, Anda mungkin memerlukan lebih banyak performa dari berbagi file Azure Anda. Jika kemungkinan jenis penggunaan ini ada, bahkan di masa depan, yang terbaik adalah membuat satu berkas Azure standar di akun penyimpanan tersendiri.

• Ada batas 250 akun penyimpanan per langganan per wilayah Azure.

Kiat

Mengingat informasi ini, sering kali perlu untuk mengelompokkan beberapa folder tingkat atas pada volume Anda ke direktori akar umum baru. Anda kemudian menyinkronkan direktori akar baru ini, dan semua folder yang Anda kelompokkan ke dalamnya, ke satu berbagi file Azure. Teknik ini memungkinkan Anda untuk tetap berada dalam batas 30 sinkronisasi berbagi file Azure per server.

Pengelompokan di bawah akar umum ini tidak memengaruhi akses ke data Anda. ACL Anda tetap seperti semula. Anda hanya perlu menyesuaikan jalur berbagi apa pun (seperti berbagi SMB atau NFS) yang mungkin Anda miliki di folder server lokal yang sekarang Anda ubah menjadi akar umum. Tidak ada perubahan lain.

Penting

Vektor skala terpenting untuk Azure File Sync adalah jumlah item (file dan folder) yang perlu disinkronkan. Untuk mengetahui detailnya, tinjau target skala Azure File Sync.

Ini adalah praktik terbaik untuk menjaga jumlah item per lingkup sinkronisasi tetap rendah. Itu adalah faktor penting untuk dipertimbangkan dalam pemetaan folder Anda ke berbagi file Azure. Azure File Sync diuji dengan 100 juta item (file dan folder) per pembagian. Tetapi sering kali yang terbaik adalah menjaga jumlah item di bawah 20 juta atau 30 juta dalam satu tempat penyimpanan. Pisahkan namespace Anda menjadi beberapa bagian jika Anda mulai melebihi angka-angka ini. Anda dapat terus mengelompokkan beberapa saham lokal ke dalam saham file Azure yang sama jika Anda tetap agak di bawah angka-angka ini. Praktik ini akan memberi Anda ruang untuk berkembang.

Ada kemungkinan bahwa, dalam situasi Anda, himpunan folder dapat secara logis menyinkronkan ke berbagi file Azure yang sama (dengan menggunakan pendekatan folder akar umum baru yang disebutkan sebelumnya). Tetapi mungkin masih lebih baik untuk mengelompokkan kembali folder agar dapat menyinkronkan ke dua alih-alih satu share file Azure. Anda dapat menggunakan pendekatan ini untuk menjaga jumlah file dan folder di setiap berbagi file tersebar merata di seluruh server. Anda juga dapat membagi saham lokal Anda dan menyinkronkannya ke lebih banyak server lokal, menambahkan kemampuan untuk menyinkronkan dengan 30 saham file Azure tambahan per server ekstra.

Skenario dan pertimbangan sinkronisasi file umum

#	Skenario sinkronisasi	Didukung	Pertimbangan (atau batasan)	Solusi (atau langkah alternatif)
1	Server file dengan beberapa disk/volume dan berbagai proses sharing ke file Azure yang sama sebagai target (konsolidasi)	Tidak	Berbagi file Azure target (titik akhir cloud) hanya mendukung sinkronisasi dengan satu grup sinkronisasi. Grup sinkronisasi hanya mendukung satu titik akhir server per server terdaftar.	1) Mulailah dengan menyinkronkan satu disk (volume akarnya) ke file share Azure. Dimulai dengan disk/volume terbesar akan membantu persyaratan penyimpanan lokal. Konfigurasikan tingkatan cloud agar semua data dipindahkan ke cloud, untuk membebaskan ruang pada disk server file. Pindahkan data dari volume/berbagi lain ke volume saat ini yang sedang disinkronkan. Lanjutkan langkah satu per satu hingga semua data dijenjangkan ke cloud/dimigrasikan. 2) Targetkan satu volume akar (disk) pada satu waktu. Gunakan tingkatan cloud untuk menjenjangkan semua data untuk menargetkan berbagi file Azure. Hapus titik akhir server dari grup sinkronisasi, buat ulang titik akhir dengan volume/disk akar berikutnya, sinkronkan, dan ulangi prosesnya. Catatan: Penginstalan ulang agen mungkin diperlukan. 3) Merekomendasikan penggunaan beberapa berbagi file Azure target (akun penyimpanan yang sama atau berbeda berdasarkan persyaratan performa)
2	File server dengan volume tunggal dan beberapa share ke Azure file share target yang sama (konsolidasi)	Ya	Tidak dapat memiliki beberapa titik akhir server per server terdaftar yang menyinkronkan ke file share Azure yang sama (sama seperti di atas)	Sinkronisasi akar volume yang memuat beberapa share atau folder tingkat atas. Lihat konsep pengelompokan berbagi dan Sinkronisasi volume untuk informasi selengkapnya.
3	Server berkas dengan berbagai berbagi dan/atau volume ke berbagai share file Azure dalam satu akun penyimpanan (pemetaan share 1:1)	Ya	Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure. Akun penyimpanan adalah sasaran penskalaan untuk kinerja. IOPS dan throughput dibagikan di seluruh file share. Simpan jumlah item per kelompok sinkronisasi dalam 100 juta item (file dan folder) untuk setiap berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.	1) Gunakan beberapa grup sinkronisasi (jumlah grup sinkronisasi = jumlah saham file Azure yang akan disinkronkan). 2) Hanya 30 berbagi yang dapat disinkronkan dalam skenario ini pada satu waktu. Jika Anda memiliki lebih dari 30 pembagian pada server file tersebut, gunakan konsep Pengelompokan Berbagi dan Sinkronisasi Volume untuk mengurangi jumlah folder tingkat akar atau tingkat atas di sumbernya. 3) Gunakan server File Sync tambahan lokal dan pisahkan/pindahkan data ke server ini untuk mengatasi batasan pada server Windows sumber.
4	Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan yang berbeda (pemetaan berbagi 1:1)	Ya	Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure (akun penyimpanan yang sama atau berbeda). Simpan jumlah item per kelompok sinkronisasi dalam 100 juta item (file dan folder) untuk setiap berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.	Pendekatan yang sama seperti di atas
5	Beberapa server file dengan satu (volume akar atau berbagi) ke berbagi file Azure target yang sama (konsolidasi)	Tidak	Grup sinkronisasi tidak dapat menggunakan titik akhir cloud (Azure file share) yang telah dikonfigurasi di grup sinkronisasi lain. Meskipun grup sinkronisasi dapat memiliki titik akhir server di server file yang berbeda, file tidak dapat berbeda.	Ikuti panduan dalam Skenario # 1 di atas dengan pertimbangan tambahan untuk menargetkan satu server file pada satu waktu.

Membuat tabel pemetaan

Gunakan informasi sebelumnya untuk menentukan berapa banyak berbagi file Azure yang Anda butuhkan dan bagian mana dari data Anda yang sudah ada akan berakhir dalam berbagi file Azure.

Buat tabel yang merekam pemikiran Anda sehingga Anda bisa merujuknya saat Anda perlu. Tetap terorganisir penting karena dapat dengan mudah kehilangan detail rencana pemetaan Anda saat Anda menyediakan banyak sumber daya Azure sekaligus. Unduh file Excel berikut ini untuk digunakan sebagai templat untuk membantu membuat pemetaan Anda.

Unduh templat pemetaan namespace.

Fase 2: Sebar sumber daya penyimpanan Azure

Dalam fase ini, perhatikan tabel pemetaan dari Fase 1 dan gunakan untuk menyediakan jumlah akun penyimpanan Azure yang tepat dan berbagi file di dalamnya.

Saham file Azure disimpan di cloud pada akun penyimpanan Azure. Tingkat pertimbangan performa lainnya berlaku di sini.

Jika Anda memiliki berbagi yang sangat aktif (berbagi yang digunakan oleh banyak pengguna dan/atau aplikasi), dua berbagi file Azure mungkin mencapai batas performa akun penyimpanan.

Praktik terbaik adalah menerapkan akun penyimpanan dengan satu file share masing-masing. Anda dapat mengumpulkan beberapa berbagi file Azure ke akun penyimpanan yang sama jika Anda memiliki berbagi file arsip atau Anda mengharapkan aktivitas harian yang rendah di dalamnya.

Pertimbangan ini lebih berlaku untuk akses cloud langsung (melalui Azure VM) daripada Azure File Sync. Jika Anda berencana untuk hanya menggunakan Azure File Sync pada pembagian ini, beberapa dapat dikelompokkan ke dalam satu akun penyimpanan Azure.

Jika Anda telah membuat daftar berbagi, Anda harus memetakannya masing-masing ke akun penyimpanan yang akan digunakan.

Pada fase sebelumnya, Anda menentukan jumlah saham yang sesuai. Pada langkah ini, Anda memiliki pemetaan akun penyimpanan untuk berbagi file. Sekarang sebarkan jumlah akun penyimpanan Azure yang tepat dengan jumlah berbagi file Azure yang sesuai di dalamnya.

Pastikan wilayah setiap akun penyimpanan Anda sama dan cocok dengan wilayah sumber Storage Sync Service yang telah Anda sebarkan.

Perhatian

Jika Anda membuat file share Azure yang memiliki batas 100 TiB, file share ini hanya dapat menggunakan opsi penyimpanan redundan lokal atau penyimpanan redundan zona. Pertimbangkan kebutuhan redundansi penyimpanan Anda sebelum menggunakan berbagi file 100 TiB.

Secara default, berbagi file Azure tetap dibuat dengan batas 5 TiB. Ikuti langkah-langkah di Membuat berbagi file Azure untuk membuat berbagi file besar.

Pertimbangan lain saat Anda menyebarkan akun penyimpanan adalah redundansi Azure Storage. Lihat Opsi redundansi Azure Storage.

Nama-nama sumber daya Anda juga penting. Misalnya, jika Anda mengelompokkan beberapa resource berbagi untuk departemen SDM ke dalam akun penyimpanan Azure, Anda harus memberikan nama yang tepat untuk akun penyimpanan tersebut. Demikian pula, saat menamai berbagi file Azure, Anda harus menggunakan nama yang mirip dengan yang digunakan untuk rekan lokalnya.

Fase 3: Tentukan berapa banyak appliance Azure Data Box yang Anda butuhkan

Mulailah langkah ini hanya setelah Anda menyelesaikan fase sebelumnya. Sumber daya penyimpanan Azure Anda (akun penyimpanan dan berbagi file) harus dibuat saat ini. Saat Anda memesan Data Box, Anda perlu menentukan akun penyimpanan tempat Data Box memindahkan data.

Pada fase ini, Anda perlu memetakan hasil rencana migrasi dari fase sebelumnya ke batasan opsi Data Box yang tersedia. Pertimbangan ini akan membantu Anda membuat rencana mengenai opsi Data Box yang harus dipilih serta berapa banyak yang Anda butuhkan untuk memindahkan NAS shares Anda ke Azure file shares.

Untuk menentukan berapa banyak perangkat dan jenis yang dibutuhkan, pertimbangkan batasan penting ini:

• Appliance Azure Data Box apa pun dapat memindahkan data hingga ke 10 akun penyimpanan.
• Setiap opsi Data Box hadir dengan kapasitasnya sendiri yang dapat digunakan. Lihat Opsi Data Box.

Lihat rencana migrasi Anda untuk menemukan jumlah akun penyimpanan yang Anda putuskan untuk diciptakan dan pembagian di dalam masing-masing. Lalu lihat ukuran dari setiap bagian di NAS Anda. Menggabungkan informasi ini akan memungkinkan Anda mengoptimalkan dan memutuskan appliance mana harus mengirim data ke akun penyimpanan mana. Dua perangkat Data Box dapat memindahkan file ke akun penyimpanan yang sama, tetapi jangan memisahkan konten dari satu file share ke dua Data Box.

Opsi Data Box

Untuk migrasi standar, pilih satu atau kombinasi dari opsi Data Box berikut ini:

• Disk Kotak Data. Microsoft akan mengirimi Anda satu atau lima disk SSD yang memiliki kapasitas masing-masing 8 TiB, untuk total maksimum 40 TiB. Kapasitas yang dapat digunakan berkurang sekitar 20 persen karena enkripsi dan overhead sistem file. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box Disk.
• Kotak Data. Opsi ini adalah yang paling umum. Microsoft akan mengirimkan perangkat Data Box yang kokoh yang fungsinya mirip dengan NAS. Ini memiliki kapasitas yang dapat digunakan 80, 120, atau 525 TiB, tergantung pada SKU yang Anda pilih. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box.
• Kotak Data Berat. Opsi ini menampilkan perangkat Data Box yang tangguh dan beroda, dengan fungsi yang mirip dengan NAS. Memiliki kapasitas 1 PiB. Kapasitas yang dapat digunakan berkurang sekitar 20 persen karena enkripsi dan overhead sistem file. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box Heavy.

Catatan

Data Box dan Data Box Heavy hanya didukung untuk menyalin data melalui SMB. Menyalin data melalui layanan salinan data tidak didukung karena tidak mempertahankan fidelitas file.

Fase 4: Salin file ke Data Box Anda

Saat Data Box tiba, Anda perlu menyiapkannya dengan konektivitas jaringan tanpa hambatan ke appliance NAS Anda. Ikuti dokumentasi penyiapan untuk jenis Data Box yang Anda pesan:

• Siapkan Data Box.
• Siapkan Data Box Disk.
• Siapkan Data Box Heavy.

Alat salin Data Box mungkin tersedia tergantung pada jenis Data Box. Pada titik ini, kami tidak menyarankan alat itu untuk migrasi ke berbagi file Azure karena ia tidak menyalin file Anda ke Data Box dengan keakuratan penuh. Alih-alih, gunakan Robocopy.

Ketika Data Box Anda tiba, akan ada share SMB yang sudah disiapkan untuk setiap akun penyimpanan yang Anda tentukan saat memesan.

• Jika file Anda dimasukkan ke dalam Azure Premium berbagi file, akan ada satu share SMB per akun penyimpanan "File storage" premium.
• Jika file Anda masuk ke akun penyimpanan standar, akan ada tiga bagian SMB untuk setiap akun penyimpanan standar (GPv1 dan GPv2). Hanya file berbagi yang berakhiran dengan _AzFiles yang berkaitan untuk migrasi Anda. Abaikan segala berbagi blok dan blob halaman.

Ikuti langkah-langkah dalam dokumentasi Azure Data Box:

1. Sambungkan ke Data Box.
2. Salin data ke Data Box.
3. Siapkan Data Box Anda untuk pengunggahan ke Azure.

Dokumentasi Data Box yang ditautkan menyediakan perintah Robocopy. Perintah itu tidak cocok untuk mempertahankan keakuratan penuh file dan folder. Alih-alih, gunakan perintah ini:

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

Beralih	Makna
/MT:n	Memungkinkan Robocopy menjalankan multi-thread. Pengaturan default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh kemampuan komputasi yang tersedia dibandingkan dengan bandwidth jaringan yang tersedia. Untuk menjalankan proses berikutnya, sesuaikan nilai jumlah utas Anda agar lebih sesuai dengan jumlah inti prosesor dan jumlah utas per inti. Pertimbangkan apakah core prosesor perlu dicadangkan untuk tugas lain yang mungkin perlu dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:n	Jumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n kali sebelum file gagal untuk disalin secara permanen. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, jika menerima bahwa file tidak disalin dan menangkapnya dalam salah satu rencana Robocopy Anda yang berikutnya, mungkin akhirnya akan berhasil menyalin file tersebut dengan sukses. Hal itu membantu proses saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang berakhir dengan sebagian besar kegagalan penyalinan karena file masih terbuka melewati batas waktu percobaan.
/W:n	Menentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara percobaan ulang. /W:n sering digunakan bersama dengan /R:n.
/B	Menjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda menghubungkan file share Azure menggunakan kunci akses akun penyimpanan dibandingkan dengan identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR	(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item-item yang ada pada target tetapi tidak ada pada sumber akan dihapus dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan demikian, salinan "catch up" dapat berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/IT	Memastikan kesetiaan dipertahankan dalam skenario pantulan tertentu. Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]	Akurasi salinan file. Bawaan: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]	Fidelitas untuk salinan direktori. Bawaan: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NP	Menentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFL	Menentukan bahwa nama file tidak akan dicatat. Meningkatkan performa penyalinan.
/NDL	Menunjukkan bahwa nama-nama direktori tidak dicatat. Meningkatkan performa penyalinan.
/XD	Menentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan folder System Volume Information yang tersembunyi. Jika digunakan sesuai dengan rancangan, semua informasi di sana spesifik untuk volume yang tepat pada sistem ini dan dapat dibangun kembali sesuai kebutuhan. Menyalin informasi ini tidak akan efektif di cloud atau jika data disalin kembali ke volume Windows lain. Meninggalkan konten ini seharusnya tidak dianggap sebagai kehilangan data.
/UNILOG:<file name>	Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/L	Hanya untuk uji coba File hanya akan dicantumkan. Mereka tidak akan disalin, tidak akan dihapus, dan tidak akan diberi cap waktu. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSM	Hanya untuk sasaran dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh. Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang telah diaktifkan untuk fitur tiering cloud pada Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai batas minimum. Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. Jika /LFSM ditentukan tanpa nilai lantai yang jelas, nilai lantai diatur menjadi 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/Z	Gunakan dengan hati-hati Menyalin file dalam mode mulai ulang. Disarankan untuk menggunakan pengalih ini hanya dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZB	Gunakan dengan hati-hati Menggunakan mode hidupkan ulang. Jika akses ditolak, maka opsi ini akan menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.

Penting

Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.

Fase 5: Sebarkan sumber daya cloud Azure File Sync

Sebelum Anda melanjutkan dengan panduan ini, tunggu sampai semua file Anda tiba di berbagi file Azure yang tepat. Proses pengiriman dan proses pengambilan data pada Data Box akan memakan waktu.

Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.

Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.

Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.

Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.

Fase 6: Sebarkan agen Azure File Sync

Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.

Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.

Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.

Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.

Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.

Di akhir proses pemasangan server, wisaya pendaftaran server akan muncul. Daftarkan server ke sumber daya Azure dari Storage Sync Service Anda yang disebutkan sebelumnya.

Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.

Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.

Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.

Fase 7: Konfigurasikan Azure File Sync di Windows Server yang sudah ada

Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.

Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.

1. Masuk ke portal Azure.
2. Temukan sumber daya Storage Sync Service Anda.
3. Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Dalam terminologi Azure File Sync, Azure File Share akan menjadi titik akhir cloud dalam topologi sinkronisasi yang Anda buat dengan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mengacu pada file share Azure dengan nama yang cocok.
4. Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
5. Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.

Setelah Anda berada di wizard Buat titik akhir server, gunakan kotak centang yang disediakan di bawah jalur folder. Buat pilihan ini hanya jika Anda telah memasukkan jalur yang mengarah ke struktur file dan folder yang sama seperti yang dapat ditemukan di berbagi file Azure (tempat Data Box memindahkan file dan folder dalam namespace ini).

Jika ada ketidakcocokan hierarki folder, maka itu akan muncul sebagai perbedaan yang tidak dapat diselesaikan secara otomatis. Hindari ketidakcocokan atau investasi apa pun dalam proses Data Box karena tidak akan menghasilkan keuntungan apa pun bagi Anda. Semua data akan dihapus dalam berbagi file Azure. Semua data perlu diunggah dari server lokal. Struktur direktori harus sesuai agar dapat memanfaatkan migrasi massal dengan Azure Data Box dan memperbarui secara otomatis penyimpanan cloud dengan perubahan terbaru pada server.

Catatan

Dengan mengaktifkan kotak centang ini, mode Sinkronisasi awal akan diatur untuk menimpa secara otoritatif file dan folder di berbagi file Azure dengan konten di jalur server ini. Opsi ini hanya tersedia untuk titik akhir server pertama kali dalam grup sinkronisasi.

Setelah Anda mengonfigurasi pengunggahan otoritatif untuk titik akhir server baru ini, Anda dapat mengaktifkan tingkatan cloud secara opsional.

Tingkatan cloud adalah fitur Azure File Sync yang memungkinkan server lokal memiliki kapasitas penyimpanan lebih sedikit daripada yang disimpan di cloud, tetapi tetap memiliki namespace penuh yang tersedia. Data yang menarik secara lokal juga di-cache secara lokal untuk kinerja akses cepat. Cloud tiering bersifat opsional. Anda dapat mengaturnya secara terpisah untuk setiap titik akhir server Azure File Sync. Gunakan fitur ini untuk mencapai jejak penyimpanan tetap lokal, namun tetap memberi cache performa lokal kepada pengguna dan menyimpan data yang lebih dingin di cloud.

Pelajari lebih lanjut dengan melihat gambaran umum tingkatan cloud atau telusuri lebih dekat berbagai kebijakan tingkatan cloud yang dapat Anda gunakan untuk menyempurnakan apa saja yang di-cache atau diberi tingkatan di server lokal.

Selesaikan migrasi Anda

Setelah Anda membuat titik akhir server, sinkronisasi akan berjalan. Tetapi sinkronisasi perlu menghitung (menemukan) file dan folder yang Anda pindahkan melalui Azure Data Box ke dalam berbagi file Azure. Bergantung pada ukuran namespace, mungkin membutuhkan waktu lama sebelum perubahan server terbaru tersinkron ke cloud. Pengguna Anda tidak akan terpengaruh dan dapat terus bekerja dengan data di server. Strategi ini mencapai migrasi cloud tanpa waktu henti.

Untuk semua berbagi file Azure / lokasi server yang perlu Anda konfigurasikan untuk sinkronisasi, ulangi langkah-langkah untuk membuat grup sinkronisasi dan menambahkan folder server yang cocok sebagai titik akhir server. Anda menggunakan Azure Data Box untuk memindahkan file Anda ke beberapa berbagi file Azure. Migrasi Anda selesai setelah Anda membuat semua titik akhir server yang menghubungkan data lokal Anda ke berbagi file Azure ini.

Langkah berikutnya

Masih banyak yang bisa ditemukan tentang Azure file shares dan Azure File Sync. Artikel berikut akan membantu Anda memahami opsi lanjutan dan praktik terbaik. Mereka juga memberikan bantuan pemecahan masalah. Artikel ini berisi tautan ke dokumentasi berbagi file Azure jika sesuai.

• Gambaran umum migrasi
• Perencanaan penyebaran Azure File Sync
• Membuat ruang berbagi file
• Memecahkan Masalah Azure File Sync