WordPress Yedekleme: Doğru Strateji, Eklentiler ve Geri Yükleme Rehberi

WordPress yedeklemesinde en sık yapılan hata, yedeği almak değil, alınan yedeğe körü körüne güvenmektir.

12 yıldır WordPress siteleri kurtarıyorum. Kaybedilen sitelerin neredeyse tamamında sorun “yedek yoktu” değildi. Sorun şuydu: “yedek vardı ama sunucudaydı ve o da gitti” ya da “yedek vardı ama açılmadı”.

Bu rehberde yedeğin neleri kapsaması gerektiğini, hangi eklentinin hangi senaryoda işe yaradığını, geri yüklemenin hem eklentili hem manuel yolunu ve çoğu rehberin atladığı kısmı, yani yedeğinizi nasıl test edeceğinizi anlatıyorum.

WordPress Yedeği Neleri Kapsamalı?

Bir WordPress kurulumu tek bir dosya yığını değil. Sunucudaki dosya sistemi ile MySQL veritabanı birlikte çalışır. Yedeğinizin tam sayılması için aşağıdaki bileşenlerin hepsinin kopyasına ihtiyacınız var.

Pratikte kritik olan iki şey var: veritabanı ve wp-content klasörünün tamamı. Çekirdek dosyalar her zaman WordPress.org’dan indirilebilir ama sizin 4 yıllık blog arşiviniz ya da özel geliştirilmiş child temanız hiçbir yerden indirilemez.

Bir noktaya özellikle dikkat çekeyim: wp-config.php dosyasını yedeklerken güvenlik anahtarlarını da kopyaladığınızı unutmayın. Bu dosya sızarsa veritabanı erişim bilgileriniz açığa çıkar. Yedeğinizi herkese açık bir klasörde tutmak, kapıyı açık bırakmakla eşdeğerdir.

Yedekleme ile güvenlik iç içe konulardır. Sitenizin hacklenip hacklenmediğini nasıl anlayacağınızı hacklenmiş site tespit rehberinde ele aldım.

3-2-1 Yedekleme Kuralı

3-2-1 kuralı kurumsal veri yönetiminden gelir ve WordPress için birebir uygulanabilir. Kuralı üç parçaya ayıralım.

3 kopya

Canlı sitenizin kendisi bir kopya sayılır. Buna ek olarak iki yedek daha olmalı.

Neden iki? Çünkü tek yedeğe güvenmek, o yedeğin bozuk çıkma ihtimalini görmezden gelmektir. Sıkıştırma hatası, yarım kalmış aktarım, bozuk ZIP arşivi; bunların hepsini gördüm. İki yedek, birinin bozuk çıkması durumunda size ikinci bir şans verir.

Ayrıca iki yedek genellikle farklı zaman noktalarını temsil eder. Siteniz virüs kaptıysa ve siz bunu üç gün sonra fark ettiyseniz, dünkü yedek de zaten enfekte olabilir. Bir hafta öncesine ait ikinci bir kopya bu durumda hayat kurtarır.

2 farklı ortam

Her iki yedek de aynı sunucunun aynı diskinde duruyorsa aslında tek kopyanız var demektir. Disk arızası, sunucu çökmesi ya da hosting hesabının askıya alınması ikisini birden götürür. “Farklı ortam” demek şu anlama gelir:

• Hosting sunucusu + bulut depolama (Google Drive, S3)
• Bulut depolama + kendi bilgisayarınızdaki harici disk
• Yedekleme eklentisinin kendi bulutu + kendi Dropbox hesabınız

1 kopya site dışında

Bu maddenin tek amacı felaket senaryosunu karşılamak. Hosting firması batarsa, hesabınız ödeme sorunundan kapanırsa, sunucunuz fidye yazılımıyla şifrelenirse ya da yanlışlıkla hesabı siz silerseniz, sunucudaki her şey aynı anda kaybolur. Site dışı kopya, sunucuya erişimi tamamen kaybettiğiniz günde sitenizi sıfırdan başka bir hostinge kurmanızı sağlar.

Benim müşterilerime kurduğum tipik yapı şudur: canlı site (1), hosting’in otomatik günlük yedeği (2) ve eklenti üzerinden Google Drive’a giden haftalık tam yedek (3). Bu, 3-2-1’i minimum çabayla karşılar.

Ne Sıklıkta Yedek Almalısınız?

Yedekleme sıklığını belirleyen tek soru şudur: “Kaç saatlik veri kaybını kabul edebilirim?” Buna teknik dilde RPO (Recovery Point Objective) denir.

Günde 40 sipariş alan bir e-ticaret sitesi için 24 saatlik kayıp, 40 siparişin kaybolması demektir. Bu kabul edilemez. Ayda 2 yazı yayınlayan bir blog için ise haftalık yedek fazlasıyla yeterlidir.

Sıklığa ek olarak iki kural daha ekliyorum:

Her büyük değişiklikten önce manuel yedek alın. WordPress sürüm yükseltmesi, PHP sürümü değişikliği, tema değiştirme, çok sayıda eklenti güncellemesi. Bunların öncesinde tek tıkla alınan yedek, geri dönüş sigortasıdır.

Dosya ve veritabanı sıklığı farklı olabilir. E-ticarette veritabanı saatlik değişir ama tema ve eklenti dosyaları haftalarca sabit kalır. Ayrı programlamak hem depolama alanı hem sunucu yükü açısından mantıklıdır.

Yedekleme Eklentileri Karşılaştırması

WordPress ekosisteminde onlarca yedekleme eklentisi var ama gerçekte iş gören ve uzun süredir aktif geliştirilen bir avuç tanesi. Aşağıdaki tabloda beşini karşılaştırıyorum.

Hangisini kime öneriyorum?

UpdraftPlus: çoğu site için doğru başlangıç. Ücretsiz sürümü 3-2-1 kuralını karşılamaya yeter: zamanlanmış yedek alır, Google Drive’a gönderir, panelden geri yükler. Kurduğum sitelerin çoğunda bu var.

Jetpack VaultPress Backup: WooCommerce siteleri için tavsiye ettiğim seçenek. Gerçek zamanlı yedekleme yapar, yani iki yedek arasında alınan siparişler kaybolmaz. Ayrıca yedekler tamamen Jetpack’in sunucularında durduğu için sitenize hiç erişemeseniz bile geri yükleme yapabilirsiniz. Ücretli olması tek dezavantajı ama günde 30 sipariş alan bir mağaza için yıllık maliyeti tek bir kayıp günden düşüktür.

Duplicator: yedeklemeden çok taşıma aracı. Siteyi localhost’tan canlıya ya da bir hostingden diğerine taşırken mükemmel. Rutin yedekleme için ücretsiz sürümü yetersiz.

All-in-One WP Migration: küçük siteler için pratik, tek tıkla dışa aktarır. Ama ücretsiz sürümdeki içe aktarma boyut sınırı, sitesi büyüdükçe kullanıcıyı duvara toslatır. Yedeği alabilirsiniz ama geri yükleyemezsiniz, ki bu yedeği anlamsız kılar.

BackWPup: ücretsiz sürümü çok cömert, S3 dahil birçok hedefe yedek atar. Ancak geri yükleme ücretsiz sürümde otomatik değil; ZIP’i indirip elle açmanız ve veritabanını phpMyAdmin’den içe aktarmanız gerekir. Teknik bilgisi olan kullanıcılar için uygun.

Hosting Yedeği Yeterli mi?

Kısa cevap: hayır, tek başına yeterli değil. Ama tamamen değersiz de değil; 3-2-1 kuralında ikinci kopya olarak iyi iş görür.

Hostinger, cPanel tabanlı firmalar, Turhost, Natro gibi sağlayıcıların çoğu “günlük otomatik yedek” sunar. Bu yedeklerin gerçekte ne olduğunu bilmek önemli.

En kritik nokta şu: sunucunuz ele geçirilirse, sunucudaki yedek de ele geçirilmiş demektir. Fidye yazılımı bulaşan bir sunucuda saldırganın ilk yaptığı işlerden biri, erişebildiği yedekleri silmek veya şifrelemektir.

Aynı şekilde, bir zafiyet üzerinden siteye giren saldırgan haftalardır oradaysa, hostingin tuttuğu son 3 günlük yedeklerin üçü de enfekte olabilir. Bu tür vakalarda çözüm yedekten dönmek değil, hacklenmiş site kurtarma sürecine girmek olur, ki bu hem uzun hem maliyetlidir.

Hosting yedeğini şöyle konumlandırın: hızlı ve pratik ikinci kopya, ama asla tek kopya değil. Küçük bir hata yaptıysanız (yanlış eklenti güncellemesi, silinen sayfa) hosting yedeği dakikalar içinde sizi kurtarır. Gerçek bir felakette ise size site dışı kopya lazım.

Yedeği Nereye Saklamalı?

Site dışı kopyanın nerede duracağı, teknik yeterliliğinize ve site büyüklüğünüze göre değişir.

Seçim yaparken üç şeye bakın:

Sürüm sayısı tutabiliyor mu? Depolama alanınız sadece bir yedeği alacak kadarsa, her yeni yedek eskisini eziyor demektir. Enfekte bir yedek temiz olanın üstüne yazarsa geri dönecek yer kalmaz.

Hesap güvenliği ne durumda? Google Drive’ınızda iki adımlı doğrulama yoksa, sitenizin tüm verisi tek bir şifrenin arkasında duruyor demektir. Yedek deponuz, sitenizin kendisi kadar korunmalıdır.

Şifreleme var mı? Yedek dosyanız wp-config.php içerdiği için veritabanı kullanıcı adı ve parolanızı barındırır. Bulut hesabınız ele geçirilirse saldırgan doğrudan veritabanınıza girebilir. UpdraftPlus Premium gibi eklentilerin sunduğu yedek şifreleme özelliğini kullanın ya da en azından bulut hesabınızı sıkı koruyun.

Geri Yükleme: Adım Adım

Yedeğin tek amacı geri yüklenebilmektir. İki yöntemi de bilmelisiniz. Eklenti yöntemi WordPress paneline girebildiğiniz senaryolarda çalışır; panel açılmıyorsa manuel yönteme mecbur kalırsınız.

Yöntem 1: Eklenti ile geri yükleme (UpdraftPlus örneği)

1. Yeni bir yedek alın. Geri yükleme öncesi mevcut durumun kopyasını almak, işlem ters giderse başladığınız noktaya dönmenizi sağlar.
2. WordPress panelinde Ayarlar bölümündeki UpdraftPlus Yedekler ekranına gidin.
3. Mevcut Yedekler sekmesinde geri dönmek istediğiniz tarihi bulun. Bulutta duran ama sunucuda olmayan yedekler için önce “Uzak depolamayı yeniden tara” deyin.
4. İlgili yedeğin yanındaki Geri Yükle butonuna basın.
5. Hangi bileşenleri geri yükleyeceğinizi seçin: Veritabanı, Eklentiler, Temalar, Yüklemeler, Diğer. Sadece veritabanı bozulduysa yalnızca veritabanını seçmek işlemi çok hızlandırır.
6. Eklenti dosyaları açar, doğrular ve geri yükler. Site büyüklüğüne göre 2-20 dakika sürer.
7. İşlem bitince “Eski dizinleri sil” uyarısını onaylayın.
8. Kontrol listesi: Ana sayfa açılıyor mu? Kalıcı bağlantılar çalışıyor mu (Ayarlar > Kalıcı Bağlantılar’a girip Kaydet demek genelde çözer)? Görseller yükleniyor mu? WooCommerce siparişleri yerinde mi? Yönetici girişi yapılabiliyor mu?

Yöntem 2: Manuel geri yükleme (FTP + phpMyAdmin)

Panel açılmıyorsa, “beyaz ekran” alıyorsanız veya site tamamen çöktüyse bu yöntemi kullanın. Elinizde iki şey olmalı: dosya arşivi (ZIP) ve veritabanı dökümü (.sql).

Adım 1: Dosyaları FTP ile yükleyin. FileZilla gibi bir FTP/SFTP istemcisiyle sunucuya bağlanın. Barındırma bilgileri hosting panelinizde yazar. public_html (veya httpdocs) klasörüne gidin.

Mevcut bozuk dosyaları silmeden önce bir kenara alın: klasörü public_html_eski olarak yeniden adlandırmak en güvenlisidir. Ardından yedek arşivinizden çıkardığınız dosyaları yükleyin. Özellikle wp-content klasörünün tamamının ve wp-config.php dosyasının yüklendiğinden emin olun.

Adım 2: Veritabanını phpMyAdmin ile içe aktarın. Hosting panelinizden phpMyAdmin’i açın. Sol taraftan sitenizin veritabanını seçin.

Önce mevcut tabloları temizleyin: tüm tabloları seçip Sil (Drop) deyin. Bu adım kritiktir; üstüne yazmak yerine temiz bir veritabanına aktarmak, çakışma hatalarını önler.

İçe Aktar sekmesine geçin, .sql dosyanızı seçin ve Başlat deyin. Dosya çok büyükse (genelde 50 MB üstü) phpMyAdmin yükleme sınırına takılabilir. Bu durumda .sql dosyasını gzip ile sıkıştırıp .sql.gz olarak yükleyin veya hostingden geçici olarak upload_max_filesize artırımı isteyin.

Adım 3: wp-config.php’yi kontrol edin. Siteyi farklı bir sunucuya veya farklı bir veritabanına taşıdıysanız wp-config.php içindeki şu dört değeri güncellemeniz gerekir:

define( 'DB_NAME', 'veritabani_adi' );
define( 'DB_USER', 'veritabani_kullanicisi' );
define( 'DB_PASSWORD', 'parola' );
define( 'DB_HOST', 'localhost' );

Ayrıca yedekteki tablo ön ekinin ($table_prefix) veritabanındaki tablo isimleriyle eşleştiğini doğrulayın. Yedekte wp_ yazıyor ama veritabanındaki tablolar wpxy_ ile başlıyorsa site açılmaz.

Adım 4: Site adresini doğrulayın. Alan adı değiştiyse veritabanında eski adres kalmış olabilir. phpMyAdmin’de wp_options tablosunu açın, siteurl ve home satırlarını yeni adresle güncelleyin. İçerik içindeki eski URL’ler için ise Better Search Replace eklentisiyle seri değiştirme yapın; SQL üzerinde elle REPLACE çalıştırmak serileştirilmiş (serialized) verileri bozabilir.

Adım 5: Son kontroller. Ayarlar bölümündeki Kalıcı Bağlantılar’a girip hiçbir değişiklik yapmadan Kaydet deyin (bu .htaccess kurallarını yeniden yazar). Ardından ana sayfa, bir iç sayfa, bir blog yazısı, iletişim formu ve varsa sepet/ödeme akışını tek tek test edin.

En Sık Yapılan 7 Yedekleme Hatası

Kurtarma çağrılarında karşıma çıkan hataların büyük çoğunluğu şu yedi başlıkta toplanıyor.

1. Test edilmemiş yedek. En yaygın ve en pahalı hata. Eklenti “yedek başarılı” diyor, dosya bulutta duruyor ama kimse açıp bakmamış. Kriz anında ZIP’in bozuk olduğu ya da veritabanı dökümünün yarım kaldığı anlaşılıyor. Test edilmemiş yedek, yedek değil; sadece bir umuttur.

2. Sadece veritabanı yedeklemek. Veritabanı dökümü küçük ve hızlı olduğu için cazip gelir. Ama uploads klasörü olmadan geri yüklediğinizde tüm görselleri kırık, tüm medya kütüphanesi boş bir site elde edersiniz. Yıllarca birikmiş görselleri geri getirmenin yolu yoktur.

3. Yedeği sunucuda saklamak. public_html/backups/ klasöründe duran yedek, sunucu çöktüğü anda sitenizle birlikte kaybolur. Dahası, bu klasör dışarıdan erişilebilirse yedeğinizi indiren biri wp-config.php üzerinden veritabanı bilgilerinize ulaşır.

4. Otomasyon kurmamak. “Ayda bir elle alırım” diyen herkes üçüncü ayda unutur. İnsan hafızası yedekleme programı değildir. Yedekleme zamanlanmış olmalı ve başarısız olduğunda size e-posta göndermelidir. Sessiz kalan bir yedekleme sistemi, çalıştığının değil sadece fark edilmediğinin göstergesidir.

5. E-ticarette seyrek yedek. Günlük yedek alan bir WooCommerce mağazasında, sabah 09:00’da yaşanan bir çökme gece 03:00’ten beri gelen tüm siparişleri siler. Müşteri parayı ödemiştir ama sizde kaydı yoktur. E-ticarette veritabanı yedeği saatlik ya da gerçek zamanlı olmalıdır.

6. Eski yedekleri hemen silmek. Alan tasarrufu için sadece son yedeği tutmak, kötü niyetli yazılım vakalarında ölümcüldür. Zararlı kod siteye üç hafta önce girdiyse ve elinizde sadece dünkü yedek varsa, geri yüklediğiniz şey zararlı kodun kendisidir. En az 30 gün, e-ticarette 90 gün geriye giden sürümler tutun.

7. Şifre ve erişim bilgilerini kaybetmek. Yedek şifreli ama parola nerede? Bulut hesabının erişimi işten ayrılan çalışanda mı? FTP bilgileri kimde? Yedeğin kendisi kadar ona erişim bilgileri de güvenli ve ulaşılabilir bir yerde (kurumsal bir parola yöneticisinde) durmalı.

Yedeğinizi Nasıl Test Edersiniz?

Bu bölüm çoğu yedekleme rehberinde yok ve tam da bu yüzden en kritik olanı. Geri yüklenmemiş bir yedeğin çalışıp çalışmadığını bilemezsiniz. Bunu öğrenmenin tek yolu, kriz anını beklemeden denemektir.

Neden test şart?

Yedeklerin sessizce bozulmasının birkaç yaygın sebebi var: sunucu zaman aşımı nedeniyle yarım kalan arşivler, PHP bellek sınırına takılıp eksik dışa aktarılan veritabanları, buluta yüklenirken kesilen aktarımlar, eklenti güncellemesinden sonra bozulan yedekleme işleri. Bunların hiçbiri panelde kırmızı uyarı olarak görünmez. Sadece geri yüklemeye çalıştığınızda ortaya çıkar.

Staging (deneme) ortamında test

En doğru yöntem, yedeği canlı siteye dokunmadan ayrı bir ortama açmaktır.

Seçenek A: Hosting’in staging özelliği. Hostinger, SiteGround, Kinsta ve birçok sağlayıcı tek tıkla staging kopyası oluşturur. Bu kopyaya yedeğinizi geri yükleyip sonucu inceleyebilirsiniz. Canlı site hiç etkilenmez.

Seçenek B: Alt alan adı. test.siteniz.com şeklinde bir alt alan açın, temiz bir WordPress kurun ve yedeğinizi oraya geri yükleyin. Arama motorlarının indekslememesi için noindex ayarını açmayı ve dizini parola korumasına almayı unutmayın.

Seçenek C: Yerel bilgisayar. LocalWP veya XAMPP ile bilgisayarınızda bir WordPress kurup yedeği oraya açın. Hiçbir sunucu maliyeti yoktur, tamamen izole bir testtir. Duplicator bu senaryo için özellikle pratiktir.

3 ayda bir tatbikat: kontrol listesi

Takviminize üç ayda bir tekrarlayan bir hatırlatma koyun. Tatbikat 30-45 dakika sürer ve şunları doğrular:

Son satır özellikle değerli. Geri yüklemenin 12 dakika mı yoksa 3 saat mi sürdüğünü önceden bilmek, kriz anında müşterilerinize ve ekibinize doğru bilgi vermenizi sağlar. Buna RTO (Recovery Time Objective) denir ve tatbikat yapmadan tahmin edilemez.

Testin sonucunu kayıt altına alın

Basit bir not dosyası yeterli: tatbikat tarihi, kullanılan yedeğin tarihi, geri yükleme süresi, karşılaşılan hatalar, yapılan düzeltmeler. Üç ay sonra aynı hatayla karşılaşırsanız çözümü hatırlamak zorunda kalmazsınız. Yönettiğim sitelerde bu kaydı tutuyorum ve zamanla hangi eklentinin hangi sunucuda sorun çıkardığını görmek çok işe yarıyor.

Sıkça Sorulan Sorular

Yedekleme, alınan yedeğe değil, geri yüklenebildiği kanıtlanmış yedeğe güvenmektir. 3-2-1 kuralını uygulayın, site dışı bir kopya tutun ve üç ayda bir mutlaka test edin. Bu sistemi kurmak ve takibini üstlenmek için aylık bakım paketim kapsamında birlikte çalışabiliriz.

Bu yazıları da okumak isteyebilirsiniz ...

WordPress Güvenliği: Sitenizi Baştan Sona Koruma Rehberi

WordPress Sitem Hacklendi mi? Belirtiler, Tespit ve İlk Müdahale

WordPress Güvenlik Eklentileri Karşılaştırması: Hangisi Size Uygun?

Başarılı Dijital Projelerin Temeli: Etkili Bir Yaratıcı Brief Nasıl Yazılır?

Yazar Hakkında

Barış Dayak

2014'ten bu yana web tasarım, WordPress ve SEO & AI görünürlük alanlarında 500'den fazla işletmeye hizmet veriyorum.