Hızlı cevap: Bozuk bir veritabanında ilk iş, motoru kurtarma bayraklarıyla zorlamak değil, ham dosyaları (SQL Server için MDF, NDF ve LDF, MySQL InnoDB için ibdata1 ve .ibd, PostgreSQL için base dizini ve WAL) başka bir diske bire bir kopyalamaktır. Tüm denemeler kopya üzerinde yapılır. Üç motor da veriyi sabit boyutlu sayfalarda tutar (SQL Server ve PostgreSQL 8 KB, InnoDB 16 KB) ve her sayfada bir sağlama toplamı vardır, bu yüzden bozulma genelde birkaç sayfayla sınırlıdır. Kurtarma sırası şudur: önce işlem günlüğünden tutarlı duruma getirmeyi dene, sonra motora özel kurtarma modunu (SQL Server emergency ve DBCC, innodb_force_recovery, PostgreSQL salt okunur başlatma) dene, en son çare olarak motor hiç açılmıyorsa sayfaları doğrudan dosyadan oyarak kayıtları çıkar. pg_resetwal, yüksek innodb_force_recovery seviyeleri ve DBCC ... REPAIR_ALLOW_DATA_LOSS veri kaybettirebilir, bu yüzden en sona bırakılır.

Veritabanı kurtarma, dosya kurtarmadan farklı bir disiplindir. Bir fotoğrafı geri getirmek bitleri bulmaktır; bir veritabanını geri getirmek, sayfalar, işlem günlükleri ve tutarlılık kuralları arasındaki ilişkiyi yeniden kurmaktır. Bu rehber, SQL Server, MySQL InnoDB ve PostgreSQL için bozulmanın nasıl oluştuğunu, motorların iç yapısını ve hangi kurtarma adımının güvenli, hangisinin son çare olduğunu uzman seviyede ele alır.

Önce ham dosyaları kopyalayın, motora dokunmayın

Üç motorda da en yıkıcı hata, bozuk veritabanı dosyaları hâlâ yerindeyken kurtarma komutları çalıştırmaktır. DBCC CHECKDB ... REPAIR_ALLOW_DATA_LOSS, yüksek innodb_force_recovery seviyesi ve pg_resetwal dosyaların içeriğini değiştirir ve başarısız olurlarsa geri dönüşü zorlaşır.

Doğru sıra: servisi durdurun, veritabanı dosyalarını işletim sistemi seviyesinde başka bir diske kopyalayın ve tüm kurtarmayı bu kopyalar üzerinde yapın. Depolama arızası varsa (disk bozuk sektör veriyor, RAID çöktü) önce blok seviyesinde imaj alınır; bu durumda arızalı diskten imaj alma ve altta RAID varsa RAID 5 ve 6 yeniden oluşturma yazılarımızdaki yöntem izlenir. Fidye yazılımı dosyaları şifrelediyse veritabanı kurtarması değil, olay müdahalesi gerekir ve anahtar olmadan şifreli sayfalar geri getirilemez.

Üç motorun sayfa yapısı

Üç motor da veriyi sabit boyutlu sayfalarda saklar. Bozulma çoğu zaman tüm veritabanını değil, belirli sayfaları etkiler; sağlama toplamları bozuk sayfayı tespit etmeyi sağlar.

Motor Veri dosyası Sayfa boyutu İşlem günlüğü Kurtarma modu
SQL Server .mdf, .ndf 8 KB .ldf emergency mode, DBCC CHECKDB
MySQL InnoDB ibdata1, .ibd 16 KB ib_logfile, redo log innodb_force_recovery 1-6
PostgreSQL base/ 8 KB pg_wal salt okunur başlatma, zero_damaged_pages

Her sayfanın bir başlığı, bir veri gövdesi ve bir sağlama toplamı vardır. Motorlar sayfayı okurken sağlama toplamını doğrular; tutmazsa sayfayı bozuk kabul eder ve genelde tüm veritabanını şüpheli (suspect) işaretler. Kurtarmanın özü, sağlam sayfaları kurtarıp bozuk olanları onarmak veya atlamaktır.

SQL Server: suspect veritabanı ve DBCC

Bir SQL Server veritabanı başlatmada tutarsızlık bulursa SUSPECT durumuna geçer ve erişime kapatır. Tipik nedenler: ani güç kaybında yarım kalan işlem günlüğü, depolama hatası veya eksik LDF dosyası.

Güvenli sıra kademelidir. Önce veritabanını emergency moduna alıp salt okunur erişim denenir; bu, hiçbir onarım yapmadan veriyi dışarı taşıma şansı verir.

ALTER DATABASE [db] SET EMERGENCY;
ALTER DATABASE [db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ([db]) WITH NO_INFOMSGS, ALL_ERRORMSGS;

DBCC CHECKDB tutarsızlıkları raporlar ve önerilen minimum onarım seviyesini söyler. Burada kritik ayrım şudur: REPAIR_REBUILD veri kaybetmeden onarır ama her bozulmaya yetmez; REPAIR_ALLOW_DATA_LOSS ise bozuk sayfaları silerek tutarlılığı sağlar, yani veri kaybına yol açar. İkincisi yalnızca yedek yokken, son çare olarak ve mutlaka kopya üzerinde çalıştırılır.

LDF dosyası kaybolmuşsa veya MDF başka bir sunucudan yetim kaldıysa, veritabanını yalnız MDF ile ekleme (attach) teknikleri kullanılır; bozuk bir boot sayfası (sayfa 9) için uzman araçlarla sayfa onarımı gerekir. Tek tek sayfaları incelemek için DBCC PAGE kullanılır. Benzer bir kurumsal sunucu senaryosunu Exchange ve Active Directory sunucu kurtarma yazımızda da ele aldık.

MySQL InnoDB: innodb_force_recovery kademeleri

InnoDB tutarsız bir sayfa gördüğünde çoğu zaman MySQL'i çökertir ve yeniden başlatmada aynı sayfada tekrar çöker. Çözüm, kurtarmayı kademeli açan innodb_force_recovery ayarıdır. Bu değeri olabilecek en düşük seviyeden başlatmak esastır.

Seviye Ne yapar Risk
1 bozuk sayfaları görmezden gelip devam eder düşük
2 arka plan temizleme (purge) çalışmaz düşük
3 işlem geri alma (rollback) yapılmaz orta
4 bozuk gizli dizinleri atlar veri kaybı olabilir
5 redo günlüğünü yok sayar veri kaybı olabilir
6 redo tamamen atlanır, en agresif yüksek veri kaybı

Doğru yaklaşım: 1 ile başlayın, MySQL açılırsa hemen mysqldump ile tüm veriyi dışarı alın, sonra temiz bir sunucuya geri yükleyin. Açılmazsa bir üst seviyeye geçin. 4 ve üstü veri kaybı anlamına geldiği için yalnızca kopya üzerinde ve başka yol kalmadığında kullanılır. 6. seviyede bile açılmazsa veya tablo alanı dosyası fiziksel olarak hasarlıysa, sayfaları doğrudan .ibd dosyasından okuyan uzman çıkarım yöntemlerine geçilir.

Önemli bir ayrıntı, dosya başına tablo alanı (file-per-table) ayarıdır: her .ibd dosyası tek bir tablonun 16 KB sayfalarını tutar ve veri sözlüğü ibdata1 içindedir. Sözlük bozulduğunda .ibd sayfalarından kayıt çıkarmak için tablo şemasının bilinmesi gerekir. Magento ve WooCommerce gibi MySQL tabanlı e-ticaret sistemlerinde bu senaryo sık görülür; ilgili yaklaşımı e-ticaret veri kurtarma yazımızda anlattık.

PostgreSQL: WAL, kontrol dosyası ve bozuk sayfalar

PostgreSQL her ilişkiyi (tablo, indeks) base dizininde dosyalar olarak tutar ve değişiklikleri önce WAL'a (write ahead log) yazar. Çökme sonrası normal başlatma WAL'ı tekrar oynatarak tutarlılığı sağlar. Sorun, WAL veya kontrol dosyası bozulduğunda başlar.

En tehlikeli araç pg_resetwal komutudur. WAL'ı sıfırlar ve sunucuyu açabilir ama tekrar oynatılmamış işlemleri kalıcı olarak kaybettirir ve veritabanını mantıksal olarak tutarsız bırakabilir. Bu yalnızca başka yol olmadığında, kopya üzerinde ve veriyi hemen pg_dump ile dışarı almak için kullanılır.

Belirli bir sayfa bozuksa ve okuma hatası veriyorsa, oturum bazında zero_damaged_pages açılarak bozuk sayfaların sıfırlanıp geri kalanının okunması sağlanabilir; bu da ilgili satırları kaybettirir ama tablonun gerisini kurtarır. Transaction id sarması (xid wraparound) gibi mantıksal bozulmalar farklı bir müdahale gerektirir. Her durumda hedef, sunucu salt okunur bile açılır açılmaz veriyi tutarlı bir dökümle dışarı taşımaktır.

Son çare: sayfaları doğrudan dosyadan oyma

Motor hiçbir modda açılmıyorsa veya dosya o kadar hasarlıysa ki içe alınamıyorsa, kurtarma veritabanı motorundan bağımsız hale gelir. Bu noktada uzman, veri dosyasını ham olarak açar, sayfa başlıklarından sayfa sınırlarını bulur, sağlama toplamı tutan sağlam sayfaları ayıklar ve bilinen şemaya göre satırları (record) ayrıştırır. Bu, bir diskten dosya oyma (carving) işleminin veritabanına uyarlanmış halidir; genel oyma mantığını ham disk kurtarma ve sektör oyma yazımızda anlattık. Sonuç, tutarlı bir canlı veritabanı değil, kurtarılan tabloların dışa aktarımıdır; çoğu olayda iş açısından ihtiyaç duyulan budur.

Kurtarma sonrası: neden yeniden olmasın

Bir veritabanı kurtarmasının ardından asıl soru, bunun tekrar yaşanmamasıdır. Çoğu olayda kök neden yedekleme stratejisinin eksikliğidir: ya yedek alınmıyordu, ya yedekler de aynı bozuk depodaydı, ya da geri dönüş hiç test edilmemişti. Düzenli ve dışarıda tutulan yedekler, geri dönüş tatbikatı ve kurtarma hedeflerinin (RPO, RTO) tanımı şarttır; konuyu iş sürekliliği ve felaket kurtarma yazımızda ve kurumsal yedekten dönüş yazımızda ele aldık.

DSET yaklaşımı

DSET olarak veritabanı kurtarmalarını Ankara Hacettepe Teknokent laboratuvarımızda, önce ham dosyaları kopyalama ilkesiyle yürütürüz. Üretim sunucusuna dokunmadan MDF, ibdata ve base dosyalarının kopyaları üzerinde çalışır, kurtarma bayraklarını en düşük veri kaybı riskinden başlatır ve motor açılır açılmaz veriyi tutarlı bir dökümle dışarı taşırız. Depolama veya RAID kaynaklı bir bozulma varsa önce blok seviyesinde imaj alırız. Bir veritabanı suspect kaldıysa, InnoDB çöküyorsa veya PostgreSQL başlamıyorsa, üretim dosyalarına hiçbir onarım komutu çalıştırmadan DSET ile iletişime geçin. Olayın hukuki bir boyutu varsa delil zincirini adli bilişim süreci yazımızdaki ilkelerle koruruz.

Sık sorulan sorular

innodb_force_recovery kaçtan başlamalıyım? Her zaman 1 ile başlayın. 1 veya 2 ile MySQL açılırsa veri kaybı riski düşüktür ve hemen mysqldump ile tüm veriyi dışarı almalısınız. Açılmazsa birer birer yükseltin. 4, 5 ve 6 veri kaybına yol açabileceği için yalnızca kopya üzerinde ve başka çare kalmadığında kullanılır; bu seviyelerde açtıktan sonra veritabanını onarıp kullanmaya devam etmek değil, dışarı alıp temiz sunucuya geri yüklemek doğrudur.

SQL Server REPAIR_ALLOW_DATA_LOSS güvenli mi? Hayır, adı gibi veri kaybettirir: bozuk sayfaları silerek tutarlılığı sağlar. Yedek varsa yedekten dönüş her zaman daha iyidir. Bu komut yalnızca yedek yokken, son çare olarak ve mutlaka veritabanı dosyalarının kopyası üzerinde çalıştırılır. Öncesinde emergency modda DBCC CHECKDB ile bozulmanın boyutunu görmek gerekir.

Fidye yazılımı veritabanı dosyalarımı şifreledi, kurtarabilir misiniz? Bu bir veritabanı bozulması değil, bir güvenlik olayıdır. Şifreli MDF veya ibd dosyaları, şifreleme anahtarı olmadan matematiksel olarak geri getirilemez. Yapılabilecek şey, şifrelenmemiş gölge kopyalar, eski yedekler veya saldırının atladığı kopyaları aramak ve olay müdahalesini yürütmektir. Anahtarsız şifre çözme sözü veren hiçbir yönteme güvenmeyin.

Kaynaklar