İşe Yarayan Web Sitesi Barındırma Felaket Kurtarma
14 Haziran 2026 tarihinde yayınlandı
Siteniz kapalıysa, hacklendiyse, bir güncellemeden sonra bozulduysa veya bir depolama sorununun ardından veri eksikse, web sitesi barındırma felaket kurtarma bunun kısa süreli bir olay mı yoksa çok pahalıya mal olan bir hafta mı olacağına karar veren kısımdır. İlk kontroller her zaman aynıdır - ne başarısız oldu, hangi veriler sağlam, hangi yedek temiz ve hizmet ne kadar hızlı şekilde kararlı bir duruma dönebilir. Panik, bir altyapı stratejisi değildir.
Çoğu işletme, bir yerlerde yedekler bulunduğu için felaket kurtarmaya sahip olduğunu düşünür. Bu, yalnızca bir parçadır. Hiç test edilmemiş, aynı sunucuda duran veya geri yüklenmesi on iki saat süren bir yedek, ödeme süreciniz çevrimdışıyken ve destek talepleri katlanmaya başlarken pek de teselli sayılmaz.
Barındırma için felaket kurtarma, arızadan hizmetin yeniden ayağa kaldırılmasına giden pratik bir yola sahip olmak demektir. Bu, yalnızca dosyaları değil, web sitenizin etrafındaki sistemleri de kapsar. Buna sanal sunucu, veritabanı, DNS davranışı, SSL sertifikaları, uygulama yığını, depolama birimleri, erişim kontrolleri ve bir olay sırasında karar vermekten sorumlu kişiler dahildir.
Web sitesi barındırma felaket kurtarma gerçekte neleri kapsar
Barındırma ortamlarında felaket her zaman dramatik bir yangın ya da tam bir veri merkezi kesintisi anlamına gelmez. Daha sık olarak bu, daha küçük ve daha can sıkıcı bir şeydir, ama yine de geliri durduracak kadar acı vericidir. Başarısız bir işletim sistemi güncellemesi, bir VPS'yi önyüklenemez hale getirebilir. Bir eklenti güncellemesi, bir veritabanı tablosunu bozabilir. Bir fidye yazılımı bulaşması, web içeriğini şifreleyebilir. Kendine fazla güvenen bir insan ve tek bir yanlış komut, yanlış dizini silebilir. Loglar da artık aynı hikâyeyi anlatıyor.
Düzgün bir kurtarma planı, hem altyapı düzeyindeki arızaları hem de uygulama düzeyindeki arızaları hesaba katar. Hypervisor ana sisteminde bir sorun varsa, tam sanal makineyi kurtarmanız veya hizmetleri başka bir düğüme taşımanız gerekebilir. Web sunucusu iyiyse ama veritabanı hasarlıysa, kurtarma yolu farklıdır. DNS yanlış değiştirildiyse, en hızlı çözüm herhangi bir sunucuyu geri yüklemek yerine kayıtları geri almak olabilir.
İşte bu yüzden kurtarma planlaması kapsamla başlar. Önce ne geri gelmeli? Bir e-ticaret mağazası için ürün sayfaları önemlidir, ama ödeme akışı daha da önemlidir. Bir SaaS uygulaması için giriş, API erişimi ve müşteri verilerinin tutarlılığı genellikle en üstte yer alır. Birçok müşteri sitesi barındıran bir ajans için izolasyon da önemlidir - bozuk bir site, tüm filoyu etkileyen bir soruna dönüşmemelidir.
En çok önem taşıyan iki sayı
Ciddi her web sitesi barındırma felaket kurtarma planı, RPO ve RTO etrafında kurulur. Bunlar kurumsal sunumlar için havalı terimler değildir. Bunlar, kurulumunuzun gerçekçi olarak verebileceği temel vaatlerdir.
Recovery Point Objective ya da RPO, ne kadar veri kaybetmeyi göze alabileceğinizi açıklar. Yedekler her 24 saatte bir çalışıyorsa, en kötü senaryonuz bir tam günlük sipariş, gönderi veya başvuru kaybı olabilir. Bu, tanıtım amaçlı bir site için kabul edilebilir olabilir. Yoğun bir mağaza veya müşteri portalı için bu genellikle kabul edilebilir değildir.
Recovery Time Objective ya da RTO, hizmetin ne kadar süre kullanılamaz kalabileceğini açıklar. Dört saatlik bir geri yükleme kulağa fena gelmeyebilir, ta ki bu dört saatin iş saatleri içinde yaşandığını, reklam kampanyalarının hâlâ sürdüğünü ve müşterilerin hâlâ tıklamaya devam ettiğini hatırlayana kadar.
Birçok barındırma sorunu, bu sayıların gerçekte olduklarından daha iyi olduğunu varsaymaktan kaynaklanır. Gecelik yedekler, on beş dakikalık bir RPO oluşturmaz. Belgelenmiş bir sorumlusu olmayan manuel bir geri yükleme süreci, bir saatlik bir RTO oluşturmaz. Hizmet ancak bu vaatler gerçekle örtüştüğünde yeniden sakinleşir.
Yedekler gereklidir, ama tek başına yeterli değildir
İyi bir barındırma yedekleme sistemi dosyaları, veritabanlarını, yapılandırmayı ve gerektiğinde tam makine veya birim anlık görüntülerini kapsamalıdır. Ayrıca sürüm geçmişine de ihtiyaç duyar. Kötü amaçlı yazılım beş gün boyunca sessizce durduysa, dün geceki yedeği geri yüklemek yalnızca aynı sorunu yeni bir zaman damgasıyla geri getirebilir.
Depolama konumu, yedekleme sıklığı kadar önemlidir. Kopyalar yalnızca aynı sunucuda veya aynı arıza etki alanında yaşamamalıdır. Bir depolama dizisi arızalanırsa, bir faturalama hatası yanlış düğümü askıya alırsa veya bir ihlal yanal olarak yayılırsa, yalnızca yerel yedekler üzücü bir şakaya dönüşür.
Test etmek daha da önemlidir. Ekipler çoğu zaman bir kesinti sırasında yedekleme betiğinin kritik bir bağlama noktasını hariç tuttuğunu, veritabanı dökümünün eksik olduğunu veya geri yüklemeden sonra izinlerin bozulduğunu öğrenir. Kurtarma testi çok basit sorulara cevap vermelidir: geri yükleyebiliyor muyuz, bu ne kadar sürüyor ve uygulama sonrasında gerçekten başlıyor mu?
Küçük ve orta ölçekli işletmeler için bu genellikle zamanlanmış yedekleri, saklanan geri yükleme noktalarını ve belgelenmiş bir geri yükleme prosedürünü birleştirmek anlamına gelir. Daha talepkâr iş yükleri için anlık görüntüler ve replikasyon zaman farkını azaltabilir, ancak maliyet ve operasyonel karmaşıklık getirirler. Bu, mimarinin bir diyagramda ne kadar şık göründüğüne değil, kesintinin iş üzerindeki etkisine bağlıdır.
Kurtarma, yüksek kullanılabilirlikle aynı şey değildir
Bu bölüm sık sık kafa karışıklığı yaratır. Yüksek kullanılabilirlik, bileşen arızası sırasında hizmeti çalışır durumda tutmaya çal ışır. Felaket kurtarma, zaten bir şeylerin ters gittiğini varsayar ve geri dönüş yolunu hazırlar.
Birden fazla sunucuya dağıtılmış yük dengelemeli bir uygulama, görünür bir kesinti olmadan tek bir örnek arızasını atlatabilir. Çok iyi. Ama kötü bir dağıtım paylaşılan verileri bozarsa veya bir saldırgan geçerli kimlik bilgilerini ele geçirirse, yüksek kullanılabilirlik sizi sihirli şekilde kurtarmaz. Yine de temiz yedeklere, geri alma kabiliyetine ve güvenli bir geri yükleme yoluna ihtiyacınız vardır.
Öte yandan, bazı işletmelerin tam çok düğümlü bir mimariye ihtiyacı yoktur. Onların ihtiyacı olan şey güvenilir yedekler, sunucu dışı depolama, aktif izleme ve makine bir makine gibi davranmayı bırakıp modern sanat gibi davranmaya başladığında hızlı yanıt verebilen bir sağlayıcıdır. Çoğu zaman daha iyi harcama budur.
Bir web sitesi barındırma felaket kurtarma planı oluşturmak
Varlık eşlemesiyle başlayın. Hangi sunucunun neyi çalıştırdığını, veritabanının nerede bulunduğunu, yüklenen medyanın nerede saklandığını, DNS'in nasıl yönetildiğini, SSL yenilemelerinin nasıl gerçekleştiğini ve kimlerin ayrıcalıklı erişime sahip olduğunu bilin. Bu bilgi yalnızca tek bir yöneticinin kafasında varsa, bu bir plan değildir. Bu, takvim davetli bir rehine durumudur.
Sonra, hizmetleri iş önceliğine göre sınıflandırın. Neyin hemen geri yüklenmesi gerektiğine, neyin bekleyebileceğine ve neyin yedekten geri yüklenmek yerine koddan yeniden oluşturulabileceğine karar verin. Statik varlıklar bir şeydir. İşlemsel veritabanları başka bir şeydir.
Ardından, olası olaylar için kurtarma yollarını belgelendirin. Bir sunucu donanım sorunu, başka bir ana sisteme taşımayı gerektirebilir. Bozuk bir sürüm, bilinen sağlıklı bir derlemeye geri almayı gerektirebilir. Ele geçirilmiş bir uygulama izolasyon, kimlik bilgisi rotasyonu, kötü amaçlı yazılım incelemesi ve temiz bir noktadan seçici geri yükleme gerektirebilir. Farklı arızalar farklı hareketler gerektirir.
İzleme bu süreci beslemelidir. Sunucu sağlığını, disk davranışını, hizmet durumunu, SSL geçerliliğini ve uygulama düzeyindeki kontrolleri topluyorsanız, sorunları daha hızlı tespit edebilir ve geri yükleme gerekmeden önce zararı azaltabilirsiniz. İzleme, kurtarmanın yerini almaz, ama çirkin kısmı kısaltır.
Yönetilen barındırmanın sonucu nasıl değiştirdiği
Yönetilmeyen ve yönetilen kurtarma arasındaki fark genellikle teori değildir. Bu; zaman, stres ve hata oranıdır.
Yönetilmeyen ortamlarda müşteri, kesintiyi fark etmekten, arıza etki alanını belirlemekten, yedek bütünlüğünü doğrulamaktan, geri yüklemeyi çalıştırmaktan, izinleri onarmaktan, hizmet bağımlılıklarını kontrol etmekten ve herkese açık erişimi doğrulamaktan sorumlu olabilir. Bu, günün her saati kapsama sunan deneyimli ekipler için uygulanabilir. Birçok küçük işletme ve ajansın böyle bir lüksü yoktur.
Yönetilen destekle birlikte kurtarma daha disiplinli hale gelir. Birileri zaten düğümü, yedekleri ve hizmet davranışını izliyordur. Geri yükleme noktaları yalnızca mevcut değildir, operasyonel olarak da anlaşılmıştır. Bir sunucu arızalanırsa, yanıt sohbette bir tahmin yarışmasıyla değil, gerçek kontrollerle başlayabilir. Bir barındırma iş ortağının değerini gösterdiği yer burasıdır.
Yönetilen VPS veya adanmış altyapı kullanan işletmeler için pratik kazanç yalnızca daha hızlı müdahale değildir. Bu, en başından beri yedeklerin, izlemenin ve idari erişimin kontrol altında olduğu bir ortama sahip olmaktır. Örneğin Kodu.cloud, altyapıyı insan operasyon desteğiyle birleştirdiğinde bunu iyi konumlandırıyor; çünkü felaket kurtarma, insanlar ve platform birbirine yabancı olmadığında en güçlü haline gelir.
Kurtarmayı başarısızlığa uğratan yaygın boşluklar
En yaygın sorun, yedeklerin iş sürekliliğine eşit olduğunu varsaymaktır. Öyle değildir. Bir diğer sık görülen sorun, DNS sağlayıcıları, posta yönlendirme, harici nesne depolama veya yeniden inşadan sonra yeniden etkinleştirilmesi gereken lisansa bağlı yazılımlar gibi ana sunucunun dışındaki bağımlılıkları unutmaktır.
Erişim yönetimi başka bir zayıf noktadır. Bir olay sırasında ekipler, root erişimine sahip tek kişinin tatilde olduğunu, kayıt kuruluşu hesabının eski bir e-posta adresi kullandığını veya çok faktörlü kimlik doğrulamanın eski bir taşerona ait olduğunu keşfeder. Bu da gerçekten çok kötü bir zamanlama.
Bir de geri yükleme doğrulaması açığı vardır. Bir sunucuyu çevrimiçi hale getirmek, hizmeti geri getirmekle aynı şey değildir. Yine de veritabanı tutarlılığını, uygulama davranışını, zamanlanmış işleri, ödeme işleme sürecini, form teslimini ve sertifika geçerliliğini doğrulamanız gerekir. Yarı geri yüklenmiş bir web sitesi, belirgin bir kesintiden daha tehlikeli olabilir; çünkü müşteriler bozuk sistemleri kullanmaya başlar.
Çoğu işletme için mantıklı bir kurulum nasıl görünür
Tipik bir küçük veya orta ölçekli işletme web sitesi için mantıklı bir felaket kurtarma duruşu sıra dışı değildir. Bu genellikle saklama özellikli otomatik yedekler, sunucu dışı depolama, geri yükleme testi, altyapı izleme, belgelenmiş sahiplik ve hızlı yardımcı olabilen bir sağlayıcı anlamına gelir. Site ödemeleri, müşteri hesaplarını veya sık içerik değişikliklerini işliyorsa, yedekleme sıklığını artırın ve geri yükleme yolundaki manuel adımları azaltın.
Ajanslar ve SaaS operatörleri için iş yükleri arasında daha güçlü segmentasyon, daha net değişiklik kontrolü ve zararın doğrudan üretime taşınma olasılığını azaltan hazırlık ortamı uygulamaları ekleyin. Çalışma süresi gereksinimleri sıkıysa, kritik hizmetler için yük devretme mimarisini değerlendirin, ama yalnızca ekibiniz bunu düzgün şekilde işletebiliyorsa. Karmaşıklığın bedeli vardır.
Asıl hedef, efsanevi sıfır riskli bir sistem yaratmak değildir. Amaç, arızayı sıkıcı, kontrollü ve kurtarılabilir hale getirmektir. Çoğu işletmenin gerçekten ihtiyaç duyduğu sakinliğin versiyonu budur.
Kurulumunuzu gözden geçiriyorsanız, kendinize tek bir basit soru sorun: birincil site önümüzdeki on dakika içinde arızalansaydı, onu kim geri yüklerdi, nereden, hangi sırayla ve geri yüklenen sürümün temiz olduğunu nasıl bilirlerdi? Bu cevabın ucu açıksa, bunu düzeltmek için en iyi zaman bir sonraki uyarıdan öncedir.
Andres Saar Müşteri Hizmetleri Mühendisi