İşe Yarayan Web Sitesi Yedek Saklama Politikası
14 Ağustos 2026 tarihinde yayımlandı
Web siteleri için bir yedek saklama politikası size birkaç yakın tarihli geri yükleme noktası, birkaç eski kurtarma seçeneği ve en azından siteyi çalıştıran sunucunun dışında bir kopya sağlamalıdır. Bir eklenti güncellemesi saat 10:15'te ödeme sürecini bozarsa, geçen salıdan kalma bir yedeğe ve umutlu bir bakışa değil, saat 10:00'dan temiz bir sürüme ihtiyacınız vardır.
Doğru zamanlama, verilerinizin ne sıklıkta değiştiğine, kesinti süresinin ne kadara mal olduğuna ve ekibinizin bir sorunun ne zaman başladığını ne kadar hızlı tespit edebildiğine bağlıdır. Statik bir şirket sitesi ile yoğun bir WooCommerce mağazası aynı şekilde korunmamalıdır. Hizmet çevrimiçi olabilir, ancak dünkü siparişler, form gönderimleri veya müşteri değişiklikleri eksikse her şey yeniden tam anlamıyla yoluna girmiş sayılmaz.
Bir Web Sitesi Yedek Saklama Politikası Neleri Kapsamalı
Saklama, yalnızca tuttuğunuz yedek sayısı değildir. Hangi yedek kopyalarının erişilebilir kalacağını, nerede depolanacağını, ne kadar süre orada tutulacağını ve ne zaman silineceğini belirleyen kurallar bütünüdür.
Kullanışlı bir politika, üç ayrı kurtarma ihtiyacını hesaba katar. Birincisi, yakın tarihli hatalar için hızlı operasyonel kurtarmaya ihtiyacınız vardır: hatalı bir dağıtım, silinen dosyalar, başarısız bir güncelleme veya kazara yapılan bir yapılandırma değişikliği. İkincisi, ele geçirilmiş yönetici erişimi veya bulaşmış kod gibi, haftalarca sessizce varlığını sürdüren bir sorun olduğunda geçmişe dönük kurtarmaya ihtiyacınız vardır. Üçüncüsü, ticari, sözleşmesel veya düzenleyici nedenlerle saklanması gereken kayıtlara ihtiyacınız olabilir.
Bu hedefler birbiriyle çelişebilir. Her yedeği sonsuza kadar saklamak, depolama maliyeti, daha yavaş yedek işleri ve kafa karıştırıcı bir geri yükleme listesi yaratır. Çok az tutmak ise, tam ihtiyacınız olan yedeğin süresi dolana kadar yer kazandırır. Mantıklı yanıt, aynı günlük yedeklerden oluşan tek uzun bir sıra değil, katmanlı saklamadır.
Depolama Sayısıyla Değil, Kurtarma Hedefleriyle Başlayın
Saklama sürelerini belirlemeden önce iki pratik hedef tanımlayın: recovery point objective ve recovery time objective.
Genellikle RPO olarak adlandırılan recovery point objective, ne kadar yakın tarihli veriyi kaybetmeyi göze alabileceğinizi yanıtlar. Gün boyunca sipariş işleyen bir e-ticaret mağazası, saatlik veritabanı yedeklerine veya işlem farkındalığı olan yedeklere ihtiyaç duyabilir. Ayda iki kez güncellenen bir tanıtım sitesi, kritik iletişim formu verileri başka yerde ele alınıyorsa günlük bir yedeği kabul edebilir.
RTO olarak da bilinen recovery time objective, sitenin ne kadar hızlı geri yüklenmesi gerektiğini yanıtlar. Yerel olarak veya yakındaki yedek depolamada saklanan yakın tarihli bir yedek, genellikle soğuk bir arşivden daha hızlı geri yüklenebilir. Ancak yalnızca yerel kopyalar yeterli değildir. Bir sunucu arızası, fidye yazılımı olayı, hatalı disk işlemi veya hesap düzeyinde ele geçirilme, siteyi ve onun yerel yedeklerini birlikte etkileyebilir.
Çoğu işletme web sitesi için bu hedefleri sade bir dille tanımlayın. Örneğin: “En fazla bir saatlik siparişi kaybedebiliriz ve vitrinin iki saat içinde geri yüklenmiş olması gerekir.” Bu, “günlük yedek alıyoruz” deyip daha sonra günlük ifadesinin her 24 saatte bir anlamına geldiğini keşfetmekten çok daha kullanışlıdır.
Gerçekte Nelerin Değiştiğini Kontrol Edin
Web sitesi dosyaları ve veritabanı verileri aynı hızda değişmez. WordPress çekirdek dosyaları aylarca dokunulmadan kalabilirken veritabanı gün boyu siparişler, yorumlar, rezervasyonlar, üyelik değişiklikleri ve form girdileri alabilir.
Eksiksiz bir yedek; uygulama dosyalarını, veritabanlarını, yapılandırma dosyalarını, yüklenen medyaları, ilgili olduğu yerlerde SSL ile ilgili yapılandırmayı, zamanlanmış görev tanımlarını ve web kökünün dışında depolanan tüm özel uygulama verilerini içermelidir. Bir veritabanı yedeği başarılı olur ancak yükleme dizini hariç tutulursa, geri yüklenen site çalışabilirken ürün görselleri veya müşteri belgeleri sessizce ortadan kaybolabilir.
Daha büyük bir uygulama için bağımlılıkları da belgelendirin. Nesne depolama, posta hizmetleri, ödeme sistemleri, harici veritabanları ve DNS kayıtları bir sunucu yedeğinin içinde yer almayabilir. Yine de kurtarma planının parçasıdırlar.
Çoğu Web Sitesi İçin Pratik Bir Saklama Zamanlaması
Yaygın bir başlangıç noktası, sık yedekleri kısa bir süre, daha seyrek yedekleri ise daha uzun süre saklamaktır. Bu, depolama kullanımının terk edilmiş bir garaj gibi büyümesine yol açmadan kullanışlı geri yükleme seçenekleri sunar.
Tipik bir küçük işletme sitesi, ajans tarafından yönetilen site veya pazarlama sitesi için günlük yedekleri 14 ila 30 gün, haftalık yedekleri 8 ila 12 hafta ve aylık yedekleri 6 ila 12 ay saklayın. CMS yükseltmesi, yeniden tasarım yayını, taşıma, eklenti değişimi veya sunucu yapılandırma çalışması gibi büyük değişikliklerden önce ek bir yedek alın.
Mağazalar, SaaS panoları, üyelik siteleri, rezervasyon platformları ve veritabanı ağırlıklı diğer hizmetler için daha sık veritabanı koruması ekleyin. 24 ila 72 saat boyunca saklanan saatlik veritabanı yedekleri uygun olabilir; bunu 30 gün boyunca günlük yedekler, 12 hafta boyunca haftalık yedekler ve 12 ay boyunca aylık yedekler izleyebilir. Kesin aralık, işlem hacmine ve uygulamanın etkin verileri tutarlı şekilde yedekleyip yedekleyemediğine bağlıdır.
Ajanslar, her hesaba tek bir zamanlama uygulamak yerine müşteriye özel politikaları değerlendirmelidir. Bir restoran menü sitesi, yüklenmiş belgeleri işleyen bir müşteri portalıyla aynı saklama süresine ihtiyaç duymaz. Siteleri risk ve iş etkisine göre gruplayın, ardından politikayı müşteri sözleşmesinde veya hizmet kapsamı içinde görünür hale getirin.
Değişiklik Öncesi Geri Yükleme Noktalarını Ayrı Tutun
Otomatik zamanlamalar, riskli işlerden önce kasıtlı olarak alınan yedeklerin yerine geçmez. Güncellemeler, taşımalar, veritabanı bakımı, şablon değişiklikleri veya sunucu düzeyindeki ayarlamalar öncesinde etiketli bir geri yükleme noktası oluşturun.
Değişiklik öncesi yedekleri, iş tamamlandıktan sonra en az yedi ila on dört gün saklayın. Bazı sorunlar ancak bir faturalandırma döngüsü, bir arka plan işi veya bir entegrasyon çalıştıktan sonra ortaya çıkar. Değişikliğin kararlı olduğu doğrulandıktan sonra normal saklama devralabilir.
Gerçekçi Operasyonlarla 3-2-1 İlkesini İzleyin
Klasik 3-2-1 modeli hâlâ pratiktir: verilerin üç kopyasını, iki farklı depolama türünde ve bir kopyayı site dışında tutun. Web sitesi operasyonları için bu çoğu zaman üretim verileri, hosting ortamında bir yedek kopya ve bağımsız site dışı depolamada şifrelenmiş bir kopya anlamına gelir.
Anahtar kelime bağımsızdır. Aynı sanal sunucuda depolanan bir yedek kullanışlıdır, ancak sunucu düzeyindeki arızaya karşı koruma değildir. Aynı hosting hesabında depolanan bir yedek de, bir saldırgan hesap kimlik bilgilerini ele geçirirse veya geniş kapsamlı bir silme işlemi yapılırsa risk altında olabilir.
Site dışı kopyalar aktarım sırasında ve bekleme halinde şifrelenmelidir. Erişim, mümkün olduğunda ayrı kimlik bilgileri kullanmalıdır; ideal olarak çok faktörlü kimlik doğrulama ve sınırlı izinlerle. Yedek silme izinleri özel dikkat gerektirir. Fidye yazılımı veya ele geçirilmiş bir yönetici, üretim verilerini ve her kurtarma noktasını tek oturumda silebiliyorsa, saklama zamanlaması kâğıt üzerinde mükemmel, pratikte ise çaresiz görünecektir.
kodu.cloud'da, yönetilen yedekleme ve izleme düzenlemeleri rutin işleri azaltabilir, ancak kurtarma gereksinimlerinin sahipliğinin yine de net olması gerekir. Sağlayıcınız sistemi sürdürebilir; işletmeniz ne kadar veri kaybını ve kesinti süresini kabul edebileceğine karar vermelidir.
Saklamayı Güvenlik Olaylarının Farkında Olacak Şekilde Tasarlayın
Kötü amaçlı yazılım geç fark edildiğinde kısa bir saklama penceresi tehlikeli olabilir. Şüpheli yönlendirmeler, spam etkinliği veya yetkisiz yönetici hesapları görünür hale gelmeden önce bir site haftalarca ele geçirilmiş durumda olabilir. Her yedek yedi gün sonra üzerine yazılıyorsa, elinizde yalnızca bulaşmış kopyalar kalabilir.
Haftalık ve aylık geri yükleme noktalarının önemli olmasının nedeni budur. Daha yüksek riskli ortamlar için, belirli bir süre boyunca değiştirilemez veya yazma korumalı yedek kopyaları değerlendirin. Değiştirilemezlik bir yedeği sihirli biçimde doğru hale getirmez, ancak ele geçirilmeden sonra bir saldırganın onu değiştirmesini veya silmesini önleyebilir.
Yedek başarısı, başarısızlığı, silme ve geri yükleme etkinliklerinin günlüklerini tutun. Uyarılar, küçük bir dijital müzeye dönüşmüş bir gelen kutusuna değil, harekete geçebilecek bir kişiye ulaşmalıdır. İzleme ayrıca depolama kapasitesini, yedek süresini ve yedek boyutundaki olağandışı değişiklikleri de kontrol etmelidir. Bir anda aşırı küçük hale gelen bir yedek, hariç tutulmuş bir veritabanına veya başarısız dosya toplamaya işaret edebilir; bir anda aşırı büyüyen bir yedek ise günlüklerin, önbellek dosyalarının veya istenmeyen verilerin yedek kümesine girdiğini gösterebilir.
Birine İhtiyacınız Olmadan Önce Geri Yüklemeleri Test Edin
Bir yedek, ancak başarıyla geri yüklendikten sonra bir kurtarma aracıdır. Yedek işi durumu, verinin kopyalandığını doğrular. Arşivin eksiksiz, okunabilir, mevcut ortamla uyumlu veya zaman baskısı altında kullanılabilir olduğunu kanıtlamaz.
Standart bir işletme web sitesi için en az üç ayda bir, gelir açısından kritik uygulamalar için ise daha sık bir geri yükleme testi yapın. Üretimin üzerine yazamayacağı bir hazırlık ortamına veya yalıtılmış konuma geri yükleyin. Uygulamanın başladığını, veritabanının bağlandığını, medya dosyalarının yüklendiğini, formların çalıştığını, zamanlanmış görevlerin mevcut olduğunu ve kritik kullanıcı eylemlerinin normal davrandığını doğrulayın.
Geri yüklemenin ne kadar sürdüğünü ve gerekli olan tüm manuel adımları kaydedin. Kurtarma, bir geliştiricinin veritabanı parolasını, bir DNS sırasını ve beş yıllık bir shell komutunu hatırlamasına bağlıysa, bu bir plan değildir. Bu, kurumsal efsaneden kalma bir parçadır.
İstisnaları Belgelendirin ve Politikayı Gözden Geçirin
Saklama politikanız tek bir sayfaya sığmalı ve birkaç doğrudan soruya yanıt vermelidir: ne yedekleniyor, ne sıklıkta, kopyalar nerede depolanıyor, her kopya ne kadar süre saklanıyor, kim geri yükleme talep edebilir ve geri yükleme testi nasıl belgelendiriliyor. Ayrıca dahil olmayan sistemleri de adlandırın; böylece hiç kimse bir yedeğin erişemediği bir üçüncü taraf hizmeti kapsadığını varsaymaz.
Büyük bir site değişikliğinden, yeni bir uyumluluk gereksiniminden, trafik artışından veya bir kurtarma olayından sonra politikayı gözden geçirin. Çevrimiçi bir mağaza büyüdükçe daha sık yedek almak gerekli hale gelebilir. Öte yandan, az değişen bir site için çok yıllı günlük yedekleri saklamak, faydalı koruma olmadan maliyet yaratabilir.
Saklama politikasını, ona en çok ihtiyaç duyacağınız an etrafında oluşturun: aceleye gelmiş bir cuma dağıtımı, kötü niyetli bir eklenti güncellemesi veya yanlış saatte yaşanan bir disk sorunu. Net geri yükleme noktaları, bağımsız bir kopya ve test edilmiş bir süreç ekibinize güvenden daha iyi bir şey verir. Size uygulanabilir bir sonraki adımı verirler.
Andres Saar Müşteri Hizmetleri Mühendisi