İşe Yarayan Sunucu Yedekleme Politikaları Rehberi
1 Ağustos 2026 tarihinde yayınlandı
Sunucu yedekleme politikaları rehberi, şu operasyonel gerçekle başlar: bir yedek yalnızca işletmenizin tolere edebileceği süre içinde geri yüklenebildiğinde değerlidir. Tamamlanmış bir yedekleme işi, kurtarmanın kanıtı değildir. Yalnızca bir sürecin çalıştığının kanıtıdır. Politikanız; neyin korunduğunu, kopyaların nerede bulunduğunu, ne kadar süre erişilebilir kaldıklarını ve gece 2:00'de geri yükleme gerektiğinde kimin sorumlu olduğunu tanımlamalıdır.
Küçük bir işletme web sitesi için, kaçırılmış bir sipariş veritabanı birkaç saatlik web dosyasından daha yıkıcı olabilir. Bir SaaS platformu için, müşteri yüklemeleri, yapılandırma dosyaları, sırlar ve veritabanı kayıtlarının her biri farklı kurtarma hedefleri gerektirebilir. Her dosyaya aynı şekilde davranmak basittir, ancak basit olan her zaman güvenli değildir.
Yedekleme Yazılımıyla Değil, Kurtarma Hedefleriyle Başlayın
Zamanlamaları veya depolama konumlarını seçmeden önce, her hizmet için iki sayı belirleyin: Recovery Point Objective (RPO) ve Recovery Time Objective (RTO).
RPO, ne kadar veri kaybedebileceğinizi yanıtlar. RPO'nuz bir saatse, yedekleme planı yaşı bir saati geçmeyen kurtarılabilir bir kopyayı korumalıdır. Gün boyunca sipariş kabul eden bir çevrimiçi mağaza, saatlik veritabanı yedeklemelerine veya replikasyona ihtiyaç duyabilir. Ayda iki kez güncellenen bir tanıtım web sitesi için günlük yedeklemeler yeterli olabilir.
RTO, hizmetin ne kadar hızlı geri dönmesi gerektiğini yanıtlar. Dört saatlik bir RTO, ekibin sunucuyu, uygulamayı ve verileri dört saat içinde yeniden oluşturmak veya geri yüklemek için test edilmiş bir yola ihtiyaç duyduğu anlamına gelir. Politikaların çoğu zaman aşırı iyimser hale geldiği nokta burasıdır. Sınırlı bir bağlantı üzerinden 500 GB'lık bir yedeği geri yüklemek, bağımlılıkları yeniden oluşturmak ve uygulamayı doğrulamak insanların beklediğinden daha uzun sürebilir. İlerleme çubuğu mütevazı bir yaratıktır. Ondan mucizeler gerçekleştirmesini istemeyin.
Bu hedefleri teknik değerlerin yanında sade bir dille yazın. Örneğin: “Müşteri portalı iki saat içinde kullanılabilir olmalı ve kaybolan kayıtlar 30 dakikayı geçmemelidir.” Bu ifade, teknik personel ile işletme sahiplerine aynı hedefi verir.
Gerçekte Neyin Korunması Gerektiğini Sınıflandırın
Tek başına bir sunucu imajı, bir hizmeti kurtarmak için gereken her şeyi içermeyebilir. Politikanız, kurtarılabilir her bileşeni ve onun source of truth'ünü belirlemelidir.
Çoğu üretim sunucusu için buna işletim sistemi ve uygulama yapılandırması, veritabanları, web sitesi dosyaları, kullanıcı yüklemeleri, yerel olarak barındırılıyorsa e-posta verileri, zamanlanmış görev tanımları, SSL sertifikaları ve yenileme yapılandırması, DNS kayıtları, güvenlik duvarı kuralları ve şifreleme anahtarları veya sırlar dahildir. Bunların bazıları, korudukları verilerle aynı yedekleme deposunda saklanmamalıdır. Gerekli anahtar olmadan bir yedek, kapı kolu olmayan çok güvenli bir kutu olabilir.
Verileri işletme etkisine göre sınıflandırın. Kritik veriler genellikle sık yedekleme, daha uzun saklama süresi, şifreleme ve tesis dışı bir kopya gerektirir. Standart operasyonel veriler günlük yedekleme kullanabilir. Geçici dosyalar, önbellekler, paket indirmeleri ve yeniden üretilebilir derleme çıktılarının çoğu zaman hiç yedekleme depolaması tüketmesine gerek yoktur.
Bu sınıflandırma aynı zamanda maliyetli aşırı saklamayı da önler. Her geliştirme çıktısının her sürümünü sonsuza kadar saklamak bir politika değildir. Bu, depolama arkeolojisidir.
Yedekleme Politikasını 3-2-1 Kuralı Etrafında Oluşturun
Yaygın 3-2-1 modeli hâlâ yararlı bir temel çizgidir: verilerin en az üç kopyasını, iki farklı depolama türünde tutun ve bir kopyayı tesis dışında saklayın. Birçok işletme için, değiştirilemez veya çevrimdışı bir kopya eklemek, politikayı fidye yazılımına ve kazara silmeye karşı daha güçlü hale getirir.
Pratik bir düzen; birincil üretim sunucusunu, hızlı geri yüklemeler için yerel veya sağlayıcı düzeyinde bir yedeği ve ayrı bir konumda şifrelenmiş tesis dışı yedek depolamayı içerebilir. Yerel kopya, silinen bir dosya veya başarısız bir güncellemeden hızlı kurtarmayı destekler. Tesis dışı kopya, daha geniş kapsamlı bir altyapı olayına karşı koruma sağlar. Değiştirilemez bir kopya, bir saldırganın veya yönetici hesabının üretim verileriyle birlikte yedekleri silmesine karşı koruma sağlar.
Doğru tasarım, risk profilinize bağlıdır. Düşük trafikli bir siteyi barındıran tek bir VPS, günlük snapshot'lar ve şifrelenmiş tesis dışı veritabanı yedekleri kullanabilir. Müşteri verileri içeren yönetilen bir uygulama yığını, saatlik veritabanı yedekleri, günlük dosya yedekleri, haftalık tam sistem imajları ve ayrı değiştirilemez saklama gerektirebilir. Dedicated servers ve çok sunuculu ortamlar, tüm host, rack veya bulut hesabı kullanılamaz durumdaysa yedeklerin erişilebilir kalıp kalmadığını da değerlendirmelidir.
Kaçınabiliyorsanız, yedek depolamayı üretimle aynı kimlik bilgileri, ağ izinleri ve kontrol düzleminin arkasına koymayın. Ayrım önemlidir. Tek bir ele geçirilmiş hesap her kopyayı silebiliyorsa, kâğıt üzerinde yedekliliğiniz vardır ama gerçekte korumanız yoktur.
Veri Değişim Hızına Uyan Zamanlamalar Belirleyin
Yedekleme sıklığı, takvimin ne kadar rahat hissettirdiğine değil, verilerin ne kadar sık değiştiğine göre belirlenmelidir. Devam eden siparişler, talepler, hesap değişiklikleri veya işlemler içeren veritabanları, statik medya dosyalarından daha sık yedekleme gerektirir. Artımlı yedeklemeler aktarım ve depolama kullanımını azaltırken, dönemsel tam yedeklemeler kurtarma zincirlerini daha az kırılgan hale getirir.
Yaygın bir politika modeli; kısa bir operasyonel pencere için saklanan saatlik veritabanı yedekleri, birkaç hafta saklanan günlük yedekler, birkaç ay saklanan aylık yedekler ve yalnızca yasal, sözleşmesel veya işletme gereksinimleri bunları haklı çıkarıyorsa tutulan yıllık arşivlerdir. Kesin süreler evrensel değildir. Saklama süresi; geç fark edilen kazara silmeleri, raporlama ihtiyaçlarını, müşteri taahhütlerini ve geçerli düzenlemeleri dikkate almalıdır.
Saat dilimlerini ve yürütme pencerelerini belgeleyin. Yedeklemenin “gece yarısı” için planlanması, müşteriler, personel ve altyapı farklı bölgelerde çalıştığında belirsizdir. Teknik belgelerde UTC gibi standart bir referans kullanın, ardından yararlı olduğu yerlerde işletme tarafına yönelik yerel saati belirtin.
Tutarlılığı Politikanın Bir Parçası Haline Getirin
Bir yedek yalnızca içindeki dosyalar birbiriyle uyumluysa yararlıdır. Canlı bir veritabanı dosyasını, veritabanı motoru ona yazarken kopyalamak; eksiksiz görünen ama temiz şekilde geri yüklenemeyen bir yedek üretebilir.
Veritabanına özgü dump'lar, transaction-consistent snapshot'lar veya uygulama farkındalıklı yedekleme araçları kullanın. Sanal makineler için, snapshot'ların crash-consistent mı yoksa application-consistent mı olduğunu doğrulayın ve bunun her iş yükü için ne anlama geldiğini anlayın. Crash-consistent bir imaj bazı sistemler için kabul edilebilir olabilir, ancak geri yükleme sonrasında veritabanı kurtarma adımları gerektirebilir.
Politikanız, gerektiğinde yedekleme öncesi ve sonrası eylemleri belirtmelidir. Buna uygulama verilerini flush etmek, dağıtılan uygulama sürümünü kaydetmek, yapılandırmayı dışa aktarmak, yedek bütünlüğünü kontrol etmek ve bir iş başarısız olursa veya beklenen süresini aşarsa uyarı vermek dâhil olabilir. Sessizce başarısız olan yedekler, kötü haberlerin özel bir türüdür.
Yedek Erişimini Üretim Erişimi Gibi Koruyun
Yedek depoları, canlı sunucuyla aynı hassas bilgileri içerir; bazen daha da fazlasını. Yedek verileri aktarım sırasında ve beklemede şifreleyin. Erişimi ayrı hesaplar, least privilege izinleri, çok faktörlü kimlik doğrulama ve mümkün olan yerlerde denetim günlükleri ile kısıtlayın.
Şifreleme anahtarlarını ve kurtarma kimlik bilgilerini, olay sırasında erişilebilir olan korumalı bir konumda belgelendirin. Depo parolasını yalnızca tek bir yönetici biliyorsa, politikanın içinde gizlenmiş bir personel riski vardır. Geri yüklemeyi kimin onaylayabileceği ve korumalı kimlik bilgilerine kimin erişebileceği dâhil olmak üzere bir acil erişim süreci tanımlayın.
Saklama ve silme kontrolleri de dikkat gerektirir. Otomatik süre sonu, gereksiz depolama büyümesini önler; ancak uzun süren bir arızadan sonra bilinen son iyi kopyayı silemeyeceğinden emin olun. Mümkün olduğunda, kritik veriler için sürümleme, object lock veya değiştirilemez saklama kullanın. Bu kontroller, biri ya da kötü amaçlı bir şey kanıtları kaldırmaya çalıştığında yararlı bir sürtünme yaratır.
Planlı Olarak Geri Yükleme Testi Yapın
Geri yükleme testi, yedekleme politikası ile umutlu bir varsayım arasındaki çizgidir. En az bir temsilî geri yüklemeyi düzenli olarak test edin ve kritik hizmetleri daha sık test edin. Üç aylık tam kurtarma tatbikatı, birçok küçük ve orta ölçekli işletme için makul bir başlangıç noktasıdır; daha yüksek riskli sistemler ise aylık veya daha sık doğrulama gerektirebilir.
Yararlı bir test, dosyaları geri yüklemekten fazlasını yapar. Hizmeti yalıtılmış bir ortama kurtarın, uygulamayı başlatın, veritabanına bağlanın, kullanıcı iş akışlarını doğrulayın ve temel veri sayımlarını veya işlem kayıtlarını karşılaştırın. Bunun ne kadar sürdüğünü, hangi manuel adımların gerektiğini ve sonucun RTO ile RPO hedeflerini karşılayıp karşılamadığını kaydedin.
Zaman içinde farklı arıza senaryolarını test edin: tek bir silinmiş dosya, bozulmuş bir veritabanı, arızalı bir sunucu diski, ele geçirilmiş bir yönetici hesabı ve tam bir sunucu yeniden oluşturması. Her senaryo farklı zayıflıkları ortaya çıkarır. Günlükler artık aynı hikâyeyi anlatıyor, ancak bunu yalnızca geri yüklenen hizmeti kontrol ettikten sonra, sadece yedekleme işini değil, söyleyebilirsiniz.
Sorumluluk Atayın ve Bir Olay Runbook'u Bulundurun
Her politikanın isimlendirilmiş bir sahibi olmalıdır. Yedekleme uyarılarını kimin izlediğini, hataları kimin araştırdığını, geri yüklemeleri kimin onayladığını ve kurtarma sırasında müşterilerle veya yönetimle kimin iletişim kurduğunu belirleyin. Yönetilen destek, operasyonel işin büyük bölümünü üstlenebilir; ancak işletmenin yine de veri öncelikleri ve yetkilendirme konusunda netliğe ihtiyacı vardır.
Sunucu adları, korunan hizmetler, depo konumları, kimlik bilgisi erişim talimatları, kurtarma sırası, DNS veya load balancer adımları ve doğrulama kontrollerini içeren kısa bir geri yükleme runbook'u bulundurun. Bunu, üretim ortamı kullanılamadığında erişilebilir bir yerde saklayın. Arızalı sunucunun içine kilitlenmiş bir belge, en güzel kurtarma durumu değildir.
Politikayı; büyük uygulama değişikliklerinden, sunucu geçişlerinden, yeni entegrasyonlardan veya gerçek bir olaydan sonra gözden geçirin. Yeni müşteri veri akışları ve yeni üçüncü taraf hizmetleri, yedekleme kapsamını hızla değiştirebilir. kodu.cloud'da, yedekleme ve izleme hizmetleri günlük operasyonel yükü azaltabilir, ancak en iyi sonuçlar bu hizmetlerin net kurtarma hedefleri ve test edilmiş prosedürlerle eşleştirilmesiyle elde edilir.
Yararlı bir sonraki adım basittir: kritik bir hizmet seçin, RPO ve RTO'sunu yazın, tesis dışı kopyasının nerede bulunduğunu doğrulayın ve bu ay bir geri yükleme testi gerçekleştirin. Sakin altyapı, kimse baskı altında değilken yapılan bu küçük kontrollerle inşa edilir.
Andres Saar Müşteri Hizmetleri Mühendisi