WordPress Yedekleme ve Geri Yükleme: Dosyalar, Veritabanı ve Test

Neyi yedeklemelisiniz: dosyalar ve veritabanı

WordPress belgelerine göre bir siteyi tam geri getirmek için iki parça gerekir: dosyalar ve veritabanı. Dosyaları yedeklemek veritabanını yedeklemek anlamına gelmez; veritabanı MySQL veya MariaDB içinde, WordPress klasörünün dışında durur.

Belgelerin önerdiği sıra: Yedeklerken önce veritabanını, sonra dosyaları alın ve ikisini aynı klasörde ya da aynı arşivde "yedek seti" olarak tutun. Geri yüklerken önce dosyaları, sonra veritabanını geri getirin. Veritabanı bilgileri değiştiyse wp-config.php dosyasını yeni bilgilere göre güncelleyin.

Üç yol: barındırma yedeği, eklenti, elle yedek

WordPress belgeleri otomatik yedeklere güvenseniz bile arada bir elle yedek alarak sürecin çalıştığını doğrulamanızı önerir. En sağlam düzen, barındırma yedeğini temel alıp bunu düzenli bir eklenti yedeği ya da elle yedekle tamamlamaktır.

cPanel ile elle yedek

cPanel'de yedekler Backup Wizard ya da Backup ekranından alınır (Files bölümü). cPanel belgelerine göre sağlayıcınız bu ekranları kapatmış olabilir.

• Kısmi yedek (önerilen): Backup Wizard'da Back Up, ardından yedeklemek istediğiniz bölümü seçin. Home Directory yedeği .tar.gz, MySQL Databases yedeği .sql uzantılı iner.
• Tam yedek: Full Backup seçeneği hesabın tamamını backup-AA-GG-YYYY adlı bir .tar.gz dosyasına koyar. Dosyayı ana dizine kaydedebilir veya FTP ya da SCP ile uzak bir sunucuya gönderebilirsiniz.
• Geri yükleme: Backup Wizard'da Restore ile kısmi yedeği (ör. veritabanı) yükleyebilirsiniz.

phpMyAdmin ile veritabanı yedeği

WordPress belgelerindeki basit yol: phpMyAdmin'i açın, soldan WordPress veritabanınızı seçin, Export sekmesine geçin, Quick seçiliyken Go düğmesine basın ve dosyayı kaydedin. Custom seçeneğinde SQL biçimini koruyup "Add DROP TABLE" seçeneğini işaretlerseniz geri yüklemede var olan tabloların üzerine yazılır. Hangi veritabanının sitenize ait olduğunu wp-config.php içindeki DB_NAME değerinden görebilirsiniz.

WP-CLI ile yedek

Sunucunuzda WP-CLI ve terminal erişimi varsa (paylaşımlı barındırmada her zaman olmaz, sağlayıcınıza sorun) veritabanını tek komutla dışa aktarabilirsiniz. Belgelere göre büyük veritabanlarında phpMyAdmin yetersiz kalabilir, komut satırı araçları bu durumda işe yarar.

# Tum veritabanini disa aktar
wp db export yedek-2026-11-01.sql

# Yalnizca belirli tablolari disa aktar
wp db export ayarlar.sql --tables=wp_options,wp_users

# Geri yukle (mevcut tablolarin uzerine yazar)
wp db import yedek-2026-11-01.sql

Yedekleme eklentileri

WordPress belgeleri otomatik yedek için eklenti dizinini işaret eder. Aşağıdakiler wordpress.org'da yayımlanan, 1 Kasım 2026 itibarıyla son birkaç hafta içinde güncellenmiş eklentilerdir. Kurmadan önce eklenti sayfasında "Last updated" ve WordPress sürüm uyumluluğunu kendiniz kontrol edin.

Site dışı kopya ve saklama süresi

WordPress belgeleri en az 3 ile 5 güncel yedek tutmanızı ve bunları farklı yerlerde saklamanızı önerir: biri barındırma sunucusunda, biri bulut depolamada (Google Drive, Dropbox vb.), biri de kendi bilgisayarınızda. Yedek sıklığı için belgelerin önerisi: az yazı yayımlanan küçük sitelerde haftada bir, yoğun sitelerde her gün. Ayrıca her güncellemeden ve taşımadan önce mutlaka yedek alın.

• Günlük yedekler: son birkaç gün, gündelik hatalar için.
• Haftalık ve aylık yedekler: daha eski bir noktaya dönmeniz gerekirse. Hacklenen sitelerde zararlı kod haftalar önce yerleşmiş olabilir; temiz bir noktaya dönmek için eski yedeklere ihtiyaç duyarsınız (bkz. hacklenen WordPress temizleme rehberi).
• Gizlilik: Yedekler kullanıcı ve sipariş verisi içerir; şifrelenmiş ve erişimi sınırlı bir yerde saklayın, gereğinden uzun tutmayın.

3-2-1 kuralı ve saklama politikaları hakkında daha geniş bir çerçeve için sunucularda yedeklemenin önemi ve veritabanı yedekleme stratejileri yazılarımıza bakabilirsiniz.

Geri yükleme testi

Hiç geri yüklenmemiş bir yedeğin çalışıp çalışmadığını bilemezsiniz. WordPress'in güncelleme belgeleri de alınan yedeklerin yerinde ve kullanılabilir olduğunu doğrulamayı "essential" yani olmazsa olmaz diye niteler. Birkaç ayda bir şu testi yapın:

• cPanel'de boş bir veritabanı ve kullanıcı oluşturun, test için bir alt alan adı açın.
• Yedekteki dosyaları alt alan adının klasörüne, veritabanı yedeğini yeni veritabanına yükleyin.
• wp-config.php dosyasındaki veritabanı bilgilerini yeni veritabanına göre düzenleyin.
• Alan adı farklı olduğu için adresleri güvenli biçimde değiştirmeniz gerekir; bu adımı WordPress site taşıma rehberimizde anlattık.
• Siteyi açın, birkaç sayfa ve görsel kontrol edin, test bitince alt alan adını ve veritabanını silin.

Tek bir dosyayı veya tabloyu geri getirmek

Her sorun için bütün siteyi geri yüklemeniz gerekmez. Yanlış düzenlenen bir tema dosyası ya da silinen bir görsel için yalnızca o dosyayı geri getirmek, son yedekten bu yana eklenen yazıları ve siparişleri kaybetmenizi önler.

Tek dosya

cPanel belgelerine göre tam yedekten public_html dosyalarını elle geri yüklemek için .tar.gz arşivini açıp ilgili dosyayı alır ve Dosya Yöneticisi (File Manager) ile yerine yüklersiniz. Aynı yöntem tek bir dosya için de geçerlidir. Bazı barındırma panellerinde dosya ve klasör geri yükleme aracı da bulunur; panelinizde varsa onu kullanabilirsiniz.

Tek tablo

• Önceden wp db export --tables=... ile tablo bazlı yedek aldıysanız o dosyayı phpMyAdmin'in Import sekmesinden içe aktarın. Dosyada DROP TABLE varsa tablo yedekteki hâliyle değiştirilir.
• Elinizde yalnızca tam veritabanı yedeği varsa canlı veritabanına doğrudan yüklemeyin. Önce cPanel'de geçici, boş bir veritabanı oluşturun ve yedeği oraya içe aktarın.
• Geçici veritabanında phpMyAdmin ile yalnızca gereken tabloyu (ör. wp_options) Custom seçeneğiyle dışa aktarın ve bu dosyayı canlı veritabanına içe aktarın.
• İşlemden önce canlı veritabanının da güncel bir yedeğini alın; iş bitince geçici veritabanını silin.

Sık yapılan hatalar

• Yalnızca dosyaları yedekleyip veritabanını unutmak (veya tersi).
• Yedeği aynı sunucuda, aynı hesapta tek kopya olarak tutmak.
• cPanel tam yedeğine güvenip kendi başına geri yükleyemeyeceğini sonradan öğrenmek.
• Yedeği hiç denememek; bozuk arşivi kriz anında fark etmek.
• Güncelleme veya taşıma öncesinde yedek almamak.
• Yedek dosyasını web kökünde, herkesin erişebileceği bir yerde bırakmak.

Sık Sorulan Sorular

Barındırma firmam yedek alıyor, yine de yedek almalı mıyım?

Evet. WordPress belgeleri barındırma yedeklerinden kopya istemenin zaman alabileceğini, kendi dosyalarınızı yedeklemeyi ve geri yüklemeyi bilmeniz gerektiğini vurgular. Sağlayıcının yedeği temel güvenceniz olsun, kendi site dışı kopyanız da ikinci güvence.

Ne sıklıkla yedek almalıyım?

Belgelere göre az içerik eklenen küçük sitelerde haftada bir, yoğun sitelerde günlük. Mağaza gibi sürekli sipariş alan sitelerde veritabanını daha sık yedeklemek mantıklıdır. Her güncellemeden ve taşımadan önce ek yedek alın.

Yedeği geri yükledim ama site açılmıyor, ne yapmalıyım?

Önce wp-config.php içindeki veritabanı bilgilerinin doğru olduğunu kontrol edin. "Error establishing a database connection" görüyorsanız veritabanı bağlantı hatası rehberimize, kritik hata ekranı görüyorsanız kritik hata çözümü rehberimize bakın.

Yedekleme eklentisi taşıma için de kullanılabilir mi?

Listedeki eklentilerin çoğu taşıma özelliği de sunar. Taşımada adres değiştirme ve DNS adımları da önemlidir; bunları WordPress site taşıma rehberimizde ve hosting taşıma rehberimizde anlattık.

Yazılım, eklenti ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: WordPress site taşıma · WordPress otomatik güncelleme ayarları · WP-Cron ve gerçek cron ayarı · Hacklenen WordPress temizleme · Sunucularda yedeklemenin önemi · Veritabanı yedekleme stratejileri