SQL Server · MySQL · Muhasebe Verileri
Veritabanı Kurtarma
SQL Server, MySQL/MariaDB ve muhasebe programı veritabanlarınız açılmıyorsa, işletmenizin hafızasını kopya üzerinde titizlikle analiz ederek geri kazanmaya çalışıyoruz.
- Gizlilik sözleşmesi (NDA)
- Onayınız olmadan işlem yok
- Bursa’da laboratuvar
Bir işletmede veritabanı; cari hesapların, faturaların, stok hareketlerinin, bordroların ve yıllar içinde biriken tüm kayıtların tutulduğu yerdir. Ay sonu kapanışında muhasebe programının “veritabanına bağlanılamıyor” uyarısı vermesi ya da e-ticaret sitenizin ürünleri gösterememesi, işin durması demektir. Veritabanı kurtarma, sıradan dosya kurtarmadan farklı olarak dosyanın iç yapısını, sayfalarını, indekslerini ve işlem günlüklerini anlamayı gerektirir.
BAMER Bursa olarak bozulmuş veritabanı dosyalarını, arızalı disk ve sunuculardan çıkarılan veritabanlarını ve yanlışlıkla silinen kayıtları inceliyoruz. Her vakada ilk hedefimiz mevcut durumu daha da kötüleştirmemek; bu nedenle onarım denemelerini asla orijinal dosya üzerinde yapmıyoruz.
Hangi Durumlarda Veritabanı Kurtarma Gerekir?
- SQL Server’da veritabanının adının yanında “Suspect”, “Recovery Pending” veya “Emergency” ibaresi görünüyor
- Sorgularda 823, 824 gibi G/Ç hataları veya sayfa sağlama toplamı (checksum) uyuşmazlığı mesajları alınıyor
- MySQL veya MariaDB servisi başlamıyor, hata günlüğünde InnoDB ile ilgili bozulma kayıtları var
- Muhasebe programı açılırken firma veya dönem verilerine ulaşılamıyor
- Elektrik kesintisi, ani kapanma ya da disk dolması sonrasında veritabanı tutarsız hâle gelmiş
- Tablolar veya kayıtlar yanlışlıkla silinmiş, güncel yedek bulunmuyor
- Veritabanı dosyaları fidye yazılımı tarafından şifrelenmiş ya da bulunduğu disk arızalanmış
Teknik Arka Plan: Veritabanları Neden Bozulur?
SQL Server (MDF, NDF ve LDF dosyaları)
Microsoft SQL Server verileri 8 KB’lık sayfalar hâlinde birincil veri dosyasında (MDF) ve varsa ikincil dosyalarda (NDF) tutar; yapılan her değişiklik önce işlem günlüğüne (LDF) yazılır. Sunucu yeniden başladığında SQL Server bu günlüğü kullanarak tamamlanmamış işlemleri geri alır ya da tamamlar. Günlük dosyası kaybolur, bozulur veya veri sayfaları zarar görürse bu kurtarma adımı başarısız olur ve veritabanı “suspect” durumuna düşer. Ani elektrik kesintileri, arızalı diskler, RAID kontrolcü sorunları ve yetersiz disk alanı en sık karşılaştığımız nedenlerdir.
Bu noktada internette sıkça önerilen “REPAIR_ALLOW_DATA_LOSS” seçeneği, adından da anlaşılacağı gibi tutarlılığı sağlamak için bozuk sayfaları ve bunlara bağlı kayıtları silebilir. Kopya alınmadan çalıştırıldığında geri dönüşü olmayan kayıplara yol açabilir.
MySQL ve MariaDB (InnoDB)
Web siteleri, e-ticaret altyapıları ve pek çok özel yazılım MySQL veya MariaDB kullanır. Varsayılan depolama motoru olan InnoDB; ibdata1 sistem tablo alanı, tablo başına .ibd dosyaları ve redo log dosyalarıyla çalışır. Bu dosyalardan biri eksik ya da tutarsızsa servis hiç başlamayabilir. Tablo yapısını tanımlayan meta verilerin kaybolduğu durumlarda bile .ibd dosyalarındaki veri sayfaları uygun yöntemlerle ayrıştırılarak satırlar yeniden oluşturulabilir. Daha eski MyISAM tablolarında ise .MYD ve .MYI dosyaları üzerinden farklı bir yol izlenir.
Muhasebe ve ERP Programı Veritabanları
Türkiye’de yaygın kullanılan Logo, Mikro ve Netsis gibi muhasebe ve ERP yazılımlarının güncel sürümleri, verilerini tipik olarak Microsoft SQL Server üzerinde saklar. Yani “muhasebe programım açılmıyor” şikâyetinin arkasında çoğu zaman bir SQL Server veritabanı sorunu yatar. Bu tür vakalarda ilgili veritabanını SQL Server düzeyinde inceleyip kurtarıyoruz. Belirtmek isteriz ki bu yazılım üreticileriyle herhangi bir iş ortaklığımız yoktur; programın kendisine değil, verinin tutulduğu veritabanına müdahale ediyoruz. Kurtarılan veritabanının programınızda yeniden çalıştırılması aşamasında yazılım bayinizle birlikte hareket etmenizi öneririz.
İlk yapılacaklar: Veritabanına yazma yapan programları ve kullanıcı bağlantılarını durdurun. SQL Server veya MySQL servisini kapattıktan sonra veri ve günlük dosyalarının (MDF, NDF, LDF ya da tüm MySQL veri klasörünün) olduğu gibi bir kopyasını başka bir diske alın. Hata mesajlarının ekran görüntüsünü ve hata günlüklerini saklayın. Elinizdeki en son yedeğin tarihini not edin.
Yapılmaması gerekenler: Kopya almadan DBCC CHECKDB onarım seçeneklerini veya innodb_force_recovery’nin yüksek değerlerini denemeyin. Günlük (LDF) dosyasını silmeyin, “detach” işlemi yapıp dosyaları taşımaya çalışmayın. Aynı diske yeni bir veritabanı kurmayın veya eski bir yedeği orijinal dosyaların üzerine geri yüklemeyin; aksi hâlde en güncel veriler kalıcı olarak kaybolabilir.
Nasıl Çalışıyoruz?
Veritabanı kurtarmada sorun yalnızca dosyada değil, dosyanın bulunduğu donanımda da olabilir. Bu yüzden önce ortamı, sonra veriyi ele alıyoruz:
- Disk veya sunucu fiziksel olarak sorunluysa önce sektör sektör imaj alınır; veritabanı dosyaları bu imajdan çıkarılır.
- Dosyaların yapısı incelenir: hangi sayfaların bozuk olduğu, günlük dosyasının durumu ve tabloların tutarlılığı tespit edilir.
- Mümkünse veritabanı yalıtılmış bir test ortamında ayağa kaldırılır; değilse sağlam sayfalardaki kayıtlar tablo tablo ayrıştırılarak yeni bir veritabanına aktarılır.
- Kurtarılan verinin tutarlılığı sizinle birlikte kontrol edilir; örneğin son fatura numaraları veya cari bakiyeler gibi bildiğiniz değerler karşılaştırılır.
Süreç ve Süre
Yalnızca günlük dosyasında sorun bulunan, donanımı sağlam bir veritabanı görece kısa sürede ele alınabilirken; fiziksel arızalı bir diskte, yüksek boyutlu ve ağır hasarlı bir veritabanında süreç uzayabilir. Ön incelemenin ardından neyin kurtarılabileceğini, tahmini süreyi ve yazılı fiyat teklifini paylaşırız; onayınız olmadan işleme başlamayız. Fiyatı etkileyen unsurları fiyatlandırma ve süreç sayfamızda bulabilirsiniz.
- 1
Cihazı ulaştırın
Laboratuvarımıza elden getirin veya kargoyla gönderin.
- 2
Arıza tespiti
Cihazınız incelenir, arızanın türü ve kurtarma ihtimali belirlenir.
- 3
Teklif ve onay
Size net bir fiyat teklifi sunulur; onayınız olmadan işlem yapılmaz.
- 4
Kurtarma
Mümkün olduğunda önce birebir kopya alınır, işlemler kopya üzerinde yapılır.
- 5
Teslim ve imha
Verileriniz teslim edilir, laboratuvardaki kopyalar güvenli şekilde silinir.
Sık Sorulan Sorular
Veritabanım “suspect” durumda, kayıtlarım kayboldu mu?
Hayır, bu durum verilerin silindiği anlamına gelmez. SQL Server veritabanını tutarlı biçimde açamadığı için erişimi durdurmuştur. Bozulmanın boyutuna göre kayıtların büyük bölümü çoğu zaman yerinde durur. Önemli olan, kopya almadan onarım komutları çalıştırmamaktır.
Sadece MDF dosyam var, LDF dosyası kayboldu. Kurtarılabilir mi?
Çoğu durumda evet; ancak günlükte bulunan ve veri dosyasına henüz yansımamış son işlemler kaybolabilir. MDF dosyasının sağlam olup olmadığı inceleme sonrasında netleşir.
Muhasebe programımın bayisi ile birlikte çalışıyor musunuz?
Yazılım üreticileri veya bayileriyle resmî bir ortaklığımız bulunmuyor. Biz veritabanı katmanında kurtarma yapıyoruz; kurtarılan veritabanının programınıza bağlanması sırasında kendi bayinizle iş birliği yapmanız süreci kolaylaştırır.
Veritabanını bize uzaktan gönderebilir miyim?
Donanım sağlamsa ve dosyaları güvenli şekilde kopyalayabiliyorsanız, kopyayı şifreli bir ortamda bize ulaştırmanız mümkündür. Disk arızası şüphesi varsa cihazın kendisini getirmeniz veya göndermeniz daha doğrudur. Talep ederseniz gizlilik sözleşmesi imzalarız.
Silinen tablo veya kayıtlar geri getirilebilir mi?
Silme işleminden sonra veritabanında yoğun yazma yapılmadıysa, silinen kayıtların bir kısmı veri sayfalarında veya işlem günlüğünde izlerini koruyabilir. Ne kadar erken müdahale edilirse şans o kadar artar.
İlgili Hizmetler
Veritabanınızın bulunduğu sunucu veya disk dizisi arızalandıysa sunucu veri kurtarma ve RAID veri kurtarma sayfalarımıza göz atın. Dosyalar şifrelendiyse fidye yazılımı sonrası veri kurtarma hizmetimiz, işletmeye özel ihtiyaçlar için ise kurumsal veri kurtarma çözümlerimiz size uygun olabilir.