Kısa cevap: Netsis yedekleme hatalarının en sık nedenleri hedef diskin dolması, SQL Server servis hesabının yedek klasörüne yazma izninin olmaması, üçüncü parti yedekleme ajanlarının log zincirini kırması ve alınan yedeğin hiç test edilmemesidir. Çözüm: yedek hedefini ve izinleri düzeltin, tek bir yedekleme stratejisinde (Full + Differential + Log) karar kılın ve her yedeği
RESTORE VERIFYONLYile doğrulayın.
“Yedeğimiz var” cümlesi ile “geri dönebileceğimiz yedeğimiz var” cümlesi arasındaki farkı, firmalar maalesef en kötü günde öğrenir. Bu yazıda Netsis veritabanı yedeği alınırken karşılaşılan hataları ve sessizce bozulan yedek düzenlerini ele alıyoruz. Yedeğiniz sağlam ama geri dönmeniz gerekiyorsa yedek geri yükleme rehberimiz tam da bunun için yazıldı.
Hata 1: Yedek Alınamıyor — Disk Dolu
Belirti: Yedekleme işi disk alanı yetersizliği hatasıyla kesiliyor ya da yedek dosyası yarım kalıyor.
Çözüm adımları:
- Hedef diskteki boş alanı kontrol edin; tam yedek için en az veritabanının veri boyutu kadar alan gerekir
- Eski yedek dosyalarını otomatik silen bir saklama (retention) kuralı tanımlayın — elle silmeye dayalı düzen er geç dolar
- Yedek sıkıştırmasını (backup compression) açın; Netsis veritabanlarında yedek boyutunu ciddi ölçüde küçültür
- Yedekleri veritabanıyla aynı diske almayı bırakın: hem alan sorununu büyütür hem de disk arızasında yedeğinizi de kaybedersiniz
Hata 2: Erişim İzni Hatası (Operating System Error 5)
Belirti: Yedekleme “Access is denied” / işletim sistemi hatası 5 benzeri bir mesajla başarısız oluyor.
Çözüm adımları:
- Yedeği alan SQL Server servis hesabının hedef klasörde yazma izni olduğunu kontrol edin — sizin Windows kullanıcınızın izni değil, servis hesabının izni geçerlidir
- Ağ paylaşımına yedek alıyorsanız paylaşım ve NTFS izinlerinin ikisini birden doğrulayın; servis hesabı yerel hesapsa ağ paylaşımına erişemeyebilir
- Hedef klasör yolunu UNC biçimiyle (
\\SUNUCU\Yedek) test edin ve yolu SQL tarafında bu biçimle tanımlayın
Hata 3: Transaction Log Yedeği Alınamıyor veya Log Zinciri Kırık
Belirti: Log yedeği hata veriyor ya da restore sırasında log zincirinin koptuğu ortaya çıkıyor.
Çözüm adımları:
- Veritabanının kurtarma modelini kontrol edin: log yedeği yalnızca Full recovery modelinde alınabilir; Simple modelde log yedeği anlamsızdır
- Ortamda birden fazla yedekleme mekanizması çalışıyorsa (SQL bakım planı + üçüncü parti ajan + sanallaştırma yedeği) hangisinin “resmi” yedek olduğuna karar verin — birden fazla araç aynı veritabanının log zincirini bölebilir
- Üçüncü parti araçlarda SQL yedeklerini “copy-only” moda alın ya da SQL tarafındaki log yedeğini tek yetkili yöntem yapın
- Zincir kırıldıysa vakit kaybetmeden yeni bir tam yedek alın; zincir ancak tam yedekle yeniden başlar
Log dosyasının kontrolsüz büyümesi de çoğu zaman aynı kök nedene bağlıdır; detaylar için transaction log şişmesi yazımıza bakın.
Hata 4: Yedek Var Ama Açılmıyor (Bozuk Yedek)
Belirti: Yedek dosyası duruyor; ancak geri yükleme denemesinde medya/bozulma hatası alıyorsunuz.
Çözüm adımları:
- Her yedeği alındıktan sonra doğrulayın:
RESTORE VERIFYONLY FROM DISK = 'D:\Yedek\NETSIS.bak' - Yedek alma komutuna
WITH CHECKSUMekleyerek yazım sırasındaki bozulmaların anında yakalanmasını sağlayın - Kaynak veritabanının kendisinde bozulma olabilir: düzenli
DBCC CHECKDBçalıştırın — bozuk veritabanının yedeği de bozuktur - Yedek dosyalarını e-posta/USB ile elden taşımak yerine otomatik kopyalama kullanın; kopyalama sırasında kesilen dosyalar sessizce bozulur
Görünmeyen Hata: Yedek “Alınıyor” Ama Plan Çalışmıyor
En tehlikeli senaryo hata mesajı olan değil, olmayan senaryodur: bakım planı aylar önce durmuş, kimse fark etmemiştir.
- ✅ Yedek işinin başarı/başarısızlık bildirimi olsun (e-posta veya izleme aracı)
- ✅ Yedek dosyasının tarihini ve boyutunu haftalık kontrol edin; boyutun anormal küçülmesi alarm işaretidir
- ✅ Ayda bir gerçek restore testi yapın: yedeği test ortamına açın, Netsis ile bağlanıp güncel kayıtları görün
- ✅ 3-2-1 kuralını uygulayın: en az 3 kopya, 2 farklı ortam, 1 kopya kurum dışında (bulut/uzak lokasyon)
Netsis İçin Önerdiğimiz Yedek Stratejisi
| Yedek Türü | Sıklık | Amaç |
|---|---|---|
| Full (tam) | Günlük (gece) | Ana geri dönüş noktası |
| Differential | Gün içi (öğle) | Restore süresini kısaltma |
| Transaction Log | 15-60 dakikada bir | Veri kaybını dakikalara indirme |
Bu tablo tipik bir KOBİ yapısı içindir; vardiyalı üretim veya yoğun fatura kesen firmalarda log sıklığı artırılır.
Yedeğin işe yaradığını kanıtlayan tek şey düzenli restore testidir. 2018’den beri yetkili bayi olarak müşterilerimizin yedek düzenini kurup izliyoruz; yedekleme kurulumunuzu denetletmek veya izlemeye almak için Netsis destek paketlerimize göz atabilirsiniz.
Sıkça Sorulan Sorular
Netsis açıkken yedek alınabilir mi?
Evet. SQL Server online yedekleme yapar; kullanıcılar çalışırken tam veya log yedeği alınabilir. Ancak yoğun mesai saatinde tam yedek almak performansı etkileyebileceği için tam yedekleri gece saatlerine planlamak standarttır.
Sadece veritabanı dosyalarını (MDF/LDF) kopyalamak yedek sayılır mı?
Hayır. Çalışan bir SQL Server’ın MDF/LDF dosyalarını dosya kopyalamayla almak tutarsız, çoğu zaman açılamayan bir kopya üretir. Yedek her zaman BACKUP DATABASE komutu veya bunu kullanan bir araçla alınmalıdır.
Yedekleri ne kadar süre saklamalıyız?
Teknik geri dönüş için birkaç haftalık zincir çoğu senaryoya yeter; ancak mali verilerde yasal saklama yükümlülükleri vardır ve dönem sonu yedeklerini (özellikle yıl sonu kapanış öncesi) uzun süreli arşivde ayrıca saklamak gerekir. Saklama planını mali müşavirinizle birlikte netleştirin.
Bulut yedeği yeterli mi, yerel yedek şart mı?
İkisi birlikte en sağlıklısıdır: yerel yedek hızlı geri dönüş sağlar, bulut/uzak kopya yangın-hırsızlık-fidye yazılımı senaryolarında kurtarır. Fidye yazılımları yerel yedek klasörlerini de şifrelediği için en az bir kopyanın sunucudan erişilemeyen bir hesapta durması kritik önemdedir.