WordPress Yedeklemelerini Güvenli Bir Şekilde Otomatikleştirme
7 Kasım 2026 tarihinde yayımlandı
Bir WordPress yedeklemesi ancak doğru verileri içeriyorsa ve işletme kesintiden etkilenmeden önce geri yüklenebiliyorsa işe yarar. WordPress yedeklemelerini güvenli bir şekilde otomatikleştirmek için hem dosyalar hem de veritabanı dışa aktarımları için zamanlama oluşturun, kopyaları üretim sunucusundan başka bir yere gönderin ve geri yüklemenin gerçekten çalıştığını doğrulayın. Başarı bildiren ancak boş bir arşiv kaydeden yedekleme işi koruma sağlamaz. Bu, cuma akşamını bekleyen son derece nazik bir sorundan ibarettir.
Eksiksiz bir WordPress yedeklemesinde neler bulunur
WordPress tek bir şeyden ibaret değildir. Site içeriğiniz, yapılandırmanız, eklentileriniz, temalarınız, yüklenen medyalarınız ve kullanıcı verileriniz dosya sistemiyle veritabanına dağılmıştır. Eksiksiz bir kurtarma için her iki taraf da gerekir.
Veritabanında yazılar, sayfalar, WooCommerce siparişleri, müşteri hesapları, form girişleri, ayarlar ve değişen diğer içerikler bulunur. Dosya sisteminde WordPress çekirdek dosyaları, eklentiler, temalar, yüklemeler ve `wp-config.php` gibi dosyalar bulunur. Yalnızca dosyaları geri yüklerseniz site, eski veya eksik içerikle açılabilir. Yalnızca veritabanını geri yüklerseniz veritabanı, mevcut olmayan dosyalara işaret edebilir.
Birçok işletme sitesi için uygulanabilir asgari düzey, günlük veritabanı yedeklemesi ve günlük tam site yedeklemesidir. E-ticaret mağazaları, üyelik platformları, rezervasyon sistemleri ve yoğun SaaS açılış sayfası ortamları, her saat yeni siparişler ve müşteri verileri gelebileceğinden veritabanlarını daha sık yedeklemeyi gerektirebilir. Yedekleme sıklığı, neyin uygun hissettirdiğine değil, gerçekçi olarak ne kadar veri kaybetmeyi göze alabileceğinize göre belirlenmelidir.
Otomasyon için doğru katmanı seçin
WordPress yedeklemelerini otomatikleştirmenin üç yaygın yolu vardır: WordPress yedekleme eklentisi, barındırma kontrol paneliniz veya yönetilen hizmet ve sunucu düzeyindeki işler. Hiçbiri her koşulda en iyi seçenek değildir. Doğru seçim; sunucuyu kimin yönettiğine, sitenin ne kadar büyük olduğuna ve ne kadar hızlı kurtarma yapmanız gerektiğine bağlıdır.
Eklenti tabanlı yedeklemeler
Küçük bir site için eklenti genellikle en basit seçenektir. Kabuk erişimi olmadan arşivler oluşturabilir, işler için zamanlama yapabilir ve yedeklemeleri uzak depolama alanına gönderebilir. Bu yöntem site sahiplerine doğrudan görünürlük sağlar ve barındırma planında yedekleme hizmeti bulunmadığında işe yarar.
Bunun karşılığında sunucu yükü artar. Site ziyaretçilere hizmet verirken büyük bir medya kitaplığını sıkıştırmak CPU, bellek, disk G/Ç ve PHP çalışanları tüketebilir. Yoğun kullanılan bir paylaşımlı ortamda veya küçük bir VPS'te yedekleme işleri zaman aşımına uğrayabilir ya da ödeme sayfalarını yavaşlatabilir. Mümkünse işi trafiğin az olduğu saatlere ayarlayın ve zamanlamanın sorunsuz olduğunu varsaymak yerine ilk birkaç çalıştırmayı izleyin.
Barındırma veya yönetilen yedeklemeler
Barındırma düzeyindeki yedeklemeler WordPress dışında çalışır. Bu, eklenti arızası, kötü amaçlı yazılım olayı veya ters giden bir WordPress güncellemesi sırasında genellikle daha güvenlidir. Yönetilen bir yedekleme sistemi, site uygulamasının sağlıklı kalmasına bağlı olmadan veritabanlarını ve dosyaları yedekleyebilir.
Bu yaklaşım WordPress içindeki hareketli parça sayısını azaltır ve genellikle altyapı düzeyinde geri yüklemeyi kolaylaştırır. Yedekleme eklentilerini, zamanlamaları, depolama kimlik bilgilerini ve uyarı kurallarını kendileri yönetmek istemeyen işletmeler için yönetilen barındırma yedeklemeleri daha rahat bir seçenektir. Kodu.cloud'da bu tür operasyonel işler, kimsenin hoşlanmadığı aylık bir hatırlatmaya bırakılmak yerine sunucu izleme ve destek hizmetleriyle birlikte yürütülebilir.
Sunucu düzeyinde yedeklemeler
Bir VPS veya özel sunucu size daha fazla kontrol olanağı sunar. Veritabanlarını dışa aktarmak, uygulama dosyalarını arşivlemek, sonucu şifrelemek ve bağımsız bir depolama konumuna aktarmak için zamanlanmış görevlerden yararlanabilirsiniz. Geliştiriciler ve ajanslar bunu sıkça tercih eder; çünkü her siteye göre zamanlamalar, saklama süreleri, hariç tutulanlar ve günlükler özelleştirilebilir.
Daha fazla kontrol, daha fazla sorumluluk da demektir. Yedekleme betiğinde hata yönetimi, yeterli disk alanı, izinler, depolama izleme ve geri yükleme belgeleri bulunmalıdır. Üç hafta boyunca sessizce başarısız olan zamanlanmış bir komut, ciddiye alınmayı gerektirecek kadar yaygın bir durumdur.
Kurtarma ihtiyaçlarınıza göre yedekleme zamanlaması oluşturun
İki soruyla başlayın: İşletme yakın zamandaki ne kadar veriyi kaybedebilir ve site ne kadar süre kullanılamaz durumda kalabilir? Bunlar kurtarma noktası hedefiniz ve kurtarma süresi hedefinizdir. Bir toplantıda bu kısaltmaları kullanmanız gerekmez, ancak yanıtları bilmelisiniz.
Ayda iki kez değişen tanıtım amaçlı bir site, günlük yedeklemeler ve 14 ila 30 günlük saklama süresiyle yeterince korunabilir. İçerik ağırlıklı bir ajans sitesi, günlük tam yedeklemelerin yanı sıra büyük güncellemelerden önce alınan bir yedeklemeden de yararlanabilir. WooCommerce mağazaları daha fazla özen gerektirir: Gün boyunca siparişler kaydediliyorsa yalnızca günlük dosya yedeklemeleri yeterli olmaz.
Faaliyette olan bir mağaza için saatlik veya birkaç saatte bir veritabanı yedeklemesi, günlük dosya sistemi yedeklemesi ve WooCommerce'i, ödeme eklentilerini, temaları ya da WordPress çekirdeğini değiştirmeden önce bir yedekleme almayı değerlendirin. Yalnızca tek bir yedekleme nesli saklamaktan kaçının. Bozulma, spam veya kötü amaçlı yazılım siteye birkaç gün önce girdiyse dünkü yedeklemede de aynı sorun bulunabilir.
Saklamanın bir maliyeti vardır. Daha fazla geri yükleme noktası daha fazla depolama alanı, aktarım kapasitesi ve bakım gerektirir. Makul bir politika genellikle yakın zamandaki birkaç günlük kopyayı, birkaç haftalık kopyayı ve az sayıda aylık kopyayı saklar. Kesin sayılar siteye ve uyumluluk gereksinimlerine bağlıdır, ancak temel ilke değişmez: Geç fark edilen bir sorundan kurtulmaya yetecek kadar geçmiş veriyi saklayın.
En az bir kopyayı üretim sunucusunun dışında saklayın
Web sitesinin yanında saklanan bir yedeklemeyi olağanüstü durum kurtarma planı olarak görmeyin. Sunucu diski arızalanırsa, bir hesap silinirse, fidye yazılımı bağlı depolama alanına ulaşırsa veya fazla özgüvenle çalıştırılan bir temizlik komutu devreye girerse üretim verileriyle yedekleme birlikte kaybolabilir.
Bağımsız kimlik bilgilerine ve tercihen farklı bir arıza alanına sahip ayrı bir yedekleme depolama alanı kullanın. Bu alan nesne depolama, bir yedekleme sunucusu veya başka bir sağlayıcı olabilir. Müşteri kayıtları, hesap verileri veya özel yüklemeler içeren arşivleri aktarmadan önce şifreleyin. Şifreleme anahtarlarını ve depolama kimlik bilgilerini web kök dizininden ve depodan ayrı bir yerde koruyun.
Bilinen 3-2-1 ilkesi hâlâ kullanışlıdır: Önemli verilerin üç kopyasını, iki farklı depolama türünde tutun ve kopyalardan birini site dışında saklayın. Bunun için bir tören düzenlemeniz gerekmez. Bu, yalnızca kötü bir olayın tam bir kayba dönüşmesini önlemenin bir yoludur.
Yedeklenmesi gerekmeyenleri hariç tutun
Büyük önbellekler, geçici dosyalar, hata ayıklama günlükleri, dağıtım çıktıları ve oluşturulmuş görsel önbellekleri, kurtarmayı iyileştirmeden yedeklemeleri yavaşlatıp maliyeti artırabilir. Güvenli bir şekilde yeniden oluşturulabildikleri sürece bu dosyaları hariç tutmak genellikle mantıklıdır.
Yüklemeler konusunda dikkatli olun. `wp-content/uploads` dizini genellikle ürün görsellerini, belgeleri, kullanıcı gönderilerini ve medya kitaplığı dosyalarını içerir. Bu dizin normalde yedeklemede tutulmalıdır. Özel uygulama dizinleri, standart dışı eklenti depolama alanları ve WordPress kök dizininin dışındaki dosyalar da incelenmelidir. Bir geliştirici, kritik varlıkları şaşırtıcı bir yere koymuş olabilir. Ne yazık ki sunucu zihin okuyamaz.
Hariç tutma listesini kesinleştirmeden önce arşiv içeriğini, uygulamanın temiz bir geri yüklemeden sonra ihtiyaç duyduklarıyla karşılaştırın. Daha küçük bir yedekleme, ancak işletmenin çalışır hâle gelmesini sağlıyorsa iyidir.
Yedekleme hatalarını görünür kılın
Raporlama olmadan otomasyon, otomasyonun yalnızca bir kısmıdır. Başarısız işler, tamamlanmayan aktarımlar, yetersiz depolama alanı, olağandışı küçük arşivler ve ilkenizde belirtilen saklama süresini aşan yedekleme yaşı için uyarılar yapılandırın. Küçük bir ortamda e-posta yeterli olabilir; ancak birden fazla müşteri sitesinden sorumlu ekipler için izlenen bir uyarı kanalı daha iyidir.
Kurulumdan sonra ve PHP, WordPress, veritabanı sürümleri, depolama kimlik bilgileri veya dosya sistemi izinlerinde önemli değişiklikler yapıldığında günlükleri kontrol edin. Başarılı bir yedeklemenin zaman damgası, beklenen boyut aralığı, hedef onayı ve saklama sonucu açıkça belirtilmelidir.
Kaynak sunucudaki kullanılabilir disk alanını da izleyin. Bazı araçlar, yüklemeden önce arşivin tamamını yerel olarak oluşturur. Diski neredeyse dolu olan bir sunucu, yedekleme sırasında arızalanabilir ve aynı anda performans sorunlarına yol açabilir. Bu, disk açısından en hoş durum değil ama önlenebilir.
Acil durumdan önce geri yüklemeleri test edin
Yedekleme iddialarının operasyonel gerçeğe dönüştüğü nokta, geri yükleme testidir. En az üç ayda bir, yakın tarihli bir kopyayı hazırlık ortamına veya ayrı bir geçici konuma geri yükleyin. WordPress'in başlatıldığını, veritabanı bağlantısının kurulduğunu, medyaların yüklendiğini, kullanıcıların oturum açabildiğini ve önemli işlevlerin çalıştığını doğrulayın.
Çevrimiçi bir mağazada ürün sayfalarını, sepet davranışını, ödeme ayarlarını, sipariş kayıtlarını, işlemsel e-posta yapılandırmasını ve ödeme eklentisi bağımlılıklarını test edin. Geri yüklenen kopyayı, gerçek müşterilere e-posta gönderebileceği veya canlı ödeme alabileceği bir yere koymayın. Önce test ortamında giden e-postayı ve ödeme işlemlerini devre dışı bırakın.
Geri yükleme sırasını işlemi yaparken belgeleyin. Yedeklemenin nerede saklandığını, hangi veritabanının içe aktarılması gerektiğini, yapılandırma değerlerinin nerede değiştirileceğini ve DNS'in ya da uygulama URL'lerinin nasıl ele alınacağını kaydedin. Gerçek bir kesinti sırasında kısa ve güncel bir çalışma kılavuzu, herhangi birinin hafızasından daha çok zaman kazandırır.
Yedekleme sürecinin kendisini koruyun
Yedekleme verilerini yazmak ve okumak için gereken izinlerle sınırlı, özel depolama kimlik bilgileri kullanın. Depolama hesabında ve barındırma kontrol panelinde çok faktörlü kimlik doğrulamayı etkinleştirin. WordPress'i, eklentileri, sunucu paketlerini ve yedekleme araçlarını güncel tutun; güvenliği ihlal edilmiş bir site, erişilebilen yedekleme kimlik bilgilerini de hedef alabilir.
Yedeklemeleriniz şifreliyse geri yükleme tatbikatları sırasında şifre çözmeyi test edin. Doğru anahtar olmadan şifrelenmiş bir arşiv son derece güvenlidir ve son derece işe yaramazdır. Kurtarma talimatlarını, üretim sunucusu kullanılamadığında da erişilebilir kalacak korumalı bir konumda saklayın.
Otomatik yedeklemeler iş yükünüzü azaltmalı, riskleri yeşil bir durum rozeti ardına gizlememelidir. Zamanlamayı belirleyin, kopyaları site dışında saklayın, işleri izleyin ve hizmet yeniden sakinken geri yükleme sürecini prova edin. Böylece WordPress'te değişiklik yaparken çok daha emin olabilirsiniz.
Andres Saar, Müşteri Hizmetleri Mühendisi