Barındırma Ekipleri için Felaket Kurtarma Kılavuzu

26 Eylül 2026 tarihinde yayımlandı

İyi bir felaket kurtarma kılavuzu, kesinti bileti gelmeden önce başlar. Ekibiniz hangi hizmetlerin öncelikli olduğunu, temiz yedeklerin nerede bulunduğunu, değişiklikleri kimin onaylayabileceğini ve müşterilerin nasıl bilgilendirileceğini zaten biliyor olmalıdır. Bir olay sırasında belirsizlik, çoğu sunucu arızasından daha fazla zaman kaybettirir. Hizmet çalışmıyor olabilir, ancak kurtarma süreci sakin kalmalıdır.

Küçük bir işletme, ajans, SaaS işletmecisi veya çevrim içi mağaza için felaket kurtarma yalnızca tam bir sunucu arızasından kurtulmakla ilgili değildir. Aynı zamanda yanlışlıkla silmeleri, başarısız dağıtımları, fidye yazılımlarını, veritabanı bozulmalarını, süresi dolmuş sertifikaları, bozuk DNS kayıtlarını ve biraz fazla yaratıcı biçimde yapılandırılmış bir bulut hesabını da kapsar. Farklı olaylar farklı yanıtlar gerektirir, ancak hazırlık büyük ölçüde aynıdır.

İşletmeniz için Kurtarmanın Ne Anlama Geldiğini Tanımlayın

İki sayıyla başlayın: Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO). Bunlar sırf evrak işi olsun diye yapılan evrak işleri değildir. Kabul edilebilir bir kesintinin ve kabul edilebilir veri kaybının sınırlarını belirlerler.

RTO, bir hizmetin kullanılamayacağı azami süredir. Ödeme adımınızın bir saat içinde yeniden çalışması gerekiyorsa RTO'su bir saattir. RPO, kaybedebileceğiniz azami veri miktarıdır. 15 dakikalık RPO, yedeklerin, çoğaltmanın veya işlem günlüklerinin olaydan en fazla 15 dakika öncesine kadar geri yüklemeye olanak sağlaması gerektiği anlamına gelir.

Her iş yüküne aynı hedefi vermeyin. Tanıtım amaçlı bir web sitesi, genellikle bir sipariş sistemine kıyasla daha uzun bir RTO'yu tolere edebilir. Üretim e-postası, müşteri veritabanları ve ödeme entegrasyonları geri yüklenirken bir geliştirme sunucusu bekleyebilir. Her hizmeti bir öncelik katmanına yerleştirin ve sahibini, bağımlılıklarını ve kurtarma hedefini belgeleyin.

Başarısız Olmadan Önce Bağımlılıkları Haritalayın

Bir web uygulaması nadiren yalnızca tek bir sunucuda çalışır. DNS'ye, bir SSL sertifikasına, bir yük dengeleyiciye, nesne depolamaya, bir veritabanına, bir e-posta sağlayıcısına, bir API'ye ve bir arka plan çalışanına bağlı olabilir. Veritabanı eksikse veya DNS ziyaretçileri hâlâ kullanılamayan bir adrese yönlendiriyorsa önce web sunucusunu geri yüklemek bir işe yaramaz.

Her kritik hizmet için basit bir bağımlılık haritası oluşturun. Sunucu adlarını, IP adreslerini, işletim sistemlerini, uygulama sürümlerini, veritabanı konumlarını, kimlik bilgilerinin depolandığı yeri, güvenlik duvarı kurallarını, zamanlanmış işleri, DNS bölgelerini ve üçüncü taraf hizmetleri kaydedin. Bu bilgileri, etkilenen altyapının dışında erişilebilir bir yerde tutun. Yalnızca arızalı sunucuda depolanan bir kurtarma belgesi, iyimserliğin oldukça sessiz bir biçimidir.

Gerçekten Geri Yükleyebileceğiniz Yedekler Oluşturun

Bir yedek, ancak geri yüklenip doğrulandıktan sonra bir kurtarma seçeneğidir. Başarılı yedekleme günlükleri bir işlemin tamamlandığını gösterir. Kopyalanan verilerin okunabilir, eksiksiz, güncel veya uygulamayla kullanılabilir olduğunu kanıtlamazlar.

Pratik bir temel olarak 3-2-1 ilkesini kullanın: önemli verilerin en az üç kopyasını iki farklı depolama türünde, bir kopyayı tesis dışında veya ayrı bir hesapta tutun. Birçok barındırma ortamında bu; hızlı geri dönüşler için yerel anlık görüntüler, üretim sunucusunun dışında zamanlanmış yedek depolama ve başka bir konumda ek bir korumalı kopya anlamına gelir.

Web sitesi dosyalarından fazlasını yedekleyin. Veritabanlarını, sanal makine yapılandırmalarını, uygulama ortam değişkenlerini, altyapı-kod dosyalarını, DNS dışa aktarımlarını, sertifika ayrıntılarını ve dağıtım belgelerini dahil edin. İşletmeniz yönetilen bir platforma dayanıyorsa, platformun neleri koruduğunu ve nelerin sizin sorumluluğunuzda kaldığını doğrulayın. “Bunun dahil olduğunu sanıyorduk” tercih edilen bir kurtarma stratejisi değildir.

Yedekleme Sıklığını Veri Değişimine Uydurun

Statik bir şirket web sitesinin günlük yedeklemeye ihtiyacı olabilir. Yoğun bir e-ticaret veritabanı, RPO'sunu karşılamak için saatlik yedeklemeler, binlog saklama veya çoğaltma gerektirebilir. Doğru seçim, verilerinizin ne kadar hızlı değiştiğine ve kaybolan faaliyetlerin ne kadarının elle uzlaştırılabileceğine bağlıdır.

Saklama da önemlidir. Bozulma veya kötü amaçlı yazılım günlerdir mevcutken yalnızca en yeni yedeği saklamak risklidir. İlk görünür belirtinin öncesine dönebilmek için birden çok geri yükleme noktası tutun. Yedekleri şifreleyin, erişimi sınırlayın ve mümkünse üretimden ayrı kimlik bilgileri kullanın. Tam üretim erişimine sahip bir saldırgan, her yedek kopyanın anahtarlarına otomatik olarak erişememelidir.

Açık ve Anlaşılır Bir Olay Çalıştırma Kılavuzu Oluşturun

Bir kesinti sırasında insanların önceden verilmiş kararlara ihtiyacı vardır. Çalıştırma kılavuzunuz baskı altında kullanılabilecek kadar kısa ve yetkin başka bir kişinin takip edebileceği kadar ayrıntılı olmalıdır. Tek bir dev belge yazmak yerine kılavuzu senaryolara göre ayırın.

Örneğin, başarısız bir VPS, silinmiş bir veritabanı, güvenliği ihlal edilmiş bir web sitesi, başarısız bir dağıtım ve bölgesel bir altyapı kesintisi için ayrı prosedürler yazın. Her prosedür, sorunun nasıl algılanacağını, daha fazla hasarın nasıl durdurulacağını, kurtarma kaynağının nerede bulunduğunu, geri yükleme sırasını, doğrulama kontrollerini, eskalasyon kişilerini ve müşteri iletişimi adımlarını belirtmelidir.

Güvenlik ihlalinden şüpheleniliyorsa, pratik olduğu durumlarda yeniden oluşturmadan önce kanıtları koruyun. Etkilenen sunucuyu yalıtın, kimlik bilgilerini yenileyin, erişim günlüklerini inceleyin ve olası giriş noktasını belirleyin. Güvenlik açığı bulunan bir eklentiyi, dışa açık bir hizmeti veya sızdırılmış bir parolayı düzeltmeden temiz bir yedeği geri yüklemek, öğle yemeğine kadar sizi aynı olaya geri döndürebilir.

Küçük Bir Ekipte Bile Rolleri Atayın

Küçük ekiplerin resmi bir acil durum komitesine ihtiyacı yoktur, ancak sorumluluk sahibi kişilere ihtiyaçları vardır. Bir kişi teknik kurtarmaya liderlik eder, biri müşteri veya iç güncellemeleri koordine eder ve gerekirse biri etkisi yüksek seçimleri onaylar. Aynı kişi birden fazla rol üstlenebilir, ancak sorumluluklar açıkça belirtilmelidir.

Durum güncellemelerini önceden hazırlayın. Nelerin etkilendiğini, nelerin kontrol edildiğini, varsa hangi geçici çözümün bulunduğunu ve bir sonraki güncellemenin ne zaman sağlanacağını belirtin. Geri yükleme süresi hakkında tahminde bulunmaktan kaçının. Müşteriler genellikle zorlu bir olayı sessizlikten veya sonradan ortadan kaybolan iyimser tahminlerden daha iyi karşılar.

Arızaya Uygun Kurtarma Yöntemlerini Seçin

Anlık görüntüler, kötü bir değişiklikten sonra hızlı geri dönüş için kullanışlıdır, ancak tam bir yedekleme politikası değildir. Anlık görüntüler aynı güvenliği ihlal edilmiş ana bilgisayarda veya depolama sisteminde kalıyorsa birincil iş yüküyle birlikte yok olabilirler. Hız için bunları kullanın, ardından dayanıklılık için bağımsız yedekleri koruyun.

Değiştirme altyapısına geri yüklemek, hasarlı bir sunucuyu yerinde onarmaktan genellikle daha güvenlidir. Yeni bir VPS veya özel sunucu sağlanabilir, yamalanabilir ve trafik aktarılmadan önce kontrol edilebilir. Bu yaklaşım ayrıca orijinal sistemi inceleme için korur. Anlık görüntüyle geri dönüşten daha uzun sürebilir; bu nedenle hız, güven ve olayın niteliği arasında bir denge söz konusudur.

Yüksek kullanılabilirlikli hizmetlerde çoğaltma ve yük devretme kesinti süresini azaltabilir, ancak operasyonel karmaşıklığı artırır. Çoğaltma, kötü verileri de iyi veriler kadar verimli biçimde kopyalayabilir. Yalnızca yedekliliğin kurtarma sorununu çözdüğünü varsaymak yerine izleme, uygun durumlarda gecikmeli kopyalar ve test edilmiş yük devretme prosedürleri kullanın.

Planı Bir Takvime Bağlı Olarak Test Edin

Test edilmemiş bir kurtarma planı, kendisine bir belge eklenmiş bir varsayımdır. Kritik sistemler için en az üç ayda bir ve büyük mimari değişikliklerden sonra geri yükleme testleri planlayın. Bir yedeği yalıtılmış bir ortama geri yükleyin, uygulamanın başlatıldığını doğrulayın, veritabanı bütünlüğünü kontrol edin, oturum açma ve işlem akışlarını test edin ve kurtarılan verileri beklenen geri yükleme noktasıyla karşılaştırın.

Her adımın ne kadar sürdüğünü kaydedin. Bir veritabanı geri yüklemesi dört saat sürüyor ancak RTO'su bir saat ise plan kâğıt üzerinde başarısız olmuyor. Önemli olan tek yerde başarısız oluyor. Daha hızlı bir yedekleme yöntemine, daha küçük kurtarma birimlerine, beklemedeki altyapıya veya gözden geçirilmiş bir iş hedefine ihtiyacınız olabilir.

İzleme de kurtarmayı desteklemelidir. Depolama kapasitesi, yedekleme hataları, sertifika süresinin dolması, olağandışı CPU davranışı, veritabanı çoğaltma gecikmesi ve başarısız zamanlanmış işler için uyarılar, bir felaketi rutin bir düzeltmeye dönüştürebilir. FASTCARE gibi yönetilen izlemeyle amaç yalnızca bir uyarı almaktan ibaret değildir. Amaç, sorun hâlâ küçükken bir teknisyenin doğru sinyalleri kontrol etmeye başlamasını sağlamaktır.

Geri Yükleyin, Doğrulayın, Ardından Olayı Kapatın

Hizmet geri geldiğinde hemen zafer ilan etmeyin. DNS çözümlemesini, SSL davranışını, güvenlik duvarı erişimini, uygulama sağlığını, zamanlanmış görevleri, veritabanı bağlantısını, e-posta teslimini ve önemli müşteri yolculuklarını doğrulayın. Çevrim içi bir mağaza için gezinmeyi, sepet etkinliğini, ödeme adımını, sipariş bildirimlerini ve ödeme geri çağrılarını test edin. Bir SaaS platformu için kimlik doğrulamayı, arka plan kuyruklarını, API yanıtlarını ve kiracı veri erişimini test edin.

Ardından ayrıntılar hâlâ tazeyken olayı gözden geçirin. Bunu ne algıladı? Kurtarmayı ne geciktirdi? Çalıştırma kılavuzunun hangi adımı anlaşılır değildi? Yedekler gerekli RPO'yu karşıladı mı? Bu yanıtları, bir sahibi ve son tarihi olan belirli değişikliklere dönüştürün. En iyi olay sonrası inceleme pratik olandır, gösterişli olan değil.

kodu.cloud müşterileri, sabah 2'de tüm kurtarma görevlerinin tek bir yoğun kişinin üzerine kalmasını azaltmak için yönetilen altyapıyı, yedekleme hizmetlerini, izlemeyi ve insan desteğini birleştirebilir. Bu, bir plana duyulan ihtiyacı ortadan kaldırmaz, ancak koşullar daha elverişsiz olduğunda plana deneyimli eller kazandırır.

Amaç hiçbir şeyin arızalanmayacağını vaat etmek değildir. Sunucular, yazılımlar ve insanlar zaman zaman şaşırtıcı kararlar verebilir. Amaç, ekibinizin bir sonraki güvenli adımı bileceği, müşterilerinizin açık güncellemeler alacağı ve hizmetin yeniden sakinleşeceği kadar öngörülebilir bir kurtarma sağlamaktır.

Andres Saar Müşteri Destek Mühendisi