Veri Yedekleme Stratejisi: Bahis Platformu için Kapsamlı Rehber

Bir bahis platformunda veri; oyuncu hesaplarını, bakiyeleri, bahis geçmişini ve finansal kayıtları kapsar. Bu verilerin kaybı yalnızca teknik bir sorun değildir: oyuncularla anlaşmazlıklarda kanıtın, muhasebede mutabakatın ve düzenleyici denetimlerde kayıtların ortadan kalkması demektir. Bu rehberde hangi verileri yedeklemen gerektiğini, sağlam bir yedekleme düzeninin nasıl kurulacağını ve en çok atlanan adım olan geri yükleme testini anlatıyoruz.

Hangi veriler kritik?

Her veri aynı değerde değildir. Önce neyin kaybının en çok zarar vereceğini belirlemek, yedekleme sıklığını ve saklama süresini doğru ayarlamanı sağlar:

• Oyuncu hesapları ve KYC belgeleri: Kimlik ve adres bilgileri, doğrulama belgeleri. Saklama süreleri lisans ve mevzuat gereksinimlerine göre belirlenir.
• Bakiye ve bahis geçmişi: Açık, kazanan ve kaybeden tüm bahisler. Anlaşmazlık çözümünde temel kanıttır.
• Finansal işlemler: Para yatırma, çekme, bonus ve düzeltme kayıtları. Mutabakat ve vergi süreçleri için gereklidir.
• Settlement kayıtları: Hangi marketin hangi sonuçla ve ne zaman sonuçlandırıldığı.
• Yapılandırma: Dağıtım ayarları, altyapı tanımları ve veritabanı şema geçmişi. Gizli değerler ayrı ve şifreli tutulmalıdır.

3-2-1 kuralı

Yaygın kabul gören 3-2-1 kuralı şunu söyler: verinin en az üç kopyası olsun, bu kopyalar en az iki farklı depolama türünde dursun ve en az biri başka bir konumda bulunsun. Bir bahis platformu için bu genellikle birincil veritabanı, aynı bölgedeki yedek depolama ve farklı bir bölgede ya da farklı bir sağlayıcıda tutulan şifreli kopya anlamına gelir. Tüm kopyalar aynı veri merkezindeyse tek bir yangın, sel ya da hesap ele geçirilmesi hepsini birden götürebilir. Fidye yazılımlarına karşı buna silinemeyen ve değiştirilemeyen (immutable) bir kopya eklemek de giderek yaygınlaşan bir pratiktir.

Replikasyon yedek değildir

Gerçek zamanlı replikasyon, birincil sunucu çöktüğünde hızla devam edebilmek için çok değerlidir. Ancak yanlışlıkla silinen bir tablo ya da hatalı bir toplu güncelleme de aynı hızla kopyaya taşınır. Bu yüzden replikasyonun yanında, zamanda geriye gidebilmeni sağlayan ayrı yedekler şarttır:

• Tam yedek: Veritabanının belirli bir andaki eksiksiz kopyası.
• Sürekli arşivleme: İşlem kayıtlarının (PostgreSQL'de WAL) düzenli arşivlenmesi; tam yedekle birlikte belirli bir ana geri dönmeyi (point-in-time recovery) mümkün kılar.
• Mantıksal döküm: Tek bir tabloyu ya da şemayı geri getirmek için pratik, taşınabilir kopyalar.

PostgreSQL için örnek

Aşağıdaki örnek, sıkıştırılmış bir mantıksal döküm alır, dosyanın okunabilir olduğunu doğrular ve şifreler. Üretimde bunu sürekli WAL arşivlemesi ve fiziksel yedeklerle birlikte kullanmak gerekir:

# Sıkıştırılmış, özel biçimde döküm al
DUMP=/yedek/bahis_$(date +%F).dump
pg_dump --format=custom --no-owner --file="$DUMP" "$DATABASE_URL"

# Dökümün bozulmadığını ve içeriğin listelenebildiğini kontrol et
pg_restore --list "$DUMP" > /dev/null && echo "döküm okunabilir"

# Şifrele ve şifresiz dosyayı sil (anahtar yedekten ayrı tutulur)
gpg --encrypt --recipient [email protected] "$DUMP" && rm "$DUMP"

Veritabanı tarafındaki diğer ayarlar için PostgreSQL performans ipuçlarımıza bakabilirsin.

Yedekleme sıklığını belirlemek

Sıklık, kaybetmeye razı olduğun veri miktarına göre belirlenir. Finansal işlemler ve bahisler için sürekli arşivleme neredeyse zorunludur; tam yedekler ise veritabanının büyüklüğüne ve yoğun saatlere göre planlanır. Yedek işlerini oyuncu trafiğinin en düşük olduğu saatlere koymak, üretim veritabanına binen yükü azaltır. KYC belgeleri gibi seyrek değişen ama değerli dosyalar için ayrı bir takvim ve ayrı bir saklama politikası tanımlamak daha düzenlidir.

Şifreleme ve erişim

Şifrelenmemiş bir yedek, sızdığında tüm oyuncu verisini ifşa eder. Yedekleri güçlü bir algoritmayla şifrele ve anahtarları yedeklerin durduğu yerden ayrı sakla. Yedek deposuna erişimi en az yetki ilkesiyle sınırla: yedek alan sistem yazabilsin ama silemesin, geri yükleme yetkisi ise yalnızca birkaç kişide olsun. Bulut depolama kullanıyorsan sürümleme ve silme korumasını aç.

Yedek işini izlemek

Sessizce başarısız olan bir yedek işi, hiç yedek almamaktan daha tehlikelidir, çünkü sahte bir güven duygusu yaratır. Her yedek işinin sonunda başarı ya da hata durumunu bir izleme sistemine veya mesaj kanalına bildir; belirli bir süre boyunca başarılı yedek gelmezse uyarı üret. Yedek dosyasının boyutundaki ani düşüşler de dikkat edilmesi gereken bir işarettir.

Geri yükleme testi: en çok atlanan adım

Test edilmemiş bir yedek, yalnızca var olduğu varsayılan bir yedektir. Düzenli aralıklarla şu adımları uygula:

1. Son yedeği ayrı bir test ortamına geri yükle.
2. Kritik tablolardaki kayıt sayılarını ve son işlem zamanlarını kaynakla karşılaştır.
3. Uygulamayı bu veritabanına bağlayıp giriş, bakiye görüntüleme ve bahis geçmişi gibi temel akışları dene.
4. Geri yüklemenin baştan sona ne kadar sürdüğünü not al; bu süre gerçek bir krizde beklemen gereken süredir.
5. Sonuçları kaydet ve sorun çıktıysa yedekleme sürecini düzelt.

RTO ve RPO hedefleri

RTO (Recovery Time Objective), sistemin ne kadar sürede yeniden çalışır hale gelmesi gerektiğini; RPO (Recovery Point Objective) ise en fazla ne kadarlık veri kaybını kabul edebileceğini tanımlar. Bahis platformlarında finansal işlemler ve açık bahisler söz konusu olduğu için RPO'nun mümkün olduğunca küçük tutulması beklenir; RTO ise işin yoğun saatlerine ve oyuncu beklentisine göre belirlenir. Hedefleri yazdıktan sonra geri yükleme testlerinde ölçtüğün sürelerle karşılaştır; ikisi tutmuyorsa ya hedef ya da mimari değişmelidir. Daha geniş bir çerçeve için felaket kurtarma planı yazımıza göz atabilirsin.

Sık yapılan hatalar

• Yedekleri üretim sunucusuyla aynı kimlik bilgileriyle erişilebilir bırakmak.
• Yalnızca replikasyona güvenip zamanda geriye dönük yedek almamak.
• Şifreleme anahtarını yedekle aynı yerde tutmak.
• Test ortamına geri yüklenen üretim verisini maskelemeden bırakmak; test ortamları genellikle daha az korunur.
• Kişisel veri saklama sürelerini yedeklerde unutmak; GDPR rehberimiz bu konuyu ele alıyor.