Web Sitesi Yedekleme ve Güvenlik Kontrol Listesi

Bir web sitesinin başına gelebilecek en kötü şey çoğu zaman saldırı değil, saldırıdan sonra geri dönülecek temiz bir yedeğin olmamasıdır. Yedekleme ve güvenlik aynı madalyonun iki yüzüdür: güvenlik sorunu yaşama olasılığını azaltır, yedek ise sorun yaşandığında zararı sınırlar. Bu yazıda, birden fazla siteyi yönetenler için uygulanabilir bir yedekleme stratejisi ve temel güvenlik kontrol listesi sunuyoruz.

Yedek almak ile geri yükleyebilmek aynı şey değil

Pek çok sitenin "yedeği vardır", ama bu yedeklerin ne kadarının gerçekten geri yüklenebildiği test edilmemiştir. Bozuk arşiv dosyaları, eksik veritabanı tabloları, yedeğe dahil edilmemiş yükleme klasörü veya yalnızca sunucunun kendisinde tutulan ve sunucuyla birlikte kaybolan yedekler sık karşılaşılan durumlardır. Bu yüzden yedekleme stratejisinin başarı ölçütü, alınan yedek sayısı değil, son geri yükleme testinin tarihi olmalıdır.

3-2-1 kuralı

Yedeklemede yaygın kabul gören 3-2-1 kuralı basit bir çerçeve sunar:

• 3 kopya: canlı veri ve en az iki yedek.
• 2 farklı ortam: örneğin sunucu diski ve bir nesne depolama servisi.
• 1 kopya başka bir yerde: sitenin bulunduğu sunucu ve veri merkezinden bağımsız bir konumda.

Web siteleri için pratik bir uygulama şöyle olabilir: sunucuda son birkaç günün yedeği (hızlı geri dönüş için), ayrıca farklı bir sağlayıcıdaki depolama alanında daha uzun süreli arşiv. Fidye yazılımı ve hesap ele geçirilmesi gibi senaryolara karşı, uzak yedeğe site sunucusundan yalnızca yazma (silme değil) yetkisiyle erişilmesi ek bir güvence sağlar.

Neyi, ne sıklıkla yedeklemeli?

Bu tablo bir başlangıç noktasıdır. Asıl soru şudur: "Bu siteyi dünkü haline geri döndürsem ne kaybederim?" Kaybedilecek şey birkaç saatlik sipariş verisiyse, günlük yedek yetmez. Saklama süresini belirlerken de şunu unutmayın: bazı saldırılar haftalarca fark edilmez; yalnızca son üç günün yedeğini tutuyorsanız, temiz bir yedeğe ulaşamayabilirsiniz.

Yedeğin içinde olması gerekenler

• Veritabanının tam dökümü (tüm tablolar, doğru karakter setiyle).
• Yüklenen medya dosyaları (WordPress'te wp-content/uploads).
• Tema, alt tema ve özel eklenti dosyaları; özellikle elle düzenlenmiş dosyalar.
• Yapılandırma dosyaları: wp-config.php, .htaccess veya Nginx yapılandırması, cron tanımları.
• Sitenin yeniden kurulumu için gereken bilgiler: PHP sürümü, gerekli PHP eklentileri, DNS kayıtları. Bunlar dosya değil ama geri yüklemede en çok zaman kaybettiren eksiklerdir.

Yedek arşivleri parola veya veritabanı bilgisi içerdiğinden şifrelenmeli ve herkese açık bir dizinde asla tutulmamalıdır. Web kök dizininde unutulmuş bir yedek.zip dosyası, saldırganların otomatik olarak aradığı ilk şeylerdendir.

Geri yükleme testi nasıl yapılır?

1. Rastgele bir site ve rastgele bir yedek tarihi seçin.
2. Yedeği canlı sunucuya değil, ayrı bir test ortamına geri yükleyin.
3. Sitenin açıldığını, yönetim paneline girilebildiğini, son içeriklerin ve görsellerin yerinde olduğunu kontrol edin.
4. Geri yüklemenin kaç dakika sürdüğünü not edin. Bu süre, gerçek bir felakette sitenin ne kadar kapalı kalacağının tahminidir.
5. Eksik veya hatalı bir şey bulursanız yedekleme yapılandırmasını düzeltin ve testi tekrarlayın.

Bu testi üç ayda bir yapmak, yedekleme sisteminin sessizce bozulmasını önlemenin en güvenilir yoludur.

Temel güvenlik kontrol listesi

Erişim

• Tüm yönetici hesaplarında güçlü ve benzersiz parolalar, mümkünse iki aşamalı doğrulama.
• Kullanıcıların yalnızca ihtiyaç duydukları yetkiye sahip olması: içerik yazarı yönetici olmamalı.
• İşi biten çalışanların, ajansların ve geliştiricilerin hesaplarının kapatılması.
• FTP yerine SFTP veya SSH anahtarıyla erişim.

Yazılım

• Çekirdek, eklenti ve temaların güncel tutulması (bkz. WordPress bakım otomasyonu).
• Kullanılmayan eklenti ve temaların silinmesi.
• Yalnızca güvenilir kaynaklardan eklenti kurulması; "ücretsiz premium" olarak dağıtılan korsan eklentiler sıklıkla zararlı kod içerir.
• Barındırma tarafında desteklenen bir PHP sürümünün kullanılması.

Sunucu ve ağ

• HTTPS zorunlu, sertifikalar otomatik yenileniyor.
• Bir web uygulama güvenlik duvarı (WAF) veya en azından giriş sayfası için hız sınırlaması.
• Dosya izinlerinin doğru ayarlanması; yükleme klasöründe PHP çalıştırılmasının engellenmesi.
• Yönetim panelinde dosya düzenleyicinin kapatılması: define( 'DISALLOW_FILE_EDIT', true );

İzleme

• Dosya bütünlüğü kontrolü: çekirdek dosyalar değiştiyse uyarı.
• Yeni yönetici hesabı oluşturulduğunda bildirim.
• Dışarıdan uptime ve içerik izleme: sayfada beklenmedik bir metin (örneğin spam bağlantılar) belirirse fark edilmesi.

Güvenlik sorunu yaşandığında ilk adımlar

Paniğe kapılıp hemen yedekten geri yüklemek cazip gelebilir, ama sorunun kaynağı kapatılmadan geri yüklenen bir site kısa sürede yeniden ele geçirilir. Daha sağlıklı bir sıra şöyledir:

1. Sınırla: gerekiyorsa siteyi bakım moduna alın, şüpheli kullanıcıları devre dışı bırakın.
2. Kanıtı sakla: mevcut hali (dosyalar ve veritabanı) ayrı bir yere kopyalayın; neyin nasıl girildiğini anlamak için gerekecek.
3. Tüm parolaları değiştir: yönetici, veritabanı, FTP/SSH, barındırma paneli. WordPress'te gizli anahtarları (salt) yenilemek, tüm oturumları sonlandırır.
4. Kaynağı bul: erişim günlükleri, yakın tarihte değişen dosyalar, güncel olmayan eklentiler.
5. Temiz yedekten dön veya temizle: saldırıdan önceki bir yedeğe dönün, ardından açığı kapatan güncellemeleri uygulayın.
6. Arama motorunu kontrol et: site spam içerik yayınladıysa, Google Search Console'daki güvenlik sorunları raporunu inceleyin ve temizlik sonrası inceleme isteyin.

Çoklu sitede yedek ve güvenliği otomatikleştirmek

Onlarca site söz konusu olduğunda yukarıdaki kontrolleri elle yapmak sürdürülebilir değildir. Otomasyonun amacı, istisnaları görünür kılmaktır:

• Her gece tüm sitelerin yedeği alınır ve sonuç tek bir rapora yazılır; yalnızca başarısız olanlar uyarı üretir.
• Yedek dosyalarının boyutu bir önceki güne göre karşılaştırılır. Aniden yarıya düşen bir yedek, eksik alınmış olabilir.
• Haftalık olarak tüm sitelerde yönetici kullanıcı listesi çekilir ve bir önceki haftayla karşılaştırılır.
• Çekirdek dosya sağlama toplamları (checksum) kontrol edilir.

Bu adımların hepsi tek bir panelde birleştiğinde, sabah tek bir ekrana bakarak "her şey yolunda mı" sorusunu yanıtlayabilirsiniz. Böyle bir düzenin nasıl kurulacağını tek panelden site yönetimi yazısında anlattık; kesintileri yakalama tarafı ise uptime izleme rehberinin konusu.

Kurtarma hedefleri: RPO ve RTO

Yedekleme planını konuşurken iki kavram işleri netleştirir. RPO (Recovery Point Objective), bir felakette en fazla ne kadarlık veri kaybını kabul edebileceğinizi ifade eder. Günlük yedek alıyorsanız RPO'nuz en kötü durumda 24 saattir; yani son yedekten sonraki bir günlük sipariş, yorum veya form kaydı kaybolabilir. RTO (Recovery Time Objective) ise sitenin ne kadar sürede yeniden yayına dönmesi gerektiğini gösterir.

Bu iki değeri her site için yazılı hale getirmek, teknik kararları kolaylaştırır. Bir tanıtım sitesi için "24 saat veri kaybı, 8 saatte geri dönüş" kabul edilebilirken, bir e-ticaret sitesi için "1 saat veri kaybı, 1 saatte geri dönüş" gerekebilir. RPO kısaldıkça daha sık yedek, RTO kısaldıkça daha hazır bir geri yükleme altyapısı (örneğin önceden hazırlanmış yedek sunucu) gerekir. Geri yükleme testinde ölçtüğünüz süre, gerçek RTO'nuzun ne olduğunu gösterir; hedefle arasında fark varsa plan gözden geçirilmelidir.

Sık görülen yedekleme hataları

• Yedeğin yalnızca aynı sunucuda tutulması: disk arızası, sunucu silinmesi veya hesabın ele geçirilmesi durumunda yedek de kaybolur.
• Başarısız yedeklerin fark edilmemesi: disk dolduğunda veya veritabanı kilitlendiğinde yedek görevi sessizce hata verir. Her yedek görevinin sonunda başarı kontrolü yapılmalıdır.
• Büyük medya klasörlerinin dışarıda bırakılması: yedeği küçültmek için yükleme klasörünü hariç tutmak, geri yüklemede tüm görsellerin kaybolması demektir.
• Şifreleme anahtarının yedekle aynı yerde saklanması: şifreli yedeğin anahtarı yedeğin yanında duruyorsa şifrelemenin anlamı kalmaz; anahtar kaybolursa da yedek açılamaz.
• Saklama politikasının olmaması: hiç silinmeyen yedekler depolama maliyetini büyütür, çok erken silinenler ise geç fark edilen sorunlarda işe yaramaz.

Sonuç

İyi bir yedekleme stratejisi üç cümleyle özetlenebilir: yedekler sunucudan bağımsız bir yerde dursun, saklama süresi geç fark edilen sorunları kapsayacak kadar uzun olsun ve geri yükleme düzenli olarak test edilsin. Güvenlikte ise mükemmellik değil, sürekli ve sıkıcı bir hijyen hedeflenir: güncel yazılım, az ve doğru yetkili kullanıcı, görünür uyarılar.

Sık sorulan sorular

Barındırma firmasının aldığı yedek yeterli mi?

Ek bir güvence olarak değerlidir, ama tek başına yeterli değildir. Bu yedekler genellikle aynı sağlayıcıda tutulur, saklama süreleri kısa olabilir ve geri yükleme sizin kontrolünüzde olmayabilir. Kendi kontrolünüzdeki bağımsız bir yedek her zaman bulunmalıdır.

Yedekleri ne kadar süre saklamalıyım?

Sitenin türüne göre değişir, ama en az 30 gün iyi bir başlangıçtır. Bazı güvenlik sorunları haftalar sonra fark edildiği için, kısa saklama süresi temiz bir yedeğe ulaşmayı imkânsız hale getirebilir.

Güvenlik eklentisi kurmak yeterli mi?

Güvenlik eklentileri faydalı bir katmandır, ama güncel yazılım, güçlü erişim kontrolü ve bağımsız yedeğin yerini tutmaz. Ayrıca aynı işi yapan birden fazla güvenlik eklentisi kurmak çakışmalara ve yavaşlamaya yol açabilir.

İlgili rehberler

• BakımWordPress Bakım ve Güncelleme Otomasyonu Rehberi
• İzlemeUptime İzleme Rehberi ve Kesinti Uyarıları
• YönetimBirden Fazla Web Sitesini Tek Panelden Yönetmek