WordPress yedek alma işlemi, olası güncelleme hatası, güvenlik sorunu, sunucu arızası ve yanlışlıkla silme durumunda siteyi geri getirebilmek için temel güvenlik önlemidir.
Yedek neleri içermeli?
WordPress sitesi tek bir klasörden ibaret değildir. Veritabanı yazıları, sayfaları, kullanıcıları, ayarları ve çoğu eklentinin verisini saklar. Dosya sistemi ise wp-content içindeki yüklemeleri, temaları ve eklentileri kapsar. Yalnızca medya klasörünü kopyalamak tüm siteyi geri getirmez; yalnızca veritabanını saklamak da görselleri geri kazandırmaz. Tam kurtarma için her iki bileşeni birlikte ve birbirine uygun tarihte saklayın.
Yedek planının kapsamına özel yapılandırma dosyalarını da alın. wp-config.php dosyası kurulum ayarları barındırır; bu dosyayı herkese açık bir klasöre yüklemeyin. Hosting paneli, SSL ve DNS yapılandırmalarının bazıları WordPress yedeğinin dışında kalabileceğinden erişim bilgilerini güvenli ortamda ayrıca belgelendirin.
WordPress yedeği nasıl alınır?
Hosting yönetim paneline girerek alan adınızın yedekleme bölümünü bulun. Otomatik yedeklerin tutulduğu tarihler, kaç gün saklandıkları ve tam olarak hangi veri türlerini kapsadıkları sağlayıcıya göre değişir. Önemli bir değişiklikten hemen önce manuel yedek oluşturun. Oluşturma tamamlandı uyarısını görmekle yetinmeyin; indirilebilen arşivin boyutunu ve tarihini kontrol edin.
WordPress yönetim panelinde bir yedekleme eklentisi tercih ediyorsanız hem dosya hem veritabanı seçeneklerini etkinleştirin. Zamanlama, uzak depolama, şifreleme, saklama sayısı ve kurtarma özelliğini değerlendirin. Eklenti isimlerinden çok düzenli kurtarma sınaması yapabilmenize önem verin.
Veritabanı nasıl yedeklenir?
phpMyAdmin gibi bir veritabanı aracıyla doğru veritabanını seçin ve dışa aktarma işlemini başlatın. SQL dosyasında kişisel veriler bulunabileceği için bu dosyayı herkese açık indirme bağlantısıyla paylaşmayın. Büyük veritabanlarında panelin süre sınırına takılabilirsiniz; hosting yedekleme özelliği veya uygun komut satırı yöntemi daha güvenli olabilir.
Veritabanı adını wp-config.php dosyasından görebilirsiniz ancak bu dosyadaki parola ve anahtarları not uygulamasına açık biçimde kopyalamayın. Geri yükleme sırasında yanlış veritabanının üzerine yazmak başka bir siteyi bozabilir. İşleme başlamadan bağlantı bilgilerini ve hedef ortamı iki kez doğrulayın.
Dosyalar nasıl yedeklenir?
Hosting dosya yöneticisi veya SFTP ile WordPress kök dizinindeki gerekli dosyaları güvenli biçimde indirin. Özellikle wp-content/uploads dizini site görsellerini barındırır. Üst dizindeki gizli yapılandırma dosyaları ve yeniden yazma kuralları da önem taşıyabilir. Çok büyük medya arşivlerinde dosya aktarımını parçalar hâlinde yapmak gerekebilir.
Yedek arşivini web kök dizininin içine bırakmayın. Aynı sunucuya yazılmış tek yedek, sunucu arızasında işe yaramayabilir. Yerel, güvenilir bulut veya ayrı sunucu gibi farklı konumlar kullanın; yalnızca gereksiz yere çoğaltılmış hassas veriye de dönüşmemesine dikkat edin.
Geri yükleme nasıl yapılır?
Önce geri dönüş hedefini belirleyin: yanlış düzenleme için bir önceki sürüm mü, saldırı öncesi temiz tarih mi, yoksa sunucu taşınması için tam kopya mı gerekiyor? Geri yükleme çoğu zaman mevcut veritabanını ve dosyaları değiştirir. Bu nedenle bozuk görünen mevcut hâlin de ayrı bir anlık yedeğini alın; sonrasında ihtiyacınız olabilecek yeni sipariş veya yorumları kaybetmeyin.
Hosting panelinde doğru yedeği seçip dosya ve veritabanı geri yüklemesini birlikte çalıştırın. Eklenti kullanıyorsanız onun kurtarma yönergelerine uyun. İşlem sonrasında oturum açma, kalıcı bağlantılar, görseller, formlar, arama ve varsa ödeme akışını test edin.
Yedekleme sıklığı nasıl seçilir?
Haftada bir yazı yayımlanan kişisel blog ile her dakika sipariş alan mağazanın veri kaybı toleransı aynı değildir. Sık değişen veritabanları daha sık yedek ister. Günlük yedek, birçok içerik sitesi için başlangıç noktası olabilir; ancak bu öneri evrensel değildir. Mağaza için daha sık anlık kurtarma noktaları gerekebilir.
Saklama süresi ve bütçe birlikte belirlenir. Son birkaç yedeğin hepsi bir haftadır bozuksa daha eski temiz sürüm bulunması gerekir. Bu yüzden farklı tarih aralıklarında saklanan dönüş noktaları oluşturun ve gerçek kurtarma denemelerinin sonucunu kayda geçirin.
Güvenlik ve kişisel veriler
Yedekler WordPress’in kendisinden daha hassas olabilir: kullanıcı bilgileri, sipariş verileri ve ayarlar içerir. Uzak depolama erişimini iki aşamalı doğrulamayla koruyun, mümkünse yedekleri şifreleyin, erişimi yalnızca yetkili kişilere verin. Bir paylaşım bağlantısının Google’da indekslenebilir hâle gelmediğini kontrol edin.
Yedeklerin silinme politikasını da belirleyin. Gereksiz eski müşteri verisini sınırsız saklamak hem güvenlik riskini hem uyumluluk yükünü artırır. İşletmenizin geçerli saklama ve veri koruma yükümlülüklerini ayrıca değerlendirin.
Kurtarma testi neden önemli?
Yedek dosyasının var olması geri dönüşün çalışacağını kanıtlamaz. Ayrı test ortamına geri yükleme yapın, menüleri ve birkaç rastgele eski yazıyı açın, eksik görsel ve bozuk karakter sorunlarını tarayın. Dosyaların tamamı indirilmiş mi, veritabanı tabloları tutarlı mı ve PHP sürümüyle uyumlu mu bakın.
Yedekleme sağlayıcısının otomatik başarılı bildirimleri yararlıdır fakat kurtarma testi kadar kesin değildir. Tarih, yedek konumu, denemeyi yapan kişi, kurtarma süresi ve bulunan sorunları kısa bir tabloda saklamak sonraki krizde karar almayı kolaylaştırır.
3-2-1 yaklaşımı nasıl uygulanır?
Yedek planı hazırlarken sık kullanılan 3-2-1 yaklaşımı, verinin üç kopyasını iki farklı ortamda tutmayı ve bir kopyayı ana sistemden ayrı konumda saklamayı önerir. WordPress için örnek: Canlı site, harici bulut yedeği ve ayrıca güvenilir yerel arşiv. Bu bir sihirli formül değildir; tüm kopyaların aynı hesapla ele geçirilmesi hâlinde riski azaltmak için erişimleri de ayırın. Yedekleri şifreleyin, kurtarma şifresini güvenli biçimde saklayın ve otomatik olarak eski kopyaları silme sınırını belirleyin.
Değişiklik öncesi anlık yedek
Tema veya eklenti güncellemesinden birkaç dakika önce alınan yedek, gece otomatik alınan yedekten daha güncel olabilir. Önce yöneticilerin içerik girişi ve e-ticaret siparişlerinin durumu hakkında bilgi edinin. Ardından veritabanı ve dosyaları eş zamanlı veya birbirine yakın tarihte kaydedin. Yedek tamamlanmadan dosyaları değiştirmeyin. Uzun işlem gerektiren sunucu taşımasında yazı yayımlamayı geçici durdurmak ya da son veritabanı eşitlemesi planlamak veri kaybını azaltabilir. Süreç boyunca hangi kopyanın referans sürüm olduğunu belgeleyin.
Taşıma ile geri yükleme farkı
Bir siteyi aynı sunucuya eski hâliyle döndürmek ve başka bir alan adına taşımak benzer görünse de farklı ayrıntılar içerir. Taşımada alan adı, medya URL’leri, önbellek ve bazen e-posta ayarları değişebilir. WordPress veritabanındaki bağlantıları gelişi güzel metin değiştirme komutuyla düzenlemek serileştirilmiş veriyi bozabilir. Güvenilir taşıma araçları veya WordPress’e uygun arama-değiştirme yöntemleri kullanın. Eski alan adından yenisine geçiş varsa yönlendirmeleri, kanonik adresleri ve site haritasını ayrıca gözden geçirin.
Yedeğin eksiksizliği nasıl sınanır?
Arşiv oluşturulduğunda dosyanın açılabildiğini ve beklenen klasörleri içerdiğini kontrol edin. SQL yedeği içinde gerekli tabloların varlığını, medya arşivinde farklı yıllardan görsellerin yer aldığını inceleyin. Tam test için kopyayı internete açık olmayan ya da erişimi korunan bir staging ortamına geri yükleyin. Eski yazılardan örnekler açın, editöre girin ve görsellerin kaynaklarını doğrulayın. Yedekleme günlüğündeki hata veya atlanan dosya uyarılarını dikkate alın. Başarısız bir kurtarma denemesi, gerçek krizden önce düzeltilebilecek önemli bulgudur.
Otomatik yedek nasıl izlenir?
Otomatik zamanlama ayarlamak işi bitirmez. Yedek aracı belirli tarihte çalışmamış veya bulut kotası dolmuş olabilir. Haftalık kontrol için son başarılı yedek tarihi, toplam boyut, hedef depolama, hata raporu ve saklanan sürüm sayısını kaydedin. Önemli güncellemelerin olduğu gün ayrıca manuel kopya alın. Birden çok yetkili kişi varsa bildirimleri doğru sorumluya yönlendirin. Yedek indirilemediğinde ya da depolama erişimi kesildiğinde ne yapılacağını önceden kararlaştırın.
En sık yapılan yedekleme hataları
Tek kopyayı siteyle aynı sunucuda saklamak, yalnızca veritabanını veya sadece uploads klasörünü yedeklemek, kurtarma denemesi yapmamak ve eski arşivleri korumasız paylaşmak sık hatalardır. Bir başka sorun yedek alırken yeni siparişlerin gelmeye devam etmesi ve dosyalarla veritabanının farklı anlara ait olmasıdır. Bu durumun etkisini sitenin faaliyet türüne göre değerlendirin. Yedeğin çalıştığını varsaymak yerine kanıtlayın; yedek planının hedefi dosya biriktirmek değil, belirli sürede işletilebilir bir siteyi geri getirmektir.
Uygulama öncesi kontrol listesi
İşleme başlamadan önce sitenin güncel yedeğini alın ve mümkünse değişiklikleri bir test ortamında deneyin. Yalnızca güvenilir ürün belgelerini izleyin; panelin görünümü kullanılan tema, eklenti ve sürüme göre değişebilir. Bir ayarı değiştirince eski değerini not edin, ardından sonucun hem masaüstünde hem mobilde doğru çalıştığını doğrulayın. Beklenmeyen bir hata çıkarsa birden fazla şeyi aynı anda değiştirmek yerine son güvenli duruma kontrollü biçimde dönün.
Sık sorulan sorular
WordPress yedek alma işlemleri uzmanlık gerektirir mi? Temel görevler yönetim panelinden yapılabilse de dosya sistemi, DNS, veritabanı, kullanıcı verisi ve ödeme altyapısını etkileyen değişiklikler teknik bilgi gerektirebilir. Emin değilseniz işlem yapmadan önce destek alın.
Bu işlemi canlı sitede hemen yapmalı mıyım? Hayır. Önce değişikliğin kapsamını belirleyin. Özellikle yüksek ziyaretli veya e-ticaret sitelerinde test, yedek ve geri dönüş planı olmadan geniş kapsamlı işlem yapmak ziyaretçilere zarar verebilir.
Hata olduğunda ilk neye bakmalıyım? Son değişikliklerin tarihine, WordPress ve eklenti sürümlerine, ilgili hata kayıtlarına ve hosting durumuna bakın. Gereksiz yeni eklenti kurmak yerine sorunun hangi adımda ortaya çıktığını kaydedin.
WordPress yedeği ne kadar süre saklanmalı?
Tek bir süre herkes için doğru değildir. Haber sitesi sık içerik değiştiriyor, mağaza sürekli sipariş alıyor olabilir. Hedeflenen geri dönüş noktası, olası hatanın ne zaman fark edileceği ve veri saklama yükümlülükleri süreyi etkiler. Yakın tarihli birkaç kopyanın yanında daha eski temiz kopya bulundurmak yararlıdır. Buna karşılık sınırsız saklama gereksiz kişisel veri ve maliyet doğurur. Düzenli gözden geçirilen bir saklama politikası kullanın.
Eklenti kullanmadan yedek alınabilir mi?
Evet. Hosting panelinden dosya ve veritabanı yedeği almak, SFTP ile dosyaları ve uygun veritabanı aracıyla SQL çıktısını indirmek mümkündür. Ancak bu işlemleri bilmeden yapmak eksik arşive yol açabilir. Manuel yedekte klasör izinleri, veritabanı tablosu ve geri yükleme sırası önemlidir. Önce test ortamında kurtarma uygulaması yapın. Parola ve anahtarları güvenli yerde tutun.
Yedek sunucuda mı bulutta mı olmalı?
Tek konum yeterli değildir. Sunucu içindeki yedek hızlı geri dönüş sağlayabilir ama sunucunun tamamen kaybolması durumunda işe yaramayabilir. Ayrı hesapla korunan uzak depolama daha dayanıklı olabilir; yine de erişim hesabı ele geçirilirse risk sürer. Dosyaları güvenli aktarın ve hassas verileri şifreleyin. Farklı konumdaki bir kopyayı açıp geri yükleyebildiğinizi aralıklı olarak test edin.
Yedek geri yükleme SEO’yu etkiler mi?
Geri yükleme sonrası eskimiş içerikler, değişen URL’ler veya kaybolmuş yönlendirmeler arama performansını etkileyebilir. Bu yüzden sadece ana sayfayı açmakla yetinmeyin. Site haritası, robots.txt, kanonik etiketler, önemli rehber URL’leri ve görselleri kontrol edin. Search Console’da belirgin yeni tarama hataları var mı izleyin. Bu, geri yüklemenin teknik olarak başarılı görünmesine rağmen ziyaretçi ve arama motoru sorunlarını azaltır.
Gerçek hayattan uygulama örneği
Örnek senaryo: Bir haber sitesinde gece alınan yedekten sonra sabah beş haber yayımlandı ve öğleden sonra tema güncellemesi bozuldu. Gece yedeğine doğrudan dönmek bu beş haberi kaybettirebilir. Önce güncel veritabanının güvenli bir kopyasını almak, ardından hangi tabloların veya dosyaların gerçekten etkilendiğini belirlemek gerekir. Kurtarma stratejisini iş akışına göre seçin. Ayrıca geri dönüşten sonra görsellerin, yazar hesaplarının ve yazı URL’lerinin aynı kaldığını kontrol edin. Bu örnek, ‘en son çalışan yedeği yükle’ yaklaşımının her zaman yeterli olmadığını gösterir.
Uygulama kayıtlarını tutmak neden önemli?
WordPress yedek alma konusunda işlemleri tek seferde bitmiş kabul etmeyin. Değişiklikten önce hangi ayarın geçerli olduğunu, işlemi hangi tarihte ve hangi kullanıcı hesabıyla yaptığınızı, kullanılan eklenti veya hizmetin sürümünü not edin. Daha sonra beklenmedik sorun ortaya çıktığında bu kayıtlar hangi adımın etkili olabileceğini anlamayı kolaylaştırır. Özellikle birden çok editör veya teknik sorumlu çalışıyorsa herkesin aynı prosedürü izlemesi önemlidir. Ekran görüntüsü alırken parola, erişim anahtarı ve kişisel verilerin görüntüde bulunmadığını kontrol edin.
Yalnızca başarılı sonucu değil, başarısız denemeleri de kayda geçirin. Örneğin Yedek neleri içermeli? bölümünde anlatılan ayarı değiştirdikten sonra önbellek veya tema etkisiyle beklenen sonucu hemen göremeyebilirsiniz. Arka arkaya çok sayıda rastgele müdahale yapmak sorun teşhisini güçleştirir. Kontrollü biçimde tek değişiklik yapın, sonucu doğrulayın ve gerektiğinde eski ayara dönün. Canlı yayında ziyaretçilerin kullandığı önemli özellikleri etkileyecek işlemleri daha sakin zaman dilimlerine planlayın.
Rehber bilgilerini güncel tutma
WordPress çekirdeği, eklentiler ve üçüncü taraf hizmetlerin arayüzleri güncellenebilir. Bu nedenle bugün görülen menü adı veya seçenek konumu ileride değişebilir. Resmî belgelerdeki yeni açıklamaları düzenli izleyin, eskimiş ekran görüntülerini yenileyin ve işlem yollarını test edin. Kurtarma testi neden önemli? konusundaki kontrolleri de güncelleme sonrasında tekrarlamak yararlıdır. Bir özelliğin artık sunulmadığını veya koşullarının değiştiğini fark ederseniz okuyucuyu yanlış yönlendirmemek için metni açıkça düzeltin. Gelişme tarihini kaynakça ve güncelleme notlarında görünür kılın.
Kaynakça
- WordPress Developer Resources, Backups (erişim: 9 Kasım 2026).
- WordPress Developer Resources, Backing Up Your Files (erişim: 9 Kasım 2026).
- WordPress Developer Resources, Backing Up Your Database (erişim: 9 Kasım 2026).
