WooCommerce yedeği başarıyla tamamlanmış görünse bile geri yükleme için güvenli olmayabilir. Dosyalar öğlen kopyalanıp veritabanı iki saat sonra alındığında yeni siparişler, ödeme bildirimleri, stok değişiklikleri ve abonelik yenilemeleri aynı kurtarma noktasına ait olmaz.
Amaç, mağazanın tutarlı bir anlık görüntüsünü almak ve yedek sürerken kabul edilen işlemler için açık bir plan oluşturmaktır. Ödeme sağlayıcıları, Action Scheduler, stok sistemi ve webhook trafiği bu planın parçasıdır.
Bu konu ne anlama gelir?
İşlem bütünlüğünü koruyan bir WooCommerce yedeği; veritabanını, ilgili dosyaları ve bekleyen işleri açıklanabilir tek bir kurtarma noktasında bir araya getirir. Bu noktadan sonra gerçekleşen işlemler de ayrıca kaydedilir; böylece geri yükleme sırasında yeni siparişlerin üzerine yazılmaz.
Başlamadan önce kabul edilebilir veri kaybını, ödeme sayfasının kısa süreli kapatılıp kapatılamayacağını, stok için hangi sistemin esas olduğunu ve ödeme kayıtlarını kimin karşılaştıracağını belirleyin.
Gerçekçi bir WordPress örneği
Bir mağaza saat 12.00’de 80 GB yükleme dosyasını kopyalamaya başlıyor. Veritabanı ise onlarca yeni sipariş ve ödeme bildirimi geldikten sonra, 14.00’te dışa aktarılıyor. Bu iki dosya birlikte geri yüklendiğinde, gerçekte hiç var olmamış karma bir mağaza durumu ortaya çıkıyor.
Daha güvenli yöntemde değişmeyen dosyalar önceden kopyalanır; veritabanı ve son dosya değişiklikleri kısa, kontrollü bir yazma aralığında alınır. Seçilen noktadan sonraki tüm işlemler ayrıca kaydedilir.
Neden önemlidir ve ne zaman kullanılır?
Bu yöntem güncelleme, taşıma, altyapı çalışması ve olay kurtarma öncesinde önemlidir. Tutarsız bir yedek; sipariş kaybına, webhook’ların yeniden çalışmasına, hatalı stoklara veya tamamlanmış ödemelerin üzerine dönülmesine yol açabilir.
Abonelik, harici stok sistemi, kargo entegrasyonu ya da asenkron ödeme akışı kullanan mağazalarda risk daha yüksektir. Nadiren değişen bir katalog için basit yedek yeterli olabilir; aktif satış yapan bir mağaza için çoğu zaman yeterli değildir.
Yeni başlayanlar için anlaşılır yol
- Kurtarma noktasını belirleyin ve ödeme sayfasının kısa süreli durup durmayacağına karar verin. Müşteriye ve destek ekibine verilecek bilgiyi de netleştirin.
- Değişmeyen dosyaları önceden kopyalayın. Ardından kontrollü aralıkta tutarlı veritabanı çıktısını ve son değişen dosyaları alın.
- Bu noktadaki sipariş, ödeme, iade, abonelik, stok ve bekleyen Action Scheduler işi sayılarını kaydedin.
- Yedeği e-posta, ödeme ve webhook bağlantıları kapalı yalıtılmış bir ortamda geri yükleyin. Kayıtları karşılaştırın ve güvenli bir test siparişi tamamlayın.
- Geçiş ve mutabakat bitene kadar eski mağazayı ve kurtarma noktasından sonra kabul edilen tüm işlemleri koruyun.
İleri teknik yol
Yoğun mağazalarda işlem tutarlılığı sağlayan bir veritabanı yöntemi kullanın ve ödeme sağlayıcısındaki işlem kimliklerini WooCommerce siparişleriyle eşleştirin. Kuyrukları planlı biçimde durdurun ya da boşaltın, webhook işlemlerini idempotent tasarlayın ve stok için yetkili sistemi önceden belirleyin.
Kurtarma noktasından sonraki yazmaların kaydı, gerçek bir geri dönüşte hangi işlemlerin birleştirileceğini gösterir. Test mağazasının canlı ödeme sistemine, kargoya veya müşterilere ulaşmasını mutlaka engelleyin.
Riskler, sık hatalar, yedekleme ve geri alma
En tehlikeli hata, en yeni arşivi mağazanın eksiksiz bir iş kaydı sanmaktır. Dosya ile veritabanı arasındaki saat farkı, alınmamış Action Scheduler kuyruğu, test ortamındaki canlı erişim bilgileri veya yanlış kaynaktan yüklenen stok verisi ciddi zarara yol açabilir.
Geri yükleme sınanmadan ve daha yeni siparişler için onaylı bir mutabakat planı hazırlanmadan canlı mağazanın üzerine yazmayın. İşlem sınırı belirsizse ya da ödeme ve stok sorumluları sonraki hareketleri eşleştiremiyorsa mevcut sistemi koruyup durun.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, desteklenen WordPress yedekleme ayarlarını ve işlemlerini tek yerde izlemeye yardımcı olur. WooCommerce için dosya ve veritabanı kapsamını, hedefi, zamanlamayı, saklama politikasını ve sorumlu kişiyi iş başlamadan belirleyin. Başarılı iş durumu yararlı bir işletim bilgisidir; mağazadaki işlemlerin tutarlı olduğunu tek başına kanıtlamaz.
Yedeği; seçilen sipariş sınırı, son dosya değişiklikleri, kuyruk durumu ve daha sonra gerçekleşen işlemlerin kaydıyla birlikte değerlendirin. Paketi yalıtılmış ortamda geri yükleyin; e-posta, ödeme ve webhook bağlantılarını kapatın. Ardından siparişleri, iadeleri, abonelikleri, stokları ve zamanlanmış işleri dış sistemlerle karşılaştırın.
Yedekleme Yöneticisi harici hizmetleri durduramaz, üçüncü taraf depolamanın sürekliliğini garanti edemez ve yeni siparişlerin nasıl birleştirileceğine karar veremez. Bunlar mağazanın kurtarma planında tanımlanmalıdır. Son doğrulanmış kurtarma noktasını koruyun; yedek dosyasını, hedefi, zamanları, test sonucunu ve bir sonraki geri yükleme testini kaydedin.
AIOWS Yedekleme Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Sitesi Yedekleme: Dosya ve Veritabanı Rehberi
- Güncellemeden Önce WordPress Yedeği Alıp Hızlı Geri Dönme
- WordPress Felaket Kurtarma Planı: Tam Kontrol Listesi
Sonuç ve önerilen yol
Net bir işlem sınırı, tutarlı veritabanı çıktısı, son dosya ve kuyruk değişiklikleri ile sonraki siparişlerin kaydı birlikte tutulmalıdır. Geri yüklemeyi dış bağlantılar kapalıyken sınayın; yeni işlemler için onaylı bir plan olmadan canlı mağazayı eski duruma döndürmeyin.
