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.

Şunun için geçerlidir:

Yönetim modeli	Faturalama modeli	Medya katmanı	Yedeklilik
Microsoft.Storage	Sağlanan versiyon 2	SSD (üst düzey)	Yerel (LRS)
Microsoft.Storage	Sağlanan versiyon 2	SSD (üst düzey)	Bölge (ZRS)
Microsoft.Storage	Sağlanan versiyon 2	HDD (standart)	Yerel (LRS)
Microsoft.Storage	Sağlanan versiyon 2	HDD (standart)	Bölge (ZRS)
Microsoft.Storage	Sağlanan versiyon 2	HDD (standart)	Coğrafi (GRS)
Microsoft.Storage	Sağlanan versiyon 2	HDD (standart)	GeoZone (GZRS)
Microsoft.Storage	Tahsis edilen v1	SSD (üst düzey)	Yerel (LRS)
Microsoft.Storage	Tahsis edilen v1	SSD (üst düzey)	Bölge (ZRS)
Microsoft.Storage	Kullandıkça ödeme yap	HDD (standart)	Yerel (LRS)
Microsoft.Storage	Kullandıkça ödeme yap	HDD (standart)	Bölge (ZRS)
Microsoft.Storage	Kullandıkça ödeme yap	HDD (standart)	Coğrafi (GRS)
Microsoft.Storage	Kullandıkça ödeme yap	HDD (standart)	GeoZone (GZRS)

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 kullanılabilirlik alanını seçme seçeneği olmasa da Azure, yük dengelemeyi geliştirmek 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 dokuz) dayanıklılığını sağlar. Kullanılabilirlik alanı güvenilirliği hakkında daha fazla bilgi edinmek için Azure kullanılabilirlik alanları nedir ? makalesini ziyaret edin.

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 dosya paylaşımları için tüm Azure bölgelerinde desteklenir. SSD 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 9s) depolama kaynakları için dayanıklılık sunar. Kullanılabilirlik alanı güvenilirliği hakkında daha fazla bilgi edinmek için Azure kullanılabilirlik alanları nedir ? makalesini ziyaret edin.

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 duruma gelirse Azure, DNS yeniden belirleme gibi ağ güncelleştirmelerini üstlenir. Bu güncelleştirmeler, güncelleştirmeler tamamlanmadan önce verilere erişirsen uygulamanızı 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

Standart dosya paylaşımları için ZRS'yi hangi bölgelerin desteklediğini anlamak için Azure bölgeleri listesine bakın ve kullanılabilirlik alanı destek sütununa bakın. ZRS, tüm üç standart katman için standart genel amaçlı v2 depolama hesaplarında desteklenir: işlem odaklı, sık erişimli ve seyrek erişimli.

FileStorage türü depolama hesabı aracılığıyla SSD dosya paylaşımları için ZRS desteklenir. SSD dosya paylaşımı hesapları için ZRS'yi destekleyen bölgelerin listesi için 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.

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. Şu anda coğrafi olarak yedekli depolama seçenekleri yalnızca standart SMB dosya paylaşımları için kullanılabilir.

Coğrafi olarak yedekli depolama (GRS), LRS kullanarak birincil bölgedeki bir veya daha fazla Azure kullanılabilirlik alanında verilerinizi zaman uyumlu olarak üç kez kopyalar. Ardından verilerinizi zaman uyumsuz şekilde ikincil bölgedeki tek bir fiziksel konuma kopyalar. İkincil bölgede verileriniz, LRS kullanılarak zaman uyumlu olarak üç kez kopyalanır.
Coğrafi alanlar arası yedekli depolama (GZRS), ZRS kullanarak verilerinizi birincil bölgedeki üç Azure kullanılabilirlik alanına zaman uyumlu olarak kopyalar. Ardından verilerinizi zaman uyumsuz şekilde ikincil bölgedeki tek bir fiziksel konuma kopyalar. İkincil bölgede verileriniz, LRS kullanılarak zaman uyumlu olarak üç kez kopyalanır.

GRS ile GZRS arasındaki birincil fark, verilerin birincil bölgede nasıl çoğaltıldığıdır. İkincil bölge içinde veriler her zaman LRS kullanılarak üç kez zaman uyumlu olarak çoğaltılır. İkincil bölgedeki LRS, verilerinizi donanım hatalarına karşı korur.

Coğrafi olarak yedekli depolama

Coğrafi olarak yedekli depolama (GRS), LRS kullanarak birincil bölgedeki bir veya daha fazla Azure kullanılabilirlik alanında verilerinizi zaman uyumlu olarak üç kez kopyalar. Ardından verilerinizi zaman uyumsuz olarak birincil bölgeden yüzlerce mil uzaktaki ikincil bir bölgedeki tek bir fiziksel konuma kopyalar. 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 desteklenip desteklemediğini belirlemek için bkz. GZRS'yi destekleyen Azure bölgeleri. GZRS'yi desteklemek için bir bölgenin kullanılabilirlik alanlarını desteklemesi ve eşleştirilmiş bir bölgeye sahip olması gerekir.

Anlık görüntü ve eşitleme sıklığı

Coğrafi ve GeoZone yedekli dosya paylaşımlarının yük devretme gerçekleştiğinde tutarlı bir durumda olduğundan emin olmak için, birincil bölgede her 15 dakikada bir bir sistem anlık görüntüsü oluşturulur ve ikincil bölgeye çoğaltılı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.

Yük devretme konusunda dikkat edilmesi gerekenler

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.

Dayanıklılık ve kullanılabilirlik 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 dayanıklılık ve kullanılabilirlik

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 to Azure account
Connect-AzAccount

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

# Get Token
$token = Get-AzAccessToken

# Invoke SRP list SKU API, and get the returned SKU list
$result = Invoke-RestMethod -Method Get -Uri "https://management.azure.com/subscriptions/$($subscriptionID)/providers/Microsoft.Storage/skus?api-version=2024-01-01" -Headers @{"Authorization" = "Bearer $($token.Token)"}

# Filter the SKU list to get the required information, customization required here to get the best result.
$filteredResult = $result | `
    Select-Object -ExpandProperty value | `
    Where-Object {
        $_.resourceType -eq "storageAccounts" -and
        # Filter based on your needs. FileStorage kind includes pv2, and pv1 file share, where StorageV2 kind include 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 we currently support the region (all small cases, 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=2024-01-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 2025-09-10