Üye & Satış Verisi Yedekleme Sistemi

Bu sistem, dijital veriye dayalı çalışan ve bu verinin kaybolması durumunda ciddi operasyonel veya hukuki sonuçlarla karşılaşacak her spor ve fitness tesisi için tasarlanmıştır.

Özellikle şu profillerdeki tesisler için önceliklidir:

• Kendi sunucusunda üyelik yazılımı barındıranlar: Bulut servisi kullanmayanlar için yedekleme tamamen tesisin sorumluluğundadır; lokal diskten ibaret tek kopya yetersizdir.
• Sağlık formu ve PAR-Q dijital arşivi tutanlar: Sakatlık davalarında onam belgesinin varlığı hukuki savunma açısından kritiktir; bu belgeler kaybolduğunda ispat yükü salone düşer.
• Ödeme ve tahsilat geçmişi değerli olan tesisler: Yıllık ve aylık gelir raporları, vergi süreçleri için zorunludur; veri kaybı hem muhasebe hem de yasal yükümlülük riski doğurur.
• Sadakat ve puan geçmişi işleyen sistemler: Üye puanlarının yok olması, ciddi müşteri şikâyeti ve itibar zararı anlamına gelir.
• Ransomware (fidye yazılımı) endişesi taşıyanlar: Fidye yazılımı, tüm sistemi şifreleyerek fidye ödenene kadar erişimi engeller; doğru yapılandırılmış harici yedek bu saldırıyı etkisiz kılar.

Kurulu yedekleme altyapısı aynı zamanda KVKK'nın 12. maddesi kapsamında teknik güvenlik önlemi sayılır ve denetimde olumlu bir gösterge olarak değerlendirilir. Sistem; sahipsiz kalmadan çalışan, düzenli aralıklarla test edilen ve alarm veren bir altyapı olarak kurulur.

Sigorta şirketleri ve kurumsal müşteriler de giderek artan sıklıkla tedarikçilerinden veri yedekleme kanıtı talep etmektedir. Bakımlı ve test edilmiş bir yedekleme sistemi, tesisin kurumsal sözleşme süreçlerinde de güvenilirlik kanıtı işlevi görür.

Spor salonu verisinin kaybolması birden fazla biçimde gerçekleşebilir ve her biri farklı boyutta hasar bırakır.

Sıkça karşılaşılan veri kaybı senaryoları:

• Disk veya sunucu arızası: Lokal sunucuda çalışan üyelik yazılımı, donanım arızasında tüm veriyi birlikte götürebilir. Yedek yoksa kurtarma imkânsız veya çok maliyetli olur.
• Fidye yazılımı (ransomware) saldırısı: Sistem şifrelenir, üye kayıtlarına ve ödeme geçmişine erişim tamamen engellenir. Fidye ödense bile veri tam olarak geri gelmeyebilir.
• Yanlışlıkla silme: Yazılım güncellemesi, veritabanı bakımı veya personel hatası sonucu kritik tablolar ya da dosyalar silinebilir.
• Yazılım geçişi sırasında veri kaybı: Eski sistemden yeni sisteme geçerken migrasyon hatası, yıllık geçmişin yok olmasına yol açabilir.
• Bulut hizmetinin sonlandırılması: Kullanılan SaaS üyelik platformu kapanırsa veya abonelik sona ererse veriye erişim kesilir.

Bu senaryoların hiçbiri kaçınılmaz değildir, ancak hepsine karşı hazırlıklı olmak gerekir. Düzgün yapılandırılmış, coğrafi olarak dağılmış ve düzenli aralıklarla test edilen bir yedekleme sistemi, tüm bu senaryolarda veriyi kurtarılabilir tutar. Kurtarma süresi (RTO) ve veri kayıp penceresi (RPO) iş gereksinimlerinize göre belirlenir.

Unutulmaması gereken önemli bir nokta daha var: yedek almak yeterli değildir. Hiç test edilmemiş yedek, kurtarma anında çalışmıyor olabilir. Bozuk, eksik veya yanlış yapılandırılmış yedek dosyası, kriz anında sahte bir güvenden ibaret kalır. Bu sistem; yedeklemenin alındığını değil, geri yüklenebileceğini düzenli testlerle kanıtlar.

1. Veri Haritası ve Önceliklendirme (1. Hafta): Hangi verinin nerede saklandığı (veritabanı, dosya sistemi, bulut, yerel disk), bu verinin ne kadar kritik olduğu ve ne sıklıkta değiştiği belirlenir. Üye kaydı, sağlık formu, ödeme geçmişi ve medya dosyaları ayrı ayrı sınıflandırılır.
2. Yedekleme Stratejisinin Tasarımı (1–2. Hafta): RPO (Recovery Point Objective — kabul edilebilir maksimum veri kaybı süresi) ve RTO (Recovery Time Objective — kabul edilebilir maksimum kesinti süresi) iş gereksinimlerine göre belirlenir. 3-2-1 kuralına uygun strateji tasarlanır: en az 3 kopya, 2 farklı medya, 1 coğrafi uzak lokasyon.
3. Altyapı Kurulumu (2–3. Hafta): Seçilen strateji doğrultusunda yedekleme yazılımı ve hedef depolama alanı (bulut, NAS, harici sunucu) yapılandırılır. Tüm yedekler AES-256 şifrelemeyle korunur. Günlük tam yedek ve saatlik artımlı yedek takvimi devreye alınır.
4. Kurtarma Testi (3. Hafta): Altyapı kurulumunun ardından gerçek bir kurtarma senaryosu simüle edilir: yedekten geri yükleme yapılır, veri bütünlüğü doğrulanır ve kurtarma süresi ölçülür. Test sonucu belgelenir.
5. İzleme ve Alarm Sistemi (3–4. Hafta): Yedekleme işlemlerini izleyen, başarısız yedek tespit ettiğinde e-posta veya SMS ile uyaran bir alarm altyapısı kurulur. Aylık otomatik kurtarma testi raporu oluşturulur.
6. Dokümantasyon ve Teslim: Yedekleme altyapısının yapılandırması, kurtarma prosedürü ve alarm müdahale kılavuzu yazılı olarak teslim edilir. Tesis personeline kısa operasyon eğitimi verilir.
7. Periyodik Sağlık Kontrolü: Kurulum sonrası 3. ayda sistematik bir sağlık kontrolü yapılır. Yedeklerin eksiksiz ve sağlıklı çalıştığı, uyarı mekanizmasının aktif olduğu ve depolama kapasitesinin aşılmadığı doğrulanır. Herhangi bir yazılım güncellemesi veya altyapı değişikliğinden sonra yedekleme yapılandırmasının güncellenmesi de bu sürecin parçasıdır.

Yedekleme altyapısının güvenliği, yedeklemenin kendisi kadar önemlidir. Şifrelenmemiş yedek, saldırgan için ikinci bir kapı anlamına gelir.

KVKK açısından: yedeklenen verinin tamamı kişisel veri kapsamındadır. Üçüncü taraf bulut hizmeti kullanılıyorsa, bu hizmet sağlayıcı ile veri işleme sözleşmesi imzalanması gerekir; bu sözleşmeyi de hazırlıyoruz. Yedekler, tanımlanan saklama süresi dolduğunda otomatik olarak güvenli biçimde silinir.

Yedekleme altyapısı yalnızca teknik bir çözüm değildir; aynı zamanda tesisin üyelerine karşı sorumluluğunu yerine getirdiğinin somut kanıtıdır. Üye verisi kaybolduğunda hem güven hem de yasal yükümlülük kaybı birlikte gerçekleşir. Düzenli olarak test edilen ve belgelenen bir yedekleme sistemi, bu ikili riski birden ortadan kaldırır ve tesisin uzun vadeli dijital sürekliliğini güvence altına alır. Fidye yazılımı saldırısına karşı ek bir güvence olarak yedek kopyaların ağdan izole (offline) ortamda tutulmasını da öneriyor ve gerektiğinde bu yapılandırmayı hayata geçiriyoruz.