ESL sisteminde yedekleme ve kurtarma: neyi, ne sıklıkla, nereye?

Etiket sisteminde bir veritabanı kaybı, birkaç saatlik kesintiden çok daha ağırdır: eşleştirme kayıtları giderse hangi etiketin hangi ürüne bağlı olduğu bilinmez ve tüm mağaza yeniden eşleştirilir. Üç bin etiketlik bir markette bu, iki günlük kurulum işinin tekrarı demektir. Bu yazı, neyin yedeklenmesi gerektiğini ve kurtarmanın nasıl provalanacağını anlatıyor.

Yedeklenecek beş katman

Eşleştirme kayıtları. Etiket kimliği ↔ ürün kodu ↔ raf konumu. En kritik katman; yeniden üretilemez.

Ürün verisi. ERP'den gelir, kaynağı sizdedir; kaybolursa yeniden aktarılır. Yine de son hâlinin yedeği, aktarım sorunlarında zaman kazandırır.

Şablonlar. Tasarlanmış etiket düzenleri; yeniden yapmak saatler alır.

Yapılandırma. Erişim noktası tanımları, mağaza grupları, kullanıcı ve yetkiler.

Olay günlüğü. Fiyat değişikliği geçmişi; denetimde istenen kayıtlar yazısı neden saklanması gerektiğini anlatıyor.

Bulut kurulumda

Yedekleme tedarikçinin sorumluluğundadır ama sizin kontrolünüzde olmalı. Sözleşmede üç sayı: yedek sıklığı (günlük makul), saklama süresi (en az otuz gün) ve kurtarma süresi hedefi (birkaç saat). Buna ek olarak kendi dışa aktarımınızı yapın: ayda bir, eşleştirme kayıtlarını ve şablonları CSV/JSON olarak indirip kendi depolamanızda saklayın. Tedarikçi kaynaklı bir kayıpta ya da sözleşme bitiminde bu kopya sizi kurtarır; veri sahipliği yazısı dışa aktarım maddesini anlatıyor.

Yerinde kurulumda

Yedekleme sizindir. Veritabanının günlük tam yedeği, tercihen mağaza dışında bir konuma (merkez sunucu ya da bulut depolama) kopyalanır. Yalnızca aynı sunucuda tutulan yedek, sunucu arızasında birlikte gider. Yedeklerin şifrelenmesi, kişisel veri içerdiği için (kullanıcı hesapları, olay günlüğü) gereklidir; KVKK ve elektronik etiket yazısı yükümlülükleri anlatıyor.

Kurtarma provası

Yedek, geri dönülebildiği kanıtlanana kadar yedek değildir. Yılda bir kez, test ortamında ya da pilot mağazada kurtarma provası yapılır: yedek geri yüklenir, eşleştirmeler kontrol edilir, süre ölçülür. Prova yapmayan kurulumlarda kurtarma denemesi, ilk kez gerçek kriz anında yapılır ve orada öğrenilen her şey pahalıdır.

Ne kadar veri kaybı kabul edilebilir?

Günlük yedekte en fazla bir günlük değişiklik kaybedilir. Etiket sisteminde bu, bir günlük eşleştirme ve şablon değişikliği demektir; çoğu mağaza için kabul edilebilir. Yoğun kurulum dönemlerinde (yaygınlaştırma sırasında) günlük yedek yetmez; o dönemde daha sık yedek ya da kurulum sonunda ek yedek alınır.

Kesinti ile veri kaybını karıştırmamak

E-paper etiketler, sunucu çökse bile son fiyatı göstermeye devam eder; müşteri açısından kesinti görünmez. Asıl risk veri kaybıdır, kesinti değil. Sistem çökerse acil durum planı yazısı kesinti tarafını, bu yazı veri tarafını ele alıyor. İki plan birbirini tamamlar: kesintide ne yapılır, veri giderse ne yapılır.

Çok mağazalı zincirde

Merkezi bulut kurulumda tek yedek tüm mağazaları kapsar. Mağaza başına yerinde sunucu varsa her mağazanın yedeği ayrı alınır ve merkeze kopyalanır; bu, yerinde kurulumun en çok işletme yükü doğuran yanıdır ve bulut mu yerel sunucu mu kararında hesaba katılmalıdır.

Kontrol listesi

Beş katman yedekleniyor mu; sıklık ve saklama süresi yazılı mı; yedek mağaza dışında bir kopyada mı; şifreli mi; yılda bir kurtarma provası yapılıyor mu; bulut kullanılıyorsa kendi dışa aktarımınız var mı? Altı evet, iki günlük yeniden eşleştirme riskini ortadan kaldırır.

Kısa özet

En değerli veri eşleştirme kayıtlarıdır. Bulutta tedarikçinin yedeğine güvenin ama kendi aylık dışa aktarımınızı yapın; yerinde kurulumda günlük yedeği mağaza dışına kopyalayın ve şifreleyin; yılda bir kurtarma provası yapın.

Eşleştirme kaydını kendiniz saklamak

Bulut ya da yerinde fark etmeksizin, eşleştirme tablosunun (etiket kimliği, ürün kodu, raf) aylık bir kopyasını kendi dosya sisteminizde tutmak, en ucuz sigortadır. Dosya birkaç megabayttır ve felaket senaryosunda tüm mağazayı yeniden eşleştirmekten kurtarır. Veri sahipliği yazısı dışa aktarımın sözleşmedeki yerini anlatıyor.

Kurtarma sırası

Bir kayıp sonrası geri yükleme sırası önemlidir: önce yapılandırma (erişim noktaları, gruplar), sonra şablonlar, sonra ürün verisi (ERP'den taze çekilebilir), en son eşleştirme kayıtları. Bu sıra, sistemin her adımda tutarlı kalmasını sağlar. Kurtarma provasında bu sırayı da deneyin.

Kimin sorumluluğunda?

Bulutta yedekleme tedarikçinin, dışa aktarım sizin; yerinde kurulumda ikisi de sizin. Bu ayrımın sözleşmede yazılı olması, kayıp anında "ben sizde sanıyordum" cümlesini önler. Sorumluluk, bakım sözleşmesinin maddelerinden biri olarak tanımlanmalı ve kurtarma süresi hedefiyle birlikte yazılmalıdır.