47 Dakikada E-ticaret Yedek Kurtarma Örneği
6 Ağustos 2026'da yayımlandı
Başarısız bir eklenti dağıtımı, küçük bir çevrimiçi perakendecinin ödeme sayfasını 09:13'te çevrimdışı bıraktı. Bu e-ticaret yedek kurtarma örneği, operasyon ekibinin neyi geri yüklediğini, neyi geri yüklemediğini ve mağazanın geçerli müşteri satın alımlarını sessizce silmeden neden 10:00'a kadar yeniden sipariş kabul ettiğini gösterir.
İlk belirti, ödeme sayfasında bir 502 hatasıydı; kategori sayfaları ise önbellekten yüklenmeye devam ediyordu. Sunucu izleme, CPU, bellek ve disk kullanımının normal olduğunu gösterdi. Bunun yerine günlükler, yeni ödeme eklentisi dosyalarının getirdiği kritik bir PHP hatasına işaret etti. Bu ayrım önemlidir. Canlı veritabanı hâlâ sipariş kaydetmeye devam ediyorsa, bir sunucuyu yeniden başlatmak veya her şeyi bir yedekten geri yüklemek kötü bir durumu daha da kötüleştirebilir.
Olay: dağıtımdan sonra ödeme sayfası hatası
Perakendeci, WordPress ve WooCommerce mağazasını barındıran bir VPS çalıştırıyordu; ayrıca ayrı bir veritabanı hizmeti ve otomatik gecelik yedekler kullanıyordu. Dağıtımdan önce ekip ayrıca isteğe bağlı bir anlık görüntü oluşturdu. Ödeme sayfası, önceki gecelik yedek ile başarısız güncelleme arasında yedi başarılı sipariş işlemişti.
09:18'de teknisyen mağazayı bakım moduna aldı ve ödeme işleyicisi webhook'larının hâlâ gelmekte olduğunu doğruladı. Bu, mutabakat için gerekli kanıtları korurken müşterilerin bozuk ödeme sayfalarını görmesini engelledi. İlk iş geri yükleme değildi. İlk iş, olayın şekil değiştirmesini durdurmaktı.
Herhangi bir geri alma işleminden önce mevcut veritabanının bir kopyası dışa aktarıldı. Erişim günlükleri, PHP hata günlükleri ve ödeme webhook kayıtları da saklandı. Bu dosyalar, hangi siparişlerin dağıtımdan önce var olduğunu ve hangilerinin sonra geldiğini belirlemeyi mümkün kıldı.
E-ticaret yedek kurtarma örneği: kurtarma yolu
Kurtarma, seçici bir yaklaşım kullandı. Ekip, zarar görmüş uygulama dosyalarını 09:05 anlık görüntüsünden geri aldı, ancak tüm veritabanını hemen geri yüklemedi. Veritabanının bir önceki geceye tam geri alınması, o sabah verilen yedi geçerli siparişi silmiş olurdu. Müşteriler ödeme onayları alırdı, ancak mağazada satın alımlarının kaydı bulunmazdı. Bu, kesinti olarak başlayıp destek kuyruğuna dönüşen sorun türüdür.
1. Yalnızca uygulama katmanını geri yükleyin
09:24'te teknisyen, etkilenen eklenti dizinini, tema dosyalarını ve dağıtım yapılandırmasını temiz değişiklik öncesi anlık görüntüden geri yükledi. Veritabanı canlı kalmaya devam etti ancak bakım modunun arkasına alındı. Geri yüklemeden sonra dosya izinleri ve sahipliği kontrol edildi, çünkü yanlış izinlerle geri yüklenen doğru bir dosya hâlâ çalışan bir düzeltme değildir.
Geri yüklenen kod temel bir PHP sözdizimi denetiminden geçti. Kritik hata uygulama günlüklerinden kayboldu ve ödeme sayfası uç noktası, staging tarzı bir testte geçerli bir yanıt döndürdü. Hizmet yeniden sakindi, ancak henüz müşterilere açılmadı.
2. Ödeme sayfasını açmadan önce canlı veritabanını doğrulayın
Ekip, üç kaynak arasında sipariş kimliklerini, işlem referanslarını, zaman damgalarını ve ödeme durumunu karşılaştırdı: WooCommerce siparişleri, veritabanı kayıtları ve ödeme işleyicisinin işlem günlüğü. Yedi ödenmiş sipariş mevcuttu ve eksiksizdi. Veritabanında iki terk edilmiş sepet göründü ancak kesinleşmiş ödemeleri yoktu, bu nedenle kurtarma çalışması gerektirmediler.
Bu adım genellikle baskı altında atlanır. Atlanmamalıdır. Yedek, bir kurtarma noktasıdır; o noktadan sonra oluşturulan her öğenin otomatik olarak yeniden oluşturulabileceğine dair bir söz değildir. E-ticarette, ödeme sayfası yeniden canlıya alınmadan önce veritabanı ile ödeme sağlayıcısının aynı hikâyeyi anlatması gerekir.
3. Önbellekleri temizleyin ve müşteri yolculuğunu test edin
09:43'te ekip, ödeme sayfasıyla ilgili sayfalar için uygulama önbelleğini, PHP opcode önbelleğini ve CDN önbelleğini temizledi. Ardından tam yolu test ettiler: ürün sayfası, sepet, kargo hesaplaması, kupon doğrulaması, ödeme sayfası, ödeme yetkilendirmesi, onay e-postası ve sipariş oluşturma.
Yalnızca sunucu tarafından test etmek yeterli değildir. Bir sayfa HTTP 200 döndürebilirken tarayıcı hâlâ eski JavaScript'i veya önbelleğe alınmış ödeme sayfası parçalarını alıyor olabilir. Ekip, gerçek alıcı deneyimini doğrulamak için temiz bir tarayıcı oturumu ve test ödeme yöntemi kullandı.
4. Mağazayı yeniden açın ve ilk işlemleri izleyin
Ödeme sayfası 09:55'te yeniden açıldı. İlk canlı sipariş 09:57'de tamamlandı ve beklendiği gibi e-ticaret platformunda, veritabanında ve ödeme işleyicisinde göründü. İzleme odaklı kaldı ve sonraki bir saat boyunca PHP hatalarına, yanıt sürelerine, başarısız ödeme sayfası isteklerine, veritabanı bağlantılarına ve disk alanına odaklandı.
10:00'da perakendeci yeniden iş başındaydı. Müşterinin gördüğü toplam ödeme sayfası kesintisi 47 dakikaydı. Ekip, herhangi bir şeye dokunmadan önce hatalı katmanı belirlediği ve mevcut sipariş verilerini koruduğu için mağaza tam sunucu geri yüklemesine ihtiyaç duymadı.
Neden tam geri yükleme ilk yanlış adımdı
Tam bir VM veya veritabanı geri yüklemesi bazen doğru yanıttır. Bu, genellikle fidye yazılımı, büyük veri bozulması, yanlışlıkla toplu silme veya hem dosyalara hem de verilere zarar veren başarısız bir yükseltmeden sonra uygundur. Mağaza tamamen durdurulmuşsa ve kurtarma noktasından bu yana yeni işlem gerçekleşmemişse bu aynı zamanda en hızlı seçenek olabilir.
Ancak bunun bir bedeli vardır: yedek zaman damgasından sonra oluşturulan tüm veriler geri yüklenen ortamdan kaybolabilir. Bir e-ticaret sitesi için buna siparişler, müşteri hesapları, envanter değişiklikleri, destek talepleri, ürün düzenlemeleri ve ödeme olayları dahil olabilir.
Asıl daha iyi soru, “Yedeğimiz var mı?” değildir. Şudur: “Hangi katman arızalandı ve yedekten bu yana ne değişti?” Pratik bir kurtarma planı; uygulama dosyalarını, veritabanlarını, yüklemeleri, yapılandırmaları ve harici hizmetleri birbirinden ayırır. Bu, sağlıklı iş faaliyetlerini geri almadan bozuk kısmı kurtarmayı mümkün kılar.
Kurtarmayı mümkün kılan şeyler
Bu olay iyi sonuçlanmasını şansa borçlu değildi. Dört operasyonel tercih kurtarma süresini azalttı ve geliri korudu:
- Planlanmış yedeklerin yanında değişiklik öncesi bir anlık görüntü mevcuttu; bu da ekibe yalnızca birkaç dakikalık temiz bir uygulama kurtarma noktası sağladı.
- Geri almadan önce veritabanı dışa aktarımları ve ödeme kayıtları alındı; böylece mevcut işlem durumu korundu.
- İzleme, altyapı kaynaklarının sağlıklı olduğunu gösterdi ve incelemeyi VPS'nin kendisinden ziyade dağıtıma daralttı.
- Ekibin tanımlı bir bakım prosedürü vardı; bu nedenle ödeme sayfası yarı çalışır durumda bırakılmak yerine bilinçli olarak duraklatıldı.
Burada bir ödünleşim vardır. Daha sık yedekleme depolama tüketir ve özellikle yoğun veritabanları için ek yük getirebilir. Anlık görüntüler hızlı olabilir, ancak üretim sunucusundan ayrı depolanan bağımsız yedeklerin yerine geçmezler. Mantıklı bir politika normalde günlük saklanan yedekleri, aktif mağazalar için daha sık veritabanı yedeklerini ve güncellemeler veya içe aktarmalardan önce isteğe bağlı bir anlık görüntüyü birleştirir.
Kurtarma planını yalnızca sunucuların değil, gelirin etrafında oluşturun
Bir tanıtım sitesi için dün geceki yedeği geri yüklemek zahmetli olabilir ama kabul edilebilir. E-ticaret için kurtarma hedefleri gelir ve müşteri verilerine dayanmalıdır. İşletmenin kaç dakikalık sipariş verisi kaybını karşılayabileceğini, ödeme sayfasının ne kadar hızlı geri dönmesi gerektiğini ve mağaza sahibi müsait olmadığında geri almayı kimin onaylayabileceğini sorun.
Yanıtları sade bir dille belgeleyin. Yedeklerin nerede depolandığını, hosting paneline nasıl erişileceğini, hangi hizmetlerin duraklatılması gerektiğini, ödeme işlemlerinin nasıl mutabık hâle getirildiğini ve siparişler gecikirse müşterilerle kimin iletişim kuracağını ekleyin. Yedeğin kullanılabilir olduğunun kanıtı olarak yakın tarihli bir test geri yüklemesi bulundurun. Hiç test edilmemiş bir yedek, daha çok nazik bir teoridir.
Yönetilen VPS altyapısında çalışan mağazalar için yükseltme noktalarını tanımlamak da yardımcı olur. Disk kullanımı keskin şekilde artarsa, yedeklemeler başarısız olursa, veritabanı gecikmesi yükselirse veya dağıtım hataları tekrarlanırsa, hosting ekibi küçük bir arızanın uzun bir akşama dönüşmesinden önce harekete geçmek için yeterli erişime ve bağlama sahip olmalıdır.
kodu.cloud'da yönetilen yedek seçenekleri, sunucu izleme ve teknisyen desteği; operasyonların bu pratik yönü için tasarlanmıştır: neyin değiştiğini bilmek, doğru bileşeni geri yüklemek ve onarım sürerken müşteri verilerini önünüzde tutmak.
Bir sonraki faydalı eylem basittir: bir sonraki büyük mağaza güncellemenizden önce bir kurtarma testi planlayın. Bir kopyayı geri yükleyin, bir test siparişi verin, e-posta ve ödeme kayıtlarını doğrulayın, ardından süreyi not edin. Gerçek bir olay yaşandığında, günlükler aynı hikâyeyi anlatıyorsa sükûneti korumak çok daha kolay olur.
Andres Saar Müşteri Hizmetleri Mühendisi