Web sitesi yedeği, sunucudaki dosyaları ara sıra başka bir klasöre kopyalamaktan ibaret değildir. Çalışan bir yedekleme yapısı; site dosyalarını, veritabanını, yapılandırmaları ve sistemin bağlı olduğu kritik servisleri birlikte ele almalı, yedeğin gerektiğinde gerçekten geri yüklenebildiğini doğrulamalıdır.
Özellikle web sitesi ERP, Netsis, e-ticaret altyapısı, ödeme sistemi veya başka kurumsal uygulamalarla veri alışverişi yapıyorsa konu daha hassas hâle gelir. Böyle bir sistemde yalnızca web dosyalarını geri getirmek yeterli olmayabilir. Yanlış zamana ait veritabanı, eksik sipariş kayıtları veya ERP ile eşleşmeyen işlem numaraları sitenin teknik olarak açılmasına rağmen operasyonun hatalı devam etmesine yol açabilir.
Nelerin yedeklenmesi gerektiği baştan belirlenmeli
Bir web projesinde korunması gereken veriler genellikle birkaç farklı yerde bulunur.
Uygulama dosyaları bunların ilkidir. Kaynak kod, yüklenen görseller, belgeler, tema ve eklenti dosyaları bu gruba girer. Kaynak kod Git gibi bir sürüm kontrol sisteminde tutuluyorsa uygulamanın önemli bir bölümü zaten başka bir noktada korunuyor olabilir. Ancak kullanıcıların yüklediği dosyalar çoğu zaman Git deposunda bulunmaz ve ayrıca yedeklenmeleri gerekir.
Veritabanı ayrı değerlendirilmelidir. Üyeler, siparişler, ürünler, içerikler, formlar ve uygulamanın oluşturduğu diğer kayıtlar burada bulunabilir. E-ticaret veya ERP bağlantılı projelerde veritabanındaki birkaç dakikalık fark bile sipariş ve stok hareketlerinde tutarsızlık yaratabilir.
Sunucu ve uygulama yapılandırmaları da hesaba katılmalıdır. Web sunucusu ayarları, zamanlanmış görevler, servis tanımları ve uygulamanın çalışması için gereken diğer konfigürasyonlar belgelenmez veya yedeklenmezse yeni bir sunucuda sistemi yeniden ayağa kaldırmak gereksiz yere uzar.
API anahtarı, parola ve sertifika gibi gizli bilgiler ise sıradan dosyalar gibi yedeklenmemelidir. Bunların erişim yetkileri kontrollü, şifreli bir sır yönetimi sistemi içerisinde tutulması daha güvenli bir yöntemdir.
Yedekleme sıklığını sitenin değişim hızı belirler
Her web sitesi için “günde bir yedek yeterlidir” demek doğru değildir.
Ayda birkaç kez güncellenen kurumsal bir sitede günlük yedek kabul edilebilir olabilir. Dakikada sipariş alan bir e-ticaret sitesinde ise aynı yöntem bir arıza sırasında saatlerce işlemin kaybolması anlamına gelebilir.
Burada iki kavram karar vermeyi kolaylaştırır: RPO ve RTO.
RPO, en fazla ne kadar verinin kaybedilebileceğini belirler. İşletme en fazla 15 dakikalık sipariş kaybını kabul edebiliyorsa yedekleme ve veri çoğaltma yapısı buna göre tasarlanmalıdır.
RTO ise sistemin ne kadar süre kapalı kalabileceğini ifade eder. Dört saatlik kesinti kabul edilmiyorsa, geri yüklenmesi saatler sürecek bir yedekleme yöntemi tek başına yeterli değildir.
Bu değerleri teknik ekip tek başına belirlememelidir. Satış, operasyon, finans ve yönetim tarafının kabul edebileceği veri kaybı ve kesinti süresi bilinmeden doğru yedekleme politikası kurulamaz.
Tek yedek, güvenilir yedek değildir
Yedeğin aynı sunucuda tutulması sık yapılan hatalardan biridir. Disk arızası, kullanıcı hatası, kötü amaçlı yazılım veya sunucunun tamamen erişilemez hâle gelmesi durumunda asıl sistem ile yedek aynı anda kaybedilebilir.
Bu nedenle yedeklerin birbirinden bağımsız ortamlarda tutulması gerekir. Uygulamada sık kullanılan yaklaşımlardan biri 3-2-1 kuralıdır: verinin üç kopyasının bulunması, bunların iki farklı depolama ortamında tutulması ve kopyalardan birinin farklı bir fiziksel veya mantıksal konumda bulunması.
Bulut depolama bu yapı içerisinde kullanılabilir ancak “buluta kopyaladık, sorun çözüldü” yaklaşımı da yeterli değildir. Yedeklerin silinmesine karşı koruma, saklama süresi, sürümleme, erişim yetkileri ve şifreleme ayrıca yapılandırılmalıdır.
Özellikle fidye yazılımı riskine karşı yedek sisteminin üretim ortamından ayrılması gerekir. Web sunucusunu ele geçiren bir hesabın bütün yedekleri de silebildiği bir yapı, yedekleme yapıyor görünür fakat gerçek bir felaket senaryosunda işe yaramayabilir.
Veritabanı ile dosya yedeği aynı anı temsil etmeli
Dinamik sistemlerde en kritik konulardan biri yedekler arasındaki zaman tutarlılığıdır.
Örneğin bir e-ticaret sitesinde ürün görseli dosya sistemine kaydedilirken ürün kaydı veritabanına yazılabilir. Veritabanının saat 02.00'de, dosyaların 04.00'te yedeklendiği bir sistemde geri dönüş sonrasında iki veri seti birbirini tam olarak karşılamayabilir.
ERP entegrasyonlarında sorun daha da belirginleşir. Web sitesi bir siparişi ERP'ye göndermiş fakat ilgili işlem web veritabanının alınan yedeğinde henüz “aktarıldı” olarak işaretlenmemiş olabilir. Sistem geri yüklendiğinde aynı sipariş ikinci kez gönderilebilir.
Bu nedenle entegrasyon geliştirilirken işlem kimlikleri, tekrar eden isteklerin yönetimi ve kayıtların hangi sistemde hangi durumda bulunduğu baştan tasarlanmalıdır.
Netsis kullanılan projelerde tablo ve veri ilişkilerini doğru anlamak özellikle önemlidir. Piasoft'un [Netsis Tabloları ve Açıklamaları] Netsis Tabloları ve Açıklamaları içeriğinde stok, fatura, cari, entegrasyon ve diğer modüllerde kullanılan tablo yapıları daha ayrıntılı incelenebilir.
Entegrasyon varsa yedekleme planı veri akışını da kapsamalı
Bir web sistemi Netsis veya başka bir ERP ile konuşuyorsa hangi sistemin hangi verinin ana kaynağı olduğu açık biçimde tanımlanmalıdır.
Ürün kartlarının ERP'den web sitesine, siparişlerin web sitesinden ERP'ye aktarıldığı bir yapıyı düşünelim. Web sitesi iki saat önceki yedeğine döndürüldüğünde ERP güncel kalacaktır. Web tarafındaki eski stok veya sipariş durumları otomatik olarak ERP'nin üzerine yazılırsa kurtarma işlemi yeni bir veri problemine dönüşebilir.
Bu nedenle geri yükleme senaryosunda entegrasyonların nasıl davranacağı önceden belirlenmelidir. Bazı servislerin geçici olarak durdurulması, sistemler arasındaki kayıtların karşılaştırılması ve yalnızca gerekli verilerin yeniden işlenmesi gerekebilir.
Aktarım kayıtlarının izlenebilir olması burada ciddi kolaylık sağlar. Her işlemin kaynak sistemini, hedef sistemini, işlem zamanını, benzersiz kimliğini ve aktarım sonucunu kaydeden loglar bulunduğunda geri dönüş sonrası hangi kayıtların tekrar işlenmesi gerektiği belirlenebilir.
Başarılı bir entegrasyonun temeli zaten bu veri modeline dayanır. ERP'nin veritabanı yapısını doğrudan anlamak isteyen ekipler için Piasoft'un Netsis ERP içerikleri de teknik hazırlık sırasında kullanılabilecek bir başlangıç noktasıdır. Netsis 3 Enterprise hakkında bilgi
Yedeğin alınması değil, geri yüklenebilmesi önemlidir
Yedekleme görevinde “başarılı” kaydı görmek yedeğin kullanılabilir olduğunu kanıtlamaz.
Dosya oluşmuş olabilir fakat bozuk olabilir. Veritabanı dışa aktarılmış görünürken işlem yarıda kesilmiş olabilir. Şifreleme anahtarı kaybedilmiş olabilir. Yıllardır çalışan yedekleme sistemi yeni sunucu sürümünde artık geçerli olmayan bir yapı üretiyor olabilir.
Bu yüzden belirli aralıklarla geri yükleme testi yapılmalıdır.
Test sırasında sadece veritabanının içe aktarılmasına bakmak yerine uygulamanın gerçekten çalışıp çalışmadığı kontrol edilmelidir. Kullanıcı oturumu açılabiliyor mu, dosyalar görüntüleniyor mu, siparişler doğru mu, zamanlanmış görevler çalışıyor mu, API bağlantıları yeniden kurulabiliyor mu?
ERP ve e-ticaret entegrasyonu bulunan projelerde test ortamında örnek bir veri akışı da denenmelidir. Sistemin açılması tek başına yeterli değildir; bağlı sistemlerle doğru şekilde çalışabilmesi gerekir.
Yedeklere erişim mümkün olduğunca dar tutulmalı
Yedek dosyaları çoğu zaman üretim sistemindeki verinin tamamını içerir. Müşteri kayıtları, sipariş bilgileri, ticari veriler ve uygulamanın yapısına bağlı olarak başka hassas bilgiler tek dosyada toplanabilir.
Bu nedenle yedek depolama alanı doğrudan internet erişimine açık bırakılmamalı, erişim hesapları sınırlandırılmalı ve mümkünse çok faktörlü kimlik doğrulama kullanılmalıdır. Aktarım sırasında ve depolama alanında şifreleme uygulanması da koruma katmanlarından biridir.
Yedekleme servisinin kullandığı hesaplara gereksiz yönetici yetkileri verilmemelidir. Bir servisin görevi veriyi okuyup yedek alanına yazmaksa, üretim ortamındaki bütün sistemleri değiştirme veya yedek geçmişini sınırsız biçimde silme yetkisine ihtiyacı olmayabilir.
Log kayıtları da korunmalıdır. Kimin hangi yedeğe eriştiği, hangi yedeğin ne zaman oluşturulduğu, silindiği veya geri yüklendiği görülebilmelidir.
Geri dönüş prosedürü yazılı olmalı
Arıza sırasında ilk kez “hangi yedeği geri döndürelim?” diye düşünmeye başlamak pahalı bir yöntemdir.
Prosedürde en azından hangi sistemlerin hangi sırayla ayağa kaldırılacağı, yedeği kimin geri yükleyebileceği, entegrasyonların ne zaman durdurulacağı ve yeniden açılacağı, veri tutarlılığının nasıl kontrol edileceği tanımlanmalıdır.
Örneğin ERP bağlantılı bir e-ticaret projesinde akış şu mantıkla ilerleyebilir: Önce veri aktarımı durdurulur. Web uygulaması ve veritabanı geri yüklenir. Son yedek zamanı ile ERP'deki son başarılı işlem karşılaştırılır. Eksik veya tekrar işlenme ihtimali bulunan kayıtlar belirlenir. Kontroller tamamlandıktan sonra entegrasyon yeniden devreye alınır.
İşletmenin gerçek mimarisine göre bu sıra değişebilir. Kritik nokta, kararların kriz anında doğaçlama verilmemesidir.
Piasoft projelerinde ihtiyaç analizi, teknik planlama, uygulama, test, yayın ve sonrasındaki bakım süreçleri birlikte ele alınıyor. Piasoft web sitesi Web sitesi Netsis, ERP, e-ticaret altyapısı veya farklı servislerle veri alışverişi yapıyorsa yedekleme mimarisi de bu bağlantılardan bağımsız tasarlanmamalıdır. Doğru veri modeli, güvenli bağlantı, hata yönetimi ve izlenebilirlik kurulmadan yapılan entegrasyon veri aktarabilir; fakat sorun çıktığında hangi kaydın nerede kaldığını açıklamak zorlaşır.
Sağlam bir yedekleme düzeni ise arıza gününde kendini belli eder: hangi verinin korunacağı bellidir, kullanılabilir birden fazla kopya vardır, geri yükleme denenmiştir ve bağlı sistemlerin naıl yeniden senkronize edileceği önceden tanımlanmıştır.