- Katılım
- 21 May 2023
- Mesajlar
- 539
- Tepki
- 17
- Puan
- 18
Diyelim ki her gece otomatik alınan bir veritabanı yedeğiniz var ve bu güvence sizi rahatlatıyor. Ama o yedek dosyasını en son ne zaman gerçekten geri yükleyip, verinin eksiksiz döndüğünü gözünüzle gördünüz?
Bu yazı, yedeğin var olmasıyla geri yüklenebilir olması arasındaki farkı ve bu ikisini nasıl ayırt edeceğinizi gösteriyor.
Yedeğin varlığı, geri yüklenebilirliğin garantisi değil
Bir yedekleme işinin "başarılı" olarak tamamlanması, dosyanın diskte oluştuğu anlamına gelir; bu dosyanın gerçekten tutarlı, bozulmamış ve geri yüklendiğinde çalışır bir veritabanı üreteceği anlamına gelmez. Disk dolarken yarım kalan bir yedek, sıkıştırma sırasında bozulan bir arşiv veya yanlış zamanlamada alınıp tutarsız bir anlık görüntü yakalayan bir dosya, hepsi "yedek alındı" logunu geçtikten sonra da bu sorunları taşıyabilir.
MySQL'in resmî yedekleme ve kurtarma belgesine göre yedekler, bir MySQL kurulumunu yükseltmeden önce alınması gereken temel bir güvenlik önlemi olarak tanımlanıyor. Belge mantıksal (logical) ve fiziksel (physical) yedekleme yöntemlerini, tam ve artımlı (incremental) yedeklemeyi ve zaman noktasına geri yükleme (point-in-time recovery) yöntemlerini ayrı ayrı ele alıyor.
MySQL'de hangi yöntem ne zaman kullanılır
Mantıksal yedekleme, veritabanının SQL komutlarına dönüştürülmüş bir çıktısını alır; taşınabilirliği yüksektir ama büyük veritabanlarında geri yükleme süresi uzayabilir. Fiziksel yedekleme ise dosya sistemi düzeyinde çalışır, genelde daha hızlı geri yüklenir ama kaynak ve hedef sunucunun uyumluluğuna daha bağımlıdır.
- Mantıksal yedek: SQL çıktısı üretir, farklı sürümler arası taşımada esnektir.
- Fiziksel yedek: Veri dosyalarının kendisini kopyalar, geri yükleme genelde daha hızlıdır.
- Tam yedek: Belirli bir andaki tüm veritabanının kopyası.
- Artımlı yedek: Son tam yedekten bu yana değişen kısmı kaydeder, depolamayı azaltır ama geri yükleme birden fazla parçanın sırayla uygulanmasını gerektirir.
Artımlı yedekler kullanıyorsanız, geri yükleme sırasında bu parçaların doğru sırayla ve eksiksiz uygulanması gerekiyor; bir parça eksikse veya bozuksa, zincirin geri kalanı da işe yaramaz hale gelebilir. Bu, "her gece yedek alınıyor" ifadesinin, "istediğim ana geri dönebilirim" ifadesiyle her zaman aynı şey olmadığını gösteriyor.
Bir MySQL sunucusu beklenmedik şekilde durursa yaşanan sorunları ayrıntılı ele alan MySQL 'Shutdown Unexpectedly' hatası yazımız, böyle bir kesintiden sonra elinizdeki yedeğin neden hemen o an işinize yarayacağı anlamına gelmediğini de dolaylı olarak gösteriyor; kesinti anındaki tutarlılık, yedeğin alındığı yöntemle doğrudan ilgili.
PostgreSQL'de üç temel yöntem
PostgreSQL'in resmî yedekleme ve geri yükleme belgesine göre üç temel yedekleme yöntemi var: SQL dump, dosya sistemi seviyesinde yedekleme ve sürekli arşivleme (continuous archiving, yani zaman noktasına geri yükleme/PITR). Belge, her yönteminin "kendi güçlü ve zayıf yönleri" olduğunu belirtiyor ve hangisinin seçileceğinin altında yatan teknikleri ve varsayımları anlamaya bağlı olduğunu vurguluyor.
Bu üç yöntem birbirinin yerine geçmiyor: SQL dump taşınabilir ama büyük veritabanlarında yavaş; dosya sistemi yedeği hızlı ama sunucu kapalıyken veya tutarlılık aracı kullanılarak alınmalı; sürekli arşivleme ise belirli bir andaki durumu değil, zaman içindeki bir aralığı geri yükleme imkânı sunuyor. Hangi yöntemi seçtiğiniz, felaket anında hangi ana kadar geri dönebileceğinizi doğrudan belirliyor.
Yedeğin kendisi kadar, veritabanının günlük işleyişinin de sağlıklı olması önemli; yavaş çalışan bir sorgu farklı bir teşhis konusu olsa da aynı veritabanı disiplini içinde duruyor. PostgreSQL'de yavaş sorgu: EXPLAIN ANALYZE okuma rehberimiz bu tarafı ayrıca ele alıyor.
Geri yükleme testini nasıl kurarsınız
Bir yedeğin gerçekten işe yarayıp yaramadığını anlamanın tek güvenilir yolu, onu ayrı bir ortamda gerçekten geri yüklemek. Bu, üretim sunucusunda değil, ayrı bir test sunucusunda veya geçici bir örnekte yapılabilir: yedek dosyası oradan geri yüklenir, temel tabloların satır sayıları ve birkaç kritik sorgunun sonucu üretimdeki güncel durumla karşılaştırılır.
Bu testin ne sıklıkla yapılacağı sizin veri değişim hızınıza bağlı; ama en azından yedekleme yönteminizi veya sunucu sürümünüzü her değiştirdiğinizde bir kez tekrarlamak makul bir alışkanlık. Bir yedekleme betiğini yıllarca aynı şekilde çalıştırıp hiç geri yüklemeden bırakmak, betiğin bir noktada sessizce bozulmuş olma ihtimalini fark etmeden geçirmenize yol açabilir; disk yolu değişmiş, yetki kaybolmuş veya sıkıştırma adımı hatayla sonuçlanıyor ama günlüğe yazılmıyor olabilir.
Bu testi düzenli bir alışkanlık haline getirmek, "yedek var" ile "yedek çalışıyor" arasındaki farkı kapatan tek yöntem. Veritabanı yönetiminin genel çerçevesini gözden geçirmek isterseniz veri tabanı yönetimi yazımıza da bakabilirsiniz; yedekleme de bu çerçevenin ayrılmaz bir parçası olarak orada yer alıyor.
Püf nokta' Alıntı:
Özetle
Bir yedekleme işinin başarıyla tamamlanmış görünmesi, o yedeğin geri yüklendiğinde çalışır bir veritabanı üreteceğinin garantisi değil. MySQL ve PostgreSQL'in resmî belgeleri farklı yedekleme yöntemlerini ve bunların güçlü/zayıf yönlerini ayrı ayrı tanımlıyor; hangisini seçerseniz seçin, o yedeği ayrı bir ortamda gerçekten geri yükleyip test etmeden güvenilir saymamak en sağlam yaklaşım.
Yedeğinizi en son ne zaman gerçekten geri yükleyip test ettiniz?
Güncelleme: 24 Ağustos 2026.
Dijital Dünyanıza Yön Veren Pusula
