CoreProtect Kurulumu ve Kullanımı (Grief Geri Alma)

CoreProtect kurulumu, bir Minecraft sunucusunda yapılacak işler listesinin en üstünde olması gereken maddedir: eklentinin jar dosyasını plugins klasörüne kopyalar, sunucuyu yeniden başlatırsınız ve o andan itibaren her blok yerleştirme, blok kırma, sandık işlemi, öldürme ve komut kullanımı veritabanına yazılmaya başlar. Kurulum sonrası hiçbir ayar yapmadan bile çalışır. Asıl iş, kaydı okumayı ve /co rollback komutunu doğru kullanmayı öğrenmekte.

Minecraft grief geri alma işinin tamamı bu eklentiye dayanır. Bir oyuncu gece spawn’ı yakıp gittiğinde ya da ortak sandıktan elmaslar kaybolduğunda elinizdeki tek kanıt CoreProtect kaydıdır. Kayıt yoksa tartışma tahmin yürütmeye döner ve genelde masum biri ceza alır.

Şunu baştan söyleyelim: CoreProtect geçmişi kaydetmez, kurulduğu andan itibaren kayıt tutar. Grief olduktan sonra kurmanın hiçbir faydası yok. Sunucuyu açtığınız ilk gün kurun.

CoreProtect Ne Yapar, Neyi Yapmaz?#

CoreProtect bir kayıt (logging) ve geri alma eklentisidir. Dünyada olan biteni satır satır bir veritabanına yazar, sonra bu kayıtları filtreleyerek sorgulamanıza ve seçtiğiniz aralığı geri sarmanıza izin verir. Kaydettiği başlıca olaylar şunlardır:

• Blok yerleştirme ve kırma (oyuncu eliyle veya patlamayla)
• Sandık, fırın, hopper ve varil gibi konteynerlere giren/çıkan eşyalar
• Kapı, düğme, levye, basınç plakası gibi etkileşimler
• Yerde bırakılan ve alınan eşyalar
• Oyuncu ve varlık ölümleri
• Sohbet mesajları, çalıştırılan komutlar, giriş/çıkış oturumları
• Tabela metinleri, sıvı akışı, ateşin yaydığı yanma

Yapmadığı şeyler de var. CoreProtect koruma eklentisi değildir: bir bölgeyi kilitlemez, blok kırmayı engellemez, arazi sistemi kurmaz. Onun işi olan biteni yazmak ve geri sarmaktır. Engelleme tarafı için WorldGuard ile bölge koruma, yetki daraltma tarafı için LuckPerms ile izin sistemi kurmanız gerekir. Bu üçü birlikte anlamlı.

Sürüm Uyumluluğu: 26.2 Sunucularında Durum#

Burası kritik. Minecraft 26.1 “Tiny Takeover” ile birlikte Mojang obfuscated sunucu jar’ı yayımlamayı bıraktı; bu, basit bir sürüm atlaması değil bir ABI kırılmasıdır. 1.21.11 ve öncesi için derlenmiş, sunucunun iç yapısına dokunan hiçbir eklenti yeniden derlenmeden 26.x üzerinde çalışmaz. CoreProtect de bu geçişten payını aldı.

26.2’ye geçmeyi planlıyor ama kayıt katmanından vazgeçemiyorsanız iki seçeneğiniz var: yükseltmeyi erteleyip 26.1.2 hattında kalmak ya da 26.2’ye çıkıp CoreProtect’siz yaşamayı göze almak. İkincisini önermiyoruz. Sürüm geçişini planlarken 26.2 kurulum ve güncelleme sayfasındaki eklenti kontrol listesini önden geçirin.

CoreProtect Kurulumu ve İlk Çalıştırma#

İndirmeniz gereken dosyalar#

Kurulum adımları#

1. Jar dosyasını plugins klasörüne kopyalayın#

   İndirdiğiniz CoreProtect-x.x.jar dosyasını sunucu kök dizinindeki plugins klasörüne atın. Panelli sunucularda dosya yöneticisini, kendi VDS’nizde SFTP istemcisini kullanabilirsiniz.

2. Sunucuyu düzgün kapatıp açın#

   Konsolda /reload kullanmayın; veritabanı bağlantısı açan eklentilerde bu komut yarım kalmış bağlantılara ve bellek sızıntısına yol açar. Doğrusu stop yazıp süreci düzgün sonlandırmak ve başlatma betiğini yeniden çalıştırmaktır.

   stop

3. İlk açılışta oluşan dosyaları kontrol edin#

   Sunucu açıldığında plugins/CoreProtect/ klasörü, içinde config.yml ve SQLite veritabanı dosyasıyla birlikte oluşur. Kayıt tutma bu andan itibaren başlar.

4. Çalıştığını doğrulayın#

   Oyun içinde bir blok kırın, sonra konsolda ya da oyunda aşağıdaki komutu çalıştırın. Sürüm bilgisi ve veritabanı durumu yazıyorsa kurulum tamamdır.

   /co status

5. Ayarları düzenleyip yeniden yükleyin#

   config.yml üzerinde değişiklik yaptıktan sonra sunucuyu yeniden başlatmanıza gerek yok; /co reload yeterli. Veritabanı türünü değiştirdiyseniz (SQLite → MySQL) tam yeniden başlatma gerekir.

   /co reload

config.yml içinde ilk bakılacak satırlar#

Varsayılan yapılandırma çalışır durumdadır. Yine de üretim sunucusunda şu satırlara bir kez göz atmakta fayda var:

# Veritabanı seçimi
use-mysql: false
mysql-host: 127.0.0.1
mysql-port: 3306
mysql-database: coreprotect
mysql-username: mcuser
mysql-password: guclu-bir-parola

# Kayıtlar kaç gün saklansın (0 = sonsuz)
purge-interval: 45

# Varsayılan ve azami yarıçap
default-radius: 10
max-radius: 100

# Hangi olaylar kaydedilsin
block-break: true
block-place: true
container-transactions: true
item-transactions: true
player-interactions: true
natural-breaks: false
liquid-tracking: true

natural-breaks: false satırı görünüşte küçük ama etkisi büyük: yaprak çürümesi ve benzeri doğal kırılmalar kapatıldığında veritabanı belirgin biçimde yavaş şişer. max-radius ise yanlışlıkla dev bir rollback çalıştırılmasını engelleyen bir emniyet kemeridir; 100 makul bir üst sınır.

Veritabanı Seçimi, Saklama Süresi ve Disk Faturası#

SQLite mi MySQL mi?#

CoreProtect varsayılan olarak SQLite kullanır ve tek sunuculu, mütevazı oyuncu sayılı kurulumlarda bu tamamen yeterlidir. Ek kurulum yok, ek servis yok, tek dosya. Ama her senaryoda doğru tercih değil.

MySQL şu üç durumda gerçekten şarttır: ağdaki birden fazla sunucunun kaydını tek havuzda toplamak istediğinizde, veritabanını oyun sunucusundan ayrı bir makinede tutmak istediğinizde ve kayıtları dışarıdan sorgulayan bir panel ya da rapor sisteminiz olduğunda. Diğer hâllerde SQLite’ta kalmak sizi hiçbir şeyden mahrum bırakmaz — ve işin aslı, çoğu sunucu hala SQLite ile gayet iyi çalışıyor.

Geçiş yapacaksanız önce veritabanını ve kullanıcıyı oluşturun, ardından use-mysql: true yapıp sunucuyu yeniden başlatın. Adım adım MySQL kurulumu ve kullanıcı yetkilendirme için Minecraft sunucusuna MySQL bağlama sayfasını kullanın.

CREATE DATABASE coreprotect CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'mcuser'@'127.0.0.1' IDENTIFIED BY 'guclu-bir-parola';
GRANT ALL PRIVILEGES ON coreprotect.* TO 'mcuser'@'127.0.0.1';
FLUSH PRIVILEGES;

Veri saklama süresi (purge) ve disk faturası#

CoreProtect yazma yoğun bir eklentidir. Her blok değişikliği bir satır demektir ve aktif bir survival sunucusunda günlük satır sayısı milyonlarla ifade edilir. Kimse size “şu kadar GB olur” diyemez çünkü bu tamamen oyuncu davranışına bağlı — ama şu kesin: sınırsız saklamaya bırakırsanız er ya da geç disk doluyor.

İki temizleme yöntemi var. Birincisi config.yml içindeki purge-interval değeriyle otomatik temizlik, ikincisi elle çalıştırılan komut:

# 30 günden eski tüm kayıtları sil
/co purge t:30d

# Sadece sohbet kayıtlarını temizle
/co purge t:7d a:chat

# Belirli bir dünyanın kayıtlarını temizle
/co purge t:14d r:#etkinlik_dunyasi

45 gün önermemizin sebebi şu: sinsi grief — tek blok redstone torch, gizli su kaynağı, temele konmuş kum — ortalama iki-üç hafta sonra fark ediliyor. 7 günlük saklama süresi bu olayların çoğunu kaçırır. 180 gün gibi bir değer ise disk faturasını gereksiz şişirir.

/co inspect ile Blok Geçmişini Okuma#

İnceleme modu CoreProtect’in en çok kullanılan özelliği. Komutu yazdığınızda mod açılır, tekrar yazdığınızda kapanır:

/co inspect

Mod açıkken şunlar olur:

• Sola tıkladığınız blok: o konumdaki blokla ilgili geçmiş listelenir — kim koydu, kim kırdı, ne zaman.
• Sağa tıkladığınız blok: o bloğun üzerindeki boşluğun geçmişi gösterilir. Yani “buraya ne konmuştu, kim aldı” sorusunun cevabı.
• Sandığa sağ tıklarsanız: konteyner işlem kaydı açılır; hangi oyuncu hangi eşyayı ne zaman koymuş veya almış, tek tek görürsünüz.

Çıktıdaki zaman damgaları 2.5 saat önce gibi göreli biçimdedir. Satırın başındaki - işareti kırma/alma, + işareti koyma/bırakma anlamına gelir. İnceleme modu açıkken normal blok kırma çalışmaz; işiniz bitince kapatmayı unutmayın (kapatmayı unutup “bloklar kırılmıyor” diye destek talebi açan çok oldu).

/co lookup Parametreleri ve Komut Referansı#

Inspect tek bir noktaya bakar; lookup ise filtreli toplu sorgu yapar. Asıl güç burada. Önce komutların tamamı:

Sorgu parametreleri her komutta aynı şekilde çalışır — lookup, rollback, restore ve purge hepsi aynı dili konuşur:

a: parametresinin alabileceği değerler bir soruşturmanın hızını doğrudan belirler:

# Ahmet son 6 saatte 50 blok yarıçapta ne kırdı?
/co lookup u:Ahmet t:6h r:50 a:-block

# Spawn'daki sandıklara son 2 günde kim dokundu?
/co l t:2d r:30 a:container

# Sunucu genelinde son 1 saatte kim TNT koydu?
/co l t:1h r:#global b:tnt a:+block

# Ahmet dışında herkesin son 12 saatteki blok hareketleri
/co l t:12h r:100 a:block e:u:Ahmet

Sonuçlar sayfa sayfa gelir; sonraki sayfa için /co l 2 yazmanız yeterli. Sorgu ne kadar dar olursa cevap o kadar hızlı döner, bu yüzden r:#global ile t:30d gibi iki geniş parametreyi aynı anda kullanmaktan kaçının.

/co rollback ve /co restore Farkı#

İkisi de aynı parametreleri alır, ama yönleri terstir:

rollback

Filtreye uyan değişiklikleri geri alır. Kırılan bloklar geri gelir, konan bloklar kalkar, alınan eşyalar sandığa döner.

restore

Aynı değişiklikleri yeniden uygular. Yani bir rollback’in tam tersi; “redo” tuşu gibi düşünün.

Doğru kullanım alışkanlığı şudur: rollback komutunu yazmadan önce birebir aynı parametrelerle bir lookup çalıştırın. Listeyi gözden geçirin, satır sayısına ve isimlere bakın. Beklediğinizden fazla satır varsa yarıçapı veya süreyi daraltın. Sonra sadece fiili değiştirip komutu tekrar çalıştırın.

# 1) Önce gör
/co lookup u:Ahmet t:3h r:40

# 2) Sonra geri al
/co rollback u:Ahmet t:3h r:40

Yanlış rollback’i geri alma#

Herkesin başına gelir: yarıçapı 40 yerine 400 yazarsınız ve yarım köyü silersiniz. Panik yok — çözüm basit. Aynı filtreleri kullanarak restore çalıştırın:

# Yanlışlıkla çalıştırılan komut
/co rollback u:Ahmet t:3h r:400

# Onu geri almak için birebir aynı parametrelerle
/co restore u:Ahmet t:3h r:400

Rollback her derde deva değil. Saldırı birden fazla hesapla yapılmışsa, olay saklama süresinin dışında kalmışsa ya da veritabanı bozulmuşsa tek çareniz yedektir. Düzenli yedek planınız yoksa sunucu yedekleme rehberini okumadan devam etmeyin.

Grief Soruşturması: Baştan Sona Bir Senaryo#

Diyelim ki sabah konsolu açtınız ve spawn’ın yanındaki ortak depo yanmış, sandıklar boş. Elinizde bir isim bile yok. İzlenecek sıra şu:

1. Olay yerine gidip inceleme modunu açın#

   Yanan bölgeye gidin, /co inspect yazın ve tahrip görmüş bir bloğa sola tıklayın. Çıkan satırda hem kullanıcı adı hem zaman damgası vardır. Bir isim yakaladıysanız iş kolaylaştı.

2. Zaman aralığını daraltın#

   Damgaya bakıp olayın kaç saat önce olduğunu belirleyin. Sonra o aralıkta bölgeyi tarayın. Yarıçapı olay yerinin büyüklüğüne göre seçin, gereğinden geniş tutmayın.

   /co lookup t:8h r:60 a:block

3. Sandık kayıtlarını ayrıca sorgulayın#

   Blok kaydı ile konteyner kaydı ayrı şeylerdir. Eşyaların nereye gittiğini görmek için konteyner işlemlerini tek başına listeleyin.

   /co l t:8h r:60 a:-container

4. Şüphelinin diğer izlerine bakın#

   Bir isim elinizdeyse o oyuncunun aynı aralıktaki komutlarını, sohbetini ve oturum kayıtlarını okuyun. Grief yapan hesap genelde önce bir arkadaşını çağırır, sonra /sethome benzeri komutlarla kaçış hazırlığı yapar.

   /co l u:Supheli t:8h a:command
   /co l u:Supheli t:8h a:chat
   /co l u:Supheli t:24h a:session

5. Geri almadan önce son kez doğrulayın#

   Rollback komutunu yazacağınız parametrelerle bir kez daha lookup çalıştırın ve listeyi okuyun. Masum bir oyuncunun aynı bölgede yaptığı inşaat da listede görünüyorsa yarıçapı küçültün ya da e:u: ile o oyuncuyu hariç tutun.

6. Geri alın ve cezayı uygulayın#

   Dünya düzeldikten sonra sıra hesabı kapatmaya gelir. Süreli ban, mute ve ceza geçmişi için LiteBans kurulumu ve ceza yönetimi sayfasındaki komutları kullanabilirsiniz.

   /co rollback u:Supheli t:8h r:60

İzinleri kimlere vermeli?#

CoreProtect izinleri sade: inceleme ve sorgulama ayrı, geri alma ayrı. Moderatörlere ilk ikisini verin, üçüncüsünü vermeyin.

/lp group moderator permission set coreprotect.inspect true
/lp group moderator permission set coreprotect.lookup true
/lp group moderator permission set coreprotect.rollback false
/lp group yonetici permission set coreprotect.rollback true

Son satırdaki ayrım önemli. Rollback yıkıcı bir işlemdir ve tecrübesiz bir elde yanlış yarıçapla çalıştırıldığında masum oyuncuların haftalarca uğraştığı yapıları siler. Moderatör kanıtı toplasın, geri almayı siz yapın. Yetkili ekibini kurarken bu ayrımı en baştan anlatmak sonradan çıkacak tartışmaların yarısını önlüyor.

Donanım ve Disk Notu#

CoreProtect’in getirdiği yük tamamen disk I/O tarafındadır. Her blok değişikliği bir yazma işlemi demek. Chunk okuma/yazma gecikmesinin üstüne bir de veritabanı yazması binince takılmalar kaçınılmaz oluyor — bu yüzden NVMe SSD şart, en az 50 GB alan planlayın; MySQL de kullanıyorsanız 100 GB ve üzeri daha rahat ettirir.

Java heap’ini pakete göre verin: 8 GB pakette -Xms6G -Xmx6G, 12 GB pakette -Xms10G -Xmx10G, 16 GB pakette -Xms14G -Xmx14G. İşletim sistemine ve MySQL sürecine pay bırakmazsanız yoğun yazma anında takılma yaşarsınız. Oyuncu sayısına göre ayrıntılı hesap RAM tablosunda; hazır kurulu Paper ve eklenti paketleri için Batihost Minecraft sunucu paketlerine bakabilirsiniz.

Özetle#

CoreProtect kurulumu jar’ı plugins klasörüne atmakla biter ama işin asıl kısmı sonrasında. Sıralamayı şöyle kurun: sürüm uyumunu doğrulayın (26.2’de henüz desteklenmediğini unutmayın), sunucuyu düzgün kapatıp açın, config.yml içinde saklama süresini ve gürültülü olay kayıtlarını ayarlayın, tek sunucudaysanız SQLite’ta kalın, ağdaysanız MySQL’e geçin.

Komut tarafında ezberlenecek şey az: /co inspect ile tek noktaya bak, /co lookup ile filtreli sorgu çek, sonuç doğruysa aynı parametreleri /co rollback’a taşı. Yanlış giderse /co restore ile aynı filtrelerden geri dön. Rollback iznini dar tutun, düzenli yedek alın ve şunu aklınızdan çıkarmayın: kayıt tutmayan sunucuda grief soruşturması diye birşey yoktur, sadece tahmin vardır.

Bir sonraki adım koruma katmanını kurmak. Griefing nasıl önlenir sayfası, buradaki kayıt altyapısının üstüne bölge koruma ve yetki daraltma eklemenizi anlatıyor; takıldığınız bir yer olursa destek talebi açabilirsiniz.