Database SQL Kurtarma
Database SQL kurtarma, donanım arızası, beklenmedik kapanma, mantıksal bozulma veya yanlışlıkla silme nedeniyle erişilemeyen ya da hasar görmüş SQL veritabanlarını (MS SQL Server, MySQL, PostgreSQL, Oracle) yeniden kullanılabilir hale getirme sürecidir. MDF/NDF/LDF dosya yapısından DBCC CHECKDB protokolüne, transaction log analizi ile silinen kayıt kurtarmadan yedeksiz kurtarma senaryolarına kadar teknik süreç bu sayfada eksiksiz ele alınmaktadır.
Rakip sayfaların tamamının boş bıraktığı: Suspect mode Emergency protokolü, REPAIR_REBUILD ile REPAIR_ALLOW_DATA_LOSS farkı, transaction log analizi ile silinen satır kurtarma, InnoDB innodb_force_recovery kademesi, PostgreSQL WAL replay, Oracle RMAN flashback ve adli amaçlı veritabanı inceleme.
MS SQL Server Dosya Yapısı: MDF, NDF, LDF
SQL Server veritabanı fiziksel olarak en az iki dosyadan oluşur. Bu dosyaların her biri farklı kritiklikte olup kurtarma sürecindeki rolü farklıdır.
| Uzantı | Dosya Türü | İçerik | Bozulunca Ne Olur? | Kurtarma Önceliği |
|---|---|---|---|---|
| .mdf | Primary Data File | Tablolar, indeksler, saklı yordamlar, görünümler, sistem nesneleri, veri sayfaları | Veritabanı SUSPECT veya RECOVERY PENDING moduna düşer; tüm erişim kesilir | Kritik — zorunlu |
| .ndf | Secondary Data File | MDF’in taştığı ek veri; filegroup bazlı büyük veritabanlarında kullanılır | İlgili filegroup erişilemez; tablolar kısmen kaybolabilir | Yüksek — mevcutsa |
| .ldf | Transaction Log File | Tüm INSERT/UPDATE/DELETE işlemlerinin zaman damgalı log kaydı; aktif işlem listesi | Log rebuild gerekebilir; point-in-time recovery imkânı kaybolur; veri kaybı riski artar | Yüksek — silinen kayıt kurtarma için kritik |
| .bak | Yedek Dosyası | BACKUP DATABASE ile alınan yedek; full / differential / log backup | Mevcut değilse kurtarma zorlaşır | Öncelikli kurtarma kaynağı |
| ibdata1 / .ibd | MySQL InnoDB | InnoDB sistem tablespace (ibdata1) ve her tablo için .ibd dosyası | InnoDB crash recovery devreye girer; tablo bütünlüğü bozulabilir | Kritik |
| pg_wal / base/ | PostgreSQL | WAL (Write-Ahead Log) segmentleri ve veri dosyaları | Cluster başlamayabilir; WAL replay gerekir | Kritik |
Veritabanı Bozulma Nedenleri ve Belirtileri
Fiziksel / Donanım Kaynaklı Bozulmalar
- Disk sektör hatası — bad sector üzerine yazma veya okuma başarısızlığı
- RAID controller arızası veya yanlış yapılandırma — write-back cache açık, UPS yok
- Beklenmedik güç kesintisi — işlem yazılırken kesilme, torn page oluşması
- Depolama donanımında yavaşlama / I/O latency — SQL Server’ın timeout sonrası yazma iptal etmesi
- SAN/NAS bağlantı kopması — iSCSI veya Fibre Channel oturumu düşmesi
- Sunucu RAM hatası (ECC hatası) — bellekteki veri sayfasının bozuk diske yazılması
Yazılımsal / Mantıksal Bozulmalar
- SQL Server servisinin ani durdurulması — aktif işlem commit edilmemesi
- Disk dolması — log dosyası büyüyemediğinde veritabanı SUSPECT moduna düşme
- Yanlış SHRINK işlemi — DBCC SHRINKDATABASE, aktif işlemlerle çakışma
- Eski SQL Server versiyonundan yeni versiyona hatalı yükseltme
- Antivirüs yazılımının MDF/LDF dosyalarını kilitlemesi veya karantinaya alması
- Yanlışlıkla DROP TABLE / TRUNCATE / DELETE — log kayıtlıysa geri alınabilir
- Fidye yazılımı (ransomware) şifrelemesi — şifreli MDF, kurtarma öncesi şifre çözme gerekir
| Hata Mesajı / Belirti | Olası Neden | İlk Müdahale |
|---|---|---|
| Database ‘X’ is in SUSPECT mode | Recovery sırasında MDF/LDF okunamadı; disk hatası veya kapanma | sp_resetstatus → Emergency mode → DBCC CHECKDB |
| RECOVERY PENDING | Log dosyası eksik veya bozuk; SQL Server işlemi tamamlayamadı | LDF mevcut değilse log rebuild; mevcutsa CHECKDB |
| Error 823 (I/O Error) | Fiziksel disk okuma/yazma hatası; bad sector | Disk S.M.A.R.T. kontrolü; disk kopyası; CHECKDB |
| Error 824 (Logical consistency) | Page checksum uyumsuzluğu — torn page veya bit flip | DBCC CHECKDB WITH DATA_PURITY |
| Error 825 (Read-retry) | Disk performans düşüşü; geçici okuma hatası | Donanım diyagnostiği; SMART analizi |
| Error 9001 (Log not available) | LDF dosyası erişilemiyor veya bozuk | LDF rebuild; son iyi yedekten geri yükleme |
| Error 1813 (Could not open new database) | MDF versiyonu uyumsuz veya bozuk header | EMERGENCY mode ile açma girişimi |
| OFFLINE / RESTORING takılı kalma | Eksik differential/log backup; restore yarıda kesildi | Restore zinciri analizi; WITH RECOVERY uygulaması |
DBCC CHECKDB: Bütünlük Kontrolü ve Onarım Seçenekleri
DBCC CHECKDB, SQL Server’ın yerleşik bütünlük kontrol aracıdır. Tüm page’lerin fiziksel ve mantıksal tutarlılığını, indeks bütünlüğünü, sistem kataloğu uyumunu ve FILESTREAM meta verilerini kontrol eder. CHECKDB önce çalıştırılır, ardından onarım kararı verilir.
DBCC CHECKDB Onarım Seçenekleri Karşılaştırması
REPAIR_FAST
Yalnızca geriye dönük uyumluluk için tutulmuştur. SQL Server 2005 sonrasında hiçbir onarım eylemi gerçekleştirmez. Kullanılmamalıdır.
Veri kaybı: Yok (işlem de yok)
REPAIR_REBUILD
Veri kaybı olmadan onarım dener. Eksik kümelenmemiş indeks satırlarını onarır, indeks rebuild eder, küçük meta veri sorunlarını giderir. FILESTREAM hataları için geçerli değildir.
Veri kaybı: Beklenmez — güvenli ilk adım
REPAIR_ALLOW_DATA_LOSS
Tüm bildirilen hataları onarmayı dener; gerekirse bozuk sayfaları siler. Yabancı anahtar kısıtlamalarını kontrol etmez. Veri kaybı kesindir. Yalnızca yedeksiz son çare olarak kullanılır.
Veri kaybı: Var — yedek zorunlu
Suspect Mode Tam Çözüm Protokolü (T-SQL)
EXEC sp_resetstatus ‘VeritabaniAdi’;— ADIM 2: Emergency moduna al (okuma erişimi açılır)
ALTER DATABASE VeritabaniAdi SET EMERGENCY;
— ADIM 3: Bütünlük kontrolü — hataları tespit et, henüz onarma
DBCC CHECKDB(‘VeritabaniAdi’) WITH NO_INFOMSGS;
— ADIM 4: Tek kullanıcı moduna geç (onarım için zorunlu)
ALTER DATABASE VeritabaniAdi
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
— ADIM 5a: Önce veri kaybı olmadan dene
DBCC CHECKDB(‘VeritabaniAdi’, REPAIR_REBUILD);
— ADIM 5b: Hata devam ediyorsa — YEDEK ALDIKTAN SONRA
DBCC CHECKDB(‘VeritabaniAdi’, REPAIR_ALLOW_DATA_LOSS);
— ADIM 6: Normal çok kullanıcı moduna dön
ALTER DATABASE VeritabaniAdi SET MULTI_USER;
— ADIM 7: Onarım sonrası doğrulama
DBCC CHECKDB(‘VeritabaniAdi’) WITH NO_INFOMSGS, DATA_PURITY;
Transaction Log Analizi ile Silinen Kayıt Kurtarma
SQL Server FULL veya BULK_LOGGED recovery modelinde çalışıyorsa, LDF dosyası tüm DML işlemlerini (INSERT/UPDATE/DELETE/TRUNCATE) zaman damgasıyla kaydeder. Bu log, silinen satırların belirli bir noktaya kadar geri alınmasını mümkün kılar.
Recovery Model ve Log Kurtarma İmkânı
- FULL Recovery Model: Tüm işlemler LDF’e yazılır. Point-in-time recovery mümkün. Silinen satır kurtarma için en uygun model.
- BULK_LOGGED: Bulk operasyonlar minimal loglanır. Çoğu DML kaydedilir; sınırlı point-in-time recovery.
- SIMPLE: Log, checkpoint sonrası yeniden kullanılır; geçmiş işlem kaydı tutulmaz. Silinen kayıt kurtarma genellikle mümkün değil — page-level recovery denenebilir.
- Recovery model kontrolü:
SELECT name, recovery_model_desc FROM sys.databases - SIMPLE modelde kurtarma için: MDF üzerindeki işaretlenmemiş (deallocated) sayfalarda page-level scan; üzerine yazılmamışsa kurtarılabilir.
Point-in-Time Kurtarma Adımları (FULL Model)
- Son FULL backup’tan geri yükle —
RESTORE DATABASE ... WITH NORECOVERY - Differential backup mevcutsa uygula —
WITH NORECOVERY - LDF (transaction log) backup’larını sırayla uygula —
WITH NORECOVERY - Hedef zaman noktasını belirle:
WITH STOPAT = '2026-03-07 09:00:00', RECOVERY - Son log backup yoksa aktif LDF’yi yedekle (tail-log backup):
BACKUP LOG ... WITH NO_TRUNCATE - Kurtarma sonrası:
DBCC CHECKDB WITH DATA_PURITYile doğrulama
Silinen Satırları Log Üzerinden Okuma (Örnek Sorgu)
SELECT
[Current LSN], [Operation], [Transaction ID],
[Begin Time], [End Time], [Transaction Name],
[Lock Information]
FROM fn_dblog(NULL, NULL)
WHERE [Transaction Name] = ‘DELETE’
AND [Begin Time] >= ‘2026-03-07 08:00:00.000’;— Not: fn_dblog aktif LDF üzerinde çalışır.
— Arşiv log analizi için ApexSQL Log veya SQL Log Analyzer gereklidir.
Veritabanı Motoruna Göre Kurtarma Yöntemleri
SQL Server 2016–2022
- Bozulma tespiti: DBCC CHECKDB — fiziksel + mantıksal bütünlük
- Suspect → Emergency → REPAIR protokolü (yukarıdaki T-SQL)
- Sayfa düzeyinde kurtarma (Enterprise Edition):
RESTORE DATABASE ... PAGE='x:y' - Log backup zinciri analizi ile point-in-time recovery
- Yedek olmayan MDF: ApexSQL Recover, Stellar Repair for MS SQL, DataNumen SQL Recovery
- Fidye yazılımı sonrası şifreli MDF: önce şifre çözme (varsa), sonra MDF onarımı
- AlwaysOn AG kurtarma: Secondary replica’dan okuma veya failover; AG senkronizasyon durumu analizi
InnoDB ve MyISAM
- InnoDB Crash Recovery:
innodb_force_recovery1→6 kademeli artış ile kurtarma girişimi - Seviye 1 (SRV_FORCE_IGNORE_CORRUPT): bozuk sayfa işaretlenerek devam; seviye 6 (SRV_FORCE_NO_LOG_REDO): log devre dışı, veri kaybı riski yüksek
mysqldumpile mümkün olan tabloları dışa aktar → temiz kurulum → içe aktar- ibdata1 bozulması: tablespace dosyaları ayrıysa (
innodb_file_per_table=ON) tek tablo bazlı kurtarma mümkün - MyISAM:
REPAIR TABLE tablo_adi;veyamyisamchk -r tablo.MYI - Araç: Stellar Repair for MySQL, DBForge Studio for MySQL
WAL ve Cluster Recovery
- WAL (Write-Ahead Log) replay:
postgresql.confiçinderecovery_target_timeile point-in-time - Cluster başlamıyorsa:
pg_resetwal— WAL’ı sıfırlar, son commit edilen veri kaybı riski; son çare - Tablo bütünlüğü:
VACUUM FULL,REINDEX,pg_dumpile sağlıklı tablolar alınır - Corrupt page atlatma:
zero_damaged_pages = on(postgresql.conf) — bozuk sayfayı sıfır olarak okur, tablo erişilebilir ama o satırlar kaybolur - pg_filedump aracı: veri dosyalarını binary düzeyde inceler, ham veri çıkarımı
- Streaming Replication slave’den kurtarma: master bozulduysa slave’i promote et
RMAN, Flashback, Data Guard
- RMAN (Recovery Manager): Tam veritabanı, tablespace, datafile veya block düzeyinde kurtarma
RMAN> RESTORE DATABASE; RECOVER DATABASE;— tam kurtarma- Flashback Technology: Flashback Query (
AS OF TIMESTAMP), Flashback Table, Flashback Database — belirli zaman noktasına dönüş - Block Media Recovery: Tek bozuk block onarımı; tüm DB offline gerekmez
- Data Guard standby’dan kurtarma: Primary çökerse switchover/failover ile standby öne alınır
- Redo log bozulması:
ALTER DATABASE CLEAR UNARCHIVED LOGFILE— log temizle, veri kaybı olabilir
Yedek Olmadan SQL Kurtarma — Hangi Senaryolarda Mümkün?
Yedek olmaması kurtarmayı imkânsız kılmaz; ancak başarı oranını ve kurtarılabilecek veri miktarını kısıtlar. Aşağıdaki matris, yedeksiz senaryolarda ne kadar veri kurtarılabileceğini ortaya koymaktadır.
| Senaryo | Yedek Durumu | Kurtarma Yöntemi | Başarı Oranı | Veri Kaybı Riski |
|---|---|---|---|---|
| Suspect mode — disk sağlıklı | Yedek yok | Emergency + REPAIR_REBUILD | %70–85 | Düşük–Orta |
| MDF bozuk, LDF sağlıklı | Yedek yok | Log replay + MDF onarım aracı | %60–80 | Orta |
| MDF bozuk, LDF yok | Yedek yok | REPAIR_ALLOW_DATA_LOSS veya adli araç | %40–65 | Yüksek |
| DROP TABLE / yanlış silme (FULL model) | Yedek yok, LDF mevcut | Transaction log analizi + undoing | %85–95 | Çok Düşük |
| DROP TABLE / yanlış silme (SIMPLE model) | Yedek yok | Page-level carving — üzerine yazılmamışsa | %30–60 | Yüksek |
| Fidye yazılımı şifrelemesi | Yedek yok | Şifre çözme anahtarı + MDF onarım | Değişken | Çok Yüksek |
| Fiziksel disk arızası + MDF üzerinde | Yedek yok | Disk kurtarma → sektör kopyası → MDF onarım | %50–75 | Yüksek |
| MySQL InnoDB crash, ibdata1 bozuk | Yedek yok | innodb_force_recovery kademeli + dump | %55–80 | Orta–Yüksek |
Adli Amaçlı Veritabanı İncelemesi — SQL Analiz Raporu
Veritabanı kurtarmanın ötesinde, hukuki süreçlerde SQL veritabanı üzerinde adli inceleme yapılması gerekebilir: silinen kayıtların tespiti, işlem zaman damgaları, kullanıcı bazlı DML aktivitesi, yetkisiz erişim veya veri manipülasyonu kanıtı.
Adli SQL İnceleme Kapsamı
- Transaction log analizi: Belirli zaman aralığında gerçekleştirilen tüm INSERT/UPDATE/DELETE işlemlerinin kullanıcı ve zaman bilgisiyle listelenmesi
- Silinen kayıt tespiti: Yanlışlıkla veya kasıtlı silinen satırların kurtarılması ve kim tarafından silindiğinin belirlenmesi
- Erişim logu: SQL Server Audit, Extended Events veya DDL Trigger kayıtlarından yetkisiz erişim tespiti
- Şema değişikliği takibi: ALTER TABLE, DROP TABLE, CREATE gibi DDL komutlarının zaman damgalı kaydı
- Hash doğrulama: Veritabanı dosyaları ve kurtarılan verinin SHA-256 hash değerleri ile zincir muhafaza belgesi
HMK m.293 Uyumlu SQL Adli Rapor İçeriği
- İncelenen veritabanı dosyalarının adı, boyutu, hash değeri (SHA-256)
- SQL Server versiyonu, veritabanı oluşturma ve son erişim tarihi
- Recovery model ve log retention durumu
- Tespit edilen bozulma türü ve DBCC CHECKDB çıktısı
- Kurtarılan kayıt listesi: tablo adı, satır ID, silme/değiştirme zamanı, işlemi yapan kullanıcı
- Uygulanan kurtarma yöntemi ve kullanılan araçlar
- Uzman bilgileri, imza ve tarih
- Uzman Mütalaası İnceleme için başvuru imkânı
SQL Kurtarma Araçları: Profesyonel Karşılaştırma
ApexSQL Recover
- MDF/NDF doğrudan onarım; LDF olmadan çalışır
- Silinen kayıt, DROP TABLE, TRUNCATE kurtarma
- Transaction log analizi ile kim-ne-zaman raporu
- Adli inceleme için detaylı denetim izi
Stellar Repair for MS SQL
- Ağır bozulmalarda sayfa düzeyinde kurtarma
- Tablolar, görünümler, SP, trigger, indeks kurtarma
- SQL Server 2005–2022 tam destek
- Onarım öncesi önizleme penceresi
DataNumen SQL Recovery
- Sektörde en yüksek kurtarma oranı iddiası
- Şifreli nesnelerin şifre çözme desteği
- Toplu MDF onarım (batch processing)
- LDF olmadan MDF kurtarma
Stellar Repair for MySQL
- InnoDB ve MyISAM tam destek
- .ibd, .frm, ibdata1 dosyaları onarımı
- Bozuk tablespace kurtarma
- MySQL 5.0–8.0 destek
pg_filedump + pg_resetwal
- pg_filedump: binary veri dosyası analizi
- pg_resetwal: WAL sıfırlama (son çare)
- zero_damaged_pages: bozuk sayfayı atla
- Açık kaynak — yerleşik PostgreSQL araçları
RMAN + LogMiner
- RMAN: Oracle’ın yerleşik yedekleme/kurtarma aracı
- LogMiner: redo/archive log analizi; DML geçmişi
- Flashback Query/Table/Database: zaman yolculuğu kurtarma
- Block Media Recovery: tek block onarımı
Database SQL Kurtarma Sürecimiz
Hizmet Kapsamı
MS SQL Server Kurtarma — MDF/NDF/LDF, Suspect Mode, DBCC
SQL Server 2005–2022 tüm versiyonları. Suspect / Recovery Pending / Offline / Restoring takılı kalma senaryolarında Emergency mode protokolü. MDF ve NDF fiziksel bozulma onarımı. LDF olmadan kurtarma; log rebuild. Sayfa düzeyinde kurtarma (Enterprise). AlwaysOn AG ve Failover Cluster kurtarma. Adli zincir muhafazalı rapor ve hash belgesi. Teklif almak için iletişime geçin.
Silinen Kayıt ve Tablo Kurtarma — Transaction Log Analizi
DROP TABLE, TRUNCATE, DELETE işlemlerinin ardından FULL recovery model LDF analizi ile point-in-time kurtarma. ApexSQL Log ve SQL Log Analyzer ile kim-ne-zaman raporlama. SIMPLE model veritabanlarında page-level carving. Adli inceleme gereksinimlerinde HMK m.293 uyumlu uzman raporu. Kurtarılan satırlar yeni tabloya aktarılarak orijinal veritabanı riske atılmaz.
MySQL, PostgreSQL, Oracle Veritabanı Kurtarma
MySQL 5.7–8.0: InnoDB innodb_force_recovery kademeli kurtarma, ibdata1 ve .ibd bozulma onarımı, MyISAM REPAIR TABLE. PostgreSQL 14–16: WAL replay, pg_resetwal, zero_damaged_pages, pg_filedump analizi. Oracle 11g–19c: RMAN restore/recover, Flashback Query/Table/Database, LogMiner DML geçmişi, Block Media Recovery. Tüm motorlar için adli rapor seçeneği.
Adli SQL İnceleme ve Uzman Mütalaası
Hukuki süreçlerde veritabanı delili: silinen kayıt tespiti, işlem zaman damgası analizi, kullanıcı bazlı DML aktivitesi, yetkisiz erişim kanıtı, şema değiştirme logu. SHA-256 hash değerleri ile zincir muhafaza belgesi. HMK m.293 uyumlu, mahkemeye sunulabilir teknik rapor. Uzman Mütalaası İnceleme için başvurun.
Sık Sorulan Sorular
SQL veritabanı nasıl kurtarılır?
İlk adım: son bilinen iyi yedekten geri yükleme — bu her zaman en güvenli yoldur. Yedek yoksa: DBCC CHECKDB ile bütünlük tespiti, Emergency mode protokolü, REPAIR_REBUILD veya REPAIR_ALLOW_DATA_LOSS. Fiziksel bozulma durumunda ApexSQL Recover, Stellar Repair veya DataNumen gibi profesyonel araçlar devreye girer. Her müdahaleden önce dosyaların bit-for-bit imajı alınmalıdır.
MDF dosyası bozulursa ne olur ve nasıl onarılır?
MDF bozulduğunda SQL Server veritabanı SUSPECT veya RECOVERY PENDING moduna düşer; Error 823, 824 veya 1813 mesajları üretilir. Onarım adımları: sp_resetstatus → SET EMERGENCY → DBCC CHECKDB (tespit) → SINGLE_USER → REPAIR_REBUILD (veri kaybı yok) veya REPAIR_ALLOW_DATA_LOSS (son çare) → MULTI_USER. Yazılımsal onarım başarısız olursa veya fiziksel disk hatası varsa profesyonel kurtarma aracı ve disk imajı gerekir.
Suspect mode nedir, nasıl çözülür?
Suspect mode, SQL Server’ın veritabanını başlatma sırasında MDF veya LDF dosyasına erişemediğinde veya bütünlük kontrolü başarısız olduğunda işaretlediği durumdur. Disk dolması, fiziksel disk hatası, beklenmedik kapanma ana nedenlerdir. Çözüm: sp_resetstatus ile durum sıfırlama, ALTER DATABASE SET EMERGENCY ile acil mod, DBCC CHECKDB ile hata tespiti ve uygun REPAIR seçeneği. Tüm adımlar sırasında dosya yedeği zorunludur.
Silinen veritabanı kaydı geri gelir mi?
Recovery modeline bağlıdır. FULL model: transaction log (LDF) analizi ile DELETE/TRUNCATE/DROP TABLE sonrası belirli bir zaman noktasına kadar kurtarma başarı oranı %85–95. SIMPLE model: LDF geçmiş işlem içermez; page-level carving ile üzerine yazılmamış satırlar kurtarılabilir (%30–60). En kritik nokta: silme işleminden sonra mümkün olan en kısa sürede disk aktivitesi durdurulmalı veya kopyalanmalıdır.
MySQL veritabanı bozulursa nasıl kurtarılır?
InnoDB için: my.cnf dosyasına innodb_force_recovery=1 ekle, MySQL’i başlat. Başlıyorsa mysqldump ile tüm tabloları dışa aktar. Başlamıyorsa recovery seviyesini 2, 3, 4, 5, 6 şeklinde artır — seviye 6’da veri kaybı yüksektir. MyISAM için: REPAIR TABLE veya myisamchk -r. ibdata1 bozulması: innodb_file_per_table aktifse tekil .ibd kurtarma mümkün; aksi halde tüm tablespace yeniden oluşturulur ve .ibd dosyaları tek tek import edilir.
DBCC CHECKDB REPAIR_REBUILD ile REPAIR_ALLOW_DATA_LOSS arasındaki fark nedir?
REPAIR_REBUILD, veri kaybı olmadan onarım yapar: eksik indeks satırlarını düzeltir, indeks rebuild eder. Güvenli ilk adımdır. REPAIR_ALLOW_DATA_LOSS ise tüm hataları gidermeye çalışır; bunu yaparken bozuk sayfaları silebilir — kalıcı veri kaybı olabilir. Microsoft, REPAIR_ALLOW_DATA_LOSS’u “son çare, yalnızca yedek yoksa” olarak tanımlar ve bu komutun bilinen son iyi yedekten geri yüklemeden daha fazla veri kaybına neden olabileceğini açıkça belirtir.
MDF Onarım
Suspect Mode Çözümü
DBCC CHECKDB
Silinen Kayıt Kurtarma
MySQL InnoDB Kurtarma
PostgreSQL WAL Kurtarma
Oracle RMAN
Transaction Log Analizi
SQL Kurtarma İzmir
Database SQL Kurtarma — Hızlı Müdahale
MS SQL Server, MySQL, PostgreSQL ve Oracle veritabanı kurtarma. Suspect mode, MDF bozulma, silinen kayıt, yedeksiz kurtarma senaryoları. DBCC CHECKDB Emergency protokolü, transaction log analizi ve profesyonel adli araç desteğiyle maksimum veri kurtarma. HMK m.293 uyumlu adli SQL inceleme raporu. İzmir merkezli, Türkiye genelinde hizmet.