Azure Dosyaları veri yedekliliği

Azure Dosyalar verilerinizin her zaman birden çok kopyasını depolar; böylece geçici donanım hataları, ağ veya güç kesintileri ve doğal afetler gibi planlı ve plansız olaylardan korunur. Yedeklilik, depolama hesabınızın hatalar karşısında bile kullanılabilirlik ve dayanıklılık hedeflerini karşılamasını sağlar.

Senaryonuz için hangi yedeklilik seçeneğinin en uygun olduğuna karar verirken, düşük maliyetlerle daha yüksek kullanılabilirlik arasındaki dengeleri göz önünde bulundurun. Hangi yedeklilik seçeneğini belirlemenize yardımcı olan faktörler şunlardır:

Verilerinizin birincil bölgede nasıl çoğaltıldığı.
Verilerinizin coğrafi olarak birincil bölgeye uzak ikinci bir bölgeye çoğaltılıp çoğaltılmadığı, bölgesel olağanüstü durumlara (coğrafi olarak yedeklilik) karşı koruma sağlamak için.

Microsoft.Storage kaynak sağlayıcısıyla oluşturulan klasik Azure dosya paylaşımları , depolama hesabı olarak adlandırılan ortak bir Azure kaynağı üzerinden yönetilir. Depolama hesabı, dosya paylaşımlarını dağıtmak için kullanılabilecek paylaşılan bir depolama havuzunu temsil eder. Depolama hesapları hakkında daha fazla bilgi için bkz . Depolama hesabına genel bakış.

Depolama hesabı oluşturduğunuzda, bu hesabın kullanıma sunduğu tüm depolama hizmetleri için paylaşılan depolama hesabı için bir yedeklilik ayarı seçersiniz. Bu nedenle, aynı depolama hesabında dağıtılan tüm dosya paylaşımları aynı yedeklilik ayarına sahiptir. Farklı yedeklilik gereksinimleri varsa, dosya paylaşımlarını ayrı depolama hesaplarında yalıtmak isteyebilirsiniz.

Birincil bölgede yedeklilik

Azure depolama hesabındaki veriler her zaman birincil bölgede üç kez çoğaltılır. Azure Dosyalar, verilerinizin birincil bölgede nasıl çoğaltıldığına ilişkin iki seçenek sunar:

Yerel olarak yedekli depolama (LRS), depolama hesaplarınızdaki verileri seçtiğiniz birincil bölgede bulunan bir veya daha fazla kullanılabilirlik alanına çoğaltır. LRS en düşük maliyetli çoğaltma seçeneğidir ancak yüksek kullanılabilirlik veya dayanıklılık gerektiren uygulamalar için önerilmez.
Alanlar arası yedekli depolama (ZRS), verilerinizi birincil bölgedeki üç Azure kullanılabilirlik alanına zaman uyumlu olarak kopyalar. Yüksek kullanılabilirlik gerektiren uygulamalar için birincil bölgede ZRS kullanan ve verilerinizi ikincil bölgeye coğrafi olarak çoğaltan coğrafi alanlar arası yedekli depolama (GZRS) kullanmanızı öneririz.

Yerel olarak yedekli depolama

Yerel olarak yedekli depolama (LRS), depolama hesaplarınızdaki verileri seçtiğiniz birincil bölgede bulunan bir veya daha fazla Azure kullanılabilirlik alanına çoğaltır. Tercih ettiğiniz erişilebilirlik alanını seçemeseniz de, Azure yük dengesini artırmak için LRS hesaplarını bölgeler arasında taşıyabilir veya genişletebilir. LRS, belirli bir yıl boyunca nesnelerin en az 99.999999999% (11 9') dayanıklılık sağlar. Daha fazla bilgi için bkz. Azure kullanılabilirlik alanları nedir?

LRS, en düşük maliyetli yedeklilik seçeneğidir ve diğer seçeneklere kıyasla en az dayanıklılık sunar. LRS, verilerinizi sunucu rafı ve sürücü hatalarına karşı korur. Ancak, veri merkezinde yangın veya sel gibi bir olağanüstü durum oluşursa, LRS kullanan bir depolama hesabının tüm çoğaltmaları kaybolabilir veya kurtarılamaz. Bu riski azaltmak için ZRS, GRS veya GZRS kullanmanızı öneririz.

LRS kullanan bir depolama hesabına yazma isteği zaman uyumlu olarak gerçekleşir. Yazma işlemi, veriler üç kopya/replika üzerine yazıldıktan sonra ancak başarıyla tamamlanır.

Aşağıdaki diyagramda verilerinizin LRS ile tek bir veri merkezinde nasıl çoğaltıldığı gösterilmektedir:

LRS ile kullanılabilirlik alanlarında verilerin nasıl çoğaltıldığını gösteren diyagram.

LRS, aşağıdaki senaryolar için iyi bir seçimdir:

Uygulamanız, veri kaybı oluşursa kolayca yeniden oluşturulabilecek verileri depolarsa.
Uygulamanız, veri idaresi gereksinimleri nedeniyle yalnızca bir ülke veya bölge içinde verileri çoğaltmayla sınırlıysa. Bazı durumlarda, verilerin coğrafi olarak çoğaltıldığı eşleştirilmiş bölgeler başka bir ülkede veya bölgede olabilir. Daha fazla bilgi için bkz. Azure bölge çiftleri ve eşleşmemiş bölgeler.

LRS, HDD (standart) dosya paylaşımları için tüm Azure bölgelerinde desteklenir. SSD (premium) dosya paylaşımları için LRS'yi destekleyen bölgelerin listesi için bkz. SSD dosya paylaşımları için LRS desteği.

Alanlar arası yedekli depolama

Alanlar arası yedekli depolama (ZRS), depolama hesaplarınızdaki verileri seçtiğiniz birincil bölgede bulunan üç veya daha fazla Azure kullanılabilirlik alanına çoğaltır. Her kullanılabilirlik alanı bağımsız enerji, soğutma ve ağ altyapısına sahip olan ayrı bir fiziksel konumu ifade eder. ZRS, belirli bir yıl boyunca en az %99,99999999999 (12 9) depolama kaynakları için dayanıklılık sunar. Daha fazla bilgi için bkz. Azure kullanılabilirlik alanları nedir?

ZRS ile, bölge kullanılamaz duruma gelse bile verilerinize hem okuma hem de yazma işlemleri için erişilebilir durumda olur. Bir bölge kullanılamaz hale gelirse, Azure DNS yeniden yönlendirme gibi ağ güncellemeleri gerçekleştirir. Bu güncellemeler, güncellemeler tamamlanmadan önce verilere erişirseniz başvurunuzu etkileyebilir. ZRS için uygulamalar tasarlarken, üstel geri bekleme ile yeniden deneme ilkelerini uygulamak da dahil olmak üzere geçici hata işlemeye yönelik uygulamaları izleyin.

ZRS kullanan bir depolama hesabına yazma isteği zaman uyumlu olarak gerçekleşir. Yazma işlemi, veriler üç kullanılabilirlik alanındaki tüm çoğaltmalara yazıldıktan sonra ancak başarıyla tamamlanır.

Azure Dosyaları iş yükleri için ZRS kullanmanın bir avantajı, bir bölge kullanılamaz hale geldiğinde, bağlı istemcilerden Azure dosya paylaşımlarını yeniden bağlamanın gerekmemesidir. Yüksek kullanılabilirlik gerektiren senaryolar için birincil bölgede ZRS kullanmanızı öneririz. Veri idaresi gereksinimlerini karşılamak üzere belirli bir ülke veya bölgeye veri çoğaltmasını kısıtlamak için ZRS'yi de öneririz.

Uyarı

Azure Dosya Eşitleme, US Gov Virginia dışındaki kullanılabilirlik bölgelerini destekleyen tüm bölgelerde bölgesel yedekliliğe sahiptir. Çoğu durumda, Azure Dosya Eşitleme kullanıcıların depolama hesaplarını ZRS veya GZRS kullanacak şekilde yapılandırmalarını öneririz.

Aşağıdaki diyagramda verilerinizin ZRS ile birincil bölgedeki kullanılabilirlik alanları arasında nasıl çoğaltıldığı gösterilmektedir:

ZRS ile verilerin birincil bölgede nasıl çoğaltıldığını gösteren diyagram.

ZRS, verileriniz geçici olarak kullanılamaz duruma gelirse verileriniz için mükemmel performans, düşük gecikme süresi ve dayanıklılık sağlar. Ancak ZRS, verilerinizi birden çok bölgenin kalıcı olarak etkilendiği bölgesel olağanüstü durumlara karşı korumayabilir. Bölgesel afetlere karşı koruma için GZRS kullanmanızı öneririz.

Bölgeye göre ZRS desteği

ZRS hem SSD hem de HDD dosya paylaşımları için desteklenir. Her medya katmanı için ZRS'yi destekleyen bölgeleri görmek için aşağıdaki kaynaklara bakın:

HDD dosya paylaşımları: Azure bölgeleri listesindeki kullanılabilirlik alanı destek sütununa bakın.
SSD dosya paylaşımları: Bkz. SSD dosya paylaşımları için ZRS desteği.

İkincil bölgede yedeklilik

SMB dosya paylaşımları için yüksek dayanıklılık gerektiren uygulamalar için coğrafi olarak yedekli depolamayı seçerek depolama hesabınızdaki verileri birincil bölgeden yüzlerce mil uzaktaki ikincil bir bölgeye kopyalayabilirsiniz. Depolama hesabınız ikincil bir bölgeye kopyalanırsa, tam bölgesel kesinti veya birincil bölgenin kurtarılamayan bir olağanüstü durum söz konusu olduğunda bile verileriniz dayanıklıdır.

Önemli

Azure Dosyalar yalnızca HDD dosya paylaşımları için coğrafi olarak yedekliliği (GRS veya GZRS) destekler. SSD dosya paylaşımları LRS veya ZRS kullanmalıdır. Ayrıca, diğer Azure depolama hizmetlerinin aksine Azure Dosyalar, bir yük devretme işlemi başlatmadan ikincil bölgedeki verilere okuma erişimini desteklemez. RA-GRS ve RA-GZRS desteklenmiyor. Bir depolama hesabını RA-GRS veya RA-GZRS kullanacak şekilde yapılandırırsanız, o hesaptaki dosya paylaşımları otomatik olarak GRS veya GZRS olarak kabul edilir.

Depolama hesabı oluşturduğunuzda, hesabın birincil bölgesini seçersiniz. Eşleştirilmiş ikincil bölge birincil bölgeye göre belirlenir ve değiştirilemez. Azure tarafından desteklenen bölgeler hakkında daha fazla bilgi için bkz. Azure bölgeleri listesi.

Azure Dosyalar, verilerinizi ikincil bir bölgeye kopyalamak için iki seçenek sunar. Coğrafi yedekli depolama seçenekleri yalnızca HDD SMB dosya paylaşımları için mevcuttur.

Coğrafi yedekli depolama (GRS), verilerinizi birincil bölgede LRS kullanarak çoğaltır ve ardından asenkron olarak ikincil bir bölgeye kopyalar. Bkz. Coğrafi yedekli depolama.
Coğrafi bölge-yedekli depolama (GZRS), verilerinizi birincil bölgede ZRS kullanarak çoğaltır ve ardından asenkron olarak ikincil bir bölgeye kopyalar. Geo-zone-redundant depolama bölümüne bakınız.

Coğrafi olarak yedekli depolama

GRS, belirli bir yıl boyunca en az %99,99999999999999 (16 adet 9) dayanıklılık sunar.

Bir yazma işlemi önce birincil konuma kaydedilir ve LRS kullanılarak çoğaltılır. Güncelleştirme daha sonra ikincil bölgeye asenkron olarak kopyalanır. veriler ikincil konuma yazıldığında, LRS kullanılarak bu konumda da çoğaltılır.

Aşağıdaki diyagramda verilerinizin GRS ile nasıl çoğaltıldığı gösterilmektedir:

Verilerin GRS ile nasıl çoğaltıldığını gösteren diyagram.

Coğrafi alanlar arası yedekli depolama

Coğrafi alanlar arası yedekli depolama (GZRS), kullanılabilirlik alanları arasında yedeklilik tarafından sağlanan yüksek kullanılabilirliği coğrafi çoğaltma tarafından sağlanan bölgesel kesintilere karşı koruma ile birleştirir. GZRS depolama hesabındaki veriler, birincil bölgedeki üç Azure kullanılabilirlik alanına kopyalanır ve bölgesel olağanüstü durumlardan korunmak için ikincil coğrafi bölgeye de çoğaltılır. Olağanüstü durum kurtarma için maksimum tutarlılık, dayanıklılık ve kullanılabilirlik, mükemmel performans ve dayanıklılık gerektiren uygulamalar için GZRS kullanmanızı öneririz.

GZRS depolama hesabıyla, kullanılabilirlik alanı kullanılamaz duruma gelirse veya kurtarılamaz durumdaysa verileri okumaya ve yazmaya devam edebilirsiniz. Ayrıca, tam bir bölgesel kesinti veya birincil bölgenin kurtarılamaz olduğu bir olağanüstü durum söz konusu olduğunda verileriniz de dayanıklıdır. GZRS, belirli bir yıl boyunca en az %99,99999999999999 (16 adet 9) dayanıklılık sağlayacak şekilde tasarlanmıştır.

Aşağıdaki diyagramda verilerinizin GZRS ile nasıl çoğaltıldığı gösterilmektedir:

Verilerin GZRS ile nasıl çoğaltıldığını gösteren diyagram.

Bir bölgenin GZRS'yi desteklediğini belirlemek için Azure bölgeleri listesine bakın. GZRS'yi desteklemek için bir bölgenin kullanılabilirlik alanlarını desteklemesi ve eşleştirilmiş bir bölgeye sahip olması gerekir.

Coğrafi yedekli anlık görüntü ve senkronizasyon frekansı

Bir failover gerçekleştiğinde coğrafi yedekli ve coğrafi bölge yedekli dosya paylaşımlarının tutarlı durumda olmasını sağlamak için, birincil bölge her 15 dakikada bir sistem anlık görüntüsü oluşturur ve bunu ikincil bölgeye çoğaltır. İkincil bölgeye yük devretme gerçekleştiğinde, paylaşım durumu ikincil bölgedeki en güncel sistem anlık görüntüsüne dayanır. Coğrafi gecikme veya diğer sorunlar nedeniyle, ikincil bölgedeki en son sistem anlık görüntüsü 15 dakikadan eski olabilir.

Depolama hesabındaki Son Eşitleme Zamanı (LST) özelliği, birincil bölgedeki verilerin ikincil bölgeye en son ne zaman başarıyla yazıldığını gösterir. Azure Dosyalar için Son Eşitleme Zamanı, ikincil bölgedeki en son sistem anlık görüntüsünü temel alır. Depolama hesabının Son Eşitleme Zamanını denetlemek için PowerShell veya Azure CLI kullanabilirsiniz.

Son Eşitleme Zamanı özelliği hakkında aşağıdakilerin anlaşılması önemlidir:

Depolama hesabındaki Son Eşitleme Zamanı özelliği, arkadaki en uzak depolama hesabındaki hizmeti (Dosyalar, Bloblar, Tablolar, Kuyruklar) temel alır.
Depolama hesabında hiçbir değişiklik yapılmadıysa Son Eşitleme Zamanı güncelleştirilmez.
Dosya paylaşımı sayısı depolama hesabı başına 100'ü aşarsa, Son Eşitleme Zamanı hesaplaması zaman aşımına neden olabilir. Depolama hesabı başına 100'den az dosya paylaşımı önerilir.

Coğrafi olarak yedekli depolama için yük devretme hususları

GRS veya GZRS ile yük devretme gerçekleşmediği sürece dosya paylaşımlarına ikincil bölgede erişilemez. Birincil bölge kullanılamaz duruma gelirse, ikincil bölgeye geçmeyi seçebilirsiniz. Yük devretme işlemi, Azure Dosyalar tarafından sağlanan DNS girişini güncelleştirir, böylece ikincil uç nokta depolama hesabınız için yeni birincil uç nokta olur. Yük devretme işlemi sırasında verilerinize erişilemez. Yük devretme tamamlandıktan sonra yeni birincil bölgede verileri okuyup yazabilirsiniz. Yük devretme tamamlandıktan sonra ikincil bölge birincil bölge olur ve verileri yeniden okuyup yazabilirsiniz. Daha fazla bilgi için Azure Dosyalar olağanüstü durum kurtarma ve yük devretme konusuna bakın.

Önemli

Azure Dosyalar okuma erişimli coğrafi yedeklilik (RA-GRS) veya okuma erişimli coğrafi alan yedekliliği (RA-GZRS) desteklemez. Bir depolama hesabı RA-GRS veya RA-GZRS kullanacak şekilde yapılandırılmışsa, dosya paylaşımları GRS veya GZRS olarak yapılandırılır ve faturalandırılır.

Aşağıdaki öğeler, yedek bölgeye geçiş olasılığınızı etkileyebilir:

İkincil bölgede bir sistem anlık görüntüsü yoksa depolama hesabının yük devretmesi bloklanır.
Depolama hesabı 100.000'den fazla dosya paylaşımı içeriyorsa depolama hesabı yük devretmesi engellenir. Depolama hesabına yük devretme işlemi yapmak için bir destek isteği açın.
Dosya tanıtıcıları ve kiralamalar, yük devretme işleminde korunmaz, bu yüzden istemcilerin dosya paylaşımlarını kaldırıp yeniden bağlamaları gerekir.
Yük devretme işlemi sonrasında dosya paylaşım kotası değişebilir. İkincil bölgedeki dosya paylaşımı kotası, sistem anlık görüntüsü birincil bölgede alındığında yapılandırılan kotayı temel alır.
Bir yük devretme gerçekleştiğinde devam eden kopyalama işlemleri iptal edilir. İkincil bölgeye yük devretme tamamlandığında kopyalama işlemini yeniden deneyin.

Depolama hesabına yük devretme yapmak için bkz. Hesap yük devretmesi başlatma.

Uyarı

Coğrafi olarak yedekli depolama ile Azure Dosyaları kullanılırken, dizin sorguları yük devretmeden sonra daha yüksek gecikme süresiyle karşılaşabilir. Bu, birincil ve ikincil depolama arasında eşitleme sırasında, özellikle birden çok dosyaya veya birden çok anlık görüntüye sahip paylaşımlara sahip dizinler için oluşabilir. Önbellek dizini altında çok sayıda dosyanız varsa, eşitleme tamamlanana kadar bazı performans düşüşleri gözlemleyebilirsiniz. Bazı durumlarda, eşitleme sonrasında bile performans etkisi devam edebilir.

SSD dosya paylaşımları için coğrafi yedeklilik

Daha önce belirtildiği gibi, SSD dosya paylaşımları için coğrafi olarak yedeklilik seçenekleri (GRS ve GZRS) desteklenmez. Ancak coğrafi olarak yedekliliği başka yollarla da elde edebilirsiniz.

Azure Dosya Eşitleme senaryolar için Azure dosya paylaşımınız (bulut uç noktanız), şirket içi bir Windows dosya sunucusu ve başka bir Azure bölgesindeki bir sanal makinede çalışan bağlı dosya paylaşımı (olağanüstü durum kurtarma amacıyla sunucu uç noktanız) arasında eşitleme yapabilirsiniz. Tüm verilerin yerel olarak mevcut olduğundan emin olmak ve Azure VM'de veri kümesinin tamamını barındıracak kadar depolama alanı sağlamak için bulut katmanlama özelliğini devre dışı bırakmanız gerekir. Değişikliklerin ikincil bölgeye hızla çoğaltılacağından emin olmak için dosyalara Azure yerine yalnızca sunucu uç noktasında erişilmesi ve değiştirilmesi gerekir.

AzCopy gibi araçları kullanarak (ACL'leri ve zaman damgalarını korumak için sürüm 10.4 veya üzerini kullanın) verileri ikincil bölgedeki bir depolama hesabına kopyalamak için kendi betiğinizi de oluşturabilirsiniz.

Yedeklilik seçeneklerinin özeti

Aşağıdaki bölümlerde yer alan tablolarda, Azure Dosyalar için kullanılabilir olan yedeklilik seçenekleri özetlenmiştir.

Azure Dosyalar dayanıklılık ve erişilebilirlik parametreleri

Aşağıdaki tabloda, her yedeklilik seçeneği için anahtar parametreler açıklanmaktadır:

Parametre	LRS (Öğrenme Kayıt Deposu)	ZRS	GRS	GZRS
Belirli bir yıl boyunca dayanıklılık yüzdesi	En az %99,9999999999 (11 tane 9 rakamı)	en az %99,99999999999 (12 adet 9)	en az %99,999999999999999 (16 adet 9)	en az %99,999999999999999 (16 adet 9)
Okuma istekleri için kullanılabilirlik	En az %99,9 (Cool katmanı için %99)	En az %99,9 (Cool katmanı için %99)	En az %99,9 (Cool katmanı için %99)	En az %99,9 (Cool katmanı için %99)
Yazma istekleri için kullanılabilirlik	En az %99,9 (Cool katmanı için %99)	En az %99,9 (Cool katmanı için %99)	En az %99,9 (Cool katmanı için %99)	En az %99,9 (Cool katmanı için %99)
Ayrı düğümlerde tutulan verilerin kopya sayısı	Bir bölge içindeki bir veya daha fazla kullanılabilirlik alanında üç kopya	Tek bir bölgedeki ayrı kullanılabilirlik alanlarında üç kopya	Üçü birincil bölgede, üçü ikincil bölgede olmak üzere toplam altı kopya	Birincil bölgedeki ayrı kullanılabilirlik alanlarında üç ve ikincil bölgede yerel olarak yedekli üç kopya dahil olmak üzere toplam altı kopya

Daha fazla bilgi için Depolama Hesapları için SLA'ya bakın.

Kesinti senaryosuna göre Azure Dosyalar dayanıklılığı ve kullanılabilirliği

Aşağıdaki tabloda, depolama hesabınız için geçerli olan yedeklilik türüne bağlı olarak verilerinizin dayanıklı olup olmadığı ve belirli bir senaryoda kullanılabilir olup olmadığı gösterilir. Azure Dosyalar, yük devretme gerçekleşmedikçe, birincil bölge kullanılamaz hale geldiğinde ikincil bölgeye okuma erişimini desteklemez.

Kesinti senaryosu	LRS (Öğrenme Kayıt Deposu)	ZRS	GRS	GZRS
Veri merkezindeki bir düğüm kullanılamaz duruma gelir	Evet	Evet	Evet	Evet
Veri merkezinin tamamı (bölgesel veya bölgesel olmayan) kullanılamaz duruma gelir	Hayır	Evet	Evet¹	Evet
Birincil bölgede bölge genelinde bir kesinti oluşur	Hayır	Hayır	Evet¹	Evet¹

¹ Birincil bölge kullanılamaz duruma gelirse, yazma kullanılabilirliğini geri yüklemek için hesap yük devretme işlemi gereklidir.

Her yedeklilik seçeneğine ilişkin fiyatlandırma bilgileri için bkz Azure Dosyalar fiyatlandırması.

Farklı faturalama modellerini temel alan bölge desteklenebilirliği

Aşağıdaki komutları kullanarak çeşitli faturalama modelleri için bölge desteklenebilirliğini doğrulayabilirsiniz.

Farklı faturalama modellerine göre bölge desteklenebilirliğini görüntülemek için Azure PowerShell veya Azure CLI kullanın.

# Login
Connect-AzAccount
# (Optional but recommended if you have multiple subs)
# Set-AzContext -Subscription $subscriptionID

$subscriptionID = "your-subscription-id-number"

# Get token (output is now SecureString by default, see https://learn.microsoft.com/powershell/module/az.accounts/get-azaccesstoken)
$secureToken = (Get-AzAccessToken).Token  # SecureString now

# Convert SecureString -> plaintext (Az 14 migration pattern)
$ssPtr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secureToken)
try {
    $plainToken = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ssPtr)
}
finally {
    [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($ssPtr)
}

# Call List SKUs
$uri = "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2025-08-01"
$headers = @{ Authorization = "Bearer $plainToken" }

$result = Invoke-RestMethod -Method Get -Uri $uri -Headers $headers

$filteredResult = $result | `
    Select-Object -ExpandProperty value | `
    Where-Object {
        $_.resourceType -eq "storageAccounts" -and
        # Filter based on your needs. FileStorage account kind includes Pv2 and Pv1 file share, where StorageV2 kind includes PayGO file shares.
        $_.kind -in @("FileStorage", "StorageV2") -and
        # Filter based on your needs. "Standard_" for PayGO file share, "StandardV2_" for Pv2 file share, "Premium_" for Pv1 file shares.
        # $_.name.StartsWith("StandardV2_") -and
        # Change region based on your need to see if the region is currently supported (all lowercase, no space in between).
        # $_.locations -eq "italynorth" -and
        $_.name -notin @("Standard_RAGRS", "Standard_RAGZRS")
    }

if ($filteredResult.Count -eq 0) {
    Write-Output "No results found."
} else {
    $filteredResult | `
        Select-Object `
            -Property `
                @{
                    Name = "sku";
                    Expression = { $_.name }
                }, `
                kind, `
                @{
                    Name = "mediaTier";
                    Expression = {
                        if ($_.tier -eq "Premium") {
                            "SSD"
                        } elseif ($_.tier -eq "Standard") {
                            "HDD"
                        } else {
                            "Unknown"
                        }
                    }
                }, `
                @{
                    Name = "billingModel";
                    Expression = {
                        if ($_.name.StartsWith("StandardV2_") -or
                            $_.name.StartsWith("PremiumV2_")
                        ) {
                            "ProvisionedV2"
                        } elseif ($_.name.StartsWith("Premium_")) {
                            "ProvisionedV1"
                        } else {
                            "PayAsYouGo"
                        }
                    }
                }, `
                @{
                    Name = "location";
                    Expression = { $_.locations | Select-Object -First 1 }
                } | ft sku, kind, mediaTier, billingModel, location
}

Bu betik, komut satırı JSON işlemcisi olan jq'yi kullanır. İndirmek için https://jqlang.org/download/ ziyaret edin

# Login to Azure account
az login

# Track down the subscription ID in GUID format and set subscription ID
subscriptionID="your-subscription-id-number"

# Get Token
token=$(az account get-access-token --query accessToken --output tsv)

# Invoke SRP list SKU API, and get the returned SKU list
result=$(az rest --method get --uri "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2025-08-01" --headers "Authorization=Bearer $token")

# Filter the SKU list to get the required information, customization required here to get the best result.
filteredResult=$(echo $result | jq '.value[] | select(.resourceType == "storageAccounts" and (.kind == "FileStorage" or .kind == "StorageV2") and (.name | test("^(?!Standard_RAGRS|Standard_RAGZRS)")))' )

if [ -z "$filteredResult" ]; then
    echo "No results found."
else
    # Print the table header
    printf "%-30s %-15s %-10s %-20s %-15s\n" "SKU" "Kind" "MediaTier" "BillingModel" "Location"
    # Print the filtered results
    echo $filteredResult | jq -r '. | "\(.name)\t\(.kind)\t\(.tier | if . == "Premium" then "SSD" elif . == "Standard" then "HDD" else "Unknown" end)\t\(.name | if test("^StandardV2_|^PremiumV2_") then "ProvisionedV2" elif test("^Premium_") then "ProvisionedV1" else "PayAsYouGo" end)\t\(.locations)"' | while IFS=$'\t' read -r sku kind mediaTier billingModel location; do
        printf "%-30s %-15s %-10s %-20s %-15s\n" "$sku" "$kind" "$mediaTier" "$billingModel" "$location"
    done
fi

Ayrıca bkz.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-07-17