WordPress Yedekleme Nasıl Yapılır? Dosyalar, Veritabanı, Saklama ve Geri Yükleme Testi

Onur Ertem
1 Ekim 2026
Güncellendi: 30 Ekim 2026

WordPress yedekleme, sitenin iki parçasının, yani sunucudaki dosyaların ve ayrı bir sistemde duran veritabanının aynı anda kopyalanıp siteden ayrı bir yerde saklanmasıyla yapılır. WordPress yedekleme nasıl yapılır sorusunun eksiksiz cevabı bir adım daha içerir: alınan kopyanın gerçekten geri yüklenebildiğinin denenmesi. Açılamayan bir yedek dosyası, yedek hiç alınmamış olmasından farksızdır.

Bu rehberde yedeğin neleri kapsaması gerektiği, ne sıklıkla alınacağı, hosting paneli, eklenti ve elle yedekleme yöntemleri, phpMyAdmin ile veritabanı dışa aktarma adımları, saklama düzeni ve geri yükleme testi ele alınır. Her adım WordPress.org’un yedekleme ve veritabanı belgeleriyle desteklenmiştir.

WordPress Sitesinin Yedeği Neden Alınır?

Yedek, site kaybolduğunda ya da bozulduğunda onu belirli bir tarihteki hâline döndürmenin tek güvenilir yoludur. WordPress’in yedekleme belgesi, veritabanının her yazıyı, her yorumu ve her bağlantıyı içerdiğini, silinmesi ya da bozulması hâlinde yazılan her şeyin kaybedilebileceğini ve bunun nedenlerinin her zaman kontrol edilebilir olmadığını belirtir.

Kayıp çoğu zaman beklenmedik bir yerden gelir: bir eklenti güncellemesinin veritabanını yarıda bırakması, yanlışlıkla silinen bir sayfa, ele geçirilen bir yönetici hesabı, sunucu arızası ya da ödemesi aksayan bir hosting hesabının askıya alınması. Bu durumların her birinde düzgün bir yedek, günler sürebilecek yeniden kurulum işini saatlere indirir.

Yedek, güvenlik önlemlerinin yerine geçmez; saldırıyı ya da hatayı önlemez, yalnızca sonrasında geri dönmeyi mümkün kılar. Güncelleme, güçlü giriş koruması ve yetki yönetimi riski azaltır, yedek ise bu önlemlerin yetmediği gün devreye giren son güvencedir.

Yedek Neleri Kapsamalı: Dosyalar ve Veritabanı

Eksiksiz bir WordPress yedeği hem dosyaları hem veritabanını içerir; biri olmadan diğeriyle site tam olarak geri kurulamaz. Resmi belge, sık düşülen bir yanılgıyı açıkça düzeltir: WordPress klasörünü indirmek veritabanını yedeklemez, çünkü veritabanı genellikle MySQL ya da MariaDB üzerinde, bu klasörün dışında durur. Yedekte bulunması gereken parçalar şunlardır:

Veritabanı: yazılar, sayfalar, yorumlar, kullanıcılar, ayarlar, sipariş ve form kayıtları
wp-content klasörü: yüklenen görseller ve dosyalar, temalar, eklentiler
wp-config.php: veritabanı bağlantı bilgileri ve güvenlik anahtarları
.htaccess ve kök dizindeki ek dosyalar: yönlendirme kuralları, doğrulama dosyaları, statik sayfalar

WordPress çekirdek dosyaları, resmi sitesinden temiz olarak yeniden indirilebildiği için belgeye göre kritik parça değildir. Öncelik wp-content, wp-config.php ve veritabanıdır; yine de tam site yedeği almak geri dönüşte zaman kazandırır.

WordPress Yedeği Ne Sıklıkla Alınmalı?

Yedek sıklığı, sitenin ne kadar sık değiştiğine göre belirlenir ve her güncellemeden önce ayrıca bir yedek alınır. Resmi belge, az içerikli küçük siteler için haftalık, sık güncellenen yoğun siteler için günlük yedeği genel bir öneri olarak verir. Aşağıdaki tablo bu öneriyi site türlerine göre somutlaştırır:

Site türü	Genel sıklık	Ek yedek anı
Nadiren değişen kurumsal tanıtım sitesi	Haftalık	Her güncellemeden ve tasarım değişikliğinden önce
Düzenli yazı yayımlanan blog ya da haber sitesi	Günlük	Toplu içerik aktarımlarından önce
Sipariş, üyelik ya da randevu alan site	En az günlük, veritabanı için daha sık düşünülebilir	Kampanya dönemleri ve eklenti güncellemeleri öncesi

Sıklığı belirlerken sorulacak soru şudur: son yedekten bu yana eklenen her şey kaybolsa bu kaybın telafisi ne kadar zor olur? Siparişlerin ve form başvurularının kaybolması, bir blog yazısının yeniden yazılmasından çok daha pahalıya mal olur.

WordPress Yedekleme Yöntemleri

WordPress yedeği üç yolla alınabilir: hosting firmasının yedekleme aracıyla, zamanlanmış çalışan bir yedekleme eklentisiyle ya da dosyaların SFTP ile indirilip veritabanının elle dışa aktarılmasıyla. Resmi belge, hosting firmalarının çoğunun bir yedekleme aracı sunduğunu, WordPress yönetim ekranlarındaki eklenti arama bölümünde otomatik yedekleme eklentileri bulunduğunu ve SFTP istemcileriyle dosyaların bilgisayara kopyalanabileceğini belirtir.

Hosting aracı kolaydır ama yedek çoğunlukla aynı hesapta kalır; hesaba erişim kaybolursa yedeğe de ulaşılamayabilir. Eklentiler zamanlamayı otomatikleştirir ve yedeği bulut depolamaya gönderebilir, ancak büyük sitelerde sunucu kaynaklarını zorlayabilir ve kendileri de güncel tutulması gereken bir yazılımdır.

Elle yedek ise zahmetlidir ama sürecin nasıl işlediğini gösterir. Resmi belge, SFTP istemcilerinin eşitleme özelliğiyle sunucudaki dosyaların bilgisayarda güncel bir ayna kopyasının tutulabileceğini de anlatır. Belge, otomatik yedeklerin arada bir elle alınan bir yedekle desteklenmesini, sürecin çalıştığından emin olmanın yolu olarak önerir.

phpMyAdmin ile Veritabanı Yedeği Adım Adım

Veritabanının elle yedeği, hosting panelindeki phpMyAdmin üzerinden SQL dosyası olarak dışa aktarılarak alınır. WordPress’in veritabanı yedekleme belgesindeki adımların sade hâli şöyledir:

Hosting panelinden phpMyAdmin açılır ve sol taraftan WordPress’in kullandığı veritabanı seçilir.
Üst menüden Dışa Aktar (Export) sekmesine geçilir.
Özel (Custom) yöntem seçilirse tüm tabloların işaretli olduğu kontrol edilir.
Biçim olarak SQL seçilir; büyük veritabanlarında sıkıştırma açılabilir.
Geri yüklemede mevcut tabloların üzerine yazılabilmesi için “DROP TABLE ekle” ve hata çıkmaması için “IF NOT EXISTS” seçenekleri işaretlenir.
Git (Go) düğmesiyle dosya bilgisayara indirilir ve dosya adına tarih eklenerek saklanır.

Hangi veritabanının siteye ait olduğu, wp-config.php dosyasındaki veritabanı adı satırından doğrulanır. Aynı hosting hesabında birden fazla site varsa yanlış veritabanını yedeklemek sık yapılan bir hatadır.

Mevcut Yedek Düzenine Birlikte Bakalım

Yedeklerin nerede durduğu, ne sıklıkla alındığı, dosya ve veritabanını birlikte kapsayıp kapsamadığı ve en son ne zaman geri yüklenip denendiği ücretsiz ön değerlendirmede netleşir. Eksik halkalar ve düzeltme sırası açıkça not edilir.

WhatsApp 0532 690 9924

Yedekler Nerede Saklanmalı? 3-2-1 İlkesi

Yedekler, sitenin çalıştığı sunucudan bağımsız en az bir konumda saklanmalıdır. WordPress’in yedekleme belgesi en az 3 ila 5 güncel yedeğin farklı yerlerde, örneğin biri hosting sunucusunda, biri bulut depolamada, biri de bilgisayarda tutulmasını önerir; böylece kopyalardan biri bozulsa ya da kaybolsa bile geri dönülecek bir sürüm kalır.

Veri korumada sık anılan 3-2-1 ilkesi aynı fikri kolay hatırlanır bir kurala dönüştürür. Verinin toplamda üç kopyası olur ve canlı site bunlardan biri sayılır; kopyalar iki farklı saklama ortamına dağıtılır; kopyalardan biri mutlaka hosting hesabının ve sunucunun dışında durur. Bu ilke bir standart ya da yasal zorunluluk değil, pratikte işe yarayan genel bir yaklaşımdır.

Belge, hosting firmalarının çoğunun sunucunun tamamını yedeklediğini ama bu yedekten kopya talep etmenin zaman alabildiğini de hatırlatır. Hızlı geri dönüş gerektiğinde site sahibinin kendi erişebildiği bir yedeğe sahip olması bu yüzden önemlidir. Hosting seçimi yapılırken yedeklerin kaç gün geriye gittiği ve site sahibinin bu yedeklere panelden doğrudan ulaşıp ulaşamadığı sorulmalıdır.

Yedek Alma ve Geri Yükleme Sırası

Tutarlı bir yedek için önce veritabanı, ardından dosyalar yedeklenir; geri yüklemede ise sıra tersine döner. Resmi belge, dosya ve veritabanı yedeğinin aynı zamana yakın alınarak tek bir “yedek seti” gibi ele alınmasını, veritabanı dökümünün aynı klasöre ya da aynı sıkıştırılmış arşive konmasını önerir. Böylece yıllar sonra bile hangi dosya yedeğinin hangi veritabanıyla eşleştiği karışmaz.

Dosya adlarında site adı, tarih ve içerik türünün yer alması (ör. firma_2026-10-01_veritabani.sql) ve kısa bir yedek günlüğü tutulması işi kolaylaştırır. Günlükte her yedeğin tarihi, kapsamı, saklandığı yer ve en son hangi tarihte geri yüklenip denendiği yazar; kriz anında hangi kopyaya dönüleceği bu kayıttan saniyeler içinde bulunur.

Geri yüklemede önce dosyalar yerine konur, sonra veritabanı içe aktarılır. phpMyAdmin’de bu iş İçe Aktar (Import) sekmesinden, SQL biçimi seçilerek yapılır ve mevcut veritabanı yedeğin alındığı andaki hâline döner. Site başka bir sunucuya ya da farklı bir veritabanı kullanıcısına taşınıyorsa wp-config.php dosyasındaki bağlantı bilgileri de yeni değerlerle güncellenir; bu adımlar WordPress site taşıma sürecinin de temelidir.

Geri Yükleme Testi Nasıl Yapılır?

Geri yükleme testi, yedeğin canlı siteye dokunmadan ayrı bir kopyaya açılıp sitenin bu kopyadan eksiksiz ayağa kalktığının doğrulanmasıdır. WordPress’in geliştirme kopyası belgesi, canlı sürümü kesintiye uğratmadan güncelleme ve değişiklik denemek için ayrı bir kurulum kullanılmasını önerir; aynı ortam yedek testi için de uygundur. Testte şu noktalar kontrol edilir:

Ana sayfa, iç sayfalar ve blog yazıları eksiksiz açılıyor mu?
Görseller ve indirilebilir dosyalar yerinde mi?
Yönetim paneline giriş yapılabiliyor, kullanıcılar ve roller doğru mu?
İletişim formu, sepet ya da üyelik gibi işlevler çalışıyor mu?
Son siparişler veya form kayıtları yedeğin tarihine uygun biçimde görünüyor mu?

Testin ne kadar sürdüğü de not edilmelidir. Gerçek bir kriz anında sitenin kaç saatte geri geleceğini bilmek, hem işletme içindeki beklentiyi hem de müşterilere verilecek bilgiyi netleştirir. Test yılda birkaç kez ve özellikle yedekleme yöntemi değiştiğinde tekrarlanır.

Yedekleme Eklentisi Seçerken Nelere Bakılır?

Yedekleme eklentisi, yedeğin nereye gönderildiğine, geri yüklemenin nasıl yapıldığına ve bir hata olduğunda haber verip vermediğine göre seçilir; arayüzün kolaylığı ikinci plandadır. Değerlendirmede şu ölçütler yol gösterir:

Yedek, sunucu dışındaki bir hedefe (bulut depolama ya da uzak bir sunucu) gönderilebiliyor mu?
Zamanlama, site trafiğinin düşük olduğu saatlere ayarlanabiliyor mu?
Önbellek klasörleri gibi gereksiz dosyalar yedeğin dışında bırakılabiliyor mu?
Yedek başarısız olduğunda e-posta ya da başka bir kanalla uyarı geliyor mu?
Arşiv şifrelenebiliyor ve eski yedekler belirlenen sayıdan sonra kendiliğinden siliniyor mu?
Yedek, eklenti bozulsa bile elle açılabilecek standart bir biçimde (SQL dökümü ve sıkıştırılmış dosya arşivi) saklanıyor mu?

Büyük sitelerde her seferinde tüm dosyaları kopyalamak yerine yalnızca değişen dosyaları ekleyen artımlı yedek, hem süreyi hem depolama alanını azaltır; WordPress’in yedek kaynakları arasında şifreli artımlı yedeklere ayrılmış bir başlık da bulunur. Eklentinin kendisi de düzenli güncellenmeli ve güvenilir bir kaynaktan kurulmalıdır; bakımı bırakılmış bir yedekleme eklentisi, tam ihtiyaç duyulduğu gün çalışmayan bir araca dönüşebilir. Kurulumdan sonra ilk yedeğin gerçekten hedefe ulaştığı ve arşivin açılabildiği mutlaka kontrol edilir.

Yedeklerin Güvenliği ve Kişisel Veriler

Yedek dosyası, sitenin kendisi kadar hassastır; kullanıcı hesapları, müşteri bilgileri, form başvuruları ve wp-config.php içindeki bağlantı bilgileri bu dosyanın içindedir. Bu yüzden yedekler herkesin erişebileceği bir web klasöründe bırakılmaz, paylaşım bağlantıları herkese açık tutulmaz ve saklandığı hesaplar iki adımlı doğrulamayla korunur.

WordPress’in sıkılaştırma belgesi, yedeğin sonradan değiştirilmediğinden emin olmak için üç yol gösterir: arşivi şifrelemek, her yedek dosyasının özet (hash) değerini ayrı bir yerde not etmek ve kopyaları üzerine yazılamayan ortamlarda tutmak. Kişisel veri içeren eski yedeklerin belirli bir süreden sonra silinmesi de veri güvenliği açısından saklamak kadar önemlidir.

KVKK açısından da durum aynıdır: Kanun, kişisel verilerin muhafazasının sağlanmasını ve bu verilere hukuka aykırı erişimin önlenmesini veri sorumlusunun yükümlülükleri arasında sayar (6698 sayılı Kanun, madde 12). Yedek bu açıdan iki yönlüdür: hem verinin korunmasının aracıdır hem de ayrıca korunması gereken bir veri kopyasıdır.

WordPress Yedeklemede Sık Yapılan Hatalar

Yedekleme sorunlarının çoğu yedeğe ihtiyaç duyulduğu gün ortaya çıkar. Sahada en sık görülen hatalar ve doğru yaklaşımlar şöyledir.

Yalnızca veritabanını ya da yalnızca dosyaları yedeklemek: içerik geri gelir ama görseller kaybolur ya da tam tersi olur. Yedek setinin iki parçası da her seferinde birlikte alınır.

Tüm kopyaları aynı sunucuda tutmak: sunucu arızası ya da hesap askıya alınması, siteyle birlikte yedekleri de erişilemez hâle getirir.

Güncellemeden önce yedek almamak: resmi belge veritabanının düzenli olarak ve her yükseltmeden önce yedeklenmesini ister; eklenti belgesi de güncelleme öncesinde güncel bir yedek bulunmasını not olarak düşer. Güncelleme sonrası hata çıkarsa sorunun kaynağı WordPress problem çözme adımlarıyla aranır, yedek ise son çaredir.

Yedeği hiç denememek: yarım kalmış bir arşiv ya da bozuk bir SQL dosyası ancak açılmaya çalışıldığında fark edilir. Düzenli geri yükleme testi ve yedek takibi, WordPress bakım ve güncelleme düzeninin kalıcı işlerinden biri olarak planlanabilir.

Yedekleme Planını Siteye Göre Kuralım

WordPress yedekleme düzeni sitenin değişme hızına, sipariş ya da form trafiğine ve hosting imkânlarına göre kurulur. Sıklık, saklama yerleri ve test takvimi birlikte belirlenebilir; ücretsiz ön değerlendirme için bir WhatsApp mesajı ya da kısa bir telefon görüşmesi yeterlidir.

WhatsApp 0532 690 9924

İlgili rehberler

Sıkça Sorulan Sorular