İşletme Verileri
Veritabanı Kurtarma: SQL Server, MySQL ve Muhasebe Verileri
Program açılmıyor, servis başlamıyor, kayıtlar eksik görünüyor. Onarım komutlarına girişmeden önce verinizi koruyacak adımları birlikte atalım.
- Gizlilik sözleşmesi (NDA)
- Onayınız olmadan işlem yok
- Bursa’da laboratuvar
Ayın son günü, beyanname hazırlığı sürüyor ve muhasebe programı açılışta veritabanına bağlanamadığını söylüyor. Başka bir senaryoda online mağazanızın yönetim paneli boş bir sayfa gösteriyor, sunucu kayıtlarında anlamadığınız hata satırları birikiyor. Veritabanı sorunları işletmeyi doğrudan durdurur ve paniğe yol açar. Oysa bu anlarda yapılan aceleci onarım denemeleri, kurtarılabilecek kayıtları kalıcı olarak silebilir.
İlk bir saat içinde: Veritabanına yazan tüm kullanıcıları ve uygulamaları durdurun. Veritabanı servisini durdurun ve klasördeki tüm veri ile işlem günlüğü dosyalarını hiçbirini atlamadan ayrı bir diske kopyalayın. Ekrandaki hata mesajlarını ve sunucunun hata kayıtlarını saklayın. Kopya almadan hiçbir onarım komutu çalıştırmayın; eski bir yedeği mevcut dosyaların üzerine geri yüklemeyin. En son sağlıklı yedeğinizin tarihini not edin.
Sorun hangi katmanda?
Bir veritabanının “açılmaması” üç farklı düzeyde ortaya çıkan sorunların ortak belirtisi olabilir. Doğru yöntemi seçebilmek için önce hangisiyle uğraştığımızı belirleriz.
Donanım katmanı
Veritabanının durduğu disk okuma hatası veriyor, RAID dizisi bozulmuş ya da sunucu tamamen açılmıyor olabilir. Bu durumda dosyalar sağlam olsa bile okunamaz. Önce depolama ortamından güvenli bir kopya alınır, veritabanı dosyaları oradan çıkarılır. Bu aşama sunucu veri kurtarma ve RAID veri kurtarma süreçleriyle iç içe ilerler.
Dosya yapısı katmanı
Ani elektrik kesintisi, dolan disk veya yarıda kalan bir yazma işlemi sonrası veri sayfaları ile işlem günlüğü arasında tutarsızlık oluşur. Veritabanı motoru kendini güvenceye almak için erişimi keser. Kayıtların büyük kısmı çoğu zaman yerindedir; sorun, motorun onları tutarlı biçimde açamamasıdır.
Mantıksal katman
Veritabanı sorunsuz açılıyor ama bir tablo yanlışlıkla boşaltılmış, bir dönem silinmiş ya da hatalı bir toplu güncelleme kayıtları bozmuş olabilir. Burada silinen satırların izleri veri sayfalarında veya günlükte aranır; müdahale ne kadar erken olursa şans o kadar yüksektir.
Platformlara göre kısa notlar
- Microsoft SQL Server: Veriler MDF/NDF dosyalarında, değişiklik kayıtları LDF günlüğünde tutulur. “Suspect” veya “Recovery Pending” durumu genellikle bu iki parçanın birbirini tutmadığını gösterir. Veri kaybına izin veren onarım seçenekleri, adından da anlaşıldığı gibi bozuk sayfaları ve bağlı kayıtları gözden çıkarır; kopya üzerinde ve son çare olarak düşünülmelidir.
- MySQL ve MariaDB: InnoDB motorunda sistem tablo alanı, tablo dosyaları ve redo günlükleri birlikte çalışır. Servis başlamıyorsa zorlamalı kurtarma ayarlarının yüksek seviyeleri yeni hasara yol açabilir. Tablo tanımları kaybolsa bile veri sayfaları ayrıştırılarak satırlar yeniden oluşturulabilir.
- Muhasebe ve ERP programları: Logo, Mikro, Netsis gibi yaygın yazılımların güncel sürümleri verilerini çoğunlukla SQL Server üzerinde tutar. Biz programın kendisine değil, arkadaki veritabanına müdahale ederiz. Bu yazılımların üreticileri veya bayileriyle bir iş ortaklığımız bulunmaz; kurtarılan verinin programa yeniden bağlanmasında kendi bayinizle çalışmanız işi kolaylaştırır.
Bizimle iletişime geçerken hazırlayabilecekleriniz
Aşağıdaki bilgiler ön değerlendirmeyi hızlandırır ve size daha net bir tablo sunmamızı kolaylaştırır. Hepsini bilmiyorsanız sorun değil; eksikleri telefonda birlikte tamamlarız.
- Kullandığınız veritabanı sistemi ve sürümü, varsa muhasebe ya da ERP programının adı ve sürümü
- Sorun başlamadan hemen önce yaşananlar: elektrik kesintisi, güncelleme, disk uyarısı, toplu işlem gibi
- Ekran görüntüsü alınmış hata mesajları ve veritabanı dosyalarının toplam boyutu
- Elinizdeki en güncel yedeğin tarihi ve sizin için en öncelikli firma, dönem veya tablolar
Kurtarma çalışmasının adımları
- Ortamın ve dosyaların değiştirilmemiş bir kopyası oluşturulur; tüm denemeler bu kopya üzerinde yapılır.
- Hangi sayfaların zarar gördüğü, günlüğün durumu ve tabloların tutarlılığı analiz edilir.
- Mümkünse veritabanı ayrı bir test ortamında açılır; açılamıyorsa sağlam sayfalardaki satırlar tablo bazında yeni bir veritabanına taşınır.
- Sonuç, sizin bildiğiniz değerlerle karşılaştırılır: son kesilen fatura numarası, belirli bir carinin bakiyesi, son stok hareketi gibi.
İlk incelemenin sonunda size hangi tabloların ve dönemlerin geri gelme ihtimali olduğunu anlatır, beklenen çalışma süresini ve yazılı teklifimizi iletiriz. Siz onaylamadan kurtarma aşamasına geçilmez. Donanımı sağlam, yalnızca günlük tutarsızlığı yaşayan bir veritabanı görece hızlı ele alınabilir. Okuma hatası veren bir disk üzerinde duran, boyutu büyük ve yaygın hasar görmüş dosyalarda ise süre uzar. Fiyatı belirleyen etkenler için fiyatlandırma ve süreç sayfamıza göz atabilirsiniz.
İşletmelerden gelen sorular
Elimizde birkaç haftalık bir yedek var. Onu yüklemek yerine neden kurtarma yaptıralım?
Yedekten sonraki haftalarda girilen faturalar, tahsilatlar ve stok hareketleri yalnızca bozuk veritabanında durur. Yedeği ayrı bir yere yükleyip saklamak mantıklıdır, ama bozuk dosyaların üzerine yazmayın; aradaki dönemi kurtarmak için o dosyalara ihtiyaç vardır.
Sunucuya uzaktan bağlanıp sorunu yerinde çözebilir misiniz?
Canlı sistem üzerinde onarım denemek, hata durumunda geri dönüşü olmayan sonuçlar doğurabilir. Bu yüzden dosyaların kopyası üzerinde çalışmayı tercih ediyoruz. Kopyayı nasıl güvenle alıp bize ulaştırabileceğinizi telefonda adım adım anlatabiliriz.
Kurtarılan veritabanını hangi biçimde teslim alırız?
Genellikle aynı veritabanı sistemine bağlanabilecek dosyalar veya yedek biçiminde teslim edilir. Tam açılamayan durumlarda tablo bazında dışa aktarılmış veriler de sunulabilir. Biçimi, kullandığınız sürüme göre önceden birlikte belirleriz.
Veritabanı dosyalarımız fidye yazılımıyla şifrelendi. Bu sayfa bizim için mi?
Kısmen. Bazı fidye yazılımları büyük dosyaların yalnızca belirli bölümlerini şifreler ve geri kalan sayfalardan kayıt çıkarmak mümkün olabilir. Genel süreç için fidye yazılımı sonrası veri kurtarma sayfamıza bakın.
Ticari verilerimizin gizliliği nasıl korunuyor?
Veriler yalnızca kurtarma amacıyla işlenir, talep ederseniz gizlilik sözleşmesi imzalanır ve teslimin ardından laboratuvardaki kopyalar güvenli biçimde silinir. Tekrarını önlemek için işletmelerin yedekleme hataları yazımız iyi bir başlangıçtır.