Yedek almak işin yarısıdır; asıl sınav, gerektiğinde o yedekten doğru ve kontrollü şekilde geri dönebilmektir. Bu rehber, Netsis veritabanını yedekten geri yükleme kararının nasıl verileceğini, prosedürün adımlarını ve geri dönüş sonrası doğrulamayı anlatır. Yedek düzeninizi henüz kurmadıysanız önce Netsis yedekleme stratejisi dokümanını okuyun.
Yedekten Geri Dönme Ne Zaman Gerekir?
- Hatalı toplu işlem: Yanlış parametreyle çalıştırılan toplu fiyat güncelleme, hatalı devir, yanlış şirkette yapılan toplu kayıt
- Kapanış/devir sonrası tutarsızlık: Maliyet çalıştırılmadan yapılan kapanış gibi geri alınması güç işlemler
- Donanım ve disk arızası: Sunucu değişimi, disk kaybı, dosya bozulması
- Zararlı yazılım: Fidye yazılımı sonrası temiz yedekten kurtarma
- Veritabanı açılmıyor: Suspect durumuna düşen veritabanında onarım başarısızsa (suspect mode çözümü)
- Planlı senaryolar: Sunucu taşıma ve test ortamı kurma (bunlar da aynı prosedürü kullanır)
Geri Dönmeden Önce: Karar Kontrol Listesi
Geri yükleme, son yedekten bu yana girilen tüm kayıtları siler. Bu yüzden karar aşaması prosedürün kendisinden daha önemlidir:
- Veri kaybı penceresini hesaplayın: Son sağlam yedek ne zaman alındı? O andan bu yana kaç saatlik kayıt girildi, bu kayıtlar yeniden girilebilir mi?
- Daha ucuz alternatif var mı? Sorun tek bir fiş veya sınırlı bir kayıt grubundaysa, düzeltme fişiyle onarmak çoğu zaman tüm veritabanını geri yüklemekten daha az maliyetlidir.
- Hangi yedeğe dönülecek? Tam yedek + fark (differential) + günlük (log) yedekleri zinciri varsa, en az veri kaybını veren nokta seçilir.
- Mevcut durumun da yedeğini alın: Bozuk görünen mevcut veritabanının o anki halini mutlaka ayrıca yedekleyin. Geri dönüş kararı yanlış çıkarsa dönebileceğiniz tek nokta budur.
Adım Adım Geri Yükleme Prosedürü
- Tüm kullanıcıların sistemden çıkışını sağlayın ve yeni kayıt girişini durdurun
- Mevcut veritabanının o anki halinin yedeğini alın (yukarıdaki 4. madde)
- Geri dönülecek yedek dosyasını belirleyin; tarih ve boyutunu doğrulayın, mümkünse önce test ortamında açarak içeriğini kontrol edin
- Geri yükleme SQL Server üzerinden yapılır: önce tam yedek, varsa üzerine fark ve günlük yedekleri sırayla yüklenir. Bu adım veritabanı yönetimi bilgisi gerektirir; ekibinizde yoksa bayinizden destek alın
- Geri yükleme sonrası veritabanı kullanıcı ve erişim eşlemelerini kontrol edin; Netsis’in veritabanına bağlanamaması bu aşamanın atlanmasından kaynaklanır
- Netsis’i açın: şirket/dönem seçimi, örnek kayıt görüntüleme ve bir rapor alma ile temel işlerliği doğrulayın
Geri Dönüş Sonrası Doğrulama
- Kayıp pencerenin sınırını netleştirin: Son fiş numaralarına ve kayıt tarihlerine bakarak hangi andan itibaren kayıtların eksik olduğunu belirleyin
- Yeniden giriş listesi çıkarın: Kayıp penceredeki işlemleri (fatura, tahsilat, irsaliye) kaynak belgelerden kullanıcılara yeniden girdirin
- e-Fatura mükerrerlik riski: Geri dönülen noktadan sonra gönderilmiş e-Belgeler GİB tarafında durmaya devam eder. Yeniden girilen faturaları göndermeden önce entegratör kayıtlarıyla karşılaştırın; aksi halde aynı belge iki kez gitmiş olur
- Entegrasyon senkronu: Banka, e-ticaret ve B2B bağlantılarının hangi tarihten itibaren yeniden eşitlenmesi gerektiğini kontrol edin
- Mizan kontrolü: Geri dönülen tarihin mizanını, o döneme ait bilinen doğru raporla karşılaştırın
Düzenli Restore Testi Rutini
Geri yüklenemeyen yedek, yedek değildir. Önerdiğimiz asgari rutin:
| Sıklık | İş |
|---|---|
| Her gün | Otomatik yedek işinin başarıyla tamamlandığının kontrolü |
| Her ay | Bir yedeğin test ortamına geri yüklenmesi, Netsis ile açılması ve mizan karşılaştırması |
| Her kapanış/yükseltme öncesi | Zorunlu tam yedek + restore doğrulaması |
Yedek işleri hata veriyorsa ertelemeden inceleyin; belirti ve çözümler için yedek alma hatası yazımıza bakın.
Prosedürü Yazılı Hale Getirin (Runbook)
Geri dönüş kararı çoğu zaman stresli bir anda, iş dururken verilir; o anda akıldan adım hatırlamak en riskli yöntemdir. Bu yüzden yukarıdaki prosedürü kendi ortamınıza uyarlanmış yazılı bir runbook’a dönüştürün ve şunları netleştirin:
- Yetki: Geri dönüş kararını kim verir, geri yüklemeyi kim yapar, kim bilgilendirilir?
- Konum: Yedek dosyaları hangi sunucuda ve hangi dış ortamda tutuluyor, erişim şifreleri nerede?
- Sıra: Hangi veritabanları hangi sırayla geri yüklenir, doğrulama adımları nelerdir?
- İletişim: Kullanıcılara ve yönetime kayıp penceresi nasıl duyurulur?
Runbook’u yılda en az bir kez, restore testiyle birlikte tatbikat olarak çalıştırın; belgede eksik çıkan her adımı test sırasında güncelleyin.
Sıkça Sorulan Sorular
Tek bir fişi kurtarmak için tüm veritabanını geri yüklemek gerekir mi?
Canlı sisteme geri yükleme gerekmez. Yedeği ayrı bir test ortamına yükleyin, ilgili kaydı orada görüntüleyin ve canlı sistemde düzeltme fişiyle işleyin. Böylece son yedekten bu yana girilen kayıtlar korunur.
Geri yükleme ne kadar sürer?
Veritabanı boyutuna ve disk hızına göre dakikalarla saatler arasında değişir. Asıl süreyi geri yüklemenin kendisi değil, sonrasındaki doğrulama ve eksik kayıtların yeniden girilmesi belirler.
Geri dönüş sonrası e-faturalar mükerrer gider mi?
Risk vardır. Geri dönülen noktadan sonra gönderilmiş belgeler GİB tarafında kayıtlıdır; yeniden girilen faturaları göndermeden önce entegratör panelindeki gönderilmiş belge listesiyle mutabakat yapın.
Yedek dosyası açılmıyor veya bozuk çıktıysa ne yapmalıyım?
Farklı ortamdaki kopyaları deneyin (3-2-1 kuralının değeri tam burasıdır) ve zincirdeki bir önceki tam yedeğe dönün. Bu senaryoyu yaşamamak için aylık restore testi rutinini atlamayın.
Restore işlemini kendi ekibimiz mi yapmalı, destek mi almalıyız?
Test ortamına geri yükleme gibi risksiz senaryoları kendi ekibinizle çalıştırıp deneyim kazanmanızı öneririz. Canlı sistemde, iş dururken yapılan geri dönüşlerde ise yedek zincirinin doğru sırayla yüklenmesi ve erişim eşlemeleri kritik olduğundan, ilk uygulamalarda yetkili bayi eşliğinde ilerlemek daha güvenlidir.
Acil veri kurtarma ve yerinde müdahale için Giza Teknoloji Netsis destek sayfasını inceleyebilir, sorularınız için iletişim sayfamızdan bize ulaşabilirsiniz.