Yedekten Kurtarma Vaka İncelemesi: 6 Saat Geri
10 Temmuz 2026 tarihinde yayımlandı
Saat 02:14 UTC'de, vitrin veritabanına sipariş yazmayı durdurdu. Saat 02:19 itibarıyla site hâlâ önbelleğe alınmış sayfaları sunuyordu, ancak ödeme süreci çoktan kurguya dönüşmüştü. Bu yedekten kurtarma vaka incelemesi, küçük bir e-ticaret işletmesi için kullanılan bir üretim VPS üzerinde bundan sonra ne olduğunu, neleri geri yüklediğimizi, neleri körü körüne geri yüklemediğimizi ve hizmetin neden gün doğmadan önce yeniden kararlı hâle geldiğini anlatıyor.
Müşteri, büyüyen bir çevrimiçi mağaza için oldukça standart bir yığın çalıştırıyordu - Nginx, PHP-FPM, MariaDB, Redis ve sistem yöneticisi olmayan iki personelin kullandığı bir kontrol paneli. Trafik çok büyük değildi, ama zamanlama acı vericiydi. Bir satış kampanyası sipariş hacmini artırmıştı, veritabanı yazmaları zirveye çıkıyordu ve dosya sistemi katmanındaki bir depolama sorunu etkin veritabanı tablolarını bozmaya başlamıştı. Hollywood tarzı dramatik değildi, ama her dakikanın önemli olacağı kadar ciddiydi.
İlk iş geri yükleme değildi. İlk iş, hasarın yayılmasını durdurmaktı. Uygulamayı bakım moduna aldık, inceleme için mevcut disk durumunu koruduk ve çoğaltma, snapshot'lar veya mantıksal dökümlerin bize en temiz kurtarma noktasını verip vermediğini kontrol ettik. Bu, insanların kabul etmek istediğinden daha önemlidir. Hızlı kurtarma iyidir. Hasarlı verilere hızlı kurtarma, sadece hızlı bir hayal kırıklığıdır.
Ne başarısız oldu ve bunu nasıl anladık
Artık günlükler de aynı hikâyeyi anlatıyordu. MariaDB, InnoDB sayfa sağlama toplamı hataları bildirmeye başladı; ardından yazma yoğun sipariş ve oturum tablolarında tablo çökmesi yaşandı. Hypervisor'ın kendisi sağlıklıydı. CPU, RAM ve ağ davranışı normal kaldı. Bu, olayı geniş çaplı bir platform kesintisinden uzaklaştırıp konuk düzeyinde depolama bütünlüğüne yaklaştırdı.
Yedeklere dokunmadan önce üç şeyi doğruladık. İlk olarak, sorunun küçük bir tablo kümesiyle sınırlı olup olmadığını ve yerinde onarılıp onarılamayacağını. İkinci olarak, son yedeklerin geçerli ve bağlanabilir olup olmadığını. Üçüncü olarak, bilinen son iyi yedekten sonra tamamlanan işlemlerin uygulama günlüklerinden, e-posta onaylarından veya ödeme ağ geçidi kayıtlarından yeniden oluşturulup oluşturulamayacağını.
Bu üçüncü kontrol çoğu zaman atlanır. Atlanmamalı. Bir yedeği geri yüklemek, kurtarmanın tamamı değildir. İşletmeler, yalnızca MySQL'in yeniden başlayıp başlamadığıyla değil; eksik siparişlerle, müşteri kayıtlarıyla ve fatura durumuyla ilgilenir.
Seçtiğimiz kurtarma yolu
Bu yedekten kurtarma vaka incelemesi faydalıdır, çünkü açık görünen seçenek en iyi seçenek değildi. Önümüzde üç aday yol vardı.
Tam bir VM snapshot geri alma işlemi tıklama sayısı açısından en hızlısı olurdu, ancak aynı zamanda birkaç saatlik meşru içerik değişikliğini, eklenti güncellemelerini ve müşteri hesabı düzenlemelerini de yok sayardı. Yolsuzluk zaten çekirdek işlemsel verilere dokunmuş olduğundan, tabloları yerinde onarmak çok fazla risk taşıyordu. Daha iyi yol, yeni bir örneğe dosya düzeyinde ve veritabanı düzeyinde geri yükleme, ardından seçici veri uzlaştırmaydı.
Bu yüzden önce temiz bir kurtarma ortamı sağladık. Aynı VPS boyutu, aynı OS ailesi, aynı panel sürümü, aynı PHP dalı. Paralel bir örneğe yeniden kurmak nefes alma alanı sağlar. Ayrıca, müşteri kök nedeni anlamak veya sorunun uygulama davranışından kaynaklanmadığını doğrulamak isterse yararlı olan adli inceleme için özgün sistemi de korur.
Son başarılı otomatik yedeği saat 23:00 UTC'den aldık. Ardından geçişten önce test ettik. Bu kulağa temel geliyor, ancak birçok ekip yedek sorunlarını ancak mümkün olan en kötü saatte fark ediyor. Arşiv doğru şekilde bağlandı, sağlama toplamları eşleşti, veritabanı içe aktarma işlemi hatasız tamamlandı ve uygulama yalıtılmış ortamda ayağa kalktı. Güzel. Sükûnet orada başlar.
Hizmeti yeni sorunlar yaratmadan geri yüklemek
Kurtarma dört aşamalıydı. İlk olarak, altyapı. Web yığınını yeniden kurduk, zaten onaylanmış sistem güncellemelerini uyguladık ve uygulamanın sürpriz bir bağımlılık uyumsuzluğu nedeniyle başarısız olmaması için çalışma zamanı sürümlerini eşleştirdik.
İkinci olarak, veri. Veritabanı geri yükleme işlemi 11 dakikada tamamlandı. Web dosyaları 4 dakikadan kısa sürede geri yüklendi. Medya varlıkları sağlamdı; bu da müşteriyi bozuk ürün görsellerinden ve öfkeli tarayıcı kutularından kurtardı. Redis, önbelleğe alınmış veriler tasarım gereği atılabilir olduğu için yedekten geri yüklenmedi. Bayat önbelleği yeni bir ortama geri getirmek, sonradan büyük karmaşa çıkaran küçük hatalardan biridir.
Üçüncü olarak, doğrulama. Uygulama girişini, ödeme akışını, yönetici yazmalarını, cron çalışmasını, SSL geçerliliğini, giden postayı ve ödeme ağ geçidi callback davranışını kontrol ettik. Ayrıca siparişler, müşteriler ve katalog tablolarındaki kayıt sayılarını önceki haftanın beklenen büyüme eğrileriyle karşılaştırdık. Rakamların kusursuz şiir olması gerekmez, ama tuhaf görünmemelidir.
Dördüncü olarak, uzlaştırma. Saat 23:00 UTC ile 02:14 UTC arasında, az sayıda başarılı ödeme işlenmişti. Bu kayıtlar geri yüklenen veritabanında yoktu, çünkü yedekleme noktasından sonra gerçekleşmişlerdi. Bunları ödeme sağlayıcısı onaylarından, e-posta sipariş bildirimlerinden ve web erişim günlüklerinden yeniden oluşturduk. Deneyimli bir operatörün işletmeye çok fazla acıdan tasarruf ettirdiği yer burasıdır. Teknik olarak başarılı bir geri yükleme, ücretli siparişleri kaybediyorsa aslında başarı değildir.
Saat 03:41 UTC itibarıyla uygulama müşteri tarafından dahili inceleme için kullanılabilir durumdaydı. Saat 04:06 UTC itibarıyla DNS ve uç yönlendirme, üretim trafiğini kurtarılan örneğe geri yönlendirdi. Ödeme süreci için toplam müşteriye yansıyan kesinti iki saatin hemen altındaydı; bu sırada sitenin büyük bölümüne okuma erişimi olayın önemli bir kısmında kullanılabilir kaldı.
Kurtarmayı hızlı yapan neydi
Bu ne şanstı ne de sihirli bir yedek düğmesiydi. Hız, hazırlıktan ve olay sırasında kararları azaltmaktan geldi.
Müşterinin zaten saklamalı otomatik zamanlanmış yedeklemeleri, izlenen sunucu davranışı ve destek yolu vardı; bunlar bilet sessizliğinde kaybolup gitmiyordu. Bu, gecenin şeklini değiştirdi. Bir yedeğin var olup olmadığını tartışmıyorduk. En güvenli geri yükleme noktasını seçiyor ve onu doğruluyorduk.
Ortam tutarlılığı da önemliydi. Barındırma yığını standartlaştırılmış olduğu için, geri yüklenen uygulamanın eski bir PHP uzantısı ya da eksik bir sistem kütüphanesi istediğini keşfetmekle gergin 45 dakika harcamadık. İnsanlar çoğu zaman yapılandırma kaymasında ne kadar kurtarma süresi yandığını hafife alır.
Daha az görünür bir kazanım daha vardı - durum bilgili olanla atılabilir olanı ayırmak. Veritabanı içeriği, yüklenen medya, yapılandırma ve SSL varlıkları dikkatle ele alındı. Önbellek, geçici dosyalar ve oluşturulmuş oturumlar temiz şekilde yeniden oluşturuldu. Bu, kurtarmayı yalın tutar ve yeni bir açılışa eski gürültüyü taşımaktan kaçınır.
Bu yedekten kurtarma vaka incelemesinin öğrettikleri
Ana ders, sadece sunucunuzu yedekleyin değildir. Çoğu işletme bu cümleyi zaten biliyor. Daha zor ders, kurtarmayı yalnızca altyapı nesneleri etrafında değil, iş işlevi etrafında tasarlamaktır.
Bir VM snapshot'ı kullanışlıdır, ama fazla kaba olabilir. Bir veritabanı dökümü kullanışlıdır, ama yüklenen dosyalar ayrıysa yeterli değildir. Bir kontrol paneli yedeği elverişlidir, ama elverişlilik yine de test edilmelidir. Doğru yedekleme stratejisi, uygulamanın nasıl davrandığına, verinin ne kadar sık değiştiğine ve gerçekte ne kadar kaybın kabul edilebilir olduğuna bağlıdır.
Bir e-ticaret sitesi için ürün görselleri genellikle sipariş kayıtlarına göre biraz daha eski kurtarma noktalarını tolere edebilir. Bir SaaS uygulaması için müşteri veritabanı durumu, yerel dosya sistemi içeriğinden daha önemli olabilir. Bir dijital ajans için, tek bir sunucuda birden çok müşteri sitesi barındırılıyorsa yalıtım kritik hâle gelir; çünkü gürültülü bir site kurtarmayı tüm rack için baş ağrısına çevirmemelidir.
Test de daha fazla saygıyı hak ediyor. Yedekler geri yüklenene kadar birer vaattir. Geri yüklendikten sonra kanıta dönüşürler. Aradaki fark pahalıdır.
Olaydan sonra ne değişti
Kurtarmayı bitiş çizgisi olarak görmedik. Hizmet kararlı hâle geldikten sonra depolama davranışını, dosya sistemi sağlığını, veritabanı bütünlük kontrollerini ve yedekleme ilkesi zamanlamasını gözden geçirdik. Anlık teknik neden, yazma baskısı altında konuk düzeyinde disk tutarsızlığına işaret ediyordu; ancak daha geniş soru, bir dahaki sefere etki alanını nasıl azaltacağımızdı.
Kampanyalar sırasında kurtarma noktası maruziyetini kısaltmak için veritabanı katmanında yedekleme sıklığı ayarlandı. I/O wait ve veritabanı hata desenleri için uyarı eşikleri sıkılaştırıldı. Müşteri ayrıca tek katmanlı bir geri yükleme anlayışından katmanlı bir anlayışa geçti - otomatik yedeklemeler, doğrulanmış geri yükleme rutinleri ve işlemsel uzlaştırma için daha net işleme.
Yönetilen operasyonel desteğin değerini gösterdiği yer burasıdır. Olaylar hiç yaşanmadığı için değil, yaşandıklarında birinin zaten önce nereye bakacağını ve düzeltirken neyi bozmaması gerektiğini bildiği için. Bu küçük fark, çoğu zaman bütün farktır.
Gelir üreten iş yükleri çalıştırıyorsanız, yararlı soru yedeğinizin olup olmadığı değildir. Yararlı soru, gece 2'de doğru veriyi doğru yere geri yükleyip bunu hızla doğrulayabiliyor ve yedek alındıktan sonra ne olduğunu hesaba katabiliyor musunuz, sorusudur. Cevap belirsizse sistem hâlâ ilgi istiyordur. Buna ödeme süreci arızası sırasında değil, sakin bir öğleden sonra cevap vermek daha iyidir.
Andres Saar Müşteri Hizmetleri Mühendisi