Bir bakım aralığında WordPress çekirdeği, sayfa oluşturucu ve on iki eklenti aynı anda güncelleniyor. Yedek başarılı görünüyor; ancak eski sürümler kaydedilmemiş, veritabanı migration’ı çalışmış ve geri dönüş planı yalnızca eski eklenti klasörlerini değişen veritabanının üzerine kopyalamaktan ibaret.
Güncelleme öncesi yedek, tanımlı bir değişiklik paketiyle ve sınanmış kurtarma kararıyla birlikte hazırlanmalıdır. Doğru dosya ve veritabanı durumunu korumalı; sürümleri, bağımlılıkları ve hangi durumda eski yedeğe dönmek, hangi durumda sorunu mevcut sürüm üzerinde düzeltmek gerektiğini göstermelidir.
Bu konu ne anlama gelir?
Güncelleme öncesi yedek, belirli bir yazılım değişikliğinden hemen önce alınan eşleşmiş kurtarma noktasıdır. Veritabanını, gereken dosyaları, bileşenlerin tam sürümlerini ve önceki durumu yeniden kurmak için gereken yapılandırma bilgilerini kapsar.
Bu paket her sürüm düşürmeyi güvenli hâle getirmez. Veritabanı migration’ları, bekleyen işler, üretilmiş dosyalar ve dış hizmetlerdeki değişiklikler ayrıca geri alınmalı veya ileri yönde düzeltilmelidir.
Gerçekçi bir WordPress örneği
Bir yönetici çekirdeği, tema altyapısını ve tüm eklentileri topluca güncelliyor. Ardından ödeme sayfası çalışmıyor; hangi bileşenin veritabanını değiştirdiği ve eski paketlerden hangisinin siteye ait olduğu bilinmiyor. Sadece eklenti klasörlerini geri kopyalamak, yeni şemayı yerinde bırakıyor.
Kontrollü süreçte önce sürümler ve bağımlılıklar kaydedilir. Cron ve kuyruk işleri tamamlandıktan sonra dosyalarla veritabanı birlikte yedeklenir; ardından en küçük anlamlı bileşen grubu güncellenip test edilir.
Neden önemlidir ve ne zaman kullanılır?
Dosyaları, veritabanı şemasını, arka plan işlerini veya kritik kullanıcı akışlarını etkileyebilecek çekirdek, tema, eklenti, PHP ve altyapı güncellemelerinden önce bu yedeği alın. Hızlı geri dönüş ancak paket erişilebilirse ve durma koşulları önceden kararlaştırılmışsa mümkündür.
Küçük bir yamada bileşenin eski sürümüne dönmek yeterli olabilir. Yeni müşteri verisi oluştuysa, geri alınamayan migration’lar çalıştıysa veya dış sistemlerde işlem gerçekleştiyse bütün siteyi eski yedeğe döndürmek daha büyük risk yaratabilir.
Yeni başlayanlar için anlaşılır yol
- Güncellenecek bileşenleri ve sürümlerini listeleyin; gereksinimleri ve sürüm notlarını inceleyin.
- Cron ve kuyruk işlerinin tamamlanmasını bekleyin. Dosyalarla veritabanını aynı noktada yedekleyip paketi değişecek sunucunun dışında saklayın.
- Arşivin açıldığını doğrulayın; mümkünse yalıtılmış bir ortamda geri yükleyin.
- En küçük anlamlı bileşen grubunu güncelleyin. Giriş, editör, canlı sayfalar, formlar, e-posta, zamanlanmış işler ve ana iş akışını sınayın.
- Önceden belirlenen koşul oluşursa durun. Gerçek değişikliğe göre geri yükleme, önceki sürüme dönme veya sorunu mevcut sürümde giderme seçeneklerinden uygun olanı seçin.
İleri teknik yol
Staging ortamında üretimdeki PHP sürümünü ve veri yapısını kullanın; veritabanı migration loglarını saklayın. Büyük güncellemeleri aşamalı yayımlayın, cache dosyalarını sürümleyin ve kuyrukları kontrollü biçimde boşaltın. Her bileşen için ayrı kurtarma seçeneği belirleyin.
Güncelleme öncesi ve sonrası sürüm ile şemayı karşılaştırın. Süre tutulan kurtarma provasında yönetim panelini, canlı şablonları, oturum açmayı, formları, e-postayı, cron’u ve önemli işlemleri test edin. Eski paketleri, ilgili arka plan işleri de sorunsuz tamamlanana kadar silmeyin.
Riskler, sık hatalar, yedekleme ve geri alma
Yedeği aynı sunucuda tutmak, özel kodu veya must-use eklentileri atlamak, ilgisiz bileşenleri birlikte güncellemek ve eski dosyaların veritabanı migration’ını geri alacağını sanmak sık yapılan hatalardır. Aktif arka plan işleri de yarım güncellenmiş sisteme veri yazabilir.
Daha yeni siparişlerin veya kullanıcı verilerinin üzerine, mutabakat planı olmadan eski yedeği dönmeyin. Paket eksikse, önceki sürümler bilinmiyorsa, geri yükleme sınanmamışsa ya da durma koşulları net değilse güncellemeyi erteleyin.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, güncelleme öncesindeki WordPress yedek kapsamını, hedefi, zamanlamayı ve saklama ayarlarını tek yerde görmeyi sağlar. Belirli değişiklik paketi için dosyalarla veritabanını eşleşen tek kurtarma noktasında alın ve yedeği, site ya da sunucu arızalansa da erişilebilecek bir hedefte tutun.
İşin başarıyla tamamlandığını gösteren durum bilgisini ilk kontrol olarak kullanın; ardından yedek dosyasını ayrıca doğrulayın. İlgili WordPress, PHP, tema, eklenti ve özel kod sürümlerini kaydedin ve geri yükleme yolunu yalıtılmış ortamda sınayın. Güncellemeden sonra beklenen sürümleri ve hata kayıtlarını kontrol edip belirlenen kullanıcı senaryolarını sınayın.
Yedekleme Yöneticisi bir veritabanı migration’ının geri alınıp alınamayacağına karar veremez, tüm dış sistem etkilerini durduramaz ve geri yükleme testi olmadan kurtarmayı kanıtlayamaz. Son doğrulanmış paketi gözlem süresince koruyun. Test başarısız olursa eski dosyaları körlemesine kopyalamak yerine bileşene göre geri yükleme, önceki sürüme dönme veya sorunu mevcut sürüm üzerinde giderme planını uygulayın.
AIOWS Yedekleme Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Sitesi Ne Sıklıkla Yedeklenmeli?
- Yeni Siparişleri Kaybetmeden WooCommerce Mağazasını Yedekleme
- WordPress Sitesini Minimum Kesintiyle Kontrollü Taşıma
Sonuç ve önerilen yol
Tanımlı güncelleme paketi için sürümleri belli, eşleşmiş ve site dışında saklanan tek bir kurtarma noktası hazırlayın. En küçük anlamlı bileşen grubunu değiştirin, kritik akışları sınayın ve kurtarma kararını dosya, şema ve veri üzerindeki gerçek değişikliğe göre verin.
