Yedekten Tek Tablo Geri Yüklemek
Bir güncelleme sırasında yanlış sorgu çalıştı ve tek bir tablodaki veriler bozuldu. Elinizde dünkü yedek var ama tamamını geri yüklerseniz bugün alınan tüm siparişleri de kaybedeceksiniz. Bu ikilem, kısmi geri yükleme bilinmediğinde yaşanır.
Bu yazı, hedefli geri yüklemeyi ele alıyor.
Tam Geri Yüklemenin Bedeli
| Yöntem | Kayıp |
|---|---|
| Tüm veritabanını geri yükle | Yedekten sonraki her şey |
| Yalnızca bozulan tabloyu geri yükle | Sadece o tablodaki değişiklikler |
| Yalnızca etkilenen satırları düzelt | Neredeyse hiç |
Üçüncü satır her zaman mümkün olmasa da hedef budur: geri yükleme kapsamını daralttıkça kaybedilen veri azalır — ve çoğu vakada bozulan yalnızca birkaç yüz satırdır, tüm veritabanı değil.
Bu nedenle acele edip tam geri yükleme yapmak pahalıya mal olur.
Önce hasarın kapsamı belirlenmelidir.
Panik kararları genellikle ikinci bir kayıp üretir.
İlk Adım: Durdurmak
- Bozulmayı üreten işlemi durdurun.
- Gerekirse siteyi bakıma alın.
- Mevcut durumun yedeğini alın.
Üçüncü madde sezgiye aykırı ama kritiktir: bozulmuş veritabanının bile yedeğini almak gerekir — geri yükleme sırasında bir hata yaparsanız, en azından bulunduğunuz noktaya geri dönebilirsiniz.
Bozuk veri, hiç veri olmamasından iyidir.
Bu yedek ayrıca hasar analizi için de gerekir.
Neyin değiştiğini karşılaştırmalı olarak görürsünüz.
Yedekten Tek Tabloyu Ayıklamak
- Döküm dosyası düz metindir.
- Tablo bölümleri işaretlidir.
- İlgili bölüm ayıklanabilir.
İkinci madde işlemi mümkün kılar: veritabanı döküm dosyalarında her tablo açık yorum satırlarıyla ayrılır — bu işaretler arasındaki bölümü ayıklamak, tüm dosyayı yüklemeden tek tabloyu geri getirmenizi sağlar.
Bu işlem metin araçlarıyla yapılabilir.
Çok büyük dosyalarda satır aralığı belirlenerek çıkarılır.
Ayıklanan bölüm ayrı bir dosyaya yazılır.
Geçici Veritabanı Yöntemi
- Yedek geçici bir veritabanına yüklenir.
- İstenen tablo oradan alınır.
- Canlı veritabanına aktarılır.
Bu yöntem en güvenlisidir: yedeği doğrudan canlı veritabanına yüklemek yerine geçici bir veritabanına yüklemek, yanlışlıkla tüm verinin üzerine yazma riskini tamamen ortadan kaldırır.
Geçici veritabanı işlem sonrası silinir.
Paylaşımlı barındırmada ek veritabanı hakkınız varsa uygulanabilir.
Bu yöntem ayrıca karşılaştırma imkânı da verir.
İlişkileri Düşünmek
| Durum | Risk |
|---|---|
| Bağımsız tablo | Sorunsuz |
| Başka tablolarla ilişkili | Tutarsızlık riski |
| Otomatik artan kimlik | Çakışma riski |
İkinci satır en dikkat gerektiren durumdur: tek bir tabloyu eski hâline döndürmek, ona bağlı diğer tablolardaki yeni kayıtları sahipsiz bırakabilir — sipariş tablosu geri yüklenirken bugünkü ödeme kayıtları karşılıksız kalır.
Bu tutarsızlık geri yükleme anında görünmez.
Sonradan raporlarda ortaya çıkar.
Üçüncü satır ise yeni kayıtlarda kimlik çakışmasına yol açabilir.
Yalnızca Etkilenen Satırlar
- Hangi satırların bozulduğu belirlenir.
- Yalnızca onlar yedekten alınır.
- Diğerlerine dokunulmaz.
Bu yaklaşım en az kayıpla sonuçlanır: bozulan kayıtları koşulla belirleyip yalnızca onları geri yüklemek, aynı tablodaki sağlam ve yeni kayıtları korur — çoğu vakada doğru çözüm budur.
Güncelleme zamanı sütunu bu belirlemeyi kolaylaştırır.
Belirli bir saatten sonra değişen kayıtlar süzülür.
Bu sütunun varlığı böyle anlarda çok değerlidir.
Geri Yükleme Sonrası
- Satır sayılarını karşılaştırın.
- Örnek kayıtları kontrol edin.
- İlişkili tabloları doğrulayın.
Üçüncü madde tutarsızlıkları yakalar: geri yüklemeden sonra sahipsiz kalan kayıtları bulan bir sorgu çalıştırmak, gözden kaçan tutarsızlıkları hemen ortaya çıkarır — bu kontrol sonradan yaşanacak garip hataları önler.
Birinci madde ise en hızlı doğrulamadır.
Beklenen ve gerçekleşen satır sayısı karşılaştırılır.
Fark varsa işlem gözden geçirilmelidir.
Önceden Hazırlık
| Hazırlık | Faydası |
|---|---|
| Tablo bazlı yedek almak | Ayıklama gerekmez |
| Sık yedek almak | Kayıp penceresi daralır |
| Geri yükleme provası | Süre bilinir |
İkinci satır en belirleyici olanıdır: yedek sıklığı, kaybedebileceğiniz en fazla veriyi doğrudan belirler — günde bir yedek alan bir site, en kötü durumda bir günlük veriyi kaybetmeyi kabul etmiş demektir.
Bu kabul bilinçli yapılmalıdır.
Sipariş alan siteler için bir gün çok uzundur.
Üçüncü satır ise kriz anında zaman kazandırır.
Yedeklerinizi düzenli alabilmek ve geri yükleme provası yapabilmek için yeterli disk ve panel erişimi gerekir; hosting altyapı çözümleri ile yedekleme planınızı kendiniz yönetebilirsiniz.
Sonuç
Bozulan bir tablo için tüm veritabanını geri yüklemek gereksiz kayıp üretir: geri yükleme kapsamını daralttıkça kaybedilen veri azalır. Önce bozulmayı durdurun, mevcut durumun bile yedeğini alın ve yedeği geçici bir veritabanına yükleyip oradan aktarın. İlişkileri unutmayın — tek tabloyu eski hâline döndürmek, ona bağlı yeni kayıtları sahipsiz bırakabilir.
Sıkça Sorulan Sorular (SSS)
Tüm veritabanını geri yüklemek zorunda mıyım?
Hayır ve genellikle yapmamalısınız. Tam geri yükleme, yedekten sonraki her şeyi kaybettirir. Çoğu vakada bozulan yalnızca birkaç yüz satırdır; kapsamı daralttıkça kayıp azalır. Önce hasarın kapsamını belirleyin.
Yedekten tek tabloyu nasıl çıkarırım?
Döküm dosyaları düz metindir ve her tablo açık yorum satırlarıyla ayrılır; bu işaretler arasındaki bölümü metin araçlarıyla ayıklayabilirsiniz. Daha güvenli yol, yedeği geçici bir veritabanına yükleyip tabloyu oradan aktarmaktır.
Tek tablo geri yüklemenin riski var mı?
Var. Bir tabloyu eski hâline döndürmek, ona bağlı diğer tablolardaki yeni kayıtları sahipsiz bırakabilir; sipariş tablosunu geri yüklerken bugünkü ödeme kayıtları karşılıksız kalır. Sonrasında sahipsiz kayıtları bulan bir sorgu çalıştırın.
Geri yüklemeden önce ne yapmalıyım?
Bozulmayı üreten işlemi durdurun ve bozuk hâliyle bile mevcut veritabanının yedeğini alın. Geri yükleme sırasında bir hata yaparsanız en azından bulunduğunuz noktaya dönebilirsiniz; ayrıca bu yedek hasar analizi için de gerekir.
