--- title: "WordPress Yedekleme: Doğru Strateji, Eklentiler ve Geri Yükleme Rehberi" url: https://barisdayak.com/wordpress-yedekleme-rehberi/ date: 2026-07-22 modified: 2026-07-22 author: "Barış Dayak" description: "WordPress yedeklemesi iki parçanın birlikte kopyalanmasıdır: dosyalar (tema, eklenti, görseller, wp-config.php) ve veritabanı (yazılar, sayfalar, ayarlar, WooCommerce siparişleri). Doğru strateji 3-2-1 kuralıdır: verinin 3 kopyası olsun, 2 farklı ortamda dursun,..." categories: - "Blog" image: https://barisdayak.com/wp-content/uploads/2026/07/wordpress-yedekleme-rehberi-img-1024x538.png word_count: 3037 --- # WordPress Yedekleme: Doğru Strateji, Eklentiler ve Geri Yükleme Rehberi WordPress yedeklemesi iki parçanın birlikte kopyalanmasıdır: **dosyalar** (tema, eklenti, görseller, wp-config.php) ve **veritabanı** (yazılar, sayfalar, ayarlar, WooCommerce siparişleri). Doğru strateji **3-2-1 kuralıdır**: verinin 3 kopyası olsun, 2 farklı ortamda dursun, en az 1 kopya site dışında bulunsun. Bir yedeğin gerçekten işe yaraması için düzenli alınması ve mutlaka test edilmesi, yani geri yüklenebildiğinin önceden kanıtlanması gerekir. 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. | Bileşen | Ne içerir? | Yedeklenmeli mi? | Kaybedilirse sonuç | | -------- | ----------- | ---------------- | ------------------- | | **Veritabanı (MySQL)** | Yazılar, sayfalar, yorumlar, kullanıcılar, eklenti ayarları, WooCommerce sipariş ve müşteri kayıtları | **Zorunlu** | Site tamamen boş açılır; sipariş geçmişi yok olur | | **wp-content/uploads** | Tüm görseller, PDF'ler, medya dosyaları | **Zorunlu** | Yazılar durur ama tüm görseller kırık | | **wp-content/themes** | Aktif tema, child tema, tema özelleştirmeleri | **Zorunlu** | Tasarım kaybolur; child temadaki özel kodlar gider | | **wp-content/plugins** | Kurulu tüm eklentiler, lisanslı premium eklentiler | **Zorunlu** | Fonksiyonlar durur; premium eklentileri yeniden indirmek gerekir | | **wp-config.php** | Veritabanı bağlantı bilgileri, güvenlik anahtarları (salt), tablo ön eki | **Zorunlu** | Site veritabanına bağlanamaz; kullanıcılar oturumdan düşer | | **.htaccess** | Kalıcı bağlantı kuralları, yönlendirmeler, güvenlik kuralları | **Önerilir** | 404 hataları ve bozulan yönlendirmeler | | **wp-includes / wp-admin** | WordPress çekirdek dosyaları | Opsiyonel | WordPress.org'dan yeniden indirilebilir | | **wp-content/cache** | Önbellek dosyaları | **Hayır** | Gereksiz; yedek boyutunu şişirir | Pratikte kritik olan iki şey var: **veritabanı** ve **wp-content klasörünün tamamı**. Çekirdek dosyalar her zaman [WordPress.org'dan](https://wordpress.org/documentation/article/backing-up-your-wordpress-site/) 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](https://barisdayak.com/hacklenmis-site-tespit-ve-temizlik/) 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. | Site tipi | İçerik değişim hızı | Veritabanı sıklığı | Dosya sıklığı | Saklama süresi | | --------- | ------------------------- | ----------------------- | ----------------- | --------------- | | **Kişisel blog / portföy** | Haftada 1-2 içerik | Haftalık | Haftalık | 30 gün (4 sürüm) | | **Kurumsal tanıtım sitesi** | Ayda birkaç güncelleme | Haftalık | Haftalık veya güncelleme öncesi | 30-60 gün | | **E-ticaret (WooCommerce)** | Sürekli sipariş, stok, müşteri | **Saatlik veya gerçek zamanlı** | Günlük | 60-90 gün | | **Haber / yüksek trafikli portal** | Günde 10+ içerik, yoğun yorum | **Günde 2-4 kez** | Günlük | 30-45 gün | | **Üyelik / kurs sitesi** | Kullanıcı ilerlemesi, ödemeler | Günlük veya 6 saatte bir | Günlük | 90 gün | | **Statik mikro site / landing** | Neredeyse hiç | Aylık | Aylık | 3 sürüm | 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. Ürün sayfalarınız trafik alıyor ama satmıyor mu? Çoğu zaman sorun içerikte değil, altyapının şema, hız ve varyant yapısında oluyor. Doğru kurulmuş bir mağaza, yazdığınız her ürün metninin karşılığını almanızı sağlar. [WhatsApp iletişim](https://wa.me/905350283109?text=Merhaba%2C%20%22%C3%9Cr%C3%BCn%20Sayfas%C4%B1%20SEO%26%238217%3Bsu%3A%20E-Ticarette%20Sat%C4%B1%C5%9F%20Getiren%20Sayfa%20Nas%C4%B1l%20Yaz%C4%B1l%C4%B1r%3F%22%20yaz%C4%B1n%C4%B1zdaki%20%22%C3%9Cr%C3%BCn%20sayfalar%C4%B1n%C4%B1z%20trafik%20al%C4%B1yor%20ama%20satm%C4%B1yor%20mu%3F%22%20b%C3%B6l%C3%BCm%C3%BCnden%20ula%C5%9F%C4%B1yorum.)[E-Ticaret Altyapı Hizmeti](https://barisdayak.com/e-ticaret-sitesi-tasarimi/) ## 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. | Eklenti | Ücretsiz sürüm kapsamı | Bulut desteği | Geri yükleme kolaylığı | E-ticaret uygunluğu | | ------- | -------------------------- | -------------- | -------------------------- | -------------------- | | **UpdraftPlus** | Zamanlanmış tam yedek (dosya + DB), manuel geri yükleme, temel bulut hedefleri | Google Drive, Dropbox, S3, OneDrive, FTP (ücretsizde çoğu mevcut) | **Çok kolay.** Panelden tek tık geri yükleme | **İyi.** Artımlı ve sık yedekleme Premium'da | | **Duplicator** | Tam site paketi + installer.php, taşıma odaklı | Ücretsizde yok (Pro'da Drive/Dropbox/S3) | Orta. installer.php ile manuel adımlar | Zayıf. Zamanlanmış yedek ücretsizde yok | | **All-in-One WP Migration** | Tek tıkla dışa aktarma; **ücretsiz içe aktarma 256 MB ile sınırlı** | Uzantılar ücretli | Kolay ama boyut sınırı engel olur | Zayıf. Büyük WooCommerce sitelerinde sınıra takılır | | **BackWPup** | Zamanlanmış yedek, DB optimizasyonu, çoklu iş tanımı | Dropbox, S3, FTP, Rackspace (ücretsizde geniş) | **Zor.** Ücretsizde otomatik geri yükleme yok, manuel | Orta. Yedek alır ama geri yükleme manuel | | **Jetpack VaultPress Backup** | Ücretsiz sürüm yok (ayrı ücretli abonelik) | Otomatik, Jetpack bulutu (sunucudan tamamen bağımsız) | **Çok kolay.** Sunucu erişimi olmadan bile tek tık | **En iyi.** Gerçek zamanlı sipariş yedeği | ### Hangisini kime öneriyorum? **UpdraftPlus:** çoğu site için doğru başlangıç. [Ücretsiz sürümü](https://wordpress.org/plugins/updraftplus/) 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. | Konu | Hosting yedeğinin durumu | Risk | | ---- | ------------------------- | ---- | | **Nerede saklanıyor?** | Genellikle aynı sunucuda veya aynı veri merkezinde | Sunucu çökerse/ele geçirilirse yedek de gider | | **Kaç sürüm tutuluyor?** | Genellikle 1-7 gün | Eski enfeksiyonu fark ettiğinizde temiz sürüm kalmamış olabilir | | **Erişim kimde?** | Hosting hesabı üzerinden | Hesabınız askıya alınırsa yedeğe erişemezsiniz | | **Tam mı, kısmi mi?** | Çoğunda dosya + DB, ama garanti değil | Sadece dosya yedeği alan sağlayıcılar var | | **Sözleşmede garanti var mı?** | Çoğu firma "yedek garantisi vermeyiz" der | Sorumluluk sizde | | **Geri yükleme ücretli mi?** | Bazı firmalarda manuel restore ücretli | Kriz anında ek maliyet ve gecikme | 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](https://barisdayak.com/wordpress-virus-temizleme-hizmeti/) 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. | Depolama | Maliyet | Otomasyon | Güvenlik | Kimler için uygun | | -------- | ------- | --------- | --------- | ------------------ | | **Google Drive** | 15 GB ücretsiz, sonrası uygun | Eklentilerle tam otomatik | İki adımlı doğrulama şart | Blog, kurumsal, küçük-orta e-ticaret. **En yaygın seçim** | | **Dropbox** | 2 GB ücretsiz, planlar pahalı | Tam otomatik | İyi | Küçük siteler; alan hızla dolar | | **Amazon S3 / Wasabi** | GB başı çok ucuz, sınırsız ölçek | Tam otomatik, sürüm kontrolü var | **En yüksek.** IAM, sürümleme, nesne kilidi | Büyük siteler, ajanslar, çok siteli yönetim | | **Yerel bilgisayar / harici disk** | Sıfır ek maliyet | **Manuel.** İnsana bağlı | Fiziksel risk (kayıp, hırsızlık, disk arızası) | Ek üçüncü kopya olarak; tek başına yetersiz | | **OneDrive** | Microsoft 365 ile 1 TB | Otomatik | İyi | Zaten Microsoft ekosistemindeki işletmeler | | **Ayrı bir sunucu / VPS (FTP)** | VPS maliyeti | Otomatik | Yapılandırmaya bağlı | Teknik ekibi olan kurumlar | 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) - **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. - WordPress panelinde Ayarlar bölümündeki UpdraftPlus Yedekler ekranına gidin. - Mevcut Yedekler sekmesinde geri dönmek istediğiniz tarihi bulun. Bulutta duran ama sunucuda olmayan yedekler için önce "Uzak depolamayı yeniden tara" deyin. - İlgili yedeğin yanındaki Geri Yükle butonuna basın. - 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. - Eklenti dosyaları açar, doğrular ve geri yükler. Site büyüklüğüne göre 2-20 dakika sürer. - İşlem bitince "Eski dizinleri sil" uyarısını onaylayın. - **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](https://wordpress.org/plugins/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: | Kontrol | Ne bakılır | Başarı kriteri | | ------- | ------------ | ---------------- | | **Dosya bütünlüğü** | Yedek arşivi hatasız açılıyor mu? | ZIP hatasız açılıyor, boyut beklenen aralıkta | | **Veritabanı içe aktarma** | `.sql` dosyası phpMyAdmin'de hatasız yükleniyor mu? | Hata mesajı yok, tablo sayısı canlıyla eşit | | **Ana sayfa** | Staging'de site açılıyor mu? | Tasarım bozulmadan yükleniyor | | **Medya** | Görseller görünüyor mu? | Kırık görsel yok, medya kütüphanesi dolu | | **İç sayfalar** | Kalıcı bağlantılar çalışıyor mu? | Blog yazıları ve sayfalar 404 vermiyor | | **Yönetici girişi** | Panele giriş yapılabiliyor mu? | Kullanıcı tablosu sağlam | | **Kritik işlev** | Form gönderimi, sepet, ödeme akışı | Sipariş oluşturulabiliyor | | **Süre ölçümü** | Geri yükleme kaç dakika sürdü? | Gerçek kriz için beklenti oluşturur | 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. Ürün sayfalarınızı satış getiren sayfalara çevirelim Mağazanızın ürün sayfalarını bu 12 maddelik kontrol listesine göre inceleyip, hangi düzeltmenin ne kadar getiri sağlayacağını önceliklendirilmiş bir listeyle sunuyorum. Kurulum, şema ve içerik tarafını uçtan uca üstlenebilirim. Product, Offer ve AggregateRating şemalarının hatasız kurulumu Kopya ürün açıklamalarının tespiti ve özgün metin yapısı Tükenen ürünler için yönlendirme haritası ve iç link mimarisi [WhatsApp iletişim](https://wa.me/905350283109?text=Merhaba%2C%20%22%C3%9Cr%C3%BCn%20Sayfas%C4%B1%20SEO%26%238217%3Bsu%3A%20E-Ticarette%20Sat%C4%B1%C5%9F%20Getiren%20Sayfa%20Nas%C4%B1l%20Yaz%C4%B1l%C4%B1r%3F%22%20yaz%C4%B1n%C4%B1zdaki%20%22%C3%9Cr%C3%BCn%20sayfalar%C4%B1n%C4%B1z%C4%B1%20sat%C4%B1%C5%9F%20getiren%20sayfalara%20%C3%A7evirelim%22%20b%C3%B6l%C3%BCm%C3%BCnden%20ula%C5%9F%C4%B1yorum.)[E-Ticaret Altyapı Hizmeti](https://barisdayak.com/e-ticaret-sitesi-tasarimi/) ## Sıkça Sorulan Sorular ### WordPress yedeği ne kadar yer kaplar? Tipik bir kurumsal site 200 MB ile 1 GB arasındadır; veritabanı genelde 20-100 MB'tır ve geri kalanı görsellerden oluşur. Görsel ağırlıklı bloglar ve WooCommerce mağazaları 5-20 GB'a çıkabilir. Alanı düşürmek için: yedeğe wp-content/cache klasörünü dahil etmeyin, medya kütüphanesindeki kullanılmayan görselleri temizleyin, veritabanındaki eski revizyonları ve spam yorumları silin. Yalnızca değişen dosyaları kopyalayan artımlı (incremental) yedekleme kullanan eklentiler de depolama tüketimini ciddi biçimde azaltır. ### Yedekten dönmek sitemi eski haline tam olarak getirir mi? Yedeğin kapsamına bağlı. Hem dosyalar hem veritabanı yedeklenmişse site, yedeğin alındığı andaki haline tam olarak döner. Ancak yedek tarihinden sonra eklenen içerikler, gelen siparişler, yeni kullanıcı kayıtları ve yorumlar geri gelmez; bu yüzden yedekleme sıklığı doğrudan kabul edilebilir kayıp miktarını belirler. Ayrıca DNS ayarları, e-posta hesapları ve SSL sertifikaları WordPress yedeğine dahil değildir; bunlar hosting tarafında ayrıca yönetilir. ### Sitem hacklendi, yedekten dönmek yeterli mi? Genellikle yeterli değildir. İki risk var. Birincisi, zararlı kod fark ettiğinizden çok daha önce girmiş olabilir ve elinizdeki yedekler de enfekte olabilir. İkincisi, saldırının girdiği güvenlik açığı (eski eklenti sürümü, zayıf parola, güncellenmemiş çekirdek) yedekten dönseniz de yerinde kalır; aynı yoldan tekrar girilir. Doğru sıra şudur: siteyi çevrimdışı alın, açığı tespit edip kapatın, tüm parolaları ve güvenlik anahtarlarını (salt) yenileyin, ardından bilinen temiz bir yedekten dönün ve dosyaları zararlı kod taramasından geçirin. ### Ücretsiz yedekleme eklentisi yeterli mi? Kişisel blog, portföy ve kurumsal tanıtım siteleri için UpdraftPlus'ın ücretsiz sürümü çoğu zaman yeterlidir: zamanlanmış yedek alır, Google Drive gibi site dışı bir hedefe gönderir ve panelden geri yüklenebilir. E-ticaret, üyelik ve yüksek trafikli sitelerde ise ücretsiz sürümler yetersiz kalır; saatlik/gerçek zamanlı yedekleme, artımlı yedekleme, yedek şifreleme ve sunucu erişimi olmadan geri yükleme gibi özellikler ücretli sürümlerde bulunur. Ölçüt basittir: bir günlük veri kaybının size maliyeti, yıllık lisans ücretinden yüksekse ücretliye geçin. ### 3-2-1 yedekleme kuralı nedir? 3-2-1 kuralı, verinizin güvende olması için bir referans standarttır: en az **3 kopya** tutun, bu kopyaları **2 farklı ortamda** saklayın ve en az **1 kopyayı site dışında** (sunucunuzdan bağımsız bir konumda) bulundurun. WordPress'te bu genellikle şöyle uygulanır: canlı sitenin kendisi, hosting'in otomatik yedeği ve bir eklenti ile buluta (örneğin Google Drive) gönderilen site dışı yedek. Amaç, tek bir arıza noktasının tüm kopyalarınızı aynı anda yok etmesini engellemektir. ### WordPress yedeğini ne sıklıkta almalıyım? Sıklığı belirleyen soru şudur: kaç saatlik veri kaybını kabul edebilirsiniz? Ayda birkaç kez güncellenen bir kurumsal site veya blog için haftalık yedek yeterlidir. Sürekli sipariş alan bir WooCommerce mağazasında ise veritabanı saatlik veya gerçek zamanlı yedeklenmelidir, çünkü bir günlük kayıp bir günlük siparişin kaybı demektir. Ayrıca her büyük değişiklikten (sürüm yükseltme, tema değişikliği, toplu güncelleme) önce mutlaka manuel bir yedek alın. 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](https://barisdayak.com/fiyatlar/#bdp-ek) kapsamında birlikte çalışabiliriz.