Azure Files ve Azure File Sync ile Hibrit Dosya Sunucusu

Diski dolan dosya sunucusunun klasik çözümü yeni disk almaktır; verinin büyük kısmı yıllardır açılmıyorsa bu para rafta duran dosyalara gider. Bazı veriler de SMB paylaşımından vazgeçemez: UNC yolu bekleyen uygulamalar, büyük CAD ve medya dosyaları, ERP ekleri ya da NTFS izin yapısına dayanan iş akışları. Bu veriyi SharePoint’e zorlamak yerine dosya sunucusunu koruyup depolamayı Azure’a genişletmek mümkündür. Aşağıda Azure Files ve Azure File Sync mimarisini, cloud tiering ayarlarını, kimlik doğrulama seçeneklerini, kurulum adımlarını ve şube ile felaket senaryolarını sahadaki tuzaklarıyla birlikte anlatıyoruz.

Hibrit dosya hizmeti ne zaman doğru seçim

Azure File Sync şu durumlarda güçlü bir seçenektir:

• Dosya sunucusunun diski doluyor, ama verinin çoğu nadiren açılıyor.
• Birden fazla şubede aynı veriye yerel hızla erişim gerekiyor ve DFS Replication’ın işletim yükünden kurtulmak isteniyor.
• Sunucu donanımı arızalandığında verinin yeni bir sunucuda dakikalar içinde erişilebilir olması isteniyor.
• Uygulamalar UNC yolu ve NTFS izinleri bekliyor; SharePoint’e taşıma uygulama değişikliği gerektiriyor.

Ekip dokümanları, birlikte düzenleme ve dış paylaşım ihtiyacı ağır basıyorsa hedef SharePoint ve OneDrive’dır. Bu ayrımı veri türüne göre yapmak için dosya sunucusundan SharePoint ve OneDrive’a göç planı rehberindeki karar tablosunu kullanabilirsiniz. İki yaklaşım aynı kurumda yan yana çalışır.

Azure Files ve Azure File Sync bileşenleri

Azure Files, bir depolama hesabı (storage account) içinde SMB ve NFS protokolleriyle erişilen yönetilen dosya paylaşımıdır. Azure File Sync ise bu paylaşımı şirket içi sunucu altyapısındaki Windows Server’larla eşitleyen ve isteğe bağlı olarak sunucuyu önbelleğe dönüştüren hizmettir.

Kurulumdan önce bilinmesi gereken kurallar:

• Bir sync group’ta tam olarak bir cloud endpoint, bir veya daha fazla server endpoint bulunur; her server endpoint farklı bir sunucuda olmalıdır.
• Bir sunucu yalnız bir Storage Sync Service’e kaydedilebilir.
• Aynı sunucudaki farklı klasörler farklı sync group’larda yer alabilir; ancak server endpoint’ler iç içe olamaz.
• Eşitleme sunucu ile Azure arasında HTTPS (443) üzerinden yapılır; 445 portu gerekmez.
• NTFS ACL’leri Azure dosya paylaşımında korunur.

Doğrudan Azure dosya paylaşımında yapılan değişiklikler sunuculara anında değil, bulut tarafındaki değişiklik algılama işiyle (en geç 24 saatte bir) yansır. Sahada sık karşılaşılan şikâyet “dosyayı Azure’a koydum, sunucuda görünmüyor” şeklindedir ve sebebi budur. Kullanıcılar sunucu üzerinden çalışmalı; betik ve uygulamalar Azure paylaşımına doğrudan yazmamalıdır.

Cloud tiering nasıl çalışır, nasıl ayarlanır

Cloud tiering açıldığında sunucu tüm veriyi tutan bir depo olmaktan çıkar, sık kullanılan verinin önbelleğine dönüşür. Katmanlanan (tiered) dosyanın içeriği yalnız Azure’da kalır; sunucuda dosya adı, boyutu, zaman damgaları ve ACL’leri taşıyan bir reparse point bulunur. Kullanıcı dosyayı açtığında içerik Azure’dan geri çağrılır (recall). Kullanıcı farkı çoğu zaman yalnız ilk açılıştaki gecikmede görür.

İki politika birlikte çalışır:

• Birim boş alan politikası: Birimde hedeflenen boş alan yüzdesi. Örnek: %20 ayarlanırsa, birim %80 dolduğunda en az erişilen dosyalar katmanlanmaya başlar. Bu politika her zaman tarih politikasından önceliklidir.
• Tarih politikası: Belirtilen gün sayısından uzun süredir erişilmeyen dosyalar, boş alan olsa bile katmanlanır.

Ayar seçerken sahada karşımıza çıkanlar:

• Sistem biriminde cloud tiering desteklenmez; veriyi ayrı bir NTFS birimine koyun.
• Boş alan yüzdesini düşük seçmek sunucuda daha fazla veri tutar, ama ani büyük kopyalamalarda birimin dolma riskini artırır.
• Antivirüs ve indeksleme yazılımlarının katmanlanmış dosyaları (offline özniteliği) okumaya çalışması toplu geri çağırmaya yol açar. Yazılımın bu dosyaları atladığını doğrulayın; tam tarama gecesi WAN hattının dolması tipik belirtidir.
• Sunucu tarafında dosya düzeyinde yedek alan yazılımlar katmanlanmış dosyaları geri çağırabilir. Yedeği Azure dosya paylaşımı üzerinden Azure Backup ile almak bu sorunu ortadan kaldırır.

Belirli bir klasörün yerel diskte hazır olması gerekiyorsa agent ile gelen sunucu cmdlet’i kullanılır:

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -Path "D:\Paylasim\Proje-2025"

Kimlik doğrulama: AD DS ile Azure Files

Kullanıcılar şirket içindeki sunucu üzerinden eriştiği sürece kimlik doğrulamayı sunucunun bağlı olduğu Active Directory yapar; ek yapılandırma gerekmez. Azure dosya paylaşımına doğrudan erişim (Azure’daki bir sanal sunucudan veya felaket anında) isteniyorsa kimlik tabanlı erişim yapılandırılır:

• AD DS: Depolama hesabı, AzFilesHybrid PowerShell modülündeki Join-AzStorageAccount ile şirket içi AD’ye bir bilgisayar hesabı veya hizmet oturum açma hesabı olarak kaydedilir. Kullanıcı hesaplarının Entra ID’ye senkronize olması gerekir.
• Microsoft Entra Kerberos: Hibrit kimlikler için, istemcilerin etki alanı denetleyicisine görüş hattı olmadan erişebildiği seçenek.

Yetkilendirme iki katmanlıdır. Paylaşım düzeyinde Azure RBAC rolleri atanır: Storage File Data SMB Share Reader, Storage File Data SMB Share Contributor ve Storage File Data SMB Share Elevated Contributor. Dizin ve dosya düzeyinde mevcut NTFS ACL’leri geçerlidir. Kurumların çoğu paylaşım düzeyinde geniş bir rol verip asıl kısıtlamayı NTFS ile yapar; bu, dosya sunucusundaki alışılmış modelle uyumludur.

AD DS kaydında unutulan nokta, depolama hesabı için AD’de oluşan bilgisayar hesabının parola süresidir. Etki alanı parola ilkesi bu hesabın parolasını döndürmeyi gerektiriyorsa ve döndürülmezse, Kerberos kimlik doğrulaması bir gün sessizce durur. Hesabın hangi OU’da durduğunu ve parola yönetimini kayıt anında belgeleyin.

Kurulum adımları ve ilk senkronizasyon

1. Depolama hesabını ve dosya paylaşımını oluşturun. Bölge seçiminde sunucuya ağ yakınlığını ve yedek bölge ihtiyacını dikkate alın.
2. Storage Sync Service kaynağını aynı bölgede oluşturun.
3. Her dosya sunucusuna Azure File Sync agent’ını kurun; desteklenen Windows Server sürümlerini agent sürüm notlarından doğrulayın.
4. Sunucuyu kaydedin, sync group’u ve uç noktaları oluşturun.

Az.StorageSync modülüyle örnek akış:

$rg  = "rg-dosya"
$sss = "sss-merkez"
New-AzStorageSyncService -ResourceGroupName $rg -Name $sss -Location "westeurope"

# Dosya sunucusunda çalıştırılır
$srv = Register-AzStorageSyncServer -ResourceGroupName $rg -StorageSyncServiceName $sss

New-AzStorageSyncGroup -ResourceGroupName $rg -StorageSyncServiceName $sss -Name "sg-ortak"

$sa = Get-AzStorageAccount -ResourceGroupName $rg -Name "stdosyamerkez"
New-AzStorageSyncCloudEndpoint -ResourceGroupName $rg -StorageSyncServiceName $sss `
  -SyncGroupName "sg-ortak" -Name "ce-ortak" `
  -StorageAccountResourceId $sa.Id -AzureFileShareName "ortak"

New-AzStorageSyncServerEndpoint -ResourceGroupName $rg -StorageSyncServiceName $sss `
  -SyncGroupName "sg-ortak" -Name "se-fs01-ortak" `
  -ServerResourceId $srv.ResourceId -ServerLocalPath "D:\Paylasim\Ortak" `
  -CloudTiering -VolumeFreeSpacePercent 20 -TierFilesOlderThanDays 90

Bu örnekteki %20 boş alan ve 90 günlük tarih politikası yalnız örnek değerlerdir; kendi erişim profilinize göre belirleyin. İlk senkronizasyonda mevcut veri sunucudan Azure’a yüklenir. Büyük veri setlerinde ilk yükleme günler sürebilir; bu sürede kullanıcılar sunucuda çalışmaya devam eder. Agent’ın ağ kısıtlama (network limit) ayarıyla mesai saatlerinde kullanılacak bant genişliğini sınırlayın, yoksa ilk sabah internet hattı şikâyeti gelir.

Doğrulama için Azure portalında sync group’un sağlık durumunu ve eşitlenemeyen öğe (per-item error) sayısını izleyin; sunucuda Olay Görüntüleyicisi’nde Applications and Services Logs\Microsoft\FileSync\Agent günlüklerine bakın. Uzun yollar, geçersiz karakterler ve açık kilitli dosyalar en sık görülen eşitleme hatalarıdır. Hata sayısı sıfıra inmeden tiering’e güvenmeyin.

Şube ve felaket senaryoları

Şube önbelleği

Merkez ve şubelerdeki sunucular aynı sync group’a server endpoint olarak eklenir. Her şube kullandığı veriyi yerel diskte tutar, geri kalanı katmanlanır. Bu yapı DFS Replication’daki tam kopya gereksinimini ortadan kaldırır. Ancak eşzamanlı düzenlemede kilitleme yoktur: iki şubede aynı dosya aynı anda değiştirilirse çakışma oluşur ve dosyalardan biri sunucu adı eklenmiş bir kopya olarak saklanır. Aynı dosyalar üzerinde yoğun eşzamanlı çalışan ekipler için bu davranışı önceden değerlendirin. Mevcut DFS yapınızla karşılaştırma için DFS Namespace ve DFS Replication tasarımı yazısına bakabilirsiniz.

Sunucu değişimi ve hızlı geri dönüş

Sunucu arızalandığında veri Azure’da olduğu için geri dönüş şu adımlarla yapılır:

1. Yeni Windows Server kurulur, veri birimi hazırlanır ve agent yüklenir.
2. Sunucu aynı Storage Sync Service’e kaydedilir.
3. Server endpoint oluşturulurken ilk indirme politikası NamespaceOnly seçilir (-InitialDownloadPolicy NamespaceOnly). Önce yalnız klasör ve dosya ad alanı iner; dosyalar kullanıcılar açtıkça geri çağrılır.
4. Paylaşımlar ve paylaşım izinleri yeniden oluşturulur; DFS Namespace kullanılıyorsa hedef yeni sunucuya çevrilir.

Kullanıcılar verinin tamamının geri yüklenmesini beklemeden çalışmaya başlar. Yine de Azure File Sync bir yedekleme çözümü değildir: silinen veya fidye yazılımıyla şifrelenen dosya Azure’a da eşitlenir. Eşitleme hatayı da kopyalar. Azure dosya paylaşımı için anlık görüntü ve Azure Backup politikası tanımlayın; genel yedek stratejisini 3-2-1-1-0 yedekleme kuralı çerçevesinde kurun.

SharePoint göçü ile karşılaştırma

Hibrit dosya hizmetinin tasarımı ve işletimi için sunucu ve bulut yönetimi hizmetimize bakabilirsiniz. Planlama ayrıntıları ve sınırlar için Microsoft’un Azure File Sync planlama dokümanı esas alınmalıdır.

Sık sorulan sorular

Azure File Sync için 445 portunu internete açmak gerekir mi?

Hayır. Azure File Sync agent’ı Azure ile HTTPS (443) üzerinden konuşur. Kullanıcılar şirket içindeki Windows sunucusuna SMB ile bağlanmaya devam eder. 445 portu yalnız istemcilerin Azure dosya paylaşımını doğrudan bağlaması isteniyorsa gerekir.

Cloud tiering açıkken yedekleme nasıl yapılmalı?

Katmanlanmış dosyaların içeriği sunucuda olmadığı için sunucu tarafında dosya düzeyinde yedek almak dosyaları geri çağırabilir. Önerilen yol, Azure dosya paylaşımını bulut tarafında Azure Backup ile yedeklemektir. Sunucu tarafında yedek alınacaksa yazılımın katmanlamayı tanıdığı doğrulanmalıdır.

Bir sunucu birden fazla Storage Sync Service’e kaydedilebilir mi?

Hayır. Bir sunucu aynı anda yalnız bir Storage Sync Service’e kaydedilebilir. Aynı sunucu, o hizmet içindeki farklı sync group’larda farklı klasörlerle yer alabilir.

Azure File Sync, SharePoint göçünün yerine geçer mi?

Amaçları farklıdır. Azure File Sync, SMB ve NTFS izin modelini koruyarak depolamayı buluta genişletir. SharePoint ise birlikte düzenleme, sürümleme ve Teams entegrasyonu sunan bir doküman yönetim platformudur. Uygulamaya bağlı veya büyük dosyalı veri için File Sync, ekip dokümanları için SharePoint daha uygundur.