Web Sitesi Yedekleme Neden Hayati? Doğru Yedekleme Stratejisi

Web sitesi yedekleme, çoğu firmanın ancak bir şey bozulduğunda hatırladığı bir konudur. 2012'den beri sahada çalışıyorum ve en pahalı dersleri hep aynı cümleyle başlayan telefonlarda gördüm: "Site açılmıyor, yedeğimiz var mı?" Bu yazıda yedeğin neden hayati olduğunu, 3-2-1 kuralını, dosya ve veritabanı ayrımını, otomasyonu ve en çok atlanan adımı, yani geri yükleme testini kendi pratiğimle anlatıyorum.

Web sitesi yedekleme nedir ve neden hayati önem taşır?

Web sitesi yedekleme, sitenizin dosyalarının, veritabanının ve ayarlarının düzenli aralıklarla kopyalanıp asıl sunucudan ayrı bir yerde saklanmasıdır. Amaç tek bir şeydir: bir saldırı, hatalı güncelleme, sunucu arızası veya insan hatası sonrasında siteyi kabul edilebilir bir sürede ve kabul edilebilir veri kaybıyla geri getirmek.

Hayati olmasının nedeni basit: siteniz artık bir broşür değil, satış kanalınız. Örneğin bir e-ticaret sitesinde siparişler, müşteri hesapları ve stok bilgisi veritabanında durur. Yedek yoksa bu verileri yeniden üretmenin bir yolu yoktur. Kurumsal sitelerde ise form kayıtları, blog içerikleri ve yıllar içinde biriken SEO değeri risk altındadır.

Üstelik yedeğin değeri, ona ihtiyaç duyduğunuz gün ortaya çıkar. Bu yüzden yedeği bir sigorta poliçesi gibi düşünmenizi öneriyorum: her ay küçük bir disiplin, kötü günde büyük bir kurtarma. Kısacası web sitesi yedekleme bir teknik detay değil, iş sürekliliği kararıdır.

Bu yazıyı okurken kendi sitenizi aklınızda tutmanızı öneriyorum. Her bölümün sonunda 'bizde bu nasıl?' diye sorun. Böylece yazının sonunda elinizde genel bir bilgi değil, kendi sitenize özel kısa bir eksik listesi olur. Ayrıca bu listeyi teknik ekibinizle veya ajansınızla paylaşarak ilk toplantıyı somut maddeler üzerinden yapabilirsiniz.

Yedeksiz bir site hangi risklerle karşı karşıya kalır?

Riskleri sınıflandırmak, yedek stratejisini neye göre kuracağınızı netleştirir. Sahada karşılaştığım kayıpların neredeyse tamamı şu başlıklardan birine giriyor:

• Kötü amaçlı yazılım ve fidye yazılımı: Saldırgan dosyaları şifreler ya da siteye zararlı kod ekler; temiz bir sürüm olmadan kodu satır satır ayıklamak zorunda kalırsınız.
• Hatalı güncelleme: Bir eklenti, tema veya çekirdek güncellemesi siteyi beyaz ekrana düşürebilir.
• Sunucu veya disk arızası: Donanım arıza verir, veri merkezi sorun yaşar, hosting firması hesabı askıya alır.
• İnsan hatası: Yanlış tabloyu silen bir sorgu ya da yanlış klasörü boşaltan bir FTP işlemi.
• Hesap ve sözleşme sorunları: Ödenmeyen bir fatura veya ayrılan bir ajans yüzünden panele erişimi kaybetmek.

Dikkat ederseniz bu risklerin bir kısmı sunucunun kendisini de vuruyor. Dolayısıyla yalnızca aynı sunucuda duran bir yedek, bu senaryoların birçoğunda işe yaramaz. İlerleyen bölümlerde bunun çözümünü konuşacağız.

3-2-1 yedekleme kuralı nedir, web sitenize nasıl uyarlarsınız?

3-2-1 kuralı, verinizin en az üç kopyasını, iki farklı ortamda tutmanızı ve bunlardan en az birini fiziksel olarak başka bir yerde saklamanızı söyler. ABD siber güvenlik ajansı CISA da veri yedekleme seçenekleri rehberinde bu yaklaşımı temel öneri olarak anlatıyor.

Web sitesine uyarladığımda bu kuralı pratikte şöyle kuruyorum:

1. Birinci kopya: Canlı sitenin kendisi.
2. İkinci kopya: Hosting panelinin veya sunucunun aldığı otomatik yedek.
3. Üçüncü kopya: Sunucudan tamamen bağımsız bir bulut depolama alanı ya da ofisteki bir disk.

Ayrıca son yıllarda kurala bir ek yapmayı alışkanlık hâline getirdim: kopyalardan biri değiştirilemez veya çevrim dışı olsun. Çünkü fidye yazılımı, erişebildiği her yedeği de şifrelemeye çalışır. Böylece saldırgan canlı siteye girse bile en az bir temiz kopyaya dokunamaz.

Bu ek maddeyi uygulamanın birkaç yolu var: bazı bulut depolama servisleri belirli bir süre silinemeyen nesne kilidi sunar, bazı ekipler ise ayda bir yedeği harici bir diske alıp fişini çeker. Hangisini seçerseniz seçin, amaç aynıdır: canlı sistemden tek bir komutla ulaşılamayan bir kopya.

Dosya yedeği ile veritabanı yedeği arasındaki fark nedir?

Bir web sitesi iki parçadan oluşur ve ikisini de ayrı ayrı düşünmeniz gerekir. Dosyalar; kodu, temayı, eklentileri, yüklenen görselleri ve yapılandırma dosyalarını içerir. Veritabanı ise yazıları, ürünleri, siparişleri, kullanıcıları ve ayarları tutar.

Sık gördüğüm hata, yalnızca dosyaları kopyalayıp veritabanını unutmak. Bu durumda elinizde tasarım kalır ama içerik gider. Tersi de mümkündür: veritabanı yedeği vardır, ancak yüklenen görseller klasörü yedeğe girmemiştir. Sonuç olarak geri yüklediğiniz sitede yüzlerce kırık görsel görürsünüz.

Bu tablo size bir şey söylüyor: iki parçanın ritmi farklı. O yüzden aynı takvime bağlamak zorunda değilsiniz.

Web sitesi yedekleme işini ne sıklıkla yapmalısınız?

Sıklığı belirlemenin en sağlıklı yolu kendinize şu soruyu sormaktır: "Son yedekten bu yana kaybettiğim her şeyi yeniden üretmem gerekse, ne kadar veri kaybını göze alabilirim?" Teknik dilde buna kurtarma noktası hedefi (RPO) denir.

Örneğin haftada bir yazı yayınlayan bir kurumsal sitede günlük veritabanı yedeği fazlasıyla yeterlidir. Öte yandan günde yüzlerce sipariş alan bir mağazada gece alınan tek yedek, akşamüstü yaşanan bir çöküşte bütün günün siparişlerini riske atar. Bu tür sitelerde saatlik veritabanı yedeği ya da sürekli işlem kaydı tutan bir çözüm düşünmelisiniz.

Saha tecrübeme dayalı başlangıç önerim şöyle, garanti değil ve sitenize göre ayarlamanız gerekir: içerik sitelerinde günlük veritabanı ve haftalık dosya yedeği; aktif e-ticarette saatlik veya daha sık veritabanı ve günlük dosya yedeği. Ayrıca her büyük güncellemeden hemen önce elle bir yedek alın. Bu tek alışkanlık, gördüğüm kurtarmaların önemli bir kısmını dakikalar içinde çözdü.

Yedekleri ne kadar süre saklamalısınız?

Saklama süresi, sıklık kadar önemlidir ve firmalar onu genellikle ihmal eder. Çünkü bazı sorunları hemen fark etmezsiniz. Bir sitenin haftalarca gizli bir zararlı kod taşıdığını, ancak Google uyarı verdiğinde öğrendiğimiz durumlar yaşadım. Yalnızca son yedi günlük yedek tutsaydık, elimizdeki bütün kopyalar kirli olacaktı.

Bu nedenle katmanlı bir saklama planı öneriyorum. Günlük yedekleri birkaç hafta, haftalık yedekleri birkaç ay, aylık yedekleri ise en az bir yıl tutabilirsiniz. Bu yapıya genellikle "dede, baba, oğul" rotasyonu denir.

Yine de saklama süresinin bir de hukuki boyutu var. Yedekler kişisel veri içerdiği için, KVKK kapsamında gereğinden uzun saklamak da bir risktir. Kısacası saklama politikanızı hem teknik ihtiyaca hem de aydınlatma metninizde yazan süreye göre belirlemelisiniz. Emin değilseniz bu noktada bir hukukçudan görüş almanızı tavsiye ederim.

Yedekleri neden sunucu dışında saklamalısınız?

Aynı sunucuda duran yedek, aslında yedek değil, sadece bir kopyadır. Sunucu çöktüğünde, hesap askıya alındığında ya da saldırgan root erişimi kazandığında o kopya da canlı siteyle birlikte gider.

Sunucu dışı saklama için birkaç seçeneğiniz var: nesne depolama sunan bulut servisleri, farklı bir sağlayıcıdaki ikinci bir sunucu veya düzenli indirilen ve şifrelenen yerel arşivler. Önemli olan, yedeğin bulunduğu yerin canlı sunucuyla aynı kimlik bilgilerini paylaşmamasıdır.

Üstelik güvenlik açısından bir ince nokta daha var: yedek arşivlerini sitenin herkese açık klasöründe bırakmayın. Sahada birçok kez "site-yedek.zip" gibi dosyaların tarayıcıdan indirilebilir durumda olduğunu gördüm. Bu dosyalar veritabanı şifrelerini ve müşteri bilgilerini içerir. Dolayısıyla yedeği alın, güvenli yere taşıyın, sunucudaki geçici kopyayı silin.

Hosting firmasının yedeği yeterli mi?

Hosting firmasının yedeği değerli bir katmandır, ancak tek katman olarak yeterli değildir. Çoğu paylaşımlı hosting paketinde firmalar yedeklemeyi "iyi niyet" hizmeti olarak verir; sözleşmede garanti, saklama süresi veya geri yükleme süresi açıkça yazmaz.

Firmanıza şu soruları sormanızı öneriyorum:

• Yedeği hangi sıklıkla alıyorsunuz ve kaç gün saklıyorsunuz?
• Yedekler aynı veri merkezinde mi, farklı bir lokasyonda mı duruyor?
• Geri yüklemeyi kendim panelden yapabiliyor muyum, yoksa destek talebi mi açmam gerekiyor?
• Geri yükleme ücretli mi ve ortalama ne kadar sürüyor?
• Hesabım askıya alınırsa yedeklerime erişebiliyor muyum?

Bu soruların cevabı belirsizse, kendi bağımsız kopyanızı mutlaka tutun. Özellikle son maddeyi önemsiyorum, çünkü hesap erişimini kaybettiğiniz gün hosting yedeğine de ulaşamazsınız.

Öte yandan hosting yedeğini küçümsemeyin. Küçük bir hatadan dönmek için çoğu zaman en hızlı yol odur; birkaç tıklamayla dünkü hâle dönersiniz. Yani hosting yedeğini hızlı kurtarma katmanı, bağımsız kopyanızı ise felaket katmanı olarak konumlandırın. İkisi birbirinin yerine geçmez, birbirini tamamlar.

Web sitesi yedekleme sürecini nasıl otomatikleştirirsiniz?

Elle alınan yedek, unutulan yedektir. Bu yüzden web sitesi yedekleme sürecini mümkün olduğunca otomatikleştirmenizi öneriyorum. Otomasyonun üç temel yolu var ve sitenizin altyapısına göre birini seçebilirsiniz.

İlk olarak hosting paneli seviyesinde takvime bağlı yedekler kurabilirsiniz; cPanel veya Plesk gibi paneller uzak bir hedefe otomatik yedek gönderebilir. İkinci olarak içerik yönetim sisteminin eklentilerini kullanabilirsiniz; WordPress için bulut depolamaya yedek gönderen eklentiler yaygındır. Üçüncü olarak kendi sunucunuz varsa, cron görevleriyle veritabanı dökümünü ve dosya arşivini alıp şifreleyerek uzak depoya gönderen betikler yazabilirsiniz.

Hangisini seçerseniz seçin, otomasyona mutlaka bir bildirim ekleyin. Başarısız olan bir yedek görevi sessizce haftalarca çalışmayabilir. Ben kendi projelerimde, yedek başarısız olduğunda veya dosya boyutu beklenenden çok küçük geldiğinde uyarı alacak şekilde kurulum yapıyorum.

Geri yükleme testi neden yedeğin kendisinden önemlidir?

Hiç denemediğiniz bir yedek, yalnızca bir umuttur. Bunu en acı şekilde, açılmayan bir arşiv dosyasıyla ya da yarıda kalan bir veritabanı dökümüyle karşılaştığımda öğrendim. Dosya oradaydı, boyutu makul görünüyordu, ama içi eksikti.

Geri yükleme testi, yedeği ayrı bir test ortamına kurup sitenin gerçekten çalıştığını doğrulamaktır. Bu testte şunlara bakıyorum: ana sayfayı açabiliyor muyum, yönetim paneline girebiliyor muyum, son eklenen içerik ve siparişler duruyor mu, görseller yükleniyor mu, formlar çalışıyor mu?

Saha tecrübeme dayalı önerim, garanti değil: en az üç ayda bir tam geri yükleme testi yapın ve süreyi kronometreyle ölçün. Böylece gerçek bir kriz anında "siteyi ne kadar sürede geri getiririz?" sorusuna tahminle değil, ölçtüğünüz bir rakamla cevap verirsiniz. Ayrıca testin adımlarını yazılı bir listeye dökün; kriz günü paniğe kapılan birinin takip edebileceği kadar sade olsun.

RPO ve RTO nedir, küçük işletmeler neden bilmeli?

RPO (kurtarma noktası hedefi), kaybetmeyi göze alabileceğiniz en fazla veri miktarını zaman cinsinden ifade eder. RTO (kurtarma süresi hedefi) ise sitenin en geç ne kadar sürede tekrar çalışması gerektiğini anlatır. ABD standartlar enstitüsü NIST'in olasılık planlaması rehberi SP 800-34 bu kavramları iş sürekliliği planlamasının temeli olarak kullanıyor.

Bu terimler kurumsal görünse de küçük işletmeler için de pratik bir işe yarar. Örneğin "RPO bir gün, RTO dört saat" dediğinizde yedekleme sıklığınız ve geri yükleme prosedürünüz kendiliğinden netleşir. Bir günlük sipariş kaybını göze alamıyorsanız, günlük yedek yetmez.

Yani önce iş hedefini koyuyorsunuz, sonra teknik çözümü ona göre seçiyorsunuz. Bu sıralama bütçeyi de korur, çünkü ihtiyacınız olmayan pahalı bir altyapıya para harcamazsınız.

Web sitesi yedekleme sırasında hangi hataları sık görüyorum?

Yıllar içinde aynı hataları farklı firmalarda tekrar tekrar gördüm. Kendi sürecinizi kontrol etmeniz için en yaygın olanları listeliyorum:

• Yalnızca dosyaları yedekleyip veritabanını atlamak.
• Yedeği canlı siteyle aynı sunucuda veya aynı hesapta tutmak.
• Yedek arşivini herkese açık klasörde unutmak.
• Yedeği şifrelememek, üstelik kimin eriştiğini bilmemek.
• Başarısız yedek görevlerini fark edecek bir bildirim kurmamak.
• Hiç geri yükleme testi yapmamak.
• Yedeğin nerede olduğunu ve nasıl açılacağını yalnızca tek bir kişinin bilmesi.

Son madde özellikle ajans değişikliklerinde can yakıyor. Eski ajans ayrıldığında yedeklerin nerede olduğunu kimse bilmiyor. Bu nedenle yedek konumunu ve erişim bilgisini kurumsal bir belgede saklamanızı öneriyorum.

Yedeklerin güvenliğini nasıl sağlarsınız?

Yedek, sitenizin tam bir kopyasıdır; yani müşteri verileri, şifre özetleri ve API anahtarları da oradadır. Dolayısıyla yedeği korumak, canlı siteyi korumak kadar önemlidir.

İlk adım şifrelemedir. Arşivi uzak depoya göndermeden önce şifreleyin ve anahtarı yedekle aynı yerde saklamayın. İkinci adım erişim kontrolüdür: yedek deposuna yalnızca yazma yetkisi olan ayrı bir kullanıcı tanımlayın, silme yetkisini kısıtlayın. Böylece canlı sunucu ele geçirilse bile saldırgan eski yedekleri silemez.

Üçüncü adım güçlü kimlik bilgileridir. Yedek servislerinizin şifrelerini tahmin edilemez tutun; bunun için şifre oluşturucu aracımızı kullanabilirsiniz. Ayrıca mümkün olan her hesapta iki adımlı doğrulamayı açın. Kısacası yedek, saldırganın gözünde bir hazinedir; onu kilitli tutmak sizin elinizde.

Site yenileme ve taşıma öncesinde yedeği nasıl ele almalısınız?

Bir siteyi yeniden tasarlarken veya başka sunucuya taşırken yedek, geri dönüş biletinizdir. Bu yazıda taşıma sürecinin ayrıntısına girmeyeceğim; SEO değerini koruma adımlarını web sitesi yenilerken SEO nasıl korunur yazısında, teknik kontrol listesini ise SEO migration kontrol listesinde anlattım.

Yedek açısından tek kuralım şu: taşıma başlamadan önce eski sitenin tam ve denediğiniz bir yedeğini alın, sonra bu yedeği yeni site yayına girdikten sonra da en az birkaç ay saklayın. Çünkü eksik bir sayfa, kaybolmuş bir yönlendirme ya da eksik kalan bir görsel çoğu zaman haftalar sonra fark edilir.

Ayrıca eski sitenin veritabanı yapısını ve URL listesini ayrı bir dosyada tutun. Böylece yeni sitede bir şey ters giderse, neyin nerede olduğunu hızlıca karşılaştırabilirsiniz.

Bir kriz anında geri yükleme adımları nelerdir?

Site çöktüğünde ilk dakikalar kritik. Panik yerine sıralı hareket etmeniz, hem veriyi hem de zamanı korur. Benim uyguladığım temel akış şu:

1. Durumu dondurun: Saldırı şüphesi varsa şifreleri değiştirin ve mevcut hâlin bir kopyasını alın; bu kopya ileride sorunun kaynağını bulmanıza yardım eder.
2. Doğru yedeği seçin: Sorunun başladığı tarihten önceki, temiz olduğundan emin olduğunuz yedeği belirleyin.
3. Önce test ortamına kurun: Mümkünse canlıya dokunmadan yedeği ayrı bir ortamda doğrulayın.
4. Canlıya alın: Dosyaları ve veritabanını geri yükleyin, ardından eklenti ve çekirdek güncellemelerini kontrol edin.
5. Açığı kapatın: Sorunun nedenini gidermeden siteyi açarsanız aynı saldırı tekrar gelir.

Geri yükleme uzun sürecekse, Google'ın iş faaliyetini geçici durdurma rehberinde önerdiği gibi geçici bakım sayfasını 503 durum koduyla sunun. Böylece arama motoru siteyi kalıcı olarak kapanmış sanmaz.

Web sitesi yedekleme SEO performansını nasıl etkiler?

Yedeğin kendisi bir sıralama faktörü değildir. Ancak yedeğin olmaması, sıralamalarınızı dolaylı yoldan ciddi şekilde etkileyebilir. Uzun süre erişilemeyen veya zararlı yazılım uyarısı alan bir site hem ziyaretçi güvenini hem de arama görünürlüğünü kaybeder.

Örneğin bir sitenin günlerce hata vermesi, arama motorunun sayfaları yeniden taramasını ve bazı URL'leri dizinden düşürmesini tetikleyebilir. Hızlı bir geri yükleme bu süreyi kısaltır. Sorunun ardından Google Search Console üzerinden tarama hatalarını ve güvenlik uyarılarını izlemenizi öneriyorum.

Ayrıca yedek dosyalarının sunucu kaynağını yorması da dikkat edilmesi gereken bir nokta. Yoğun saatlerde alınan büyük yedekler siteyi yavaşlatabilir; bu da kullanıcı deneyimine yansır. Hızın SEO'ya etkisini site hızı yazısında ayrıntılı anlattım. Kısacası yedekleri trafiğin en düşük olduğu saatlere planlayın.

Yedekleme için bütçe nasıl planlanır?

Yedekleme bütçesini konuşurken önce kaybın maliyetini hesaplamanızı öneriyorum. Örnek hesap: siteniz günde ortalama on sipariş alıyor ve her sipariş size belirli bir kâr bırakıyor. Sitenin iki gün kapalı kalması, yalnızca kaçan siparişler değil, reklam bütçesinin boşa gitmesi ve müşteri güveninin sarsılması anlamına gelir. Bu tabloyu gördüğünüzde yedek maliyetini doğru bağlama oturtursunuz.

Maliyet kalemleri genellikle üç başlıkta toplanır: depolama alanı, yedek yazılımı veya eklenti lisansı ve bu süreci yöneten kişinin zamanı. Depolama tarafında çoğu küçük site için aylık maliyet düşük kalır; asıl yükü zaman ve disiplin oluşturur.

Bu nedenle en ucuz çözümü değil, en sürdürülebilir çözümü seçin. Kimsenin kontrol etmediği pahalı bir sistem, her ay birinin baktığı basit bir düzenden daha az koruma sağlar. Kısacası bütçeyi araçtan önce rutine ayırın.

E-ticaret sitelerinde yedeklemenin farkı nedir?

E-ticaret sitesinde veritabanı her dakika değişir. Siparişler, ödeme kayıtları, stok hareketleri ve müşteri hesapları sürekli güncellenir. Bu yüzden kurumsal bir sitede yeterli olan günlük yedek, aktif bir mağazada ciddi bir boşluk bırakır.

Burada dikkat ettiğim ilk konu tutarlılıktır. Yedek alırken veritabanına yazma devam ediyorsa, döküm dosyasında yarım kalmış bir sipariş olabilir. Bunu önlemek için veritabanı motorunun tutarlı döküm seçeneklerini kullanıyorum ve büyük mağazalarda işlem kayıtlarını (binary log) ayrıca saklıyorum. Böylece son tam yedekten sonraki işlemleri de geri oynatabiliyorum.

İkinci konu, geri yükleme sonrası mutabakattır. Eski bir yedeğe döndüğünüzde, arada gelen siparişleri ödeme sağlayıcısının panelinden tek tek kontrol etmeniz gerekir. Ayrıca stok sayılarını da doğrulayın. Aksi hâlde müşteriye olmayan bir ürünü satabilirsiniz.

Yedekleme politikasını nasıl yazılı hâle getirirsiniz?

Yazılı olmayan bir yedek planı, onu kuran kişiyle birlikte şirketten ayrılır. Bu yüzden kısa ama net bir yedekleme politikası belgesi hazırlamanızı öneriyorum. Bu belge uzun olmak zorunda değil; bir iki sayfa yeterli.

Belgeye şu başlıkları koyuyorum: neyi yedeklediğiniz, ne sıklıkla yedeklediğiniz, kopyaları nerede sakladığınız, ne kadar süre tuttuğunuz, kimin erişimi olduğu ve geri yüklemeyi adım adım nasıl yaptığınız. Ayrıca son geri yükleme testinin tarihini ve süresini de buraya not edin.

Örneğin ajansla çalışıyorsanız, bu belgeyi sözleşmenin ekine koyabilirsiniz. Böylece iş birliği bittiğinde yedeklerin size devredilmesi yazılı bir yükümlülük olur. Üstelik yeni bir ekip geldiğinde sıfırdan başlamaz, belgeyi okuyup süreci devralır.

Belgeyi yılda bir güncelleyin. Çünkü hosting, eklentiler ve iş hacmi değiştikçe yedek ihtiyacınız da değişir; eski bir politika, yeni riskleri kapsamayabilir.

Alan adı, DNS ve e-posta ayarlarını da yedeklemeli misiniz?

Evet, çünkü bir site yalnızca dosya ve veritabanından ibaret değildir. Alan adının DNS kayıtları, e-posta yönlendirmeleri, SSL ayarları ve sunucu yapılandırması da sitenin çalışması için gereklidir. Bu bilgileri kaybettiğinizde, elinizde tam bir yedek olsa bile siteyi yeni bir sunucuda ayağa kaldırmak saatler sürebilir.

Bu yüzden DNS kayıtlarınızın güncel bir listesini düzenli olarak dışa aktarın. Mevcut kayıtları hızlıca görmek için DNS sorgulama aracını kullanabilirsiniz. Ayrıca web sunucusu yapılandırma dosyalarını, cron görevlerini ve PHP sürüm bilgisini de not edin.

Kurumsal e-posta ayrı bir başlıktır. Birçok firma e-postayı hosting paketinde tutar ve sitenin yedeğiyle birlikte düşünmez. Oysa önemli yazışmalar tam da oradadır. E-posta altyapınızı nasıl kurduğunuzu kurumsal e-posta altyapısı yazısında anlattım; yedek planınıza posta kutularını da ekleyin.

Yedekleme sürecini kim sahiplenmeli?

Yedeğin teknik tarafı bir geliştiriciye veya ajansa ait olabilir, ancak sahipliği her zaman işletmede kalmalı. Sahada gördüğüm en riskli durum, herkesin yedeği başkasının aldığını düşünmesidir. Ajans hosting firmasına, hosting firması müşteriye, müşteri de ajansa güvenir; sonunda kimse almaz.

Bu nedenle işletme içinde bir sorumlu belirleyin. Bu kişinin teknik bilgiye sahip olması gerekmez; ayda bir yedek raporuna bakması, bildirimleri takip etmesi ve üç ayda bir geri yükleme testini takvime koyması yeterlidir.

Ayrıca yedek depolama hesabının işletme adına açılmasına dikkat edin. Ajansın kişisel hesabında duran yedekler, iş birliği bittiğinde size ulaşmayabilir. Kısacası teknik işi devredebilirsiniz, ama sahipliği asla devretmeyin.

Yedekleme stratejisi için kontrol listesi nasıl olmalı?

Buraya kadar anlattıklarımı tek bir kontrol listesinde topluyorum. Bu listeyi yılda bir kez, ayrıca her ajans veya hosting değişikliğinde gözden geçirmenizi öneriyorum:

• Dosyaları ve veritabanını ayrı ayrı yedekliyorsunuz.
• Sıklık, RPO hedefinize uygun.
• En az bir kopyayı sunucu dışında ve farklı kimlik bilgileriyle koruyorsunuz.
• Yedekler şifreli ve erişim yetkileri kısıtlı.
• Başarısız yedekler için bildirim kurulu.
• Saklama süresi tanımlı ve KVKK politikasıyla uyumlu.
• Son geri yükleme testi üç aydan eski değil.
• Geri yükleme adımları yazılı ve en az iki kişi biliyor.

Bu listenin hepsi işaretliyse iyi bir noktadasınız. Eksik maddeler varsa, en üstten başlayarak tek tek kapatın; hepsini aynı hafta çözmek zorunda değilsiniz.

Web sitesi yedekleme sürecini kendiniz mi yönetmelisiniz, destek mi almalısınız?

Küçük ve az değişen bir kurumsal sitede, iyi bir hosting yedeği ve ayda bir alınan bağımsız bir kopya çoğu zaman yeterlidir. Bu düzeyi kendiniz rahatlıkla yönetebilirsiniz.

Öte yandan e-ticaret sitesi işletiyorsanız, özel yazılım kullanıyorsanız veya birden fazla sunucunuz varsa, işin içine otomasyon, şifreleme ve izleme girer. Bu noktada destek almak mantıklıdır. Web tasarım projelerimde yedek planını teslimin bir parçası olarak kuruyorum; e-ticaret danışmanlığı tarafında ise sipariş verisinin korunmasını ayrı bir başlık olarak ele alıyorum.

Hangi yolu seçerseniz seçin, yedek konusunu siteyi güncel tutma rutininizin içine yerleştirin. Teknik sağlığın diğer taraflarını merak ediyorsanız teknik SEO ipuçları yazısı iyi bir devam olur. Sorularınız için iletişim sayfasından bize ulaşabilirsiniz.