Paniğe Kapılmadan Sunucu Yedekleri Nasıl Yönetilir
3 Ağustos 2026 tarihinde yayımlandı
Bir geri yükleme talebi nadiren uygun bir zamanda gelir. Bu, bir güncelleme bir yapılandırmanın üzerine yazdıktan, bir veritabanı tablosu ortadan kaybolduktan, fidye yazılımı paylaşılan bir dizine ulaştıktan veya bir disk artık yeterince çalıştığına karar verdikten sonra gelir. Sunucu yedeklerinin nasıl yönetileceğini bilmek, bu an tam kapsamlı bir acil duruma dönüşmeden önce ona hazırlanmak anlamına gelir.
İyi bir yedekleme planı, mümkün olan en büyük arşivi toplamaktan ibaret değildir. Asıl mesele, birincil sunucu kullanılamadığında erişebileceğiniz yerlerde, doğru kopyaları doğru süre boyunca saklamaktır. Ayrıca, birinin bunu kontrol edebileceği, buna güvenebileceği ve sabah 2'de kahramanca yazılmış bir shell scriptinin şifresini çözmeden buradan geri yükleme yapabileceği kadar basit olmalıdır.
Yedekleme Yazılımıyla Değil, Kurtarmayla Başlayın
Bir zamanlama veya depolama konumu seçmeden önce, her hizmet için kurtarmanın nasıl görünmesi gerektiğine karar verin. Kişisel bir portföy sitesi, bir günlük değişikliği kaybetmeyi tolere edebilir. Her saat sipariş alan bir çevrim içi mağaza muhtemelen edemez. İkisi de aynı sunucuda çalışsa bile bunlar farklı yedekleme gereksinimleridir.
İki hedef bunu pratik hâle getirir. Kurtarma noktası hedefiniz yani RPO, kaybetmeyi göze alabileceğiniz en yüksek veri miktarıdır. RPO dört saatse, yedeklemeler veya çoğaltma değişiklikleri en az dört saatte bir yakalamalıdır. Kurtarma süresi hedefiniz yani RTO, hizmetin ne kadar hızlı yeniden kullanılabilir olması gerektiğidir. Büyük bir arşivden tam sunucu geri yüklemesi, küçük bir iç araç için kabul edilebilir olabilir; ancak dakikalar içinde geri dönmesi gereken yoğun trafiğe sahip, müşteri odaklı bir site için kötü bir seçimdir.
Web siteleri, veritabanları, posta kutuları, uygulama dosyaları ve sunucu yapılandırması için bu hedefleri yazın. Bu küçük adım yaygın bir hatayı önler: Sunucudaki her dosyaya eşit derecede acil muamelesi yapmak, ardından kimsenin doğrulamaya vakit bulamadığı pahalı ve yavaş yedeklemeler oluşturmak.
Gerçekte Nelerin Korunması Gerektiğini Bilin
Bir sunucu yedeği, çalışan bir hizmeti yeniden kurmak için gereken parçaları içeriyorsa işe yarar. İçerik, kullanıcılar, siparişler ve ayarlar bir veritabanında yaşıyorsa yalnızca web sitesi dosyaları yeterli değildir. Uygulama yüklemelere, ortam değişkenlerine, SSL sertifikalarına veya web sunucusu yapılandırmasına bağlıysa yalnızca bir veritabanı dökümü yeterli değildir.
Çoğu barındırma ortamı için dört alanı koruyun: web sitesi ve uygulama dosyaları, veritabanları, uygun olduğunda posta verileri ve sunucu veya hesap yapılandırması. Zamanlanmış görevleri, yerel olarak barındırılıyorlarsa DNS ayarlarını ve yeniden oluşturması zahmetli olacak özel hizmet ayarlarını da ekleyin. API anahtarları ve ortam dosyaları gibi gizli bilgileri koruyun, ancak bunları plandan sessizce çıkarmayın.
Hesap düzeyindeki yedeklemeleri tam sunucu yedeklemelerinden ayırmak da yardımcı olur. Tek bir site veya müşterinin yardıma ihtiyacı olduğunda hesap yedeklemeleri daha hızlı geri yüklenir. Tam sunucu görüntüleri, büyük bir arıza, taşıma veya felaket düzeyinde yanlış yapılandırmadan sonra değerlidir. Biri diğerinin yerini tutmaz.
Sunucu Yedekleri Net Bir Zamanlamayla Nasıl Yönetilir
Doğru zamanlama, verilerin ne sıklıkla değiştiğini izler. Çoğunlukla statik bir web sitesi için haftalık tam yedekleme ve önemli değişikliklerden önce bir yedekleme yeterli olabilir. Günlük yayın yapılan WordPress siteleri için günlük dosya ve veritabanı yedeklemeleri daha güvenli bir başlangıç noktasıdır. Mağazalar, üyelik platformları, rezervasyon sistemleri ve aktif SaaS uygulamaları, işlemler dünkü tema dosyalarından daha önemli olduğu için genellikle daha sık veritabanı yedeklemesine ihtiyaç duyar.
Pratik bir yaklaşım, düzenli tam yedeklemelerin yanında sık artımlı yedeklemeler çalıştırmaktır. Artımlı yedeklemeler yalnızca önceki yedeklemeden bu yana değişenleri kaydeder; bu da depolama kullanımını ve yedekleme sürelerini azaltır. Tam yedeklemeler daha temiz bir kurtarma dayanağı sağlar, ancak daha fazla zaman ve alan tüketir. Ödünleşim açıktır: daha sık geri yükleme noktaları veri korumasını iyileştirirken daha fazla yedekleme işi daha fazla depolama, izleme ve saklama çalışması oluşturur.
Sırf geleneksel hissettirdiği için her görevi gece yarısına planlamaktan kaçının. Veritabanları, sıkıştırma, dosya taramaları ve aktarımların tümü CPU, disk G/Ç ve ağ kapasitesi için rekabet edebilir. Yedeklemelerin yoğun bir siteyi en yoğun saatlerinde yavaşlatmaması için işleri kademeli planlayın. Müşterileriniz birden fazla zaman dilimindeyse tahmin yürütmek yerine gerçek trafik düzenlerini kontrol edin.
Birden Fazla Kopyayı, Birden Fazla Yerde Tutun
Bilinen 3-2-1 kuralı hâlâ faydalıdır: verilerin üç kopyasını, iki farklı depolama türünde tutun ve bir kopyayı tesis dışı saklayın. Fidye yazılımına veya hesap ele geçirilmesine maruz kalan sunucular için bir koruma daha ekleyin: bir yedeği belirli bir süre boyunca silinmeye ve değiştirilmeye karşı değiştirilemez ya da başka şekilde korumalı tutun.
Yerel yedeklemeler küçük geri yüklemeler için kullanışlı ve hızlıdır, ancak felaket kurtarma değildir. Sunucunun diski arızalanırsa, veri merkezinde kesinti olursa veya bir saldırgan yönetici erişimi kazanırsa yerel kopyalar sunucuyla birlikte kaybedilebilir. Yedekleri ayrı olarak, ideal olarak farklı bir konumda ve ayrı kimlik bilgileri altında saklayın.
Saklama, sıklık kadar düşünülmeyi hak eder. Yalnızca en son yedeği tutmak donanım arızasına karşı korur, ancak haftalarca fark edilmeyen bir soruna karşı korumaz. Mantıklı bir saklama politikası genellikle kısa vadeli günlük kopyaları, birkaç haftalık kopyayı ve birkaç aylık arşivi birleştirir. Tam sayılar depolama maliyetlerine, uyumluluk gereksinimlerine ve kullanıcıların eksik veya bozuk verileri fark etmesinin genellikle ne kadar sürdüğüne bağlıdır.
Varsayılan olarak yedekleri sonsuza kadar saklamayın. Depolama alanı fark edilmeden dolar, geri yükleme seçenekleri kafa karıştırıcı hâle gelir ve eski arşivler artık elinizde tutmanız için bir neden olmayan verileri saklayabilir. Saklama kuralları belirleyin, bunları düzenli olarak gözden geçirin ve yalnızca gerçek bir iş gerekçesi olduğunda istisna yapın.
Yedekleme Sistemini Üretim Ortamı Gibi Koruyun
Yedekleme arşivleri canlı sunucuyla aynı değerli bilgileri, bazen daha da fazlasını içerir. Bunların kendi güvenlik kontrollerine ihtiyacı vardır. Yedekleri aktarım sırasında ve beklemede şifreleyin, yedek depolama için ayrı kimlik bilgileri kullanın ve arşivleri kimin silebileceğini veya saklama ayarlarını değiştirebileceğini sınırlayın.
En güvenli tasarım, üretim erişimini yedek erişiminden ayırır. Ele geçirilmi ş bir web sitesi hesabı, onu kurtarmak için tutulan kopyaları silememelidir. Mümkün olduğunda kısıtlı hizmet kimlik bilgileri, yönetici erişimi için çok faktörlü kimlik doğrulama ve son yedeklerin hemen silinmesini önleyen depolama politikaları kullanın.
Ayrıca yedek verilerinin boyutunu da izleyin. Geçici dosyalar, önbellekler, bağımlılık klasörleri, eski günlükler ve oluşturulmuş küçük görseller küçük bir siteyi çok büyük bir arşive dönüştürebilir. Atılabilir dosyaları hariç tutmak para tasarrufu sağlar ve kurtarmayı hızlandırır. Yine de dikkatli olun: bir dizini yalnızca zahmetli göründüğü için asla hariç tutmayın. Bunun yeniden üretilebildiğini ve burada hiçbir uygulama verisinin bulunmadığını doğrulayın.
Veritabanı Yedeklemelerini Tutarlı Hâle Getirin
Veritabanları, yedekleme işiniz çalışırken değiştikleri için özel muameleyi hak eder. Veritabanını bilen bir süreç olmadan ham veritabanı dosyalarını kopyalamak, tam görünen ancak temiz şekilde geri yüklenemeyen bir arşiv üretebilir.
Veritabanı motoru ve iş yükü için tasarlanmış bir yöntem kullanın. Mantıksal dökümler taşınabilir ve incelenmesi kolaydır, ancak büyük veritabanlarında daha yavaş olabilir. Fiziksel yedeklemeler büyük sistemler için genellikle daha hızlıdır ve zaman noktasına kurtarmayı destekleyebilir, ancak yönetimleri daha karmaşık olabilir. Birçok web sitesi iş yükü için düzenli veritabanı dökümlerini sık işlem günlüğü yedeklemeleri veya çoğaltmayla eşleştirmek mantıklı bir denge sağlar.
Geri yüklendiğinde uygulama dosyalarıyla veritabanı verilerinin eşleştiğini test edin. Dünün yüklemeleriyle birlikte öğlen alınmış bir veritabanını geri yüklemek, bozuk ürün görselleri, eksik belgeler veya var olmayan dosyalara işaret eden kayıtlar oluşturabilir.
İhtiyacınız Olmadan Önce Geri Yüklemeleri Test Edin
Başarılı bir yedekleme işi yalnızca bir dosyanın oluşturulduğunu kanıtlar. Arşivin eksiksiz olduğunu, parolanın erişilebilir olduğunu, depolama hesabına ulaşılabildiğini veya uygulamanın geri yüklemeden sonra çalışacağını kanıtlamaz.
Bir geri yükleme testi zamanlaması belirleyin. Kritik hizmetler için aylık veya büyük değişikliklerden sonra test edin. Daha düşük riskli siteler için üç ayda bir makul olabilir. Canlı bir hizmetin üzerine yazmamak için yalıtılmış bir konuma geri yükleyin, ardından veritabanını, dosya izinlerini, site davranışını, zamanlanmış görevleri ve önemli tüm entegrasyonları kontrol edin.
Süreyi ölçün ve sonucu kaydedin. Bir geri yükleme altı saat sürüyorsa ancak üzerinde anlaşılan RTO iki saatse, düzeltmek için hâlâ zaman varken bir planlama boşluğu bulmuşsunuz demektir. Bu, daha sonra çok gürültülü bir olayı önleyen tam da bu tür sessiz operasyonel iştir.
Arızaları İzleyin ve Kurtarma Yolunu Belgelendirin
Yedekleme yönetimi, birinin bir günlük dosyasına bakmayı hatırlamasına bağlı olamaz. Başarısız işler, atlanan zamanlamalar, düşük depolama kapasitesi, aktarım hataları ve alışılmadık derecede küçük veya büyük yedek boyutları için uyarılar yapılandırın. Bir yedek aniden 40 GB'tan 400 MB'a düşerse, en çok ihtiyaç duyduğunuz verileri hariç bırakmış olabilir.
Depolama konumu, erişim süreci, şifreleme anahtarı konumu, geri yükleme adımları, beklenen kurtarma süreleri ve kararlardan sorumlu kişiyle birlikte kısa bir kurtarma runbook'u tutun. Sunucu kapalı olsa bile erişilebilir bir yerde tutun. FASTPANEL gibi bir kontrol paneli, rutin web sitesi, veritabanı ve hesap yedekleme görevlerini tek yerde görmeyi kolaylaştırabilir; ancak alttaki politika yine de sahiplenme ve düzenli kontroller gerektirir.
Amaç, bir diyagramda etkileyici görünen karmaşık bir yedekleme mimarisi değildir. Amaç, ekibinizin güncel kopyalar ve net kararlarla sakince uygulayabileceği bir kurtarma sürecidir. Bu süreci şimdi oluşturun; böylece bir sonraki bozuk güncelleme olması gerektiği şey olarak kalabilir: bir felaket değil, bir aksaklık.