Web Sitesi Yedek Saklama Politikası Kılavuzu
10 Mayıs 2026 tarihinde yayımlandı
Yedek çok eski olduğu için başarısız olan bir geri yükleme can sıkıcıdır. Gerekli yedek zaten silinmiş olduğu için başarısız olan bir geri yükleme ise daha kötüdür. Bu web sitesi yedek saklama politikası kılavuzu, her iki sorunu da önlemek ve internetin yarısını sonsuza kadar depolamadan temiz bir şekilde kurtarma yapabilmeniz için yeterli geçmişi korumanıza yardımcı olmak için burada.
Yedekleme ile ilgili sorunların çoğu, yedekleme görevinin kendisinden kaynaklanmaz. Bunlar zayıf saklama kararlarından kaynaklanır. Ekipler günlük yedeklemeleri etkinleştirir, üç ay boyunca kendilerini güvende hisseder ve sonra yalnızca yedi kopya tuttuklarını fark eder. Ya da her şeyi bir yıl boyunca tutar ve ihtiyaç duymadıkları depolama için ödeme yaparlar; buna rağmen, kimse gerçek geri yükleme kullanımını planlamadığı için kurtarma yine çok uzun sürer.
Bir yedek saklama politikasının gerçekte neyi kontrol ettiği
Bir saklama politikası, her yedeğin ne kadar süre tutulacağını, kaç geri yükleme noktası bulunacağını ve farklı kurtarma senaryoları için hangi kopyaların kullanılabilir olacağını belirler. Bu kulağa basit geliyor, ancak maliyeti, hızı, uyumluluğu, olay müdahalesini ve hatta müşteri güvenini etkiler.
Bir işletme web sitesi için saklama, yalnızca bir sunucu arızasından sonra afet kurtarma ile ilgili değildir. Aynı zamanda hatalı dağıtımlardan, kötü amaçlı yazılımlardan, bozuk eklentilerden, yanlışlıkla içerik silinmesinden ve günler önce sessizce başlamış veritabanı bozulmalarından kurtarmayla da ilgilidir. Günümüzde birçok olayda günlükler aynı hikâyeyi anlatıyor: yedek vardı, ancak işe yarar geri yükleme noktası yoktu.
Bu nedenle sıklık ve saklama birlikte planlanmalıdır. 30 gün saklanan günlük bir yedek size 30 geri yükleme noktası sağlar. 48 saat saklanan saatlik bir yedek ile 30 gün saklanan günlük yedekler, size hızlı kısa vadeli kurtarma ve daha yavaş ortaya çıkan sorunlar için yeterli geçmiş sağlar. Aynı sistem, çok farklı sonuç.
Riskinize uygun bir web sitesi yedek saklama politikası kılavuzu nasıl oluşturulur
Doğru politika iki soruyla başlar. İlk olarak, ne kadar veri kaybetmeyi göze alabilirsiniz? İkinci olarak, gerçekçi olarak ne kadar geriye dönük kurtarma yapmanız gerekiyor?
E-ticaret mağazanız her saat sipariş işliyorsa, tam bir günlük veriyi kaybetmek genellikle kabul edilebilir değildir. Pazarlama siteniz ayda iki kez değişiyorsa, günlük anlık görüntüler fazlasıyla yeterli olabilir. Birden fazla müşteri sitesi yöneten ajanslar genellikle daha uzun saklama süresine ihtiyaç duyar; çünkü sorunlar bazen geç fark edilir, özellikle de eklenti güncellemelerinden veya birkaç kişinin yaptığı içerik düzenlemelerinden sonra.
Pratik bir model, katmanlar halinde düşünmektir. Kısa vadeli hatalar için sık yedekler, yakın tarihli olaylar için günlük yedekler ve daha uzun geriye dönük inceleme için haftalık veya aylık yedekler tutun. Bu, hem operasyonel kurtarmayı hem de geç tespit edilen sorunları korur.
Yaygın bir başlangıç modeli şöyledir:
- Dinamik siteler için 24 ila 48 saat boyunca saatlik yedekler
- 14 ila 30 gün boyunca günlük yedekler
- 8 ila 12 hafta boyunca haftalık yedekler
- 6 ila 12 ay boyunca aylık yedekler
Bu evrensel bir yasa değildir. Yalnızca makul bir başlangıç seviyesidir. Sürekli yazma işlemleri olan bir SaaS platformu, birkaç dakikada bir veritabanına özel yedeklere ihtiyaç duyabilir. Bir tanıtım sitesi ise yalnızca günlük ve haftalık kopyalarla gayet iyi durumda olabilir. Bu; değişim hızına, gelir etkisine, uyumluluk gereksinimlerine ve ekibin sorunları ne kadar hızlı fark ettiğine bağlıdır.
Saklamayı yalnızca sunucu boyutuna değil, web sitesi türüne göre eşleştirin
Depolama kapasitesi yanlış ilk girdidir. Doğru olan kurtarma riskidir.
Bir WooCommerce mağazası için müşteri siparişleri, envanter değişiklikleri ve ödeme durumu güncellemeleri kısa yedekleme aralıklarını değerli kılar. Saatlik dosya ve veritabanı koruması haklı görülebilir; çünkü veri değişiklikleri sık ve işletme açısından kritiktir. Bu durumda, yüksek sıklıklı yedekler için kısa bir saklama penceresi ile daha uzun günlük ve haftalık kopyalar faturayı makul seviyede tutar.
İçerik ağırlıklı bir ajans sitesi veya yayıncı sitesi için hatalar hemen fark edilmeyebilir. Bir editör sayfaları kaldırabilir, medyanın üzerine yazabilir veya ancak bir hafta sonra fark edilen bozuk değişiklikler yayımlayabilir. Burada, çok sık anlık görüntülerden ziyade daha uzun günlük saklama daha önemlidir.
Bir SaaS uygulaması için uygulama sunucusu, veritabanı, yüklenen varlıklar ve yapılandırma adına ayrı saklama mantığına ihtiyaç duyabilirsiniz. Tüm bileşenleri tek bir yedek kümesi olarak ele almak pahalı ve hantaldır. Veritabanlarının genellikle daha sıkı kurtarma noktalarına ihtiyacı vardır. Statik varlıklar ise çoğu zaman daha yavaş bir takvimde tutulabilir.
Geliştirme veya hazırlık ortamları için saklama çok daha kısa olabilir. Ortam koddan ve altyapı tanımlarından yeniden üretilebiliyorsa, uzun bir yedek geçmişi tutmak için çok az neden vardır. Bütçeyi, hataların faturaya dönüştüğü üretim ortamı için saklayın.
Maliyet ile kurtarma derinliği arasındaki denge
Saklama her zaman bir dengeleme işidir. Daha fazla geri yükleme noktası daha çok seçenek sunar, ancak aynı zamanda depolama kullanımını, çoğaltma süresini ve yönetim karmaşıklığını artırır. Daha az saklama para kazandırır, ancak kaçış yollarınızı daraltır.
Ucuz görünen politika gerçek hayatta her zaman ucuz değildir. Bir kötü amaçlı yazılım bulaşması on gün önce başladıysa ve saklama süreniz yedi günse, kurtarma maliyeti tasarruf ettiğiniz depolamadan çok daha pahalı hale gelir. Olay müdahalesi, adli inceleme çalışmaları, kaybedilen siparişler ve acil destek, birkaç saklanan yedekten daha pahalıya mal olma eğilimindedir.
Öte yandan, her günlük yedeği sonsuza kadar tutmak da pek akıllıca değildir. Budama yapılmadan uzun süreli saklama karmaşa yaratır ve baskı altında geri yükleme seçimini yavaşlatabilir. Bir kesinti sırasında, kimse 2014'ten kalma bir aile fotoğraf arşiviymiş gibi neredeyse aynı olan 900 geri yükleme noktası arasında gezinmekten hoşlanmaz.
Daha iyi bir yaklaşım katmanlı saklamadır. Değişimin yeni olduğu yerde yoğun kapsama, yaş arttıkça ise seyrek kapsama tutun. Bu, gereksiz çoğaltma olmadan esneklik sağlar.
Yerel, site dışı ve değiştirilemez kopyalar
Bir saklama politikası, yalnızca yedekler siteyi bozan aynı olaydan sağ çıkarsa faydalıdır. Web sitesi ve yedekler aynı şekilde tehlikeye atılmış sistemde bulunuyorsa, yalnızca bir yedek klasörü var diye hizmet yeniden sakin hale gelmez.
Ciddi web sitesi koruması için kopyaları birden fazla yerde tutun. Yerel yedekler geri yüklemeleri hızlandırabilir. Site dışı yedekler barındırma arızasına, büyük bozulmalara ve hesap düzeyindeki olaylara karşı koruma sağlar. Tehdit modelinizin bir parçası fidye yazılımı veya kötü niyetli silme ise, değiştirilemez ya da yazma korumalı yedek depolama dikkat etmeye değerdir.
Küçük işletmeler bazen planlamayı burada yetersiz yapar. Yedek saklamanın yalnızca zamanla ilgili olduğunu varsayarlar. Aynı zamanda yalıtımla da ilgilidir. Aynı sunucudaki yedi günlük kopya, sıfır faydalı kopyaya dönüşmeye hâlâ tek kötü gün uzaklıktadır.
Yalnızca yedekleme başarısını değil, geri yükleme hızını da test edin
Başarılı olarak işaretlenen bir yedekleme görevi iyi bir kurtarma deneyimini garanti etmez. Dosyalar yavaş geri yüklenebilir. Veritabanları belirli bir zamana yönelik koordinasyon gerektirebilir. Bağımlılıklar eşleşmeyebilir. Kimlik bilgileri eksik olabilir. DNS ve SSL durumu ayrı işlem gerektirebilir.
Saklama politikası geri yükleme testleri tarafından şekillendirilmelidir. Ekibiniz bir müşteri sitesini dünkü anlık görüntüden 20 dakikada geri yükleyebiliyorsa, bu güçlü bir operasyonel konumdur. Geçen ayın yedeğini geri yüklemek birkaç sistemden manuel birleştirme gerektiriyorsa, uzun saklama yalnızca kâğıt üzerinde vardır.
Sürece güvenmek için geri yükleme testlerini yeterince sık yapın. Yakın tarihli bir yedeği ve daha eski bir yedeği test edin. Mümkün olduğunda ayrı bir ortama geri yükleyin. Yalnızca dosyaların varlığını değil, uygulama davranışını da kontrol edin. Temiz şekilde içe aktarılan ancak oturum açmayı bozan bir veritabanı yine de başarısız bir kurtarmadır.
Uyumluluk, sözleşmeler ve müşteri beklentileri
Bazı saklama gereksinimleri düzenlemelerden gelir. Diğerleri sözleşmelerden, iç politikadan veya basit iş mantığından gelir. Müşteri verilerini, ödemeyle ilgili iş akışlarını veya düzenlemeye tabi kayıtları işliyorsanız, yedek saklama yasal yükümlülükler ve silme gereksinimleriyle uyumlu olmak zorunda olabilir.
Burada dikkatli olun. Yedek saklama, genel veri saklama ile aynı şey değildir. Bir işletmenin talep üzerine canlı sistemlerden müşteri verilerini silmesi gerekebilir; buna karşılık yedekler kontrollü sona erme döngülerini izler. Yasal ve operasyonel kurallar açıkça belgelenmelidir; böylece saklama politikanız denetimler veya müşteri soruları sırasında karmaşa yaratmaz.
Ajanslar ve yönetilen barındırma müşterileri için, geri yükleme kararlarının kime ait olduğunu ve kurtarmanın makul olarak ne kadar geriye gidebileceğini tanımlamak da akıllıcadır. Beklentiler sihirli değil, sakin ve net olmalıdır.
Çoğu KOBİ web sitesinin başlayabileceği pratik bir politika
Kullanılabilir bir başlangıç noktasına ihtiyacınız varsa, bu web sitesi yedek saklama politikası kılavuzu birçok üretim web sitesi için basit bir model önerir. Site gün boyunca değişiyorsa 48 saat boyunca saatlik yedekler tutun. 30 gün boyunca günlük yedekler tutun. 8 hafta boyunca haftalık yedekler tutun. Site ticari değere, müşteri kayıtlarına veya daha uzun içerik döngülerine sahipse 12 ay boyunca aylık yedekler tutun.
Ardından gerçeğe göre ayarlayın. Geri yüklemeler neredeyse her zaman son 24 saati kullanıyorsa, kısa vadeli sıklığı artırın. Sorunlar düzenli olarak iki hafta sonra keşfediliyorsa, günlük saklama süresini uzatın. Depolama maliyetleri yükselmeye başlarsa, üretim geçmişine dokunmadan önce düşük değerli ortamlardaki çoğaltmayı azaltın.
Bunu kendileri takip etmek istemeyen ekipler için, izlenen yedekler, net geri yükleme prosedürleri ve insan desteği içeren bir yönetilen barındırma kurulumu, sessiz riskin büyük bir kısmını ortadan kaldırır. Bu, kodu.cloud gibi sağlayıcıların yedekleri yalnızca bir onay kutusu olarak görmek yerine yedekleme sistemlerinin etrafına operasyonel destek sunmasının nedenlerinden biridir.
Politikayı yazılı hale getirin. Yedekleme sıklığını, saklama pencerelerini, depolama konumunu, geri yükleme test takvimini, sahipliği ve istisnaları tanımlayın. Yalnızca birinin kafasında var olan bir politika, genellikle tatile çıkan kişiyle aynı anda ortadan kaybolur.
Yalnızca bir elektronik tabloda düzenli görünen sorunlar için değil, gerçekten karşılaştığınız sorunlardan kurtulmaya yetecek kadar geçmiş tutun. Yedek saklamanın teori olmaktan çıkıp işletmeyi korumaya ba şladığı yer burasıdır.
Andres Saar Müşteri Hizmetleri Mühendisi