Saat gece iki. Sitenizin yöneticisi olarak telefonunuza bir uyarı düşüyor: ana sayfa yerine sarı bir hata ekranı, ya da daha kötüsü, sitenizin URL'sini arattığınızda Google "Bu site güvenli olmayabilir" uyarısı veriyor. Bir eklenti güncellemesi veritabanını bozmuş olabilir, bir saldırgan wp-admin'e sızıp içeriği değiştirmiş olabilir, ya da bir ekip arkadaşınız yanlış sayfayı silmiş olabilir. Sebep ne olursa olsun, o anda sorduğunuz tek soru aynı: elimde, gerçekten çalışan, bu ana kadar olan her şeyi geri getirecek bir kopya var mı?
Bu yazı o sorunun cevabını iki yönden ele alıyor: yedeğiniz yoksa gerçekte neyi kaybettiğinizi ve doğru bir yedekleme stratejisinin somut olarak neye benzediğini. Genel geçer tavsiyeler yerine, hangi yöntemin hangi senaryoda işe yaramadığını ve bir yedeğin geri yüklenebilir olduğundan nasıl emin olacağınızı anlatıyoruz.
Yedeğiniz yoksa gerçekte ne kaybedersiniz
"Yedek almadım, ne olacak ki" düşüncesi genelde kaybın boyutunu küçümsemekten kaynaklanır. Kaybettiğiniz şey tek bir dosya değil, üst üste binen birkaç farklı şeydir. Önce içerik kaybı var: yıllar içinde yazılmış blog yazıları, ürün açıklamaları, müşteri yorumları, form gönderimleri. Sonra arama motoru otoritesi geliyor; Google'ın sitenize yıllar içinde verdiği güven, sayfalar 404 döndüğü anda sıfırlanmaz ama ciddi şekilde sarsılır, özellikle site günlerce erişilemez durumda kalırsa. Ardından gelir kaybı: bir e-ticaret sitesi için her saatlik kesinti doğrudan kayıp sipariş demektir, bir ajans için ise müşteriye "siteniz kayboldu, elimizde kopyası yok" demek zorunda kalmak, o müşteriyi tamamen kaybetmek anlamına gelebilir.
Son olarak, çoğu zaman göz ardı edilen bir maliyet var: yeniden kurma süresi. Yedeği olmayan bir site sıfırdan kurulmaz, çünkü veritabanındaki binlerce satır, yüklenmiş görseller, eklenti ayarları elle yeniden üretilemez. Gerçekte olan şey, sitenin büyük ölçüde kaybolması ve geriye sadece parça parça hatırlanan bir hafızanın kalmasıdır. Bir yedek sisteminin bedeli, bu senaryoyla karşılaştırıldığında neredeyse önemsiz kalır.
Rakamlarla tehdit: bu ihtimal sandığınızdan daha yakın
Bunu soyut bir risk gibi görmek kolay, ta ki rakamlara bakana kadar. Patchstack'in 2025 WordPress Güvenlik Raporu'na göre, dünya genelinde günde yaklaşık 13.000 WordPress sitesi hackleniyor; yıllık bazda bu rakam 4,7 milyonu buluyor. Aynı raporda, yeni açıklanan güvenlik açıklarının ortanca 5 saat içinde kitlesel olarak istismar edilmeye başlandığı, yani bir yama çıkana kadar geçen sürenin artık saldırganların lehine işlediği belirtiliyor. Bu, "benim küçük sitemle kimse ilgilenmez" varsayımının neden yanıltıcı olduğunu gösteriyor: bu saldırıların büyük kısmı otomatik taramalarla, sitenin büyüklüğüne bakılmaksızın yapılıyor.
İkinci rakam yedeklemeyle daha da doğrudan ilgili. Sophos'un State of Ransomware 2025 raporuna göre, fidye yazılımı saldırılarının %94'ünde saldırganlar kurbanın yedeklerini de hedef alıyor; yedekler ele geçirildiğinde kurtarma maliyeti kat kat artıyor. Bunun anlamı şu: yedeğiniz sadece var olması gereken bir şey değil, saldırganın ilk hedeflerinden biri, dolayısıyla ana sisteminizle aynı erişim bilgilerini paylaşan bir yedek, aslında hiç yedek değil.
Eksiksiz bir yedek neyi kapsamalı
Eksiksiz bir yedek iki parçadan oluşur: site dosyaları ve veritabanı. Dosya tarafında sadece tema ve eklentiler değil, en kritik olan wp-content/uploads klasörü de dahil olmalı; buradaki yıllar içinde biriken görseller, PDF'ler ve indirilebilir dosyalar çoğu zaman gigabaytlarca yer tutar ve birçok kısıtlı yedekleme çözümü, boyutu küçültmek için tam da bu klasörü atlar. wp-config.php dosyası ve .htaccess de unutulan ama kritik dosyalardır; site anahtarlarını ve sunucu seviyesi yönlendirme kurallarını taşırlar, kaybolduklarında site teknik olarak ayakta kalsa bile beklenmedik şekilde davranmaya başlar.
Veritabanı tarafında ise yazılar, sayfalar, yorumlar ve kullanıcı hesapları akla ilk gelenler; ama eklenti ayar tabloları, WooCommerce kullanıyorsanız sipariş ve stok verileri, form eklentisi kullanıyorsanız gönderim kayıtları da aynı veritabanının parçası. Sadece dosyaları yedeklerseniz içerik ve ayarları kaybedersiniz, sadece veritabanını yedeklerseniz yüklediğiniz görselleri ve eklenti dosyalarını kaybedersiniz. Gerçek bir felaket kurtarma senaryosunda ikisine de aynı anda, aynı zaman damgasıyla ihtiyacınız olur; farklı tarihlerden alınmış bir dosya yedeği ile bir veritabanı yedeğini birlikte geri yüklemek, eşleşmeyen ID'ler ve kayıp medya bağlantıları yüzünden yeni sorunlar yaratır.
Yedekleme yöntemlerini karşılaştırma
"Yedek alıyorum" demek tek bir şey ifade etmiyor; hangi yöntemi kullandığınız, o yedeğin bir felaket anında işe yarayıp yaramayacağını belirliyor. Aşağıdaki tablo, sahada en sık karşılaşılan dört yaklaşımı aynı kriterlerle karşılaştırıyor.
| Yöntem | Otomatik mi | Sunucudan bağımsız mı (offsite) | Geri yükleme kolaylığı |
|---|---|---|---|
| Manuel FTP indirme + phpMyAdmin export | Hayır, elle yapılır | Ancak siz başka bir yere taşırsanız | Zor: dosya ve veritabanı elle eşleştirilir, hata payı yüksek |
| Yedekleme eklentisi (WordPress içinden) | Evet, zamanlanabilir | Sadece harici depolama bağlarsanız, varsayılan olarak hayır | Orta: eklenti çalışıyorsa kolay, sitenin kendisi çöktüyse eklentiye erişemezsiniz |
| Host seviyesinde yedekleme (hosting panel) | Evet | Hayır, genelde aynı sunucuda veya aynı sağlayıcıda tutulur | Kolay ama sağlayıcıya bağımlı; hesap askıya alınırsa erişim de gider |
| Bağımsız, sunucu dışı bulut yedekleme | Evet | Evet, ayrı bir sağlayıcı ve ayrı kimlik bilgileriyle | Kolay: site tamamen erişilemez olsa bile yedeğe ulaşılır |
Tablodaki fark aslında tek bir soruya iniyor: siteniz tamamen erişilemez hale gelirse (hesap askıya alınır, sunucu ele geçirilir, hosting sağlayıcısı iflas eder) yedeğinize hâlâ ulaşabilir misiniz? Sadece son satırdaki yaklaşım bu soruya kesin "evet" cevabı veriyor, çünkü yedek, sitenin kaderine bağlı olmayan tamamen ayrı bir sistemde duruyor.
Ne sıklıkla yedek alınmalı
Sıklık, sitenizin ne kadar hızlı değiştiğine bağlı. Günde birkaç yazı yayınlanan bir blog veya sürekli sipariş alan bir e-ticaret sitesi için günlük, hatta saatlik yedekleme mantıklı; içerik nadiren değişen bir kurumsal tanıtım sitesi için haftalık yeterli olabilir. Pratik bir kural şu: en son yedekten bu yana kaybetmeyi göze alabileceğiniz içerik miktarı ne kadarsa, yedekleme aralığınız o miktarı üretmeniz için geçen süreyi aşmamalı. Bir e-ticaret sitesi günde 50 sipariş alıyorsa ve haftalık yedek kullanıyorsa, en kötü senaryoda bir haftalık siparişi kaybetme riskini göze almış olur.
Sıklıktan sonra sıra saklamada: 3-2-1 kuralı
Doğru sıklıkta alınmış ama tek bir yerde duran bir yedek, hâlâ kırılgandır. Burada yedekleme dünyasının en eski ve en test edilmiş kuralı devreye giriyor: en az 3 kopya, 2 farklı ortamda, 1 tanesi sunucudan tamamen bağımsız. Üç kopya, tek bir dosyanın bozulma ihtimaline karşı yedeklilik sağlar; iki farklı ortam (örneğin sunucu diski ve bulut depolama), tek bir depolama teknolojisinin veya sağlayıcının aynı anda arızalanma riskini azaltır. Ama asıl kritik olan üçüncü şart: en az bir kopyanın sunucudan tamamen bağımsız, offsite bir konumda durması.
Bunun nedeni basit: yedekleri sadece sitenizin bulunduğu sunucuda tutmak, aslında hiç yedek tutmamakla neredeyse aynı risk seviyesindedir. Sunucu hacklenirse, saldırgan aynı erişimle yedek dosyalarına da ulaşır ve onları da silebilir veya şifreleyebilir; tam olarak Sophos'un raporundaki %94'lük rakamın işaret ettiği senaryo bu. Sunucu donanımsal olarak çökerse veya hosting sağlayıcısı hesabınızı (yanlışlıkla ya da haklı bir nedenle) askıya alırsa, aynı sunucudaki yedek de sizinle birlikte erişilemez hale gelir. Ayrı bir depolama sağlayıcısında, ayrı kimlik bilgileriyle tutulan bir kopya, bu senaryoların hiçbirinde sizinle birlikte kaybolmaz.
Bir yedeğin gerçekten işe yaradığından nasıl emin olursunuz
Test edilmemiş bir yedek, var olduğunu düşündüğünüz ama aslında olmayan bir güvenlik ağıdır. Bozuk sıkıştırılmış dosyalar, yarım kalmış veritabanı export'u, yükleme sırasında kesilen bağlantı yüzünden eksik kalan bir arşiv, hepsi bir yedeğin "alındı" görünüp aslında geri yüklenemez olmasının yaygın nedenleri. Bunu keşfetmenin en kötü anı, tam da o yedeğe ihtiyacınız olduğu andır.
Somut bir test prosedürü şöyle işler: önce canlı siteden ayrı, gerçek bir hosting ortamında (yerel bir kurulum da olur) boş bir WordPress kurun. Ardından en güncel yedeğinizi bu ortama geri yükleyin, dosyaları ve veritabanını tam olarak yedekleme aracının önerdiği sırayla uygulayın. Geri yükleme bittiğinde üç şeyi kontrol edin: site giriş ekranına ulaşılabiliyor mu, rastgele seçtiğiniz birkaç sayfa ve gönderi eksiksiz görünüyor mu, yüklü medya dosyaları (görseller, PDF'ler) kırık link vermeden açılıyor mu. Medyada kırık link görürseniz nedenini ve düzeltme yollarını kırık link düzeltme rehberinde bulabilirsiniz. Bu üçü de doğruysa yedeğiniz gerçekten çalışıyor demektir. Bu testi ayda bir tekrarlamak, yedekleme aracınızın sessizce bozulmadığından emin olmanın tek yolu; birçok yedekleme hatası fark edilmeden aylarca sürer, çünkü kimse yedeği gerçekten geri yüklemeden hatanın var olduğunu göremez.
Siteniz hacklendiğinde ya da çöktüğünde, adım adım ne yapmalısınız
İlk adım siteyi hemen bakım moduna alıp veya tamamen kapatıp daha fazla hasarı önlemek; bir saldırgan hâlâ erişimi elindeyse, site açık kaldığı her dakika ek zarar verme fırsatı bulur. İkinci adım, hacklenme öncesine ait, temiz olduğundan emin olduğunuz en yakın yedeği bulmak. Burada acele etmemek gerekir: hacklenme sonrası alınmış bir yedeği geri yüklemek, zararlı kodu da olduğu gibi geri getirir ve sorunu çözmek yerine sıfırlar. Bu yüzden yedeklerin sadece son halini değil, tarihli bir geçmişini tutmak (örneğin son 30 günün her gününe ait ayrı bir kopya) kritik önem taşır; hangi tarihte neyin değiştiğini bilmeden temiz noktayı bulmak neredeyse imkansızdır.
Yedek geri yüklendikten sonra, siteyi tekrar yayına almadan önce açığın nasıl girdiğini bulup kapatmak gerekir. Aksi halde aynı yoldan birkaç gün içinde tekrar saldırıya uğrarsınız, çünkü sadece sonucu düzeltip sebebi bırakmış olursunuz. Bu genelde güncel olmayan bir eklenti, zayıf bir yönetici parolası veya eski bir kullanıcı hesabıdır; geri yükleme sonrası tüm parolaları değiştirmek ve eklenti/çekirdek güncellemelerini kontrol etmek, sürecin atlanmaması gereken son adımıdır.
Manuel mi otomatik mi yedekleme daha güvenli
Manuel yedekleme insan hafızasına bağlıdır ve tam da en çok ihtiyaç duyulan anda, yoğun bir haftada ya da tatildeyken unutulur. Kimse kötü niyetle yedek almayı atlamaz, sadece hatırlamak için ayrı bir sisteme güvenmek gerçekçi değildir. Otomatik yedekleme bu riski tamamen ortadan kaldırır: belirlenen sıklıkta, kimsenin hatırlamasına gerek kalmadan arka planda çalışır ve başarısız olduğunda size haber verir. Tek sistemden çok sayıda site yönetiyorsanız otomatik yedekleme neredeyse zorunlu hale gelir; onlarca siteyi elle takip etmek, er ya da geç en az birinin gözden kaçmasına yol açar, tam da yedeğe ihtiyaç duyulduğu gün.
Kaynaklar
- Patchstack, State of WordPress Security in 2025 raporu, patchstack.com
- Sophos, State of Ransomware 2025 raporu, sophos.com
Bu adımları her site için elle takip etmek yerine, Watch Your WP otomatik yedeklemeyi, yedek indirmeyi ve tek tıkla geri yüklemeyi tüm siteleriniz için tek panelden ücretsiz yönetir.
Erdinç
Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.
LinkedIn