Web sitesi sahiplerinin çoğu, siteleri çalıştığı sürece yedekleme konusunu hiç düşünmüyor. Sorun, tam da bu yüzden büyüyor: hosting hesabı hacklendiğinde, yanlışlıkla bir dosya silindiğinde veya sunucu sağlayıcısı beklenmedik bir arıza yaşadığında geri dönecek bir plan olmuyor.

Web mimarisi ve yazılım projelerinde sık karşılaştığım bir durum: müşteri "sitem hacklendi, ne yapacağım" diye ulaşıyor ve elinde hiçbir yedek bulunmuyor. Bu yazıda küçük işletmeler için gerçekçi, uygulanabilir bir yedekleme ve felaket kurtarma yaklaşımını ele alıyorum.

1. Neden "Bana Olmaz" Yanılgısı Tehlikeli?

Küçük işletme sahipleri genelde hedef olmayacaklarını düşünüyor, oysa otomatik saldırı botları site büyüklüğüne bakmıyor; bilinen güvenlik açıklarını tarayıp bulduğu her siteye saldırıyor. Ayrıca insan hatası da en az saldırı kadar sık: yanlışlıkla silinen bir dosya, bozulan bir güncelleme veya hosting sağlayıcısının kendi teknik sorunu, hedefli bir saldırıdan çok daha sık yaşanan veri kaybı sebepleri arasında.

2. Yedekleme Neyi Kapsamalı?

Bir web sitesinin tam yedeği tek bir dosyadan ibaret değil, birkaç farklı bileşeni kapsıyor.

  • Kaynak kod: HTML, CSS, JS dosyaları veya CMS kurulumu
  • Veritabanı: WordPress gibi dinamik sistemlerde içerik veritabanda tutulur, ayrı yedeklenmesi gerekir
  • Görseller ve medya: Yüklenen tüm görsel, video ve doküman dosyaları
  • Yapılandırma dosyaları: DNS ayarları, e-posta yönlendirmeleri, SSL sertifikası bilgileri
  • Alan adı (domain) bilgisi: Domain'in hangi hesapta, hangi sağlayıcıda kayıtlı olduğu belgelenmeli

3. Yedek Nerede Saklanmalı?

En sık yapılan hata, yedeği sitenin barındığı aynı sunucuda tutmak. Sunucu tamamen kaybedildiğinde (fiziksel arıza, hesap askıya alma, saldırı) o sunucudaki yedek de kayboluyor. Doğru yaklaşım, yedeği barındığı sunucudan bağımsız bir konumda (ayrı bulut depolama, farklı bir hesap) tutmak. "3-2-1 kuralı" (3 kopya, 2 farklı ortam, 1'i uzak konumda) küçük bir işletme için de uygulanabilir bir çerçeve sunuyor.

4. Otomatik mi, Manuel mi?

Manuel yedekleme, "hatırlarsam yaparım" mantığına dayandığı için güvenilir değil. Hosting sağlayıcılarının çoğu otomatik yedekleme özelliği sunuyor; bu özellik açık değilse etkinleştirilmeli. Statik HTML sitelerde ise Git gibi bir sürüm kontrol sistemi, kod değişikliklerinin otomatik olarak kayıt altına alınmasını sağlıyor; bu hem yedekleme hem de hata durumunda önceki sürüme dönme imkanı veriyor.

5. Felaket Kurtarma Planı: Yedek Yetmez, Süreç de Gerekir

Yedek dosyasına sahip olmak tek başına yetmez. Felaket anında ne yapacağınız önceden belli değilse panikle geçen saatler işi büyütür. Basit bir felaket kurtarma planında şunlara bakıyorum:

Adım 1: Erişim bilgilerini tek yerde topla

Hosting paneli, domain yönetim paneli, e-posta hesabı ve yedekleme servisi giriş bilgilerini güvenli ama ulaşabileceğiniz bir yerde (şifre yöneticisi gibi) tutmanızı öneririm. Kriz anında bu bilgilere ulaşamamak ilk saatleri boşa geçirtir. Bu bilgilerin kimde olması gerektiğini web sitesi sahipliği yazımda anlattım.

Adım 2: Yeniden yükleme sürecini önceden test et

Yedeğin gerçekten çalıştığından emin olmanın tek yolu ara sıra deneme amaçlı geri yükleme yapmak. Hiç denenmemiş bir yedek kriz anında bozuk çıkabilir. Bunu en az yılda bir kez yapmanızı öneririm. Küçük teknik sorunların işletmeye gerçek maliyetini teknik krizler yazımda anlattım.

Adım 3: İletişim planı hazırla

Site geçici olarak açılmıyorsa müşterilere ya da ziyaretçilere nasıl haber vereceğinizi (sosyal medya duyurusu, geçici bir sayfa) önceden düşünün.

Yedek Dosyalarını Adlandırın ve Tarihleyin

Yedek dosyasının adına tarih ekleyin, örneğin site-2026-10-14. Hangi yedeğin ne zaman alındığı belli değilse kriz anında hangisini geri yükleyeceğinize karar vermek zorlaşır. Aynı klasörde "yedek" ve "yedek-son" adlı dosyalar birikirse hangisinin güncel olduğunu kimse bilemez.

Kaç Yedek Saklamalı?

Yalnızca son yedeği saklamak yeterli değil, çünkü sorun fark edildiğinde son yedek de bozulmuş olabilir. Son birkaç haftanın yedeklerini saklamak, bozulmamış bir sürüme geri dönmenizi sağlar. Saklama süresi sitenin ne sıklıkla değiştiğine bağlı, çok sık değişen bir sitede daha sık yedek ve daha uzun saklama gerekir.

Büyük Değişiklikten Önce Yedek Alın

Yeni bir sürümü yayınlamadan, eklenti güncellemeden ya da tasarım değiştirmeden önce elle bir yedek alın. Otomatik yedek gece çalışıyorsa gündüz yaptığınız değişiklik yedeklenmemiş olur. Değişiklik bozulursa geri dönecek tazelikte bir kopyanız bulunmalı.

Saf Kodlu Sitede Yedek Nasıl İşler?

Veritabanı olmayan saf kodlu bir sitede yedek, site dosyalarının bir kopyasından ibaret ve geri yüklemesi çok kolay. Kendi sitelerimde sürüm kontrolü kullanıyorum ve günlük otomatik yedek alıyorum, böylece her değişikliğin geçmişi duruyor. Bu yöntem, bir değişiklik bozulduğunda önceki hale dönmeyi dakikalara indiriyor.

E-posta Yedeği

Siteyle birlikte iş e-postası da kaybolabilir. E-posta hesabınız barındırma firmasında duruyorsa içeriğin bir kopyasını ayrıca saklayın. Müşteri yazışmaları ve teklifler çoğu zaman yalnızca e-postada bulunuyor ve bunları kaybetmek siteyi kaybetmekten daha ağır olabilir.

Geri Yükleme Denemesi İçin Takvim

Yedek geri yüklemeyi üç ayda bir bir test ortamında deneyin. Dosyalar açılıyor mu, görseller yerinde mi, formlar çalışıyor mu? Deneme birkaç saatinizi alır ama gerçek bir krizde elinizdeki yedeğin işe yaradığını bilmenizi sağlar. Denemeyi takvime yazarsanız unutulmaz.

Barındırma Firmasının Yedeği Yeterli mi?

Barındırma firmaları genelde kendi yedeklerini tutar ama bunlar sizin için garanti edilmiş bir hizmet olmayabilir. Kapsamı ve saklama süresi sözleşmeye göre değişiyor ve hesabınız askıya alınırsa o yedeğe de erişemezsiniz. Kendi kopyanızı ayrıca saklamak, bu bağımlılığı ortadan kaldırıyor. Hesapların kimin adına açıldığını web sitesi sahipliği ve mülkiyeti yazımda anlattım, güvenlik tarafını ise web sitesi güvenliği yazımda ele aldım.

6. Küçük İşletmeler İçin Gerçekçi Bütçe Yaklaşımı

Kurumsal düzeyde felaket kurtarma sistemleri karmaşık ve maliyetli olabiliyor ama küçük bir işletme için bu seviyeye gerek yok. Düzenli otomatik yedekleme, yedeğin ayrı bir konumda tutulması ve erişim bilgilerinin düzenli olması, çoğu senaryoyu karşılıyor. Web yazılım hizmetlerim kapsamında yeni proje teslimlerinde yedekleme yapılandırması da değerlendiriliyor.

Sitenizin yedekleme durumunu gözden geçirmek isterseniz web yazılım hizmetlerimi inceleyebilir ya da doğrudan görüşebilirsiniz.

Sık Sorulan Sorular

Web sitesi yedeği ne sıklıkla alınmalı?

İçerik sık güncellenen sitelerde (blog, e-ticaret) günlük otomatik yedek; nadiren güncellenen kurumsal sitelerde haftalık yedek yeterli olabilir. Önemli olan yedeğin düzenli ve otomatik alınmasıdır, manuel hatırlatmaya bağlı kalmamaktır. Yedek tek başına yetmez, sitenin kendisini korumak için neler yaptığımı web sitesi güvenliği yazımda anlattım.

Yedek dosyalar nerede saklanmalı?

Yedek, barındığı sunucudan bağımsız bir konumda tutulmalı; aynı sunucuda tutulan yedek, sunucu tamamen kaybedildiğinde işe yaramaz. Bulut depolama veya ayrı bir hesapta saklama önerilir.

Statik HTML site de yedeklenmeli mi?

Evet. Statik sitede veritabanı olmasa da kaynak kodu, görseller ve yapılandırma dosyaları kaybedilebilir; sürüm kontrolü (Git) ve ayrı bir depolama alanı statik siteler için de gereklidir.