WordPress Yedekleme Stratejileri: Paylaşımlı Hosting ve VPS’te Otomatik Yedek ve Geri Yükleme

WordPress Yedeklemenin Gerçek Değeri: Neden Bu Kadar Önemli?

WordPress kullanan hemen herkes yedek almanın önemli olduğunu bilir; ama iş pratiğe geldiğinde çoğu zaman “daha sonra bakarız” klasörüne kaldırılır. Ta ki bir eklenti güncellemesinden sonra sitenin bozulmasına, temadaki ufak bir düzenlemenin beyaz ekrana dönüşmesine ya da veritabanında beklenmedik bir tutarsızlık çıkmasına kadar. DCHost tarafında yüzlerce WordPress sitesini barındırdığımız için şunu çok net görüyoruz: Yedek, sadece teknik bir güvenlik önlemi değil; iş sürekliliğinin kalbidir. Yedekleme stratejinizi doğru kurduğunuzda, yaşanabilecek bir problemi “felaket” olmaktan çıkarıp “küçük bir geri dönüş işlemi” seviyesine indirirsiniz. Bu yazıda, hem paylaşımlı hosting hem de VPS ortamlarında WordPress için otomatik yedek alma ve geri yükleme stratejilerini, gerçek hayatta karşılaştığımız senaryolardan süzerek anlatacağız. Hedefimiz, sizde şu duyguyu oluşturmak: “Site bozulsa da, hack’lense de, yanlışlıkla silsem de en fazla birkaç adım geriye dönerim; panik yok.”

Ne Yedeklenmeli? WordPress’in Yapısını Doğru Anlamak

Sağlam bir yedekleme stratejisinin ilk adımı, neyi yedeklemeniz gerektiğini netleştirmektir. WordPress’te tüm site, kabaca iki ana parçadan oluşur: dosyalar ve veritabanı.

• Dosyalar: WordPress çekirdeği, tema ve eklenti dosyaları, medya yüklemeleri, yapılandırma dosyaları.
• Veritabanı: Yazılar, sayfalar, yorumlar, kullanıcılar, ayarlar, WooCommerce siparişleri gibi işin asıl “veri” kısmı.

Pratikte şu yollarla düşünmek işinizi kolaylaştırır:

• wp-content/ klasörü: Temalar, eklentiler ve uploads klasöründeki görseller/belgeler burada. Genellikle en kritik dosya yedeğiniz buradan gelir.
• wp-config.php: Veritabanı bağlantı bilgileri, bazı güvenlik ve performans ayarları. Özellikle elinizle düzenlediyseniz mutlaka yedeğe dahil edin.
• Veritabanı (MySQL/MariaDB): Tüm içerik ve ayarların kalbi. Bu dosya kaybolursa, dosyalar tek başına sitenizi geri getiremez.

Ek olarak, bazı klasörlerin yedekten hariç tutulması iyi bir pratiktir:

• Önbellek klasörleri (cache eklentilerinin oluşturduğu dizinler)
• Geçici (tmp) klasörler
• Log dosyalarının tutulduğu dizinler

Bunları hariç tutmak, yedek boyutunu küçültür, yedekleme süresini kısaltır ve geri yükleme işlemini hızlandırır.

İş Tarafından Bakmak: RPO, RTO ve Yedekleme Sıklığı

Yedekleme stratejinizi planlarken teknikten önce iş hedeflerini netleştirmek gerekir. Burada iki kavram kritik:

• RPO (Recovery Point Objective): En fazla ne kadar veri kaybını kabul edebilirsiniz? Örneğin “en fazla son 4 saatteki içerik değişiklikleri kaybolsun” gibi.
• RTO (Recovery Time Objective): Siteniz bozulduğunda en geç ne kadar sürede geri ayağa kalkmalı? 15 dakika mı, 2 saat mi, 1 gün mü?

Bu değerler; sitenizin türüne (blog, kurumsal site, WooCommerce mağazası, LMS platformu vb.) ve gelir modelinize göre değişir. Örneğin, yoğun sipariş alan bir e-ticaret sitesinde RPO’nuz çok düşüktür; birkaç dakikalık sipariş kaybı bile sorun olabilir. Bu durumda sadece günlük değil, saatlik veritabanı yedekleri bile konuşulmalıdır.

RPO/RTO kavramlarını daha geniş bir felaket kurtarma çerçevesinde ele almak isterseniz, felaket kurtarma planı nasıl yazılır rehberimizde çok daha detaylı bir yol haritası bulabilirsiniz.

Paylaşımlı Hosting’te WordPress Yedekleme Stratejisi

Paylaşımlı hosting, özellikle giriş seviyesinde WordPress kullanıcılarının çoğunlukla tercih ettiği ortam. Burada avantajınız; çoğu işin panel (cPanel, Plesk vb.) ve altyapı tarafından sizin adınıza otomatikleştirilmiş olması. Dezavantajınız ise, çekirdek sunucuya tam erişiminizin olmaması. Dolayısıyla strateji, panel yedekleri + WordPress eklentileri + harici depolama üçgeninde şekillenmeli.

cPanel / Plesk Üzerinden Panel Bazlı Yedekler

Birçok DCHost paylaşımlı hosting paketinde, kontrol paneli üzerinden hem manuel hem otomatik yedekleme seçenekleri bulunur. Tipik olarak üç tür yedekten söz edebiliriz:

• Tam hesap yedeği (full backup): Tüm dosyalar, veritabanları, e-posta hesapları ve ayarlar tek bir arşivde toplanır. Felaket durumlarında “her şeyi bir kerede geri alma” için idealdir.
• Kısmi yedekler: Sadece home dizini (dosyalar) veya sadece belirli veritabanları. Küçük geri dönüş ihtiyaçları için pratiktir.
• Otomatik periyodik yedekler: Hosting sağlayıcınızın sizin için periyodik aldığı günlük/haftalık yedekler. Bunların sıklığı ve saklama süresini mutlaka öğrenin.

Burada kritik nokta şu: Panel yedekleri çoğu zaman aynı sunucuda veya aynı veri merkezinde tutulur. Donanım arızası, disk sorunu ya da büyük ölçekli bir problemde bu yedeklerin de risk altında olabileceğini unutmamak gerekir. Bu nedenle, panel yedeklerini stratejinizin tek bacağı olarak görmek hatalıdır.

WordPress Eklentileriyle Otomatik Yedek Alma

Paylaşımlı hosting ortamında kök erişiminiz (root) olmadığı için, çoğu zaman en pratik çözüm bir WordPress yedekleme eklentisi kullanmaktır. Genel yaklaşım şu şekilde olmalı:

• Eklentiyi dosyalar + veritabanı yedekleyecek şekilde yapılandırın.
• Yedeklerin mutlaka sunucu dışına (örn. S3 uyumlu nesne depolama, harici FTP, başka bir sunucu) gönderilmesini sağlayın.
• Yedek dosyalarını şifreleme (encryption) ve sıkıştırma (compression) seçeneklerini aktif edin.
• Yedek saklama politikasını (örneğin son 14 yedeği tut, eskileri sil) net belirleyin.

Bu eklentiler genelde WordPress’in kendi zamanlayıcısı olan wp-cron üzerinden çalışır. Trafiği az sitelerde wp-cron’un tetiklenmesi gecikebilir; yüksek trafikli sitelerde de her istekte tetiklenmesi performansı etkileyebilir. Bu konuyu daha derinlemesine anlamak için, wp-cron’u devre dışı bırakma ve gerçek cron job kurulumuna dair rehberimizi mutlaka okumanızı öneririm.

3-2-1 Kuralını Paylaşımlı Hosting’te Uygulamak

Yedekleme dünyasında altın standart kabul edilen bir kural vardır: 3-2-1 yedekleme stratejisi.

• 3 kopya: Verinizin en az 3 kopyası olmalı (1 asıl, 2 yedek).
• 2 farklı medya: Bu kopyalar en az 2 farklı tür depolama medyasında tutulmalı (örneğin sunucu diski + harici depolama).
• 1 uzak konum: En az 1 kopya fiziksel olarak farklı bir lokasyonda olmalı.

Paylaşımlı hosting için pratik bir örnek:

• 1. Kopya: Canlı WordPress dosyaları ve veritabanı (üretim ortamınız).
• 2. Kopya: DCHost’un panel üzerinden aldığı otomatik yedekler.
• 3. Kopya: WordPress eklentisiyle alınan ve S3 uyumlu uzak depolamaya gönderilen yedekler.

Bu yaklaşımı daha sistematik şekilde kurmak, cPanel/Plesk tarafında otomasyonları anlamak istiyorsanız, 3-2-1 yedekleme stratejisi rehberimizde paylaşımlı hosting ve VPS ortamları için detaylı bir kontrol listesi bulabilirsiniz.

VPS Üzerinde WordPress Yedekleme Stratejisi

VPS’e geçtiğiniz anda oyunun kuralları değişir: Daha fazla özgürlük, ama aynı oranda daha fazla sorumluluk. DCHost VPS’lerinde ister panel (cPanel, Plesk vb.) kullanın, ister tamamen elle yönetilen bir Linux ortamı tercih edin, yedekleme stratejisini artık sistem seviyesinde düşünmeniz gerekir.

Dosya ve Veritabanı için Ayrı Yedek Akışları Kurmak

VPS’te en sağlıklı yaklaşım, dosya ve veritabanı için ayrı ama koordineli yedek süreçleri tanımlamaktır.

1) Dosya Yedekleri

• WordPress kurulum dizinini (genellikle /var/www/… veya /home/kullanici/public_html) düzenli arşivleyin.
• Özellikle wp-content/ (temalar, eklentiler, uploads) ve wp-config.php kritik.
• Yedek formatı olarak tar.gz (sıkıştırılmış arşiv) yaygın ve pratiktir.

2) Veritabanı Yedekleri

• Küçük ve orta ölçekli sitelerde mysqldump ile periyodik veritabanı dökümleri yeterli olabilir.
• Daha büyük ve kritik yoğunluklu veritabanlarında tutarlı yedek ve Point-in-Time Recovery (PITR) gibi kavramlar devreye girer.

MySQL/MariaDB tarafında hangi senaryoda hangi aracı kullanmanız gerektiğiyle ilgili kafanız karışıksa, MySQL/MariaDB yedekleme stratejileri yazımızda mysqldump, XtraBackup ve PITR senaryolarını detaylıca anlattık. WordPress veritabanınız da bu prensiplerin tamamından birebir etkilenir.

Uzak Depolamaya Otomatik Senkronizasyon (rsync, rclone, restic, borg)

VPS kullandığınızda yedeklerin sadece sunucunun kendi diskinde kalması, kabul edilebilir bir risk değildir. Dosya ve veritabanı yedeklerini şu araçlarla uzak depolamaya gönderebilirsiniz:

• rsync: Sunucudan başka bir sunucuya artımlı dosya senkronizasyonu için ideal.
• rclone: S3 uyumlu depolama, bulut depolama servisleri gibi çok sayıda hedefe senkronizasyon sağlar.
• restic / borg: Deduplication, şifreleme, sürümleme gibi gelişmiş özelliklere sahip yedekleme araçlarıdır.

Bu araçlarla WordPress yedeklerinizi S3 uyumlu bir depolama alanına, başka bir DCHost VPS’ine veya tamamen farklı bir lokasyondaki yedek sunucusuna gönderebilirsiniz. Özellikle restic ve borg, artımlı yedek ve sürüm yönetimi tarafında güçlü oldukları için disk alanı tasarrufu da sağlar. Bu iki aracı S3 uyumlu bir hedefle nasıl kullanabileceğinizi merak ediyorsanız, restic ve borg ile S3 uyumlu uzak yedekleme rehberimizde adım adım bir anlatım bulabilirsiniz.

Snapshot ve Uygulama-Tutarlı Yedekler

VPS seviyesinde bir diğer güçlü yöntem de disk snapshot’larıdır. Altyapı seviyesinde alınan snapshot, o anki diskin tüm halini yakalar. Ancak burada dikkat etmeniz gereken nokta, veritabanının bu sırada yazma işlemi yapmıyor olması veya uygulama-tutarlı bir yedek yaklaşımı kullanmanızdır. Aksi halde snapshot’tan döndüğünüzde veritabanı tutarsızlıklarıyla karşılaşabilirsiniz.

Linux tarafında LVM snapshot ve fsfreeze gibi mekanizmalarla uygulama-tutarlı yedek almanın detaylarını merak ediyorsanız, WordPress’in de sıkça kullandığı MySQL/PostgreSQL gibi veritabanları için hazırladığımız uygulama-tutarlı yedekler rehberine göz atabilirsiniz.

Otomasyon: wp-cron, Gerçek Cron ve Zamanlama Stratejileri

Hem paylaşımlı hosting hem de VPS ortamında, yedeklerin “akla geldikçe” değil, tamamen otomatik alınması gerekir. Otomasyonda üç katman düşünebilirsiniz:

• WordPress içi zamanlayıcı (wp-cron): Eklentilerin çoğu buradan faydalanır.
• Sistem cron (crontab): Sunucu seviyesinde belirli komutları belirli zamanlarda çalıştırmanızı sağlar.
• Harici zamanlayıcılar: Bazı durumlarda harici bir monitoring veya otomasyon aracı da tetikleyici olabilir.

Pratik bir yaklaşım şöyle olabilir:

• Günlük dosya yedeği: Gece 02:00–04:00 arası trafiğin en az olduğu saatte.
• Saatlik veritabanı yedeği: Özellikle WooCommerce gibi dinamik sitelerde her saat başı küçük veritabanı dökümleri.
• Haftalık tam yedek + uzak senkronizasyon: Tam yedeği alıp, S3 uyumlu uzak depolamaya veya farklı sunucuya göndermek.

WordPress tarafında wp-cron kullanmaya devam edecekseniz, en azından wp-cron’u gerçek cron ile tetiklemek performans ve güvenilirlik açısından önemli bir adımdır. Detaylı adımlar ve örnek cron satırları için tekrar hatırlatalım: wp-cron ve gerçek cron job kurulum rehberimize göz atmayı unutmayın.

Geri Yükleme Stratejisi: Yedek Almak Yetmez, Dönmeyi de Bilmek Gerekir

Yedek almak tek başına güvenlik sağlamaz; geri dönüş senaryolarınızı netleştirip test etmediğiniz sürece hâlâ risk altındasınız. DCHost’ta en sık gördüğümüz hatalardan biri, yıllarca yedek alıp bir kez bile geri dönüş denemesi yapmamış WordPress siteleri.

Senaryo 1: Küçük Hatalar (Tema/Eklenti Bozulması)

Örneğin yeni bir tema güncellemesi yaptınız ve tasarım dağıldı. Bu durumda genellikle aşağıdaki adımlar yeterli olur:

• Yalnızca wp-content/themes klasörünün ilgili tema dizini için yedekten geri dönüş.
• Eğer değişiklik veritabanı ayarlarını da etkilediyse ilgili tarihli veritabanı yedeğine kısmi dönüş.

Paylaşımlı hosting’te bunu panelin dosya yöneticisi veya FTP üzerinden; VPS’te ise SSH ile dosyaları yedekten geri kopyalayarak yapabilirsiniz.

Senaryo 2: İçerik Kaybı (Yanlışlıkla Silinen Yazılar/Sayfalar)

Bu durumda genellikle sadece veritabanı seviyesinde geri dönüş yapmak istersiniz; çünkü dosyalarınız sağlamdır. İzlenebilecek yollar:

• İlgili veritabanının tamamını, içerik kaybından hemen önceki yedekten geri yüklemek.
• Eğer mümkünse, sadece ilgili tabloları (örneğin wp_posts, wp_postmeta) geri almak.

Burada dikkat: Eğer bu arada yeni siparişler alınmış bir WooCommerce siteniz varsa, eski veritabanına tam dönüş sipariş kaybına yol açabilir. Bu gibi durumlarda, tablo bazlı veya satır bazlı daha ince kontrollü geri dönüşler düşünülmelidir.

Senaryo 3: Felaket Durumları (Hack, Tamamen Silinme, Disk Arızası)

Bu, en ağır senaryodur ve genellikle şu adımlar izlenir:

1. Güvenli bir ortamda (mümkünse ayrı bir DCHost hesabında veya izole bir VPS’te) temiz bir WordPress kurulumu hazırlamak.
2. En güncel tam dosya yedeğini ve veritabanı yedeğini bu ortama geri yüklemek.
3. DNS veya panel yönlendirmelerini bu yeni ortama işaret edecek şekilde güncellemek.

Bu tür felaket senaryolarında, daha önce yazdığınız felaket kurtarma planının gerçekten işe yaradığını görmek istersiniz. Bunun için periyodik geri yükleme testleri yapmanızı kesinlikle öneriyoruz. Testleri nasıl planlayacağınız ve dokümante edeceğiniz konusunda ilham almak için, tekrar felaket kurtarma planı rehberine bakabilirsiniz.

Test Ortamları (Staging) ve Yedekten Geri Dönüş Provaları

Canlı sitenize dokunmadan, yedeklerinizi test edebileceğiniz bir staging ortamı kurmak, özellikle ajanslar ve geliştiriciler için oyunu bambaşka bir seviyeye taşıyor. DCHost üzerinde ikinci bir paylaşımlı hosting hesabı, alt domain veya ayrı bir VPS ile staging ortamı kurup, düzenli olarak:

• Üretim ortamındaki son yedeği staging’e aktarma,
• Yeni eklenti/tema denemeleri yapma,
• Yedekten geri dönüş süresini ölçme

gibi provalar yapabilirsiniz. Böylece canlı ortamda gerçekten ihtiyaç duyduğunuzda, daha önce defalarca çalışmış bir senaryoyu tekrarlamış olursunuz.

WordPress, Veritabanı ve Yedekleme Ekosistemini Birlikte Düşünmek

WordPress yedeklerini izole bir konu gibi görmek, eksik bir bakış açısı oluşturur. Aslında olay, web sunucusu, PHP, veritabanı, dosya sistemi ve ağ tarafının birlikte tasarlanmasıdır. Bu yüzden blogumuzda WordPress ve veritabanı tarafını birlikte ele aldığımız pek çok yazı var. Örneğin, veritabanı yedeklerini ciddiye alanlar için hazırladığımız MySQL/MariaDB yedekleme stratejileri yazısı, sadece veritabanı katmanında bile kaç farklı senaryo olduğunu gösteriyor.

Aynı şekilde, uzak yedekleri S3 uyumlu depolama üzerinde sürümleyebilmek için restic ve borg ile S3 uyumlu yedekleme rehberi WordPress dosyalarınızı da güvenle taşıyabileceğiniz bir altyapı sunuyor. Bu yazıları okuyup elinizdeki WordPress yedekleme stratejisini gözden geçirdiğinizde, muhtemelen “eksik halkalar” kendini göstermeye başlayacaktır.

DCHost Tarafında Neleri Sağlıyoruz, Siz Nerede Devreye Girmelisiniz?

DCHost olarak amacımız, siz WordPress sitenizi geliştirirken altyapı tarafında öngörülebilir ve dökümante edilmiş çözümler sunmak. Paylaşımlı hosting paketlerinde panel tabanlı otomatik yedekler, VPS çözümlerinde ise snapshot ve blok seviye yedekleme gibi imkanlar sunarken; sizden beklenen, bunun üzerine kendi WordPress seviyesindeki stratejinizi inşa etmeniz.

Kendinize şu soruları sorun:

• Şu an kullandığım paylaşımlı hosting veya VPS’te otomatik yedek ne sıklıkla alınıyor, nerede tutuluyor?
• WordPress içinde ek bir eklentili yedekleme katmanı kurdum mu?
• Yedeklerimin en az bir kopyası farklı bir lokasyonda mı duruyor?
• Son 6 ay içinde kaç kez geri yükleme testi yaptım?

Bu sorulardan birine bile net cevap veremiyorsanız, WordPress yedekleme stratejinizi gözden geçirmenin tam zamanıdır.

Sonuç ve Yol Haritası: Bugün Neyi Değiştirebilirsiniz?

WordPress için yedekleme konusu, kulağa sıkıcı gelebilir; ama en kritik anda geleceğinize “imza atan” başlıklardan biridir. Paylaşımlı hosting’te panel yedekleri ve eklenti tabanlı uzak kopyalarla, VPS’te ise sistem seviyesinde cron, rsync/rclone/restic akışlarıyla oldukça sağlam bir yapı kurmak mümkün. Önemli olan; ne sıklıkla yedek aldığınızı, yedeklerin nerede durduğunu ve gerektiğinde nasıl geri döneceğinizi net bir şekilde biliyor olmanız.

Bugün yapabileceğiniz somut adımlar şöyle olabilir:

• Panelinizdeki otomatik yedekleme ayarlarını ve saklama sürelerini kontrol edin.
• WordPress’e güvenilir bir yedekleme eklentisi kurup, uzak depolamaya günlük yedek alacak şekilde yapılandırın.
• VPS kullanıyorsanız, dosya ve veritabanı için ayrı cron job’lar tanımlayıp, en az bir uzak lokasyona kopya gönderin.
• Önümüzdeki hafta için bir geri yükleme testi planlayın ve sonucu mutlaka not alın.

Eğer DCHost’ta barındırdığınız bir WordPress siteniz varsa ve mevcut yedekleme stratejinizi birlikte gözden geçirmek isterseniz, destek ekibimize bilet açmanız yeterli. İş ihtiyaçlarınızı, RPO/RTO beklentilerinizi ve altyapınızı birlikte analiz edip, paylaşımlı hosting veya VPS tarafında sizin için en doğru otomatik yedek ve geri yükleme kurgusunu beraber şekillendirebiliriz.