aslain.dev
0%
01 Hizmetler 02 Hakkımda 03 Projeler 04 Stack 05 Blog 06 İletişim
← Tüm makaleler Metin2

Metin2 Backup: mysqldump ve Cron ile Otomatik Yedekleme

Bir Metin2 backup stratejisi olmadan sunucu işletmek, kaza anını beklemekten ibarettir. Bir disk hatası, yanlış bir DELETE sorgusu ya da başarısız bir tablo değişikliği; oyuncuların aylar süren ilerlemesini saniyeler içinde silebilir. İyi haber şu: MySQL'in kendi araçlarıyla, ücretsiz ve birkaç satır kabuk koduyla tam otomatik, sıkıştırılmış ve zamanlanmış yedekleme kurabilirsin. Bu rehberde mysqldump ve cron kullanarak Linux tabanlı bir Metin2 sunucusunda hangi veritabanlarının neden ve nasıl yedeklenmesi gerektiğini adım adım anlatıyorum.

Metin2 hangi veritabanlarını kullanır?

Klasik bir Metin2 kurulumunda oyun mantığı genellikle birkaç ayrı şemaya bölünür. Birebir isimler dağıtıma göre değişebilir, ama tipik olarak şunları görürsün:

  • account — kullanıcı hesapları, parolalar, e-posta ve ban bilgileri.
  • player — karakterler, envanter, item'lar, lonca verileri, quest durumu. En kritik ve en sık değişen şema budur.
  • common — item proto, shop, mob ve ortak konfigürasyon tabloları.
  • log — ticaret, drop ve oyuncu hareket kayıtları. Genellikle büyük ama kayıp halinde oyunu durdurmaz.

Pratikte account ve player şemaları altın değerindedir; bir veri kaybında oyuncu tepkisi doğrudan bunlara bağlıdır. common şemasını da yedeklemelisin çünkü item ayarlarındaki manuel değişikliklerin tek kopyası orada olabilir.

mysqldump ile tek seferlik yedek almak

İlk olarak elle bir yedek alıp aracın çalıştığını doğrulayalım. mysqldump bütün şemayı, çalışan sunucuyu durdurmadan tutarlı bir SQL dosyasına döker:

mysqldump -u root -p \
  --single-transaction --quick \
  --routines --triggers \
  player > player.sql

Önemli bayraklar:

  • --single-transaction: InnoDB tablolarında, tabloları kilitlemeden tutarlı bir anlık görüntü alır. Metin2 player şemasındaki canlı veriyi yedeklerken oyunun donmaması için kritik.
  • --quick: Büyük tabloları satır satır akıtır, RAM'i şişirmez.
  • --routines --triggers: Stored procedure ve trigger'ları da dahil eder.

Birden çok şemayı tek dosyada toplamak için --databases kullanabilirsin:

mysqldump -u root -p --single-transaction --quick \
  --routines --triggers \
  --databases account player common > metin2_full.sql

Not: Eğer MyISAM tabloların varsa --single-transaction onlarda tutarlılık garanti etmez; o durumda yedek anında yazma trafiğinin düşük olması ya da --lock-tables kullanılması gerekir.

Yedekleme betiği yazmak

Otomasyon için yeniden kullanılabilir bir kabuk betiği hazırlayalım. Tarihli dosya adı, sıkıştırma ve eski yedekleri temizleme mantığını tek yere koyuyoruz. /usr/local/bin/metin2-backup.sh olarak kaydet:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/var/backups/metin2"
DBS="account player common"
KEEP_DAYS=14
STAMP=$(date +%F_%H%M)

mkdir -p "$BACKUP_DIR"

for DB in $DBS; do
  mysqldump --defaults-extra-file=/root/.my.cnf \
    --single-transaction --quick \
    --routines --triggers "$DB" \
    | gzip > "$BACKUP_DIR/${DB}_${STAMP}.sql.gz"
done

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

Parolayı betiğe gömmek yerine --defaults-extra-file ile ayrı bir kimlik dosyasından okuyoruz. /root/.my.cnf şöyle görünür ve sadece root okuyabilecek izinlere sahip olmalı:

[client]
user=root
password=GUCLU_BIR_PAROLA
chmod 600 /root/.my.cnf
chmod 700 /usr/local/bin/metin2-backup.sh

set -euo pipefail satırı betiği güvenli kılar: bir komut hata verirse betik durur, böylece bozuk veya yarım bir yedek sessizce üretilmez.

Cron ile zamanlama

Betiği elle çalıştırıp ls -lh /var/backups/metin2 ile .sql.gz dosyalarının oluştuğunu gördükten sonra zamanlamaya geçebiliriz. Root'un crontab'ını düzenle:

crontab -e

Her gece 04:00'te tam yedek, her 6 saatte bir ek yedek almak için:

# dk sa gün ay haftagünü  komut
0 4 * * *   /usr/local/bin/metin2-backup.sh >> /var/log/metin2-backup.log 2>&1
0 */6 * * * /usr/local/bin/metin2-backup.sh >> /var/log/metin2-backup.log 2>&1

Çıktıyı bir log dosyasına yönlendirmek (>> ... 2>&1) önemlidir; bir gün yedek başarısız olduğunda nedenini orada görürsün. Sunucu sahnesinin yoğun olduğu saatlerden kaçınmak için tam yedeği oyuncu trafiğinin en düşük olduğu zamana koy.

Off-site kopya ve doğrulama

Aynı makinedeki yedek, makine çökerse seninle birlikte gider. Yedekleri başka bir sunucuya ya da nesne depolamaya kopyala. Basit bir rsync satırını betiğin sonuna ekleyebilirsin:

rsync -az "$BACKUP_DIR/" backup@yedek-sunucu:/metin2/

En çok atlanan adım ise geri yükleme testidir. Hiç denenmemiş bir yedek, yedek sayılmaz. Ayda bir, yedeği boş bir test veritabanına geri yükleyip içine bakmayı alışkanlık edin:

gunzip < player_2026-06-28_0400.sql.gz | mysql -u root -p player_test

Tablo sayısı, son karakterler ve item kayıtları beklediğin gibiyse yedeğin gerçekten işe yaradığından emin olursun.

Sık Sorulan Sorular

Yedek alırken sunucuyu kapatmam gerekir mi?

InnoDB tabloları için hayır. --single-transaction tutarlı bir anlık görüntü aldığı için oyun açık kalabilir. MyISAM tablolarında ise tam tutarlılık için kısa süreli bir kilit veya düşük trafik anı tercih edilmelidir.

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

player şeması en az günde bir, mümkünse 6 saatte bir yedeklenmeli; çünkü kayıp en çok burada hissedilir. common ve account daha az değiştiğinden günlük yedek genellikle yeterlidir. Kaç saatlik veri kaybını göze alabileceğine göre aralığı ayarla.

Sıkıştırma performansı etkiler mi?

gzip dump anında çalışır ve CPU kullanır, ama disk yazımını çok azalttığı için net etki genelde olumludur. Çok büyük şemalarda gzip yerine paralel çalışan pigz ile süreyi belirgin biçimde kısaltabilirsin.

Sunucunu kayıplara karşı sağlama almak mı istiyorsun? Metin2 altyapın için otomatik yedekleme, izleme ve felaket kurtarma kurulumunda yardıma ihtiyacın olursa benimle iletişime geç — verini kaybetmeden uyumana yardımcı olayım.

Bu kategorideki tüm yazılar →

Devamı için