Ana içeriğe geç

Önemli Anlarda İşe Yarayan Sunucu Yedekleme Depolaması

· 5 dakikalık okuma
Customer Care Engineer

21 Ekim 2026'da yayımlandı

Önemli Anlarda İşe Yarayan Sunucu Yedekleme Depolaması

Başarısız bir güncelleme nadiren kendini nazikçe belli eder. Bir dakika önce bir web sitesi sipariş alıyor veya potansiyel müşterilerden bilgi topluyordur. Bir sonraki dakika veritabanı geçişi ters gitmiş, disk okunamaz hâle gelmiş ya da bir hesap ihtiyaç duyduğu dosyaları silmiş olabilir. Sunucu yedekleme depolaması, böyle bir anı uzun süreli bir kesinti yerine kontrollü bir kurtarma sürecine dönüştürür.

Yedekleme, verilerin yalnızca bir kopyası değildir. Bir konumu, zamanlaması, saklama politikası ve şu rahatsız edici soruya net bir yanıtı olan bir kurtarma planıdır: İşletmenizin tolere edebileceği süre içinde önemli verileri geri yükleyebilir misiniz?

Tek bir web sitesi için yanıt basit olabilir. Bir ajans, barındırma sağlayıcısı veya birden fazla müşteri hesabı bulunan sunucu içinse daha fazla düşünmek gerekir. Amaç, mümkün olduğunca büyük bir yedekleme dosyaları yığını oluşturmak değildir. Amaç, kurtarma sürecini öngörülebilir hâle getirmektir.

Sunucu yedekleme depolamasında korunması gerekenler​

Sunucu olaylarının çoğu yalnızca tek bir veri türünü etkilemez. Yalnızca web sitesi dosyalarını geri yüklemek, veritabanı eksikse veya güncel değilse sitenin bozuk hâlde açılmasına neden olabilir. İlgili uygulama dosyaları olmadan veritabanını geri yüklemek de farklı türde bir soruna yol açabilir. İşe yarar bir yedekleme planı tek bir klasörü değil, hizmetin tamamını dikkate alır.

Birçok Linux barındırma sunucusunda bu; web sitesi dosyalarını, veritabanlarını, e-posta posta kutularını, DNS veya uygulama yapılandırmasını, SSL ile ilgili ayarları ve kullanıcı hesabı verilerini korumak anlamına gelir. WordPress siteleri barındırıyorsanız veritabanına özellikle dikkat etmeniz gerekir. Yazılar, siparişler, form girdileri, kullanıcı hesapları ve site ayarları genellikle burada bulunur. Dosyalar önemlidir; ancak sorun başlamadan beş dakika önce yapılan değişiklikler çoğunlukla veritabanında yer alır.

Sunucunun değiştirilmesi gerekene kadar yapılandırma yedeklemeleri kolayca gözden kaçabilir. Sanal ana bilgisayarları, PHP ayarlarını, zamanlanmış görevleri, e-posta yapılandırmasını ve hesap izinlerini elle yeniden oluşturmak mümkündür. Ancak bu tür işler, kısa bir kurtarma sürecini çok uzun bir akşama dönüştürebilir.

Depolamayı Umuda Göre Değil, Kurtarma Gereksinimlerine Göre Seçin​

Yerel yedeklemeler hızlı oluşturulur ve hızlı geri yüklenir. Ancak sorun sunucunun kendisindeyse onlar da risk altındadır. Disk arızası, fidye yazılımı olayı, sağlayıcı kesintisi veya yanlışlıkla silme; üretim verilerini ve yerel yedeklemesini aynı anda etkileyebilir.

Uzak yedekleme depolaması verilerinizi ayrı bir yerde tutar. Birincil sunucuya erişilemese bile kurtarma noktalarının kullanılabilir olmasını sağlayabilir. Bu, her yedeklemenin geri yükleme hızının düşük olduğu uzak bir konumda tutulması gerektiği anlamına gelmez. Planınızın tek bir makineye, hesaba veya arıza alanına bağlı kalmaması gerektiği anlamına gelir.

Pratik bir kurulumda genellikle hem yerel hem de uzak kopyalar kullanılır. Hızlı geri yüklemeler için güncel yedeklemeleri sunucuya yakın tutun, ardından daha büyük arızalara karşı koruma sağlamak için kopyaları ayrı bir depolama alanına gönderin. Doğru denge; verilerinizin boyutuna, internet bağlantınıza, kurtarma hedeflerinize ve bütçenize bağlıdır.

Küçük bir tanıtım sitesi için günlük uzak yedekleme yeterli olabilir. Düzenli sipariş alan bir e-ticaret mağazası, daha sık veritabanı yedeklemesine ihtiyaç duyabilir; çünkü bir günlük işlemi kaybetmek küçük bir aksaklık değildir. Bir barındırma sağlayıcısı, sunucudaki diğer herkesi önceki bir duruma döndürmeden tek bir müşteriyi geri yüklemeye olanak tanıyan hesap düzeyinde yedeklemelere ihtiyaç duyabilir.

Ekibinizin Uygulayabileceği Bir Sunucu Yedekleme Depolama Politikası Oluşturun​

En iyi politika, ekibiniz yorgunken ve telefonlar susmazken bile anlayabileceği politikadır. Nelerin yedeklendiğini, yedeklemenin ne sıklıkta çalıştığını, kopyaların nerede saklandığını, ne kadar süreyle tutulduğunu ve geri yüklemeyi kimin yapabileceğini belirtmelidir.

Kurtarma noktası hedefi ve kurtarma süresi hedefiyle başlayın. Kurtarma noktası hedefi, ne kadar veri kaybetmeyi göze alabileceğinizi belirtir. Yedeklemeler 24 saatte bir çalışıyorsa neredeyse bir günlük veriyi kaybetme olasılığınız vardır. Kurtarma süresi hedefi, bir hizmetin ne kadar hızlı yeniden kullanıma açılması gerektiğini belirtir. İndirilmesi 10 saat süren bir yedekleme arşiv için uygun olabilir; ancak bu sabah çevrimiçi olması gereken ve gelir getiren bir site için uygun değildir.

Saklama süresi de aynı ölçüde pratik bir yaklaşımla belirlenmelidir. Günlük kopyaları yedi ila 30 gün saklamak yaygındır; ancak bu, birkaç hafta boyunca fark edilmemiş bir sorunu yakalamaya yetmeyebilir. Aylık kurtarma noktaları bu konuda yardımcı olabilir. Öte yandan, her yedeklemeyi sonsuza kadar saklamak maliyet, karmaşa ve gerçekte hangisinin geri yüklenmesi gerektiğine dair belirsizlik yaratır.

Başlangıç için birçok ekip dört katmanlı kurtarma noktası saklar:

  • yakın zamandaki değişiklikler için sık yedeklemeler
  • rutin geri yüklemeler için günlük yedeklemeler
  • daha sonra keşfedilen sorunlar için haftalık yedeklemeler
  • uzun vadeli kurtarma ihtiyaçları için aylık yedeklemeler

Kesin zamanlama değişmez bir kural değildir. Önemli olan, web sitelerinizin ve müşterilerinizin çalışma biçimine uymasıdır.

Otomasyon En Yaygın Arızayı Önler​

Birileri seyahatteyken, müşteri işleriyle meşgulken veya geçen cuma alınan kopyanın herhâlde yeterli olduğunu düşünürken elle yedekleme yapmak kolay görünür. Otomatik yedekleme işleri, sürecin belleğe bağlı olmasını önler. Ayrıca, bir acil durum ortaya çıkarmadan önce hataları fark etmeyi kolaylaştırır.

Yedekleme sisteminiz, işlerin başarıyla tamamlanıp tamamlanmadığını ve depolama alanının tükenmek üzere olup olmadığını bildirmelidir. Ancak tamamlanmış bir iş her zaman işe yarar bir yedekleme anlamına gelmez. Veritabanı dışa aktarımı boşsa, yedekleme hedefine erişilemiyorsa veya hariç tutulan bir dizinde kritik dosyalar bulunuyorsa iş başarılı görünürken geri yükleme eksik kalabilir.

Bu nedenle görünürlük önemlidir. Bir sunucu kontrol paneli; zamanlanmış yedeklemeleri, hedef ayarlarını ve hesap düzeyinde kurtarmayı, her işi komut satırında yapılacak bir uygulamaya dönüştürmeden yönetmeyi kolaylaştırabilir. FASTPANEL, yöneticilere alttaki sunucu üzerinde denetim olanağı sunarken bu rutin barındırma görevlerini görünür ve yönetilebilir kılmak üzere tasarlanmıştır.

Yedekleme kimlik bilgilerini herkese açık web dizinlerinde saklamaktan veya tüm müşteriler için geniş erişimli tek bir depolama hesabını paylaşmaktan kaçının. Mümkün olduğunda ayrı kimlik bilgileri kullanın, erişimi gereken en düşük düzeyle sınırlayın ve yedeklemeleri kimin silebileceğini gözden geçirin. Sunucuya erişim sağlayan bir saldırgan, tüm kurtarma kopyalarını kolayca silememelidir.

İhtiyaç Duymadan Önce Geri Yüklemeleri Test Edin​

Hiç geri yüklenmemiş bir yedekleme, yalnızca bir varsayımdır. Test etmek onu kanıta dönüştürür.

Her yedeklemeyi test etmek için üretim sitesini aksatmanız gerekmez. Yakın tarihli bir web sitesini veya veritabanını hazırlık ortamına, geçici bir alt alan adına ya da başka bir yalıtılmış konuma geri yükleyin. Dosyaların mevcut olduğunu, veritabanının doğru şekilde içe aktarıldığını, uygulamanın bağlanabildiğini ve önemli işlevlerin çalıştığını kontrol edin. WordPress sitesi için bu; oturum açmayı, sayfaları yüklemeyi, form göndermeyi ve medya dosyalarının görüntülendiğini doğrulamayı içerebilir.

En yeni yedeklemeden fazlasını test edin. Yakın tarihli bir kopya sorunsuz çalışırken saklanan daha eski bir sürüm bozulmuş, eksik veya bulunamaz durumda olabilir. Düzenli testler, belgelerinizin sistemi kuran kişi dışındaki biri tarafından da anlaşılacak kadar açık olup olmadığını gösterir.

Yedeklemenin konumunu, erişim yöntemini, beklenen geri yükleme süresini, yedek sunucu devreye giriyorsa DNS adımlarını ve kararları onaylayabilecek kişilerin iletişim bilgilerini içeren kısa bir kurtarma kılavuzu hazırlayın. Bu bürokrasi değildir. Baskı altındayken doğaçlama yapmak zorunda kalmamanızı sağlar.

Ödünleşimleri Göz Önünde Bulundurun​

Daha sık yedekleme, daha fazla depolama alanı kullanır ve yoğun bir sunucuya ek yük getirebilir. Tam yedeklemeleri geri yüklemek kolaydır, ancak daha fazla alan kaplar. Artımlı yedeklemeler depolama kullanımını ve yedekleme süresini azaltabilir; ancak kurtarma, birbirine bağlı bir yedekleme kümesine bağlı olabilir. Şifreleme, depolanan verileri korur; ancak şifreleme anahtarlarının kaybolması yedeklemelerinizi kullanılamaz hâle getirebilir.

Her duruma uyan tek bir ayar yoktur. Veritabanı ağırlıklı bir uygulama, sık veritabanı yedeklemelerinin yanı sıra daha seyrek dosya yedeklemelerine ihtiyaç duyabilir. Çoğunlukla statik olan bir şirket sitesi, dakika dakika kurtarma yerine tesis dışındaki kopyalara öncelik verebilir. Barındırma işletmeleri için tek bir hesabı sorunsuz biçimde geri yüklemek, sunucunun tamamının görüntüsünü hızla geri yüklemekten daha önemli olabilir.

Sorulması gereken doğru soru, “Mükemmel yedekleme stratejisi nedir?” değildir? Asıl soru şudur: “Hangi arızaya hazırlıklıyız ve bu arızadan ne kadar hızlı kurtulabiliriz?”

Kurtarma İmkânını Elinizin Altında Tutun​

Sunucu yedekleme depolamasının değeri, zamanlanmış bir işin çalıştığını bildirdiği gün değil, bir şeylerin bozulduğu gün ortaya çıkar. Net kurtarma hedefleri belirleyin, kopyaları üretim sunucusundan ayrı tutun, yalnızca görünür dosyaları değil hizmetin tamamını koruyun ve geri yüklemeleri düzenli olarak test edin.

Böylece bir güncelleme beklenmedik biçimde davrandığında veya bir disk ömrünü tamamladığına karar verdiğinde kurtarma, ekibinizin kriz anında yolunu bulmaya çalışacağı bir durum olmaktan çıkar ve izleyebileceği bir sürece dönüşür.