N+1 Yedeklilik Nedir? 2N, 2N+1 ve Tier Farkları

Yedeklilik nedir, N+1 yedeklilik ne anlama gelir?

Yedeklilik, bir sistemin çalışması için gereken bileşenlerin yanında, arıza anında yükü devralacak fazladan bileşen bulundurmaktır. N+1 yedeklilikte N, yükü taşımak için gereken birim sayısını gösterir; +1 ise tek bir arızayı ya da planlı bakımı kesintisiz atlatmanızı sağlayan ek birimdir.

Kavram veri merkezlerinden çıktı; ancak aynı mantığı bir sunucunun güç kaynağında, bir ağ bağlantısında ya da bir web uygulamasının sunucu havuzunda da görürsünüz. Talha Aslan ve ekibi olarak web sitesi ve e-ticaret projelerinde hosting kararlarını konuşurken bu terimle sık karşılaşıyoruz.

Bu rehberde terimi sade bir dille açıyoruz. Ayrıca 2N ve Tier gibi komşu kavramlarla farkını gösteriyor, bir site sahibi olarak hizmet sözleşmesinde neye bakmanız gerektiğini anlatıyoruz. Teknik tanımlarda Uptime Institute ve Linux çekirdeği belgeleri gibi birincil kaynaklara dayanıyoruz.

N harfi neyi temsil eder ve N değerini nasıl hesaplarsınız?

N, tam yükü taşımak için gereken asgari birim sayısıdır. Birim; UPS modülü, jeneratör, soğutma ünitesi ya da ağ cihazı olabilir. Hesabı her zaman yük ile tek birimin kapasitesi arasındaki orandan başlatırsınız.

Örnek hesap: Bir veri salonunun kritik BT yükü 300 kW olsun ve her UPS modülü 100 kW taşıyabilsin. Bu durumda N değeri 3 olur. N+1 tasarımda salona 4 modül koyarsınız; böylece herhangi bir modül devre dışı kaldığında kalan üç modül yükü taşımaya devam eder.

Ancak hesap yalnızca kapasiteye bakar. Yük büyüdükçe N de büyür; dolayısıyla bugün N+1 olan bir sistem, yeni rack dolapları eklendiğinde fark ettirmeden N düzeyine iner. Bu nedenle yedeklilik tasarımını tek seferlik bir karar olarak değil, kapasite planlamasıyla birlikte izlediğiniz bir değer olarak görün.

Bir başka ayrıntı da şudur: N+1 tanımında +1 her zaman tek birim demektir. Örneğin on modüllü bir sistemde tek yedek modül, toplam içinde oransal olarak küçük bir pay taşır. Aynı anda iki modül arızalanırsa sistem kapasite açığına düşer. Bazı tasarımlarda N+2 gibi ara düzeyler görürsünüz; mantık aynıdır, yalnızca yedek birim sayısı artar.

N+1, 2N ve 2N+1 arasındaki fark nedir?

Üç kavram aynı soruya farklı düzeyde cevap verir: bir parça ya da bir hat devre dışı kaldığında ne olur? N+1 tek bir ek birim ekler. 2N ise tüm sistemi iki kez kurar; iki bağımsız hat vardır ve her biri tek başına yükün tamamını taşıyabilir. 2N+1 bu iki katlı yapıya bir ek birim daha ekler.

Örnek hesap: N değeri 3 olan bir UPS sisteminde N+1 için 4, 2N için 6, 2N+1 için 7 modül gerekir. Yani 2N, N+1'e göre daha fazla donanım, alan ve bakım işi demektir.

Öte yandan 2N, dağıtım hattını da çiftlediği için N+1'in çözmediği bir sorunu çözer: ortak hattaki arızayı. N+1 sistemde dört modülün hepsi aynı çıkış panosuna bağlıysa o pano hâlâ tek başına tüm yükü durdurabilir. 2N yapıda ise A hattı ile B hattı birbirinden ayrıdır ve sunucular iki hattan da beslenir.

Tek hata noktası nedir ve yedeklilik onu nasıl ortadan kaldırır?

Tek hata noktası (single point of failure, kısaca SPOF), arızalandığında tüm sistemi durduran ve yedeği olmayan bileşendir. Örneğin dört UPS modülünüz olabilir; ancak hepsi tek bir dağıtım panosuna bağlıysa o pano tek hata noktasıdır. Bu yüzden N+1 bileşen sayısı tek başına kesintisizlik garantisi vermez.

Web siteleri için tipik tek hata noktaları şunlardır:

• Tek dağıtım panosu ya da tek transfer şalteri.
• Binaya giren tek fiber hattı ya da tek internet operatörü.
• Yalnızca bir veritabanı sunucusu ve onun tek diski.
• Tüm kayıtları barındıran tek DNS sağlayıcısı ya da tek ad sunucusu; bu konuda anycast DNS yazımız yol gösterir.
• Yalnızca bir kişinin bildiği parola ya da tek bir kişinin yapabildiği geçiş işlemi.

Tek hata noktasını bulmak için basit bir yöntem kullanabilirsiniz. Sistem şemasında her kutunun üzerine parmağınızı koyun ve şu soruyu sorun: bu kutu yarın sabah çalışmazsa site açılır mı? Cevap hayırsa o kutu tek hata noktasıdır. Ardından her kutu için ya bir yedek ekler ya da riski bilerek kabul edersiniz.

Veri merkezinde hangi bileşenler N+1 yedeklilik ile korunur?

Uptime Institute, Tier II tesislerdeki yedekli kritik güç ve soğutma bileşenlerini UPS modülleri, chiller ya da pompalar ve jeneratörler olarak sayar. Pratikte N+1 yedeklilik şu katmanlarda karşınıza çıkar:

• Kesintisiz güç kaynağı (UPS) modülleri ve bataryaları.
• Jeneratörler ve yakıt besleme ekipmanı.
• Soğutma üniteleri, chiller cihazları, pompalar ve fanlar.
• Güç dağıtım üniteleri ve dolap içi PDU'lar.
• Ağ tarafında yönlendiriciler, anahtarlar ve farklı operatörlerden gelen bağlantılar.

Her katmanın N değeri farklıdır. Dolayısıyla bir tesis UPS tarafında N+1, soğutma tarafında 2N olabilir. Sağlayıcınızın sayfasında yalnızca "N+1 altyapı" yazıyorsa hangi katmandan söz ettiğini sormanız gerekir. Çünkü zincirin en zayıf halkası toplam dayanıklılığı belirler.

Ağ katmanı ayrıca önem taşır. Tesisin içi kusursuz yedekli olsa bile tek operatörle bağlanan bir veri merkezi, o operatörün sorununda dünyadan kopar. Bu konuda AS numarası ve BGP rehberimiz, birden fazla operatörle bağlantının nasıl çalıştığını anlatır.

Güç zincirinde yedeklilik nasıl çalışır: şebeke, UPS ve jeneratör?

Elektrik zinciri genelde şu sırayla ilerler: şebeke beslemesi, transfer şalteri, UPS, dağıtım panosu ve son olarak sunucunun güç kaynağı. Şebeke kesildiğinde UPS bataryaları yükü anında devralır. Jeneratör çalışıp devreye girene kadar köprü görevi görür; ardından jeneratör uzun süreli beslemeyi üstlenir.

Uptime Institute, yanlış bilinenleri anlattığı yazısında veri merkezi için tek güvenilir güç kaynağının jeneratör tesisi olduğunu belirtir; çünkü şebeke plansız kesintilere açıktır. Aynı yazıya göre Tier yaklaşımı jeneratörün sürekli çalışmasını istemez. Bununla birlikte tesisin kritik yükü çalışma süresi sınırı olmadan taşıyabilme kapasitesine sahip olmasını arar.

Bu yüzden güç tarafında N+1 sorusu iki yerde anlam taşır: UPS modül sayısı ve jeneratör sayısı. Örneğin iki jeneratörden her birinin yükü tek başına taşıyabildiği bir kurguda biri bakımdayken öteki işi sürdürür.

Öte yandan yakıt tankı, yakıt pompası ya da transfer şalteri tekse yedekli jeneratörler bile tek hata noktasının arkasında kalır. Kısacası güç yedekliliğini makine sayısıyla değil, şebekeden sunucuya uzanan yolun tamamıyla değerlendirirsiniz.

Soğutmada N+1 neden ayrıca önemlidir?

Sunucular tükettikleri elektriğin büyük kısmını ısıya çevirir. Soğutma durduğunda salon sıcaklığı hızla yükselir ve donanım kendini korumak için kapanabilir. Yani elektrik kesintisiz olsa bile soğutma arızası fiilen bir kesintiye dönüşebilir. Bu nedenle tasarımcılar soğutma ünitelerini, pompaları ve fanları da N+1 ya da daha üst düzeyde kurgular.

Soğutmada dikkat etmeniz gereken ayrıntı, ünitelerin yerleşimidir. Kâğıt üzerinde N+1 olan bir sistemde yedek ünite salonun uzak köşesindeyse arızalı ünitenin bölgesini yeterince soğutmayabilir. Ayrıca soğutma ünitelerini besleyen elektrik hattının da yedekli olması gerekir; aksi halde güç tarafındaki tek bir arıza iki sistemi birden durdurur.

Site sahibi olarak bu ayrıntıları kendiniz denetleyemezsiniz. Ancak bir teklif görüşmesinde "soğutma kaç ünite, kaçı yedek?" diye sorabilirsiniz. Net cevap alamamak da sizin için bir bilgidir; şeffaf sağlayıcılar bu soruyu genellikle rahatça yanıtlar.

Uptime Institute Tier seviyeleri yedeklilikle nasıl ilişkilidir?

Uptime Institute'un Tier sınıflandırma sistemi, veri merkezi altyapısını dört düzeyde tanımlar ve her üst düzey alttakinin gereksinimlerini kapsar. Kurumun resmi açıklamasına göre düzeyler şöyledir:

Tablodan gördüğünüz gibi Tier II bileşen yedekliliğine, Tier III ise dağıtım yolunun yedekliliğine odaklanır. Tier IV de bunlara hata toleransını ekler. Yani Tier merdiveninde her basamak, bir önceki basamağın çözmediği bir tek hata noktasını hedef alır.

Şunu da ekleyelim: Tier sınıflandırması bir tesisin fiziksel altyapısını değerlendirir. Sizin sitenizin yazılımı, veritabanı ayarları ya da güncelleme süreciniz bu değerlendirmenin dışında kalır. Bu nedenle Tier IV bir tesiste barınan tek sunuculu bir site, sunucu ya da yazılım arızasında yine kapanabilir. Tesis düzeyi ile uygulama düzeyini ayrı ayrı düşünmek, beklentilerinizi gerçekçi tutar.

Tier seviyesi ile bileşen sayısı neden aynı şey değildir?

Yaygın bir varsayım, N+1'in Tier III'e, 2N'in Tier IV'e karşılık geldiğidir. Uptime Institute bu eşleştirmeyi doğru bulmaz. Kuruma göre bileşen sayısını artırmak belirli bir Tier düzeyini tek başına belirlemez ya da garanti etmez; çünkü değerlendirme dağıtım yollarını ve diğer sistem öğelerini de kapsar.

Aynı kaynak, bileşenlerin nasıl bağlandığına bağlı olarak yalnızca N+1 bileşenle Tier IV düzeyine ulaşmanın mümkün olduğunu da belirtir. Ayrıca Uptime Institute, Tier standardının belirli bir teknoloji, şema ya da tasarım kriteri dayatmadığını, yalnızca sonucu tanımladığını vurgular.

Dolayısıyla bir sağlayıcının "2N altyapı" demesi ile tesisin Tier sertifikasına sahip olması farklı iddialardır. İfade farkına da dikkat edin: "Tier III uyumlu" ya da "Tier III standartlarında" gibi sözler bağımsız bir sertifika anlamına gelmeyebilir.

Kurumun açıklamasına göre tasarım sertifikası bile, kurulu tesisin sertifikasyonuna kadar geçici bir doğrulamadır. Emin olmak istiyorsanız sağlayıcıdan sertifikanın türünü ve tesisin adını isteyin. Böylece pazarlama dili ile denetlenmiş bir iddiayı birbirinden ayırırsınız.

Uptime yüzdeleri yıllık kaç dakika kesintiye karşılık gelir?

Erişilebilirlik yüzdesini kesinti süresine çevirmek basit bir hesaptır. Bir yıl 365 gün, yani 8.760 saattir. Yüzde 99,9 erişilebilirlik, kalan yüzde 0,1'lik dilimde yılda 8,76 saat kesintiye izin verir. Aşağıdaki tablo bu hesabı birkaç yaygın değer için gösterir.

Örnek hesap: Değerleri 365 günlük yıl ve 30 günlük ay varsayımıyla hesapladık ve yuvarladık.

Önemli bir not: Uptime Institute, Tier standardında yıllık beklenen kesinti sürelerine yapılan atıfları 2009'da kaldırdığını açıklar. Kuruma göre güncel standart, Tier düzeylerine erişilebilirlik tahmini atamaz. Bu yüzden internette Tier düzeyleriyle eşleşen yüzdeler görürseniz bunları resmi tanım olarak değil, gayriresmi tahminler olarak okuyun.

Paralel yedeklilik erişilebilirliği matematiksel olarak ne kadar artırır?

Örnek hesap: Birbirinden bağımsız iki güç kaynağınız olsun ve her biri zamanın yüzde 99'unda çalışır durumda kalsın. Sistemin durması için ikisinin aynı anda arızalı olması gerekir. Bu olasılık 0,01 × 0,01, yani 0,0001'dir. Böylece erişilebilirlik teorik olarak yüzde 99,99'a çıkar.

Ancak bu hesabın kritik bir varsayımı var: bağımsızlık. Gerçekte iki güç kaynağı aynı panodan besleniyorsa arızalar birlikte gelir. Aynı yazılım hatası, aynı üretim partisi ya da aynı bakım hatası da iki birimi birden etkileyebilir. Mühendisler buna ortak nedenli arıza adını verir.

Seri bağlı bileşenlerde ise tablo tersine döner. Örnek hesap: yüzde 99,9 erişilebilir bir uygulama sunucusunu yüzde 99,9 erişilebilir bir veritabanına bağımlı hale getirirseniz toplam erişilebilirlik iki değerin çarpımı olur, yaklaşık yüzde 99,8.

Yani zincire eklediğiniz her yedeksiz halka toplam süreyi aşağı çeker. Bu nedenle yedekliliği tek bir katmanda değil, zincirin bütününde düşünmelisiniz. Paralel kurgu kazandırır, seri kurgu kaybettirir; tasarımın özü bu iki etkiyi dengelemektir.

Sunucu düzeyinde yedeklilik: çift PSU, RAID ve çift ağ kartı

Veri merkezi altyapısı yedekli olsa da sunucunun kendisi tek hata noktası olabilir. Bu yüzden kurumsal sunucularda üç yaygın önlem görürsünüz:

• Çift güç kaynağı (PSU): Sunucu iki ayrı güç kaynağıyla gelir ve her biri sunucuyu tek başına besleyebilir. Gerçek fayda için iki kaynağı farklı PDU'lara, ideal olarak farklı güç hatlarına bağlamanız gerekir.
• RAID: Disklerin bir kısmı arızalandığında veriyi erişilebilir tutar. RAID 1, 5, 6 ve 10 farklı düzeyde koruma sunar; RAID 0 ise yedeklilik sağlamaz. Ayrıntılar için RAID seviyeleri rehberimize bakabilirsiniz.
• Çift ağ kartı ve bağlantı birleştirme: İki ağ arayüzü tek bir mantıksal arayüz gibi çalışır. Biri koptuğunda trafik ötekine geçer.

Bu önlemler sunucu içindeki tekil arızalara karşı korur. Öte yandan anakart, işlemci ya da işletim sistemi arızası yine sunucuyu durdurur. Dolayısıyla tek sunucu ne kadar yedekli bileşene sahip olursa olsun, sunucunun kendisi için ikinci bir sunucu gerekir.

Bu ayrımı dedicated sunucu ile VPS ve bulut sunucu arasında seçim yaparken de göz önünde tutun. Bulut platformlarında donanım katmanı sizden gizlidir; yedekliliği orada sağlayıcının mimarisi ve sizin uygulama tasarımınız belirler.

Linux sunucuda yedekli bileşenlerin durumunu nasıl kontrol edersiniz?

Kendi VPS'inizi ya da fiziksel sunucunuzu yönetiyorsanız yedekli bileşenlerin durumunu okumak için iki çekirdek arayüzünden yararlanabilirsiniz. Linux çekirdeğinin bonding belgesine göre her bonding aygıtının /proc/net/bonding dizininde salt okunur bir dosyası vardır. Bu dosya yapılandırmayı ve her alt arayüzün durumunu gösterir:

cat /proc/net/bonding/bond0

Aynı belgeye göre active-backup kipinde yalnızca bir arayüz etkindir; etkin arayüz arızalandığında öteki devreye girer. Yazılım RAID kullanıyorsanız çekirdeğin md belgesindeki degraded özniteliği, dizinin kaç disk eksik çalıştığını gösterir. Sağlıklı dizide değer 0, tek disk arızasında 1 olur:

cat /sys/block/md0/md/degraded

Aygıt adları sizin sisteminizde farklı olabilir; bond0 ve md0 yalnızca örnektir. Önemli olan, bu değerleri düzenli izlemenizdir. Yedekli bir dizinin bir diski aylarca arızalı kalırsa sisteminiz fark ettirmeden N düzeyine iner.

Çift PSU durumu gibi donanım bilgileri ise üreticiye özel yönetim arayüzlerinden gelir. Bunun için sunucu üreticinizin belgesine bakın ve emin olmadığınız bir aracı üretim sunucusunda denemeyin.

Yedeklilik neden yedekleme değildir?

Yedeklilik çalışmayı sürdürmek içindir; yedekleme ise geri dönmek içindir. RAID 1 kurulu bir sunucuda yanlışlıkla bir tabloyu silerseniz sistem silme işlemini iki diske birden yazar. Aynı durum fidye yazılımı, hatalı eklenti güncellemesi ya da bozuk bir veritabanı göçü için de geçerlidir: yedekli sistem hatayı da yedekli biçimde saklar.

Bu yüzden iki kavramı birbirinin yerine koymayın. İyi bir plan ikisini birlikte içerir:

• Yedeklilik: Donanım arızasında hizmeti ayakta tutar ve kesinti süresini sıfıra yaklaştırır.
• Yedekleme: Veriyi geçmiş bir noktaya geri getirir; insan hatasına ve kötü amaçlı yazılıma karşı korur.
• Coğrafi ayrım: Yedeklerin farklı bir konumda durması, tesis düzeyindeki bir felakette veriyi korur.

Yedekleme tarafını nasıl kuracağınızı web sitesi yedekleme stratejisi yazımızda anlattık. Veritabanı özelinde ise mysqldump ve pg_dump rehberimiz adım adım yol gösterir.

Web sitesi sahibi olarak SLA'da neye bakmalısınız?

Hizmet seviyesi sözleşmesi (SLA), sağlayıcının erişilebilirlik taahhüdünü ve bu taahhüt tutmazsa size ne vereceğini yazar. Yedeklilik iddiası pazarlama metninde yer alır; bağlayıcı olan ise SLA metnidir. İncelerken şu maddelere odaklanın:

1. Erişilebilirlik yüzdesi ve ölçüm dönemi: aylık mı, yıllık mı?
2. Kesintinin tanımı: yalnızca hizmetin tamamen durması mı, yoksa ciddi yavaşlamayı da kapsıyor mu?
3. Planlı bakım: sağlayıcı bakım sürelerini erişilebilirlik hesabının dışında mı bırakıyor?
4. Telafi: genellikle hizmet kredisi biçimindedir; kredinin üst sınırını kontrol edin.
5. Talep süreci: krediyi almak için kaç gün içinde başvurmanız gerekir?
6. Kapsam: SLA ağı mı, sunucuyu mu, yoksa sizin uygulamanızı mı kapsar?

Yukarıdaki tabloyla birleştirince SLA'nın gerçek anlamını görürsünüz. Aylık yüzde 99,9 taahhüdü, bir ayda yaklaşık 43 dakikalık kesintinin sözleşmeye uygun olduğu anlamına gelir. E-ticaret siteniz için bu süre bir kampanya akşamına denk gelirse kayıp, kredi tutarından çok daha büyük olabilir. Kısacası SLA bir sigorta değil, sağlayıcının kendine koyduğu hedeftir.

Hosting seçerken yedeklilik iddialarını nasıl sorgularsınız?

Sağlayıcı sayfalarında "N+1 güç", "yedekli ağ" ya da "Tier III veri merkezi" gibi ifadeler sık geçer. Bu ifadeleri sorgulamak için teknik ekip olmanız gerekmez; doğru soruları sormanız yeterlidir:

• Hangi katman yedekli: UPS, jeneratör, soğutma, ağ, yoksa hepsi mi?
• Tesisin Tier sertifikası var mı, varsa tasarım sertifikası mı yoksa kurulu tesis sertifikası mı?
• Kaç farklı operatörle bağlantı var ve fiber çıkışları farklı güzergâhları izliyor mu?
• Sunucum çift PSU ile mi geliyor ve iki PSU farklı hatlara mı bağlı?
• Fiziksel donanım arızalanırsa sağlayıcı sanal makinemi başka bir sunucuya otomatik taşıyor mu?

Bu sorular, hosting seçim rehberimizdeki kriterlerle birlikte iyi bir kontrol listesi oluşturur. Ayrıca yedekliliğin fiyata nasıl yansıdığını sunucu kiralama maliyeti yazımızda ele aldık.

Kendi veri merkezini işleten hosting firmaları ile başkasının tesisinde alan kiralayan firmalar arasındaki farkı ise aynı serideki veri merkezi sahibi hosting yazımızda kısaca karşılaştırıyoruz. Bu fark, yedeklilik sorularına kimin doğrudan cevap verebileceğini de belirler.

Uygulama katmanında yedeklilik: yük dengeleme, DNS ve replikasyon

Altyapı yedekliliği tesisin içinde kalır. Siteniz için asıl kesintisizlik ise uygulamanın birden fazla sunucuya yayılmasıyla gelir. Yük dengeleyici gelen istekleri birkaç uygulama sunucusuna dağıtır ve sağlık kontrolünden geçemeyen sunucuyu havuzdan çıkarır. Böylece tek bir sunucunun çökmesi ziyaretçiye yansımaz.

Havuzda sağlıklı sunucu kalmadığında ise ziyaretçi çoğu zaman bir hata sayfası görür; bu durumu 503 Service Unavailable yazımızda ayrıntılı ele aldık.

Veritabanında replikasyon benzer bir rol üstlenir: birincil sunucunun verisini bir ya da birden fazla kopyaya aktarırsınız. Ancak replikasyon da yedekleme yerine geçmez, çünkü silme komutunu da kopyalara taşır. DNS tarafında ise birden fazla ad sunucusu, tek bir DNS noktasının çökmesine karşı korur.

Bu mimari, tek sunuculu bir siteye göre belirgin karmaşıklık getirir. Oturum yönetimi, dosya yüklemelerini ortak bir depoda saklama ihtiyacı ve dağıtım süreci değişir. Bu nedenle küçük bir kurumsal site için çoğu zaman gereksizdir; yüksek trafikli e-ticaret ve SaaS projelerinde ise ciddi bir seçenek olur.

Ne zaman kendiniz uğraşmamalı, işi hosting sağlayıcınıza bırakmalısınız?

Veri merkezi düzeyindeki yedeklilik tamamen sağlayıcının sorumluluğundadır; UPS, jeneratör ve soğutma üzerinde sizin bir kontrolünüz yoktur. Sizin işiniz doğru sağlayıcıyı seçmek ve SLA metnini okumaktır. Sunucu düzeyinde ise sorumluluk hizmet türüne göre değişir:

• Paylaşımlı hosting kullanıyorsanız RAID, bonding ya da PSU ayarı sizin alanınız değildir; bu işi sağlayıcıya bırakın.
• Yönetilen VPS ya da yönetilen sunucuda izleme ve donanım değişimini sağlayıcı üstlenir; siz yalnızca uyarıları takip edin.
• Yönetilmeyen fiziksel sunucuda RAID ve ağ yapılandırması sizdedir; deneyiminiz yoksa üretim ortamında ilk kez denemeyin.
• Çok sunuculu bir uygulama mimarisi kurmak yazılım ve operasyon bilgisi ister; bu noktada deneyimli bir geliştirme ekibiyle çalışmak daha güvenlidir.

Şunu da unutmayın: bir bağlantı birleştirme ayarını yanlış yaptığınızda sunucuya uzaktan erişiminizi kaybedebilirsiniz. Böyle bir değişikliği konsol erişiminiz olmadan ya da sağlayıcının destek ekibine haber vermeden yapmayın. Web sitenizin altyapısını birlikte planlamak isterseniz web tasarım hizmetimiz kapsamında bu kararları da konuşuyoruz.

Hangi site hangi yedeklilik düzeyine ihtiyaç duyar?

Doğru düzey, kesintinin size maliyetine bağlıdır. Aşağıdaki çerçeve saha tecrübesine dayalı bir başlangıç önerisidir, garanti değildir:

Son olarak, kesintiyi fark etmenin de bir yolu olmalı. Sitenizin erişilebilir olup olmadığını hızlıca görmek için site çöktü mü aracımızı kullanabilirsiniz; ancak kalıcı çözüm, dakikalık kontrol yapan bir izleme servisidir. Yedeklilik ancak bozulan parçayı zamanında fark ettiğinizde işe yarar.