Yedeklilik, çoğaltma ve yedekleme nedir?

Bulutu genellikle küresel olarak dağıtılmış, yaygın bir sistem olarak düşünüyoruz. Ancak gerçekte bulut, veri merkezlerinde çalışan donanımlardan oluşur. Dayanıklılık, bulutta barındırılan bileşenlerinizin çalıştırıldığı fiziksel konumlarla ilişkili risklerden bazılarını hesaba ayırmanızı gerektirir.

Bu makale, hizmet kesintisine, kesintiye veya veri kaybına neden olan fiziksel risklere dayanıklı iş yükleri oluşturmak için kullanılan yöntemler olan yedeklilik, çoğaltma ve yedeklemeye genel bir giriş sağlar.

Yedeklilik, bir hizmet bileşeninin birden çok özdeş kopyasına sahip olma ve bu kopyaları, herhangi bir bileşenin bir hata noktası haline gelmesini önleyecek şekilde kullanma özelliğidir.

Çoğaltma veya veri yedekliliği , çoğaltma olarak adlandırılan birden çok veri kopyasını koruyabilme özelliğidir.

Yedekleme , kaybolan verileri geri yüklemek için kullanılabilecek verilerin zaman damgalı bir kopyasını koruyabilme özelliğidir.

Güvenilirlik açısından bakıldığında, birçok riski azaltmanın önemli bir yolu , iş sürekliliği planlamanıza bir tür yedeklilik, çoğaltma veya yedekleme eklemektir.

Uyarı

Bu makale, tek tek Azure hizmetleri hakkında tasarım kılavuzu veya ayrıntılı bilgi sağlamaz. Belirli Azure hizmetlerinin güvenilirlik açısından nasıl çalıştığı hakkında bilgi için her hizmetin güvenilirlik kılavuzuna bakın.

Yedeklilik

Yedeklilik, bir bileşenin birden çok örneğinin dağıtılmasından oluşur. Yedekliliği anlamak kolay olsa da, bazı durumlarda uygulaması karmaşık hale gelebilir.

Yedekliliği anlamaya başladığınızda, veri depolamayan bileşenler olan durum bilgisi olmayan bileşenlerle ilgili olarak yedekliliği göz önünde bulundurmak en kolayıdır. Gerçek dünya çözümlerinin çoğu durum yönetimi gerektirse de, bu bölümde, yedekliliği durum bilgisi olmayan uygulama programlama arabirimi (API) açısından ele alıyoruz. Örnek API girişi kabul eder, bu giriş üzerinde çalışır ve veri depolamadan bir çıkış döndürür. Sonraki bölümde, Çoğaltma: Veriler için yedeklilik bölümünde durum bilgisi içeren yedeklilik üzerinde durmamız gereken noktalar ekleyeceğiz.

Senaryo: Durum bilgisi olmayan yedeklilik

Bu örnekte, durum bilgisi olmayan bir API bileşeni sanal makineye dağıtılır. Fiziksel konakta bir donanım hatası varsa API bileşeninin kapalı kalma süresini önlemek için örnek, aşağıdakilere sahip yedekli bir çözüm uygular:

• API örneğinin birden çok kopyasını dağıtır.
• İstekleri API örnekleri arasında dağıtmak için bir yük dengeleyici uygular.

Yük dengeleyici, yalnızca iyi durumdaki örneklere istek göndermek için her örneğin durumunu izler.

Yedeklilik konusunda dikkat edilmesi gerekenler

Yukarıdaki senaryoda olduğu gibi yedekli çözümler uygularken aşağıdakileri göz önünde bulundurmak önemlidir:

• Kaynak maliyetleri. Tanım gereği yedeklilik, bir şeyin birden çok kopyasına sahip olmayı içerir ve bu da çözümü barındırmak için toplam maliyeti artırır.

• Performans. Öğelerin kopyalarını ne kadar geniş bir coğrafi alan dağıtırsanız, azaltmaya yardımcı olduğunuz riskler de o kadar fazla olur. Ancak, istemcilerden gelen isteklerin daha uzun mesafelere gitmesi daha uzun sürer çünkü daha fazla ağ altyapısından geçmeleri gerekir ve bu da ağ gecikme süresini artırır.

  Gerçek dünya durumlarının çoğunda ağ gecikme süresi, bir veri merkezi içinde veya hatta bir şehir genelindeki veri merkezleri arasında gitme gibi kısa mesafeler için önemsizdir. Ancak kopyaları uzun bir mesafeye dağıtırsanız ağ gecikme süresi daha önemli hale gelebilir.

• Örneklerin tutarlılığı. Örneklerin birbiriyle tutarlı tutulması ve örneklerin tek tek yapılandırılmasını önlemek önemlidir çünkü örnekler arasında yanlışlıkla farklar ortaya çıkabilir. Örnekler arasında farklar varsa istekler, hangi örneğin onlara hizmet ettiğine bağlı olarak farklı şekilde işlenebilir. Bu, tanılanması zor hatalara ve davranışlara neden olabilir.

• Çalışmanın dağılımı. Bir bileşenin birden çok örneğine sahip olduğunuzda, çalışmayı bunlar arasında dağıtmanız gerekir. Çalışmayı tüm örneklere eşit olarak yayabilir veya tek bir birincil örneğe istek gönderebilir ve yalnızca birincil örnek kullanılamıyorsa ikincil örnek kullanabilirsiniz.

  Gelen istekleri alan bileşenler için yük dengeleyiciler genellikle bu istekleri örneklere göndermek için kullanılır. Ancak, bazen bileşenler bağımsız olarak çalışır ve istemcilerden istek almaz, bu nedenle bu durumlarda örneklerin birbirleriyle çalışmalarını koordine etmeleri gerekebilir.

• Sağlık izleme. Her örneğin sistem durumu, söz konusu örneğin işini yapıp yapmadığını belirler ve bir sorun olduğunda hızlı kurtarmayı etkinleştirmek için sistem durumu izleme önemlidir.

  Yük dengeleyiciler genellikle sağlık izlemesi yapar. Yük dengeleyici içermeyen bileşenler için, tüm örneklerin durumunu izleyen bir dış bileşeniniz olabilir veya her örnek diğer örneklerin durumunu izleyebilir.

Buluttaki fiziksel konumlar

Bulut ortamında bile bir örneğin veya veri parçasının belirli bir fiziksel konumda depolandığını anladığınızda yedeklilik gereksinimi açıktır.

Örneğin:

• Sanal makine herhangi bir anda tek bir fiziksel yerde çalışır.
• Veriler, katı hal sürücüsü (SSD) veya sunuculara bağlı sabit disk gibi belirli bir fiziksel konumda depolanır.

Bir veri parçasının birden çok kopyası veya bir bileşenin örnekleri olsa bile, her kopya depolandığı fiziksel donanıma bağlıdır.

Bulut ortamının fiziksel konumu fiziksel kapsamlar halinde düzenlenebilir. Her fiziksel kapsamda, bu kapsamdaki bileşenleri veya verileri tehlikeye atabilecek olası riskler vardır. Fiziksel kapsam açısından tanımlanabilir risklerin kapsamlı olmayan bir listesi şu şekildedir:

Fiziksel kapsam	Olası risk
Disk veya sunucu gibi belirli bir donanım parçası	Donanım hatası
Veri merkezindeki raf	Raf üstü ağ anahtar kesintisi
Veri merkezi	Binanın soğutma sistemiyle ilgili sorun
Azure'da kullanılabilirlik alanı olarak adlandırılan bir veri merkezi grubu	Şehir genelinde elektrik fırtınası
Veri merkezinin bulunduğu daha geniş coğrafi alan (örneğin, bir Azure bölgesi olan bir şehir)	Yaygın doğal afet

Güvenilirlik açısından bakıldığında, fiziksel kapsamla ilişkili riskleri azaltmanın önemli bir yolu, bir bileşenin örneklerini farklı fiziksel kapsamlara yaymaktır. Yerleşik yedekliliğe sahip Azure hizmetleri, yedekli örnekleri dağıtmanın aşağıdaki üç yoldan birini veya birkaçını sunabilir:

• Yerel yedeklilik , örnekleri tek bir Azure veri merkezinin birden çok bölümüne yerleştirir ve tek bir örneği etkileyebilecek donanım hatalarına karşı koruma sağlar. Yerel yedeklilik genellikle en düşük maliyeti ve gecikme süresini sağlar. Ancak veri merkezi hatası, tüm örneklerin kullanılamadığı anlamına gelebilir.

• Alanlar arası yedeklilik , örnekleri tek bir Azure bölgesindeki birden çok kullanılabilirlik alanına dağıtır. Alanlar arası yedeklilik, donanım hatalarına ek olarak veri merkezi hatalarına karşı koruma sağlar.

• Coğrafi yedeklilik , örnekleri birden çok Azure bölgesine yerleştirir ve büyük ölçekli bölgesel kesintilere karşı koruma sağlar. Coğrafi yedeklilik daha yüksek maliyetlidir ve daha geniş çözüm tasarımınızı ve her bölgedeki bileşenlerinizin örnekleri arasında nasıl geçiş yapacağınızı göz önünde bulundurmanız gerekir. Ayrıca, Eşzamanlı ve eşzamansız çoğaltma bölümünde açıklanan gecikmeyi de göz önünde bulundurmanız gerekir.

Azure'da yedeklilik nasıl çalışır: İşlem hizmetleri

Yedeklilik, Azure'ın neredeyse her bölümünde kullanılır. Azure'ın yedekliliği nasıl uyguladığına bir örnek olarak, işlem iş yüklerini çalıştıran hizmetleri göz önünde bulundurun.

Azure'da, tek bir sanal makine (VM) bir Azure veri merkezinde tek bir fiziksel konakta çalışır. VM'nin beklediğiniz yerde (bölge ve kullanılabilirlik alanı gibi) çalıştığından emin olmak için Azure'a yönergeler sağlayabilirsiniz ve bazı durumlarda bunu size ayrılmış bir konağa yerleştirmek bile isteyebilirsiniz.

Bir sanal makinenin birden çok örneğini çalıştırmak yaygın bir durumdır. Bu senaryoda, bunları tek tek veya bir Sanal Makine Ölçek Kümesi kullanarak yönetmeyi seçebilirsiniz. Ölçek kümesi kullandığınızda, bunu destekleyen tek tek VM'leri görmeye devam edebilirsiniz, ancak ölçek kümesi yedekli VM'lerin yönetilmesine yardımcı olacak çeşitli özellikler sağlar. Bu özellikler, vm'leri bölge veya kullanılabilirlik alanı içindeki hata etki alanlarına yayma gibi belirttiğiniz kurallara göre otomatik yerleştirmeyi içerir.

İşlem görevlerini gerçekleştirmek için sanal makineleri kullanan başka birçok Azure işlem hizmeti vardır. İşlem hizmetleri genellikle sanal makinelerin nasıl dağıtıldığını belirleyen çeşitli yedeklilik ayarları sunar. Örneğin, bir hizmet, sanal makineleri kullanılabilirlik alanları arasında otomatik olarak dağıtmak ve yük dengelemeyi yapılandırmak için etkinleştirebileceğiniz bir alanlar arası yedeklilik ayarı sağlayabilir.

Çoğaltma: Veriler için yedeklilik

Duruma (verilere) uygulandığında yedeklilik çoğaltma olarak adlandırılır. Çoğaltma ile canlı verilerin çoğaltma olarak adlandırılan birden çok gerçek zamanlı veya neredeyse gerçek zamanlı kopyasını tutabilirsiniz. Risklere dayanıklılığı artırmak için çoğaltmaları farklı konumlara dağıtabilirsiniz. Bir kopya kullanılamaz hale gelirse, başka bir kopyanın işlevini devralması için sistem devreye girebilir.

Farklı çoğaltma türleri vardır ve her biri veri tutarlılığı, performans ve maliyet için farklı öncelikler uygular. Her çoğaltma türü, iş sürekliliği tartışmalarında kullanılan iki temel ölçümü etkiler: olağanüstü durum senaryosunda tolere edilebileceğiniz maksimum kapalı kalma süresi miktarı olan kurtarma süresi hedefi (RTO) ve olağanüstü durum senaryosunda tolere edilebilecek maksimum veri kaybı miktarı olan kurtarma noktası hedefi (RPO). Bu ölçümler ve bunların iş sürekliliği ile ilişkisi hakkında daha fazla bilgi edinmek için bkz. İş sürekliliği, yüksek kullanılabilirlik ve olağanüstü durum kurtarma nedir?

İşlevsel ve performans gereksinimlerini karşılamada çoğaltmanın öneminden dolayı, çoğu veritabanı sistemi ve diğer veri depolama ürünleri ve hizmetleri sıkı bir şekilde tümleştirilmiş bir özellik olarak bir tür çoğaltma içerir. Sundukları çoğaltma türleri genellikle mimarilerine ve kullanılmaya yönelik yöntemlere bağlıdır. Azure hizmetleri tarafından desteklenen çoğaltma türleri hakkında bilgi edinmek için bkz. Azure hizmet güvenilirliği kılavuzları.

Önemli

Çoğaltma yedeklemeyle aynı değildir. Çoğaltma, birden çok çoğaltma arasındaki tüm değişiklikleri eşitler ve verilerin eski kopyalarını korumaz.

Bazı verileri yanlışlıkla sileceğinizi varsayalım. Silme işlemi her çoğaltmaya uygulanır ve verileriniz her yerde silinir. Bu durumda, silinen verileri bir yedekten geri yüklemeniz gerekebilir. Yedekleme, bu makalenin devamında açıklanmıştır.

Zaman uyumlu ve zaman uyumsuz çoğaltma

Verileri çoğalttığınızda, bu verilerde yapılan tüm değişiklikler çoğaltmalar arasında eşitlenmiş olarak tutulmalıdır. Veriler değiştiğinde tutarlılığı korumaya çalışırken karşılaşılan birkaç temel zorluk vardır:

• Gecikme. Bir çoğaltmanın güncelleştirilmesi zaman alır ve çoğaltmalar ne kadar ayrı olursa, çoğaltmalar arasındaki uzaklık boyunca veri iletmek ve bir bildirim almak o kadar uzun sürer.

• Değişiklik yönetimi. Çoğaltmalar eşitlenirken veriler değişebilir ve bu nedenle verilerin tutarlılığını yönetmek karmaşık hale gelebilir.

Bu zorlukları gidermek için veri değişikliklerini çoğaltmanın ve veri tutarlılığını yönetmenin iki ana yolu vardır:

• Zaman uyumlu çoğaltma , güncelleştirmenin tamamlanmış olarak kabul edilmesi için güncelleştirmelerin birden çok çoğaltmada gerçekleşmesini gerektirir. Aşağıdaki diyagramda zaman uyumlu çoğaltmanın nasıl çalıştığı gösterilmektedir:

  

  Bu örnekte aşağıdaki adım dizisi gerçekleşir:

  1. İstemci verileri değiştirir ve istek, isteği işleyen ve değiştirilen verileri depolayan çoğaltma 1'e gönderilir.
  2. Çoğaltma 1, isteği işleyen ve değiştirilen verileri depolayan değişiklikleri çoğaltma 2'ye gönderir.
  3. Çoğaltma 2, çoğaltma 1'e yapılan değişikliği kabul eder.
  4. Çoğaltma 1, istemciye yapılan değişikliği onaylar.

  Zaman uyumlu çoğaltma tutarlılığı garanti edebilir ve bu da sıfırdan oluşan bir RPO'yu destekleyebileceği anlamına gelir. Ancak bu, performans maliyetine neden olur. Çoğaltmalarınız coğrafi olarak ne kadar ayrıysa ve çapraz geçiş yapılması gereken ağ atlama sayısı ne kadar fazlaysa, çoğaltma işlemi o kadar fazla gecikme süresine neden olur.

• Zaman uyumsuz çoğaltma arka planda gerçekleşir. Aşağıdaki diyagramda zaman uyumsuz çoğaltmanın nasıl çalıştığı gösterilmektedir:

  

  Bu örnekte aşağıdaki adım dizisi gerçekleşir:

  1. İstemci verileri değiştirir ve istek çoğaltma 1'e gönderilir.
  2. Replika 1, isteği işler, değiştirilen verileri depolar ve değişikliği hemen istemciye onaylar.
  3. Belirli bir zamanda, kopya 1 değişikliği kopya 2 ile senkronize eder.

  Zaman uyumsuz çoğaltma işlem akışlarının dışında gerçekleştiğinden, uygulama performansında kısıtlama olarak çoğaltmayı kaldırır. Ancak, başka bir kopyaya yük devretmeniz gerekiyorsa bu kopya en son verilere sahip olmayabilir ve bu nedenle RPO'nuzun sıfırdan büyük olması gerekir. Eşzamanlı olmayan çoğaltmanın tam olarak destekleyebileceği RPO, çoğaltma sıklığına bağlıdır.

Replika rolleri

Birçok çoğaltma sisteminde çoğaltmalar farklı roller üstlenebilir ve bu da verilerdeki değişiklikleri koordine etmeye yardımcı olur ve çakışma olasılığını azaltır. Etkin ve pasif olmak üzere iki ana rol türü vardır. Replikaların bu rollerle dağıtılmasının iki yaygın yolu vardır.

• Etkin-pasif çoğaltma, doğru bilgi kaynağı olarak davranmaktan sorumlu olan tek bir etkin çoğaltmanız olduğu anlamına gelir. Verilerde yapılan tüm değişiklikler o replikasyona uygulanmalıdır. Diğer tüm çoğaltmalar pasif bir rolde hareket eder, bu da etkin çoğaltmadan verilerde güncelleştirmeler aldıkları, ancak değişiklikleri doğrudan istemcilerden işlemedikleri anlamına gelir. Pasif çoğaltmalar, yük devretme gerçekleşmediği ve çoğaltmaların rolleri değişmediği sürece canlı trafik için kullanılmaz. Aşağıdaki diyagramda bir pasif replikası olan bir aktif-pasif sistem gösterilmektedir.

  

  Aktif-pasif bir sistemde, failover işlemi için gereken süre RTO'yu belirler. Genellikle aktif-pasif bir sistem için RTO dakika cinsinden ölçülür.

  Bazı çoğaltma çözümleri, pasif çoğaltmalardan verileri okumanızı (ancak yazmamanızı) sağlayan salt okunur çoğaltmaları da destekler. Bu yaklaşım, uygulamanızın işlem çalışması için kullandığınız birincil çoğaltmayı etkilemeden analiz veya raporlama gerçekleştirmeniz gerektiğinde çoğaltmalarınızdan daha fazla kullanım elde etmek için yararlı olabilir. Çeşitli Azure hizmetleri, okuma erişimi GRS (RA-GRS) çoğaltma türüne sahip Azure Depolama ve Azure SQL Veritabanı etkin coğrafi çoğaltma dahil olmak üzere salt okunur çoğaltmaları destekler.

• Aktif-aktif replikasyon, canlı trafik için aynı anda birden fazla aktif replikanın kullanılmasını sağlar ve bu replikalardan herhangi biri istekleri işleyebilir.

  

  Etkin-etkin çoğaltma, sistem tüm çoğaltmalardaki kaynakları kullanabileceğinden yüksek bir performans düzeyi sağlar. Etkin-etkin çoğaltma, bazı durumlarda sıfır RTO'yu destekleyebilir. Bununla birlikte, bu avantajlar veri tutarlılığını karmaşık hale getirme maliyetine neden olur çünkü birden çok çoğaltmada aynı anda yapılan değişikliklerin zaman uyumsuz olarak mutabık hale gelmesi gerekebilir.

Karmaşık veri hizmetleri hem etkin-etkin hem de etkin-pasif çoğaltmayı birleştirebilir. Örneğin, bir çoğaltma kümesini Azure'un bir bölgesine, diğerini ise farklı bir bölgeye dağıtabilir. Her bölgede tek bir etkin replika isteklere hizmet verirken, bir veya daha fazla pasif replika yük devretme için hazır olur. Bu arada, her iki bölge de etkin-etkin bir modelde çalışır ve trafiğin bunlar arasında dağıtılabilmesini sağlar.

Azure veri hizmetlerinde çoğaltma nasıl çalışır?

Verileri depolayan her Azure hizmeti bir tür çoğaltma sunar. Ancak her hizmet, hizmetin mimarisine ve hedeflenen kullanımlarına özgü farklı bir yaklaşım kullanabilir.

Örnek olarak, Azure Depolama bir dizi özellik aracılığıyla hem zaman uyumlu hem de zaman uyumsuz çoğaltma sağlayabilir:

• Verilerinizin birden çok kopyası birincil bölgenizde zaman uyumlu olarak çoğaltılır. Çoğaltmaları yerel olarak yedekli depolamadaki (LRS) tek bir veri merkezine farklı fiziksel donanıma yerleştirmeyi veya alanlar arası yedekli depolama (ZRS) için birden çok kullanılabilirlik alanına yaymayı seçebilirsiniz.
• Birincil bölgeniz eşlenmişse ve coğrafi olarak yedekli depolamayı (GRS) etkinleştirirseniz, veriler eşleştirilmiş bölgeye de çoğaltılır. Eşleştirilmiş bölgeler coğrafi olarak uzak olduğundan bu çoğaltma, uygulama aktarım hızınız üzerindeki etkiyi azaltmak için zaman uyumsuz olarak gerçekleşir.
• Coğrafi alanlar arası yedekli depolama katmanını (GZRS) kullanarak alanlar arası yedekli depolamayı ve coğrafi olarak yedekli depolamayı aynı anda kullanmayı seçebilirsiniz. Bölge içindeki veriler zaman uyumlu olarak çoğaltılır ve bölgeler arasında veriler zaman uyumsuz olarak çoğaltılır.

Daha fazla bilgi için bkz. Azure Depolama yedekliliği.

Bir diğer örnek de çoğaltma sağlayan Azure Cosmos DB'dir. Tüm Azure Cosmos DB veritabanlarının birden çok çoğaltması vardır. Replikaları küresel olarak dağıttığınızda, istemcilerin kullandığınız bölgelerden herhangi birindeki bir replikaya yazabileceği çok bölgeli yazma işlemlerini destekler. Bu yazma işlemleri bölge içinde senkron olarak çoğaltılır ve ardından diğer bölgeler arasında asenkron olarak çoğaltılır. Azure Cosmos DB, farklı çoğaltmalar arasında yazma çakışmaları olması durumunda bir çakışma çözümleme mekanizması sağlar. Daha fazla bilgi edinmek için bkz. Azure Cosmos DB ile genel veri dağıtımı - başlık altında.

Sanal makineler kullanıyorsanız, kullanılabilirlik alanları arasında veya başka bir Azure bölgesine sanal makineleri ve disklerini çoğaltmak için Azure Site Recovery'yi kullanabilirsiniz.

Bir Azure çözümü tasarlarken, hizmetin farklı konumlar da dahil olmak üzere nasıl yedeklilik ve çoğaltma sağladığını anlamak için her hizmetin güvenilirlik kılavuzlarına bakın.

Yedekleme

Yedekleme, verilerinizin belirli bir zamanda bir kopyasını alır. Bir sorun varsa yedeklemeyi daha sonra geri yükleyebilirsiniz . Ancak, yedekleme alındıktan sonra verilerinizde yapılan değişiklikler yedeklemede olmaz ve kaybolabilir.

Yedeklemeyi kullanarak, verilerinizi Microsoft Azure bulutu içinde veya içinde yedeklemek ve kurtarmak için çözümler sağlayabilirsiniz. Yedekleme sizi çeşitli risklerden koruyabilir, örneğin:

• Donanım veya diğer altyapılarda yıkıcı kayıplar.
• Veri bozulması ve silme.
• Fidye yazılımı gibi siber saldırılar.

Önemli

Yedekleme ve geri yükleme işlemlerinizi diğer kurtarma adımlarınızla birlikte düzenli olarak test edip doğrulamanız önemlidir. Test, yedeklemelerinizin kapsamlı ve hatasız olmasını ve işlemlerinizin bunları doğru bir şekilde geri yüklemesini sağlar. Testler, ekibinizin izleyebileceğiniz süreçleri anlamasını sağlamak için de önemlidir. Daha fazla bilgi edinmek için bkz . Test etme ve tatbikatlar.

Yedekleme gereksinimlerinizi nasıl etkiler?

Olağanüstü durum kurtarma stratejisinin bir parçası olarak kullanıldığında yedeklemeler genellikle saat cinsinden ölçülen bir RTO ve RPO'yu destekler:

• RTO, yedeklemeyi geri yükleme ve geri yüklemenin başarıyla tamamlandığını doğrulama dahil olmak üzere kurtarma işlemlerinizi başlatmanız ve tamamlamanız için geçen süreden etkilenir. Yedeklemenin boyutuna ve kaç yedekleme dosyasının okunmasının gerektiğine bağlı olarak, yedeklemenin tam olarak geri yüklenmesinin birkaç saat veya daha uzun sürmesi yaygındır.

• RPO, yedekleme işleminizin sıklığından etkilenir. Yedeklemeleri daha sık alıyorsanız, yedeklemeden geri yükleme yapmak zorundaysanız daha az veri kaybedersiniz. Ancak yedeklemeler depolama gerektirir ve bazı durumlarda yedeklemeler alınırken hizmetin performansını etkileyebilir. Bu nedenle yedekleme sıklığını göz önünde bulundurmanız ve kuruluşunuzun gereksinimleri için doğru dengeyi bulmanız gerekir. Yedekleme sıklığı, iş sürekliliği planlamasında dikkate alınmalıdır.

Bazı yedekleme sistemleri, farklı saklama sürelerine sahip birden çok yedekleme katmanı ve daha az depolama alanı kaydedip tüketmek için daha hızlı olan değişiklik veya artımlı yedeklemeler de dahil olmak üzere daha karmaşık yedekleme gereksinimlerini destekler.

Azure hizmetlerinde yedekleme

Birçok Azure hizmeti verileriniz için yedekleme özellikleri sağlar.

Azure Backup , sanal makineler, Azure Depolama ve Azure Kubernetes Service (AKS) gibi çeşitli önemli Azure hizmetleri için ayrılmış bir yedekleme çözümüdür.

Ayrıca, birçok yönetilen veritabanı hizmetin bir parçası olarak kendi yedekleme özelliklerini sağlar, örneğin:

• Azure SQL Veritabanı otomatik yedeklemeler sağlar.
• Azure Cosmos DB hem sürekli hem de düzenli yedekleme özellikleri sağlar.
• Azure Key Vault, kasanızdaki verilerin yedeğini indirmenize olanak tanır.
• Azure App Service, web uygulamaları için hem otomatik hem de özel yedekleme sağlar ve veritabanlarını da yedekleyebilir.

Yedekleme ve çoğaltma karşılaştırması

Yedekleme ve çoğaltmanın her ikisi de sizi farklı risklere karşı korur ve iki yaklaşım birbirini tamamlayıcı niteliktedir.

Çoğaltma, günlük dayanıklılığı destekler ve genellikle yüksek kullanılabilirlik stratejisinde kullanılır. Bazı çoğaltma yaklaşımları çok az kapalı kalma süresi veya veri kaybı gerektirir ve düşük RTO ve RPO'yu destekler. Ancak, çoğaltma sizi veri kaybına veya bozulmasına neden olan risklere karşı korumaz.

Buna karşılık, yedekleme genellikle yıkıcı risklere karşı son savunma hattıdır. Yedeklemeleri yapılandırma şekliniz tam olarak ne kadar yüksek olacağını etkilese de yedeklemeler genellikle nispeten yüksek bir RTO ve RPO gerektirir. Yedekten toplam geri yükleme genellikle olağanüstü durum kurtarma planının bir parçasıdır.

Bileşenleri yedeklilik için hazırlama

Mimarisinin bir parçası olarak yedeklilik kullanan bir sistem tasarlarken şunların nasıl yapılacağını da göz önünde bulundurmanız önemlidir:

• Tutarlılık için yinelenen kaynak yapılandırması.
• Kapasiteyi örnek başarısızlıkları sırasında aşırı tahsis ederek yönetin.

Yinelenen kaynak yapılandırması

Bulut ortamlarında, kaynaklarınızın her birinin yapılandırması kritik önem taşır. Örneğin, bir ağ yük dengeleyici oluşturduğunuzda, nasıl çalıştığını etkileyen çeşitli ayarlar yapılandırabilirsiniz; ve Bir işlevi Azure İşlevleri kullanarak dağıttığınızda güvenlik, performans ve uygulama yapılandırma ayarlarıyla ilgili ayarları yapılandırırsınız. Azure'daki her kaynağın davranışını yönlendiren bir tür yapılandırma vardır.

Farklı yerlerdeki kaynakların yedekli kopyalarını yönetirken, bunların yapılandırmasını denetlemeniz önemlidir. Kaynakların aynı şekilde davranması için birçok ayarın her kopyada aynı şekilde ayarlanması gerekir. Ancak belirli bir bölgenin sanal ağına yapılan başvurular gibi bazı ayarlar her kopya arasında farklı olabilir.

Kaynaklarınızda tutarlılığı korumanın yaygın bir yaklaşımı, Bicep veya Terraform gibi kod olarak altyapıyı (IaC) kullanmaktır. Bu araçlar bir kaynağı tanımlayan dosyalar oluşturmanıza olanak tanır ve bu tanımları kaynağın her örneği için yeniden kullanabilirsiniz. IaC kullanarak, dayanıklılık amacıyla birden çok kaynak örneği oluşturma ve yönetme yükünü azaltabilir ve bunun yanı sıra birçok başka avantaj da vardır. Daha fazla bilgi edinmek için bkz. Kod olarak altyapı (IaC) nedir? ve Kod olarak altyapıyı kullanma önerileri.

Fazla sağlama ile kapasiteyi yönetme

Bir örnek başarısız olduğunda, genel sistem kapasiteniz iyi durumdaki işlemler sırasında gereken kapasiteden farklı olabilir. Örneğin, genellikle gelen web trafiğinizi işlemek için bir web sunucusunun altı örneğine sahip olduğunuzu ve bu örneklerin bir bölgedeki üç Azure kullanılabilirlik alanına eşit şekilde yayıldığını varsayalım:

Kullanılabilirlik alanında kesinti yaşanırsa, iki örneği geçici olarak kaybedebilir ve yalnızca dört web sunucusu örneğiyle kalabilirsiniz. Uygulamanız genellikle meşgulse ve altı örneğin de normal trafiğinize ayak uydurmasını gerektiriyorsa, daha düşük bir kapasitede çalışmak çözümünüzün performansını etkileyebilir.

Hatalara hazırlanmak için hizmetinizin kapasitesini fazla sağlayabilirsiniz . Aşırı sağlama, çözümün bir miktar kapasite kaybına tolerans göstermesini ve performansı düşürmeden çalışmaya devam etmesini sağlar.

Bir kullanılabilirlik alanının hatasını dikkate almak için web sunucunuzun örneklerini fazladan sağlamak amacıyla şu adımları izleyin:

1. En yoğun iş yükünüzün gerektirdiği örnek sayısını belirleyin.
2. En yüksek iş yükü örnek sayısını [(zones/(zones-1)] faktörüyle çarparak aşırı tahsis örnek sayısını alın.
3. Sonucu en yakın tamsayıya yuvarla.

Uyarı

Aşağıdaki tabloda üç kullanılabilirlik alanı kullandığınız ve bu bölgelerden birinin kapasite kaybını hesaba eklemek istediğiniz varsayılır. Gereksinimleriniz farklıysa formülü buna göre ayarlayın.

En yüksek iş yükü örneği sayısı	[(zones/(zones-1)] faktörü	Formül	Sağlanan örnekler (Yuvarlatılmış)
3	3/2 veya 1,5	(3 x 1,5 = 4,5)	5 örnek
4	3/2 veya 1,5	(4 x 1,5 = 6)	6 örnek
5	3/2 veya 1,5	(5 x 1,5 = 7,5)	8 örnek
6	3/2 veya 1,5	(6 x 1,5 = 9)	9 örnek
7	3/2 veya 1,5	(7 x 1,5 = 10,5)	11 örnek
8	3/2 veya 1,5	(8 x 1,5 = 12)	12 örnek
9	3/2 veya 1,5	(9 x 1,5 = 13,5)	14 örnek
10	3/2 veya 1,5	(10 x 1,5 = 15)	15 örnek

Yukarıdaki örnekte, en yüksek iş yükü web sunucusunun altı örneğini gerektirir, bu nedenle aşırı sağlama toplam dokuz örnek gerektirir:

Sonraki adımlar

Yedeklemeye geçiş ve ana sisteme geri dönme hakkında bilgi edinin.