Netsis Yedek Geri Yükleme: Veri Kaybında Acil Müdahale Rehberi

Kısa cevap: Netsis veritabanını yedekten geri yüklemek için önce mevcut bozuk durumun yedeğini alın, sonra SQL Server’da RESTORE DATABASE ... WITH NORECOVERY ile full yedeği, ardından differential ve transaction log yedeklerini sırayla geri yükleyip son adımda RECOVERY ile veritabanını açın. Doğru yedek zinciriyle sistem 1-2 saatte çalışır hale gelir.

Veri kaybı yaşadıysanız panik yok — doğru yedek stratejiniz varsa 1-2 saat içinde sistemi geri getirebilirsiniz. Bu rehberde restore senaryolarını, transaction log replay ve veri tutarlılık kontrollerini anlatıyoruz.

⚠️ İlk yapacağınız: Mevcut bozuk veritabanına müdahale etmeyin. Önce mevcut hâliyle (bozuk dahi olsa) bir yedek alın. Restore başarısız olursa geri dönüş için bu yedek hayatınızı kurtarabilir.

Senaryo 1: Mantıksal Veri Kaybı

Yanlış silinen kayıt, hatalı toplu güncelleme gibi durumlar. Veritabanı sağlam, sadece içerik bozulmuş.

Çözüm

Adım 1: Point-in-time restore

Eğer FULL recovery model kullanıyorsanız hatadan önceki ana dönüş mümkün:

RESTORE DATABASE [NETSIS_DB] FROM DISK = "C:\Backup\netsis_full.bak" WITH NORECOVERY;
RESTORE LOG [NETSIS_DB] FROM DISK = "C:\Backup\netsis_log.trn" WITH STOPAT = "2026-04-30 14:30:00", RECOVERY;

Senaryo 2: Veritabanı Bozulması (Suspect)

Disk hatası, ani elektrik kesintisi veya SQL crash sonrası DB SUSPECT durumuna düşer.

Çözüm

-- Adım 1: Emergency mode
ALTER DATABASE [NETSIS_DB] SET EMERGENCY;
ALTER DATABASE [NETSIS_DB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

-- Adım 2: DBCC CHECKDB
DBCC CHECKDB ([NETSIS_DB]);

-- Adım 3: Repair (en az veri kaybıyla)
DBCC CHECKDB ([NETSIS_DB], REPAIR_REBUILD);

-- Adım 4: Veri kaybı kabul edilebilirse
DBCC CHECKDB ([NETSIS_DB], REPAIR_ALLOW_DATA_LOSS);

-- Adım 5: Multi-user moda dön
ALTER DATABASE [NETSIS_DB] SET MULTI_USER;

Senaryo 3: Tam Veritabanı Kaybı

Sunucu çökmesi, disk hatası, ransomware vb. — DB tamamen kaybedildi.

Çözüm

Adım 1: Yeni SQL Server kurulumu

Yeni sunucu/yeni disk üzerine SQL Server kurun. Versiyon eski ile aynı veya daha yeni olmalı.

Adım 2: Full backup restore

RESTORE DATABASE [NETSIS_DB] FROM DISK = "C:\Backup\netsis_full.bak" WITH REPLACE, NORECOVERY;

Adım 3: Differential restore (varsa)

RESTORE DATABASE [NETSIS_DB] FROM DISK = "C:\Backup\netsis_diff.bak" WITH NORECOVERY;

Adım 4: Log restore (varsa)

RESTORE LOG [NETSIS_DB] FROM DISK = "C:\Backup\netsis_log.trn" WITH RECOVERY;

Restore Sonrası Kontrol Listesi

1. DBCC CHECKDB çalıştırın → 0 hata bekleniyor
2. Kullanıcı bağlantı testi → Netsis client ile login
3. Son işlemler kontrolü → Beklenen son fişler görünüyor mu?
4. Stok dengesi testi → Birkaç stok kalemi karşılaştırma
5. Cari hesap kontrolü → Müşteri/satıcı bakiyeleri
6. Backup zinciri yeniden başlatma → Yeni full backup alın

Yedekleme Stratejisi (Önleme)

Tip	Sıklık	Amaç
Full backup	Haftalık (Pazar gece)	Komple geri dönüş
Differential	Her gün gece	Son full den fark
Transaction log	Saatlik	Saatlik geri dönüş

🛡️ Önemli not: Yedekleri farklı bir lokasyona (NAS, cloud, USB) kopyalayın. Aynı sunucuda saklanan yedek, sunucu çöktüğünde kayboluyor. Aylık restore testi yapın — yedekten dönmeyen yedek, yedek değildir.

Bu konuda profesyonel destek mi gerekiyor?

Logo Yazılım yetkili Netsis bayisi olarak 7/24 hizmetinizdeyiz. Daha kapsamlı koruma için Netsis bakım anlaşması, kurumsal Netsis teknik destek ve genel Netsis destek hizmetlerimizden yararlanabilirsiniz.

Sıkça Sorulan Sorular

Netsis yedeğini geri yüklemek ne kadar sürer?

Veritabanı boyutuna ve yedek zincirine bağlıdır; sağlam bir full + differential + log yedeğiniz varsa çoğu sistem 1-2 saat içinde tekrar çalışır hale gelir. Tam veritabanı kaybında (yeni SQL Server kurulumu dahil) bu süre yarım güne kadar uzayabilir.

FULL recovery model olmadan belirli bir saate geri dönebilir miyim?

Hayır. Point-in-time restore (örneğin STOPAT ile belirli bir saate dönüş) yalnızca FULL recovery model ve düzenli transaction log yedeği varsa mümkündür. SIMPLE recovery model’de yalnızca en son full veya differential yedeğe dönebilirsiniz.

DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS güvenli mi?

Bu komut bozuk sayfaları silerek veritabanını tutarlı hale getirir, ancak adından da anlaşılacağı gibi veri kaybına yol açabilir. Yalnızca sağlam bir yedekten geri dönüş mümkün değilse ve son çare olarak kullanılmalıdır; öncesinde mutlaka mevcut durumun bir kopyası alınmalıdır.

Yedeklerimi nereye saklamalıyım?

Yedekleri kesinlikle veritabanıyla aynı sunucuda tutmayın. Farklı bir lokasyona (NAS, bulut veya harici disk) kopyalayın ve aylık restore testi yaparak yedeğin gerçekten geri yüklenebildiğini doğrulayın.