Web Siteleri için Yedekleme Saklama Politikası Rehberi

6 Kasım 2026'da yayımlandı

Mevcut olduğu hâlde web sitenizin doğru sürümünü geri yükleyemeyen bir yedek, gece 2'de pek teselli etmez. Uygulanabilir bir yedekleme saklama politikası rehberi basit bir soruyla başlar: Bir şey bozulduğunda, silindiğinde veya güvenliği ihlal edildiğinde ne kadar geriye gitmeniz gerekebilir?

Küçük bir işletme sitesi için yanıt birkaç hafta olabilir. Müşterilerinin mağazalarını, veritabanlarını ve e-postalarını yöneten bir ajans için bu süre birkaç ay veya daha uzun olabilir. Doğru politika, tüm yedekleri sonsuza kadar saklamakla ilgili değildir. Depolama maliyetlerini ve yönetimini başka bir soruna dönüştürmeden gerçek sorunları çözmeye yetecek sayıda temiz ve kurtarılabilir kopyayı saklamakla ilgilidir.

Yedekleme saklama politikası gerçekte ne işe yarar

Yedekleme planı, kopyaların ne zaman oluşturulacağını belirtir. Saklama politikası ise her kopyanın silinmeden önce ne kadar süre kullanılabilir durumda kalacağını belirtir. Her ikisine de ihtiyacınız var.

Saklama kuralları olmazsa depolama alanı sessizce dolar ve sonunda yedeklemeler başarısız olur ya da faturalar gereksiz yere yükselir. Kurallar çok katıysa ihtiyacınız olan tek yedek zaten silinmiş olabilir. Bu, insanların beklediğinden daha sık yaşanır: bozuk bir eklenti güncellemesi birkaç gün fark edilmeyebilir, yanlışlıkla silinen bir dosya ay sonunda fark edilebilir ya da bir veritabanı sorunu yakın tarihli tüm yedeklere kopyalanmış olabilir.

İyi bir politika, kısa vadeli kurtarmayı uzun vadeli korumadan ayırır. Yakın tarihli yedekler, başarısız bir dağıtım veya bozuk bir WordPress güncellemesi gibi yaygın olaylarda işe yarar. Daha eski geri yükleme noktaları, yavaş gelişen sorunlarda, denetimlerde, dönemsel raporlamada veya tespit edilmesi zaman alan bir ihlalde yardımcı olur.

Depolama alanıyla değil, kurtarma ihtiyaçlarıyla başlayın

Saklama sürelerini mevcut depolama alanına göre belirlemek cazip gelebilir. Bunun yerine risklerden başlayın. Depolama yönetilmesi gereken bir maliyettir, ancak kaybedilen web sitesi verileri, kaçırılan siparişler ve uzun süreli kesintiler genellikle daha pahalıya mal olur.

İki kurtarma hedefi, karar vermeyi kolaylaştırır. Kurtarma Noktası Hedefiniz (RPO), kaybetmeyi göze alabileceğiniz en fazla veri miktarıdır. Bir çevrimiçi mağaza en fazla bir saatlik sipariş kaybını göze alabiliyorsa, en az bu sıklıkta yedekleme veya veritabanı koruması gerekir. Haftada bir güncellenen tanıtım sitesi çok daha uzun bir aralığı tolere edebilir.

Kurtarma Süresi Hedefiniz (RTO), hizmetin ne kadar sürede yeniden çalışır hâle gelmesi gerektiğini belirtir. Bir yedek ancak bu süre içinde geri yükleyebiliyorsanız işe yarar. Günlük yedeklemeler RPO'nuzu karşılayabilir, ancak büyük bir sunucuyu uzak depolama alanından geri yüklemek yine de RTO'nuzu aşmanıza neden olabilir. Saklama ve kurtarma hızı birlikte planlanmalıdır.

Çoğu web sitesi için sistemleri etkilerine göre sınıflandırın. Kişisel bir portföy sitesi, şirketin pazarlama sitesi, yoğun bir WooCommerce mağazası, müşteriye ait bir barındırma hesabı ve bir posta sunucusu otomatik olarak aynı kurallara tabi olmamalıdır. Veriler ne kadar sık değişiyor ve gelir ya da güven onlara ne kadar bağlıysa yedeklemeler de o kadar sık alınmalı ve daha dikkatli saklanmalıdır.

Uygulanabilir bir yedekleme saklama politikası rehberi

Katmanlı bir plan işe yarar; çünkü her tam yedeği süresiz saklamadan sık geri yükleme noktaları sağlar. Tipik bir işletme web sitesi için makul bir başlangıç noktası; günlük yedekleri 14 ila 30 gün, haftalık yedekleri 8 ila 12 hafta, aylık yedekleri ise 6 ila 12 ay saklamaktır.

Bu bir başlangıç noktasıdır, değişmez bir kural değil. İçeriği her gün güncellenen bir site için 30 günlük sürüm gerekebilir. Bir e-ticaret işletmesinin, özellikle indirim dönemlerinde, daha sık veritabanı yedeklemesine ihtiyacı olabilir. Büyük bir yeniden tasarım üzerinde çalışan geliştirici, sürüm kararlı hâle gelene kadar saklama süresini geçici olarak uzatabilir. Küçük, statik bir site haftalık ve aylık kopyalarla iyi korunabilir.

Mali, sözleşmeye dayalı veya düzenlemeye tabi kayıtları olan sistemler için daha uzun saklama süreleri gerekebilir. Ancak operasyonel yedekleme saklama süresini resmî kayıt saklama süresiyle karıştırmayın. Yedekleme, kurtarma amacıyla tasarlanır. Hukuki arşivler için her zaman doğru biçim, erişim yöntemi veya kontrol sistemi olmayabilir. İşletmenizin mevzuata uyum gereklilikleri varsa bunları uygun hukuki veya operasyonel yönlendirmeyle ayrıca tanımlayın.

Değişiklikler sırasında daha fazla sürüm saklayın

Risk yılın her dönemine eşit dağılmaz. Büyük eklenti güncellemeleri, geçişler, sunucu değişiklikleri, yeni entegrasyonlar ve toplu içe aktarımlar, web sitesinin en çok beklenmedik davranışlar sergileyebileceği anlardır.

Değişiklikten önce doğrulanmış bir yedek oluşturun. Yeni sürüm makul bir süre boyunca düzgün çalışana kadar yedeği normalden daha uzun süre saklayın. Örneğin, bir müşteri sitesini taşırsanız müşteri formların, e-posta teslimatının, ödemelerin ve önemli sayfaların beklendiği gibi çalıştığını onaylayana kadar taşıma öncesi yedeği saklayın.

Bu küçük alışkanlık yaygın bir hatayı önler: sorunun birkaç hafta önce başladığını fark etmeden hemen önce bilinen son sağlam kopyayı silmek.

3-2-1 ilkesini zahmetli hâle getirmeden uygulayın

3-2-1 yaklaşımı, farklı türdeki arızalara karşı koruma sağladığı için hâlâ kullanışlıdır. Önemli verilerin en az üç kopyasını, iki farklı depolama türünde tutun ve kopyalardan birini tesis dışında saklayın.

Bir web sitesi için bu; sunucudaki canlı veriler, yerel veya sağlayıcı tarafından yönetilen bir yedek ve ayrı bir yedekleme depolama alanında saklanan şifrelenmiş bir kopya anlamına gelebilir. Önemli olan ayrıştırmadır. Yalnızca aynı sunucuda saklanan yedekler, sunucuyla birlikte kaybolabilir. Aynı hesapta tutulan yedekler, ele geçirilmiş kimlik bilgilerinden aynı şekilde etkilenebilir.

Tesis dışı depolama karmaşık olmak zorunda değildir. Bu, kopyanın kurtarmaya çalıştığınız arızadan korunduğu anlamına gelir. Ekibinizin gerçekten sürdürebileceği bir depolama konumu ve erişim modeli seçin.

Yedekleri silinmeye ve fid yazılımlarına karşı koruyun

Yedekleme politikası; yedekleri kimin silebileceğini, saklama ayarlarını kimin değiştirebileceğini ve kurtarma verilerine kimin erişebileceğini belirtmelidir. Bu izinler önemlidir; çünkü yönetici erişimi elde eden bir saldırgan, üretim verilerini şifrelemeden veya silmeden önce kurtarma noktalarını kaldırmaya çalışabilir.

Mümkün olduğunda, belirli bir süre için değiştirilemez veya yazmaya karşı korumalı yedekler kullanın. Bu, geniş erişim yetkisine sahip bir hesap tarafından bile yedeklerin vaktinden önce değiştirilmesini veya silinmesini önler. Bu özellik; kritik siteler, barındırma sağlayıcıları ve birden fazla müşteri ortamından sorumlu ajanslar için özellikle değerlidir.

Şifreleme de önemlidir. Yedeklemeler çoğu zaman veritabanları, yapılandırma dosyaları, müşteri verileri ve bazen kimlik bilgileri içerir. Verileri aktarım sırasında ve depolandıkları yerde şifreleyin, erişimi yalnızca ihtiyacı olan kişilerle sınırlandırın ve kurtarma anahtarlarını güvenli biçimde saklayın. Kusursuz biçimde saklanan ancak kimsenin şifresini çözemediği bir yedek de başarısız bir kurtarma planı demektir.

İhtiyaç duymadan önce geri yüklemeleri test edin

Yedeklemenin başarılı olduğuna dair iletiler, geri yükleme testi değildir. Bir görev başarıyla tamamlanırken arşiv eksik olabilir, veritabanı dökümü zarar görmüş olabilir veya geri yükleme işlemi ihtiyaçlarınızı karşılayamayacak kadar yavaş olabilir.

Sistemin önemine uygun aralıklarla geri yükleme testi yapın. Basit bir site için üç ayda bir test yeterli olabilir. Yoğun trafiğe sahip mağazalar ve barındırma ortamları, özellikle yedekleme araçlarını, sunucu yapılandırmalarını veya depolama hedeflerini değiştirdikten sonra, daha sık test edilmelidir.

Mümkün olduğunda, geri yüklemeyi güvenli bir hazırlık ortamında gerçekleştirin. Yalnızca ana sayfanın yüklenip yüklenmediğini kontrol etmekle yetinmeyin. Veritabanının bağlandığını, yakın tarihli içeriğin mevcut olduğunu, kullanıcı oturum açma işlemlerinin çalıştığını, medya dosyalarının görüntülendiğini, zamanlanmış görevlerin yürütüldüğünü ve ödeme ya da iletişim formu entegrasyonlarının normal şekilde çalıştığını doğrulayın. Kurtarmanın ne kadar sürdüğünü ve hangi adımların zorluk çıkardığını kaydedin. Bu kayıt, bir olay sırasında elinizde olmasına sevineceğiniz iş akışı kılavuzuna dönüşür.

Politikayı başkasının da uygulayabileceği şekilde yazın

Saklama politikası bir veya iki sayfayı geçmemeli, herkesin açmaktan kaçındığı bir belgeye dönüşmemelidir. Nelerin yedeklendiğini, yedeklemenin ne sıklıkta çalıştığını, her yedek türünün ne kadar süre saklandığını, kopyaların nerede tutulduğunu, süreçten kimin sorumlu olduğunu ve geri yüklemelerin nasıl test edildiğini belirtin.

İstisnaları da tanımlayın. Örneğin, yüksek hacimli bir veritabanına sahip müşteri hesabında daha sık yedekleme yapılabilirken arşivlenmiş projeler yalnızca aylık saklamaya geçirilebilir. İstisnaları belgelemek, ayarların gizemli, tek seferlik kararlar yığınına dönüşmesini önler.

FASTPANEL kullanıcıları, ayarları birkaç farklı araçta aramak yerine web sitelerini, veritabanlarını ve sunucu işlemlerini tek ve anlaşılır bir kontrol panelinden yöneterek bu çalışmayı daha görünür kılabilir. Görünürlük politikanın yerini tutmaz, ancak politikayı uygulamayı çok daha kolay hâle getirir.

Ortalık sakinken saklama politikanız sıkıcı görünmelidir. Bu bir iltifattır. Kötü bir güncelleme, başarısız bir geçiş veya yanlışlıkla silme yaşandığında sıkıcı olması; doğru kopyanın hâlâ durduğu, geri yükleme yolunun bilindiği ve ekibinizin sağlam bir başlangıç noktasına sahip olduğu anlamına gelir.