Sunucu Yedekleme: Oyun Sunucusu Felaket Kurtarma Rehberi

Bir oyun sunucusunda en pahalı kayıp donanım değil, veridir: oyuncu karakterleri, envanterler, lonca kayıtları, ekonomi ve aylarca biriken ilerleme. İyi bir sunucu yedekleme stratejisi olmadan tek bir disk arızası, hatalı bir DELETE sorgusu ya da fidye yazılımı, topluluğunuzu bir gecede dağıtabilir. Bu rehberde otomatik yedek, sunucu dışı (offsite) kopya ve test edilmiş bir geri yükleme planını tek bir mantıklı sistemde nasıl birleştireceğinizi anlatıyorum.

Neyi yedeklemelisiniz?

Çoğu kişi sadece veritabanını yedekler ve bir felakette sunucunun yarısının eksik olduğunu fark eder. Tam bir kurtarma için şu katmanların hepsi gerekir:

• Veritabanı: MySQL/MariaDB içindeki oyuncu, hesap ve ekonomi verisi. Asıl değer burada.
• Oyun dosyaları: sunucu çekirdeği (binary), quest dosyaları, ayarlar ve harita verisi.
• Yapılandırma: nginx/systemd servisleri, güvenlik duvarı kuralları, cron tanımları.
• Yüklenen içerik: oyuncu logoları, web sitesi varlıkları, log arşivleri.

Pratik bir kural: sunucuyu sıfırdan kurmanız gerekirse, hangi dosyaları geri koyduğunuzda her şey yeniden çalışıyorsa, o dosyalar yedeğe girer.

3-2-1 kuralı

Sektör standardı basit ama güçlüdür: verinizin 3 kopyası, 2 farklı ortamda, bunlardan 1 tanesi tamamen sunucu dışında. Tek bir VPS üzerindeki yedek gerçek bir yedek değildir; çünkü sunucu komple çökerse yedek de onunla gider. Offsite kopya, sağlayıcınızın veri merkezi yansa bile sizi ayakta tutan şeydir.

Otomatik veritabanı yedeği

Veritabanı için mysqldump en güvenilir başlangıçtır. Tek tablonun değil, tutarlı bir anlık görüntünün alınması için işlemsel bir dump kullanın:

#!/bin/bash
set -euo pipefail
STAMP=$(date +%F_%H%M)
DEST=/var/backups/db
mkdir -p "$DEST"

mysqldump --single-transaction --quick --routines \
  --databases player account log \
  | gzip > "$DEST/game_$STAMP.sql.gz"

# 14 günden eski yedekleri sil
find "$DEST" -name 'game_*.sql.gz' -mtime +14 -delete

--single-transaction InnoDB tabloları kilitlemeden tutarlı bir kopya alır; canlı sunucuyu durdurmanız gerekmez. Betiği cron ile çalıştırın:

# crontab -e
0 */6 * * * /opt/scripts/db_backup.sh >> /var/log/db_backup.log 2>&1

Bu satır 6 saatte bir yedek alır. Yoğun bir sunucuda saatlik, küçük bir toplulukta günlük sıklık yeterlidir. Kayıp toleransınızı (RPO — kabul edebileceğiniz maksimum veri kaybı süresi) belirleyip aralığı ona göre seçin.

Dosyalar için artımlı yedek

Oyun dosyaları için her seferinde her şeyi kopyalamak israftır. rsync yalnızca değişenleri aktarır ve --link-dest ile değişmeyen dosyaları sabit bağlantı (hard link) olarak paylaşan anlık görüntüler oluşturur:

rsync -a --delete \
  --link-dest=/var/backups/files/latest \
  /srv/gameserver/ \
  /var/backups/files/$(date +%F_%H%M)/
ln -sfn /var/backups/files/$(date +%F_%H%M) /var/backups/files/latest

Böylece her anlık görüntü tam bir kopya gibi görünür ama yalnızca değişen dosyalar kadar yer kaplar.

Offsite kopya

Yerel yedekler hazır olduktan sonra onları sunucu dışına gönderin. rclone Backblaze B2, Wasabi, S3 gibi onlarca depolama sağlayıcısıyla çalışır ve şifreli aktarım yapabilir:

rclone sync /var/backups remote:oyun-yedek \
  --transfers 4 --checksum --log-file /var/log/rclone.log

Mümkünse istemci tarafı şifreleme (rclone crypt) kullanın; böylece depolama sağlayıcısı dosyalarınızın içeriğini göremez. Offsite hedefin sunucudaki yedekleri silebildiği bir senkronizasyon kullanıyorsanız, sağlayıcının nesne sürümleme veya yazılan veriyi belirli süre kilitleyen özelliğini açın — fidye yazılımı yerel yedekleri silse bile bulutta eski sürüm kalır.

En kritik adım: geri yüklemeyi test edin

Test edilmemiş bir yedek, yedek değil bir dilektir. Düzenli olarak gerçek bir geri yükleme provası yapın: yedeği boş bir test sunucusuna açın ve sunucunun gerçekten ayağa kalktığını doğrulayın.

gunzip < game_2026-06-28_0600.sql.gz | mysql -u root -p

Bu provada üç şeyi ölçün: dump bozuk mu (gzip -t ile bütünlük kontrolü), import ne kadar sürüyor (RTO — kurtarma süresi hedefiniz), ve karakter/ekonomi verisi tutarlı mı. Ayda bir kez yapılan 15 dakikalık bu prova, gerçek bir felakette saatlerce panik yapmaktan kurtarır.

Sık Sorulan Sorular

Ne sıklıkla yedek almalıyım?

Kabul edebileceğiniz veri kaybına bağlı. Aktif bir PvP sunucusunda oyuncular saatlik ilerlemeye duyarlıdır, bu yüzden saatlik veritabanı yedeği mantıklıdır. Daha sakin sunucularda 6 saatlik veya günlük aralık yeterlidir. Dosyaları ise yalnızca değişiklik yaptığınızda yedeklemek yeterli olur.

Yedeği aynı sunucuda tutmak yeterli mi?

Hayır. Aynı diskteki yedek disk arızasında, aynı VPS'teki yedek sunucu çökmesinde işe yaramaz. En az bir kopya tamamen farklı bir konumda (bulut depolama veya başka bir veri merkezi) olmalı.

Canlı sunucuyu durdurmadan tutarlı yedek alabilir miyim?

Evet. InnoDB tabloları için mysqldump --single-transaction sunucu çalışırken tutarlı bir anlık görüntü verir. Dosya tarafında rsync çalışan sunucuyla uyumludur; yalnızca sürekli yazılan tek bir büyük dosya yerine birçok ayrı dosya olması işi kolaylaştırır.

Sunucunuzun yedek ve kurtarma planını birlikte kuralım. Otomatik yedekleme, offsite şifreli kopya ve test edilmiş bir geri yükleme akışı tasarlamak için benimle iletişime geçin.