WordPress Yedek Geri Yükleme: Adım Adım Rehber

Yedeğiniz var ama site bozuldu ya da hacklendi. Şimdi asıl iş başlıyor: wordpress yedek geri yükleme sırasında yanlış bir adım, mevcut siteyi tamamen silebilir ya da yarım çalışan bir kopya bırakabilir. Bu rehber, hangi yöntemi ne zaman seçeceğinizi, manuel geri yüklemeyi komut komut ve geri yüklemeden sonra neleri kontrol etmeniz gerektiğini anlatıyor. Yedek almanın kendisi için WordPress yedekleme rehberine bakabilirsiniz.

Hangi geri yükleme yöntemini seçmeliyim?

Siteniz yönetici paneline hâlâ girilebiliyorsa en hızlısı yedeği aldığınız aracın kendi geri yüklemesidir. Panel açılmıyorsa hosting panelindeki yedek ya da manuel yöntem kalır. Seçim, yedeğin nerede durduğuna ve siteye ne kadar erişebildiğinize bağlıdır.

Hangi yolu seçerseniz seçin, geri yüklemeden önce mevcut durumun da bir kopyasını alın. Bozuk bir site bile, geri yükleme yanlış giderse sizi o ana döndürür ve içinde yedekte olmayan son içerikler olabilir.

Yedekleme eklentisiyle geri yükleme nasıl yapılır?

Eklenti tabanlı araçlarda süreç benzerdir: yedek listesinden bir kayıt seçersiniz, neyin geri yükleneceğini (dosyalar, veritabanı ya da ikisi) işaretlersiniz ve onaylarsınız. Ayrıntılar eklentiye göre değişir, bu yüzden kendi aracınızın belgesine bakın.

1. 1Geri yüklemeden önce sunucudaki mevcut hâlin bir yedeğini alın.
2. 2Geri yüklenecek yedeğin tarihini ve içeriğini (veritabanı, eklentiler, temalar, yüklemeler) kontrol edin.
3. 3Yalnızca gereken parçayı seçin. Sorun sadece veritabanındaysa dosyaları da geri yüklemeniz gerekmez.
4. 4İşlem sürerken sayfayı kapatmayın, PHP zaman aşımı yaşanırsa işlemi baştan değil, aracın belgesindeki yönteme göre sürdürün.
5. 5İşlem bitince oturum açın, kalıcı bağlantıları yeniden kaydedin ve kontrol listesini uygulayın (aşağıda).

Yedek dosyası çok büyükse (özellikle yükleme klasörü) eklentiler çoğu zaman PHP bellek ve süre sınırına takılır. Bu durumda manuel yönteme geçmek daha güvenilirdir.

Hosting panelinden yedek nasıl geri yüklenir?

cPanel, Plesk ve benzeri panellerde yedekler hosting firmasının politikasına göre günlük ya da haftalık tutulur. Geri yüklerken panelin size seçenek sunup sunmadığına dikkat edin: bazı paneller yalnızca ana dizini, bazıları yalnızca veritabanını, bazıları da tüm hesabı geri yükleyebilir.

• Tüm hesabı geri yüklemek, aynı hesaptaki diğer sitelerinizi de eski hâline döndürebilir. Mümkünse yalnızca ilgili klasörü ve veritabanını seçin.
• Hosting yedekleri çoğu zaman sınırlı süre saklanır ve hesap kapanırsa ya da sunucu kaybolursa onlar da gider. Sunucu dışında bir kopyanız olmalı.
• Panelin sağladığı yedeğin içinde veritabanı olduğundan emin olun. Yalnızca dosya içeren bir yedek siteyi geri getirmez.

Yedeği manuel olarak (FTP ve veritabanı) nasıl geri yüklerim?

Manuel geri yükleme iki parçadır: dosyalar sunucuya kopyalanır, veritabanı da bir .sql dosyasından içe aktarılır. SSH erişiminiz varsa WP-CLI hem hızlı hem de büyük dosyalarda en az sorun çıkaran yoldur.

1. Dosyaları geri yükleyin

FTP/SFTP ile yedekteki WordPress dosyalarını sunucuya yükleyin. Mevcut klasörün üzerine yazmadan önce wp-config.php dosyasını kenara alın, çünkü içindeki veritabanı bilgileri bu sunucuya özgüdür. Yedekteki wp-config.php farklı bir veritabanı adı ya da kullanıcı içeriyorsa bağlantı hatası alırsınız.

2. Veritabanını içe aktarın

phpMyAdmin'de önce veritabanını seçin, sonra İçe Aktar sekmesinden .sql dosyasını yükleyin. phpMyAdmin dosya boyutu ve süre sınırına takılırsa dosyayı sıkıştırarak (.sql.gz) deneyin ya da SSH ile WP-CLI kullanın:

# Önce mevcut veritabanının güvenlik kopyasını alın
wp db export onceki-durum.sql

# Yedeği içe aktarın
wp db import yedek.sql

WP-CLI belgesine göre wp db import yeni bir veritabanı oluşturmaz, yalnızca SQL dosyasındaki işlemleri çalıştırır ve bağlantı bilgilerini wp-config.php dosyasından alır. Yani veritabanının ve kullanıcısının hosting panelinden önceden oluşturulmuş olması gerekir.

3. Tablo önekini ve karakter kümesini kontrol edin

Yedekteki tabloların öneki (örneğin wp_) ile wp-config.php içindeki $table_prefix değeri aynı olmalı. Farklıysa WordPress kurulum ekranını gösterir ya da boş bir site açar. Ayrıca MySQL 8 sunucudan alınan bir dökümü eski MySQL ya da MariaDB sürümüne aktarırken collation hatası (ör. bilinmeyen collation) görebilirsiniz. Bu durumda SQL dosyasındaki collation adlarını hedef sunucunun desteklediği değere çevirmek ya da hedefi güncellemek gerekir.

Geri yükledikten sonra adresler ve serileştirilmiş veri neden bozulur?

Yedeği farklı bir alan adına, farklı bir klasöre ya da HTTP'den HTTPS'e taşıyorsanız veritabanındaki eski adresler kalır ve site eski adrese yönlenir, görseller kırılır. Bunu SQL dosyasında bul-değiştir ile yapmak tehlikelidir, çünkü WordPress'in tema ve widget ayarları PHP serileştirilmiş biçimde saklanır ve içinde metin uzunluğu yazar. Uzunluk değişirse veri okunamaz hâle gelir.

WordPress belgeleri de bu yüzden serileştirmeyi doğru işleyen araçları (WP-CLI'nin search-replace komutu ya da Better Search Replace gibi eklentiler) öneriyor. Önce deneme çalıştırması yapın:

wp search-replace 'https://eski-alan-adi.com' 'https://yeni-alan-adi.com' --all-tables --dry-run --report-changed-only

# Sonuç mantıklıysa --dry-run olmadan tekrar çalıştırın
wp search-replace 'https://eski-alan-adi.com' 'https://yeni-alan-adi.com' --all-tables --skip-columns=guid

--skip-columns=guid yazı kimliklerinin (GUID) değişmemesini sağlar, çünkü GUID bir adres olmaktan çok kalıcı bir tanımlayıcıdır. Site adresini doğrudan wp-config.php içinde sabitlemek isterseniz WP_HOME ve WP_SITEURL sabitlerini kullanabilirsiniz, ancak bu durumda ayarlar ekranından düzenlenemezler.

Geri yüklemeden sonra neleri kontrol etmeliyim?

Site açıldı diye iş bitmez. Geri yükleme ile en sık yaşanan sorunlar sessizdir: formlar çalışmaz, ödeme sayfası eskiyi gösterir, e-postalar gitmez.

• Ayarlar, Kalıcı bağlantılar ekranında Değişiklikleri Kaydet düğmesine basın ya da WP-CLI ile yönlendirme kurallarını yenileyin (yazı sayfaları 404 veriyorsa genellikle budur).
• Önbellek eklentisini ve varsa sunucu/CDN önbelleğini temizleyin. WP-CLI ile nesne önbelleği için wp cache flush komutu kullanılabilir.
• Ana sayfa, bir yazı, bir sayfa, giriş ve (varsa) ödeme akışını elle deneyin.
• İletişim formu ve sipariş e-postalarını test edin.
• Medya kütüphanesinde görseller açılıyor mu, yükleme klasörünün izinleri doğru mu bakın.
• Yedek eski bir tarihe aitse, o tarihten sonra gelen siparişleri, yorumları ve yazıları ayrıca kurtarmanız gerekebilir.
• Sitede bilinmeyen bir yönetici hesabı ya da şüpheli dosya kalmadığından emin olun. Geri yükleme nedeniniz saldırıysa temiz bir yedeğe dönün, sonra şifreleri ve güvenlik anahtarlarını değiştirin.

Bir saldırı sonrası geri yüklüyorsanız sitem hacklendi, ne yapmalıyım yazısındaki adımları da izleyin. Güncelleme kaynaklı bir bozulmadan dönüyorsanız yedeğin tamamı yerine güncelleme sonrası site bozuldu rehberindeki daha küçük geri alma adımları yeterli olabilir.

Yedeğin çalıştığını önceden nasıl anlarım?

Prova için üretim sitesine dokunmanız gerekmez. Yedeği bir alt alan adına ya da yerel bir WordPress ortamına yükleyin.

Test edilmemiş yedek, çalışıp çalışmadığı bilinmeyen yedektir. Geri yükleme provasını kriz anında değil, sakin bir günde yapın. Bir test alt alan adına ya da yerel ortama yedeği geri yükleyip siteyi açmak, yedeğin bozuk olup olmadığını size önceden söyler. Aylık bir prova çoğu site için yeterlidir. Prova sırasında kaç dakika sürdüğünü de not edin, böylece gerçek bir kesintide ne kadar beklemeniz gerektiğini bilirsiniz.

Yalnızca bir eklenti, tema ya da tablo nasıl geri yüklenir?

Her sorun için tüm siteyi eski haline döndürmek gerekmez. Bozulan şey bir eklenti ya da temaysa, yedekteki o klasörü FTP ile yalnızca wp-content/plugins ya da wp-content/themes altına kopyalamak çoğu zaman yeter. Veritabanındaki tek bir tabloyu geri almak için yedek SQL dosyasından yalnızca o tablonun bölümünü çıkarıp içe aktarmanız gerekir, ancak WordPress tabloları birbirine bağlıdır (yazılar ve yazı meta verisi gibi), bu yüzden seçili tablo geri yüklemesini yalnızca ne yaptığınızı biliyorsanız yapın.

Dosya ve veritabanı sürümlerinin uyumsuz olması klasik bir tuzaktır. Örneğin eklentiyi eski sürüme döndürürken veritabanı yeni sürümün şemasıyla kalmış olabilir. Eklentinin sürüm notlarında veritabanı değişikliği var mı bakın.

Dosya izinleri ve sahiplik

Dosyaları FTP ile yeniden yüklediğinizde izinler ve dosya sahibi sunucudaki beklentiyle uyuşmayabilir. Bu durumda görsel yüklenmez, eklenti güncellenemez ya da sayfa 403 verir. WordPress sertleştirme belgelerinin önerdiği genel düzen, klasörler için 755 ve dosyalar için 644 izinleridir. Sunucunuz farklı bir kullanıcıyla çalışıyorsa hosting firmanızın önerdiği değerleri kullanın. wp-config.php için daha kısıtlı bir izin (ör. 600 ya da 640) tercih edilebilir, çünkü içinde veritabanı şifresi vardır.

Yedek aldım ama geri yüklenmiyor, ne yapmalıyım?

Yedek dosyası bozuk, eksik ya da hedef ortamla uyumsuz olabilir. Hata mesajı çoğu zaman nedeni söyler.

• Dosya boyutu sıfıra yakın ya da beklenenden çok küçükse yedek yarım kalmıştır. Başka bir tarihteki yedeği deneyin.
• Arşiv açılmıyorsa dosyayı yeniden indirin. Yarım indirme ve FTP istemcisinin ikili (binary) yerine metin kipinde aktarması arşivi bozabilir.
• İçe aktarma ortasında kesiliyorsa PHP süre ve bellek sınırlarını aşıyorsunuzdur. WP-CLI ya da hosting panelinin komut satırı aracı bu sınırlara takılmaz.
• SQL dosyasında karakter kodlaması hatası varsa dosyayı UTF-8 olarak açıp kaydettiğinizden emin olun.
• Yedek yalnızca dosya ya da yalnızca veritabanı içeriyor olabilir. Yedek içeriğini geri yüklemeden önce açıp bakın.

Hiçbir yedek çalışmıyorsa elinizdeki en eski ama sağlam kopyaya dönüp sonradan eklenen içeriği elle yeniden girmek, yarım bir siteyle uğraşmaktan çoğu zaman daha güvenlidir. Genel hata tablolarında takılırsanız WordPress kritik hata yazısındaki adımlar da işe yarar.

Sık sorulan sorular

Yedeği geri yüklemek mevcut siteyi siler mi?

Evet, çoğu yöntem mevcut dosya ve veritabanı tablolarının üzerine yazar. Bu yüzden geri yüklemeden önce o anki durumun yedeğini alın, sonradan lazım olabilir.

Yalnızca veritabanını geri yüklersem site düzelir mi?

Sorun içerikte, ayarlarda ya da kullanıcılardaysa evet. Sorun dosyalardaysa (bozuk eklenti, değiştirilmiş çekirdek dosya) veritabanı tek başına yetmez, dosyaları da döndürmeniz gerekir.

Geri yükleme ne kadar sürer?

Site boyutuna, sunucu hızına ve yönteme bağlıdır. Küçük bir blog dakikalar içinde, yüklemeleri gigabaytlarca olan bir mağaza belirgin biçimde uzun sürebilir. Süreyi tahmin etmenin en iyi yolu bir prova yapmaktır.

Yedeklerimi sunucuda mı tutmalıyım?

Tek başına sunucuda tutmayın. Sunucu çökerse, hesap askıya alınırsa ya da saldırı olursa yedek de gider. En az bir kopya farklı bir yerde durmalı.

Kaynaklar

• WP-CLI: wp db import
• WP-CLI: wp search-replace
• WordPress: Site taşıma ve adres değiştirme

Erdinç

Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.

LinkedIn