Veritabanı yönetimi ve site güvenilirliği mühendisliğinin yüksek riskli dünyasında, iyi bilinen bir aksiyom vardır: Schrödinger’in Yedeği. Herhangi bir yedeğin durumu, onu geri yüklemeye çalışana kadar bilinmez. O ana kadar, hem mükemmel şekilde çalışır durumda hem de tamamen bozulmuş olma kuantum durumunda var olur.
DevOps mühendisleri ve veritabanı yöneticileri (DBA’lar) için, aktif bir olay sırasında kritik bir veritabanı yedeğinin bozuk olduğunu keşfetmek, en büyük kabus senaryosudur. Bu durum, rutin bir kurtarma işlemini felaketle sonuçlanan bir veri kaybı olayına dönüştürür. Veri bütünlüğünün bu “sessiz katili”, yedekleme işleri temel yük (payload) tehlikeye girmiş olsa bile sıklıkla başarılı bir Exit Code 0 raporladığı için genellikle fark edilmez.
Bu kapsamlı rehberde, yedekleme bozulmasının anatomisini inceleyecek, veritabanına özgü doğrulama tekniklerini keşfedecek ve üretim ortamları için otomatik, kurşun geçirmez geri yükleme hatlarının nasıl oluşturulacağını göstereceğiz.
Yedekleme Bozulmasının Anatomisi
Bozulmayı tespit etmek için önce nasıl meydana geldiğini anlamanız gerekir. Yedekleme bozulması genellikle iki kategoriye ayrılır: fiziksel (altyapı düzeyi) ve mantıksal (uygulama düzeyi).
Fiziksel Bozulma
Fiziksel bozulma, depolama ortamındaki gerçek bitler değiştiğinde meydana gelir. Bu, kaynak diskten okuma işlemi sırasında, ağ üzerinden iletim sırasında veya hedef depolama alanında hareketsiz dururken gerçekleşebilir.
* Bit Çürümesi (Bit Rot): Depolama ortamının kademeli olarak bozulması, bitleri sessizce tersine çevirebilir.
* İletim Hataları: TCP’nin sağlama toplamları (checksum) olsa da, bunların oldukça zayıf (16-bit) olduğu bilinmektedir. Yüksek verimli ortamlar, TCP’nin yakalayamadığı sessiz veri bozulmalarını kablo üzerinde yaşayabilir.
* Depolama Denetleyicisi Hataları: RAID denetleyicilerindeki veya SAN yapılarındaki donanım hataları, işletim sistemine başarı raporu verirken çöp veri yazabilir.
Mantıksal Bozulma
Mantıksal bozulma, yedekleme dosyasının kendisi tamamen sağlam olmasına rağmen içindeki verilerin bozuk olması nedeniyle muhtemelen daha tehlikelidir.
* Çöp Girer, Çöp Çıkar (GIGO): Canlı veritabanınızda bozuk bir dizin veya yırtık bir sayfa varsa, yedekleme aracınız bu bozuk sayfayı sadakatle kopyalayabilir. Yedekleme işi başarılı olur, ancak geri yükleme başarısız olur veya bozuk bir veritabanı ortaya çıkar.
* Tamamlanmamış İşlemler: Veritabanı G/Ç’sini düzgün bir şekilde dondurmadan (örneğin, MySQL’de FLUSH TABLES WITH READ LOCK kullanmadan) alınan dosya sistemi düzeyindeki anlık görüntüler, yırtık sayfalara ve kurtarılamaz durumlara neden olur.
Proaktif Tespit: Sağlama Toplamları ve Kriptografik Hashing
Fiziksel bozulmaya karşı ilk savunma hattı kriptografik doğrulamadır. Dosya boyutlarına veya değiştirilme tarihlerine güvenmek yetersizdir.
Veritabanı Düzeyinde Sağlama Toplamlarını Etkinleştirme
Modern ilişkisel veritabanı yönetim sistemleri (RDBMS), sayfa düzeyinde sağlama toplamlarını destekler. Etkinleştirildiğinde, veritabanı her sayfayı diske yazmadan önce bir sağlama toplamı hesaplar. Sayfa okunduğunda (bir sorgu veya yedekleme işlemi tarafından), sağlama toplamı doğrulanır.
PostgreSQL için, küme başlatma sırasında veri sağlama toplamlarını etkinleştirebilirsiniz:
# Sağlama toplamları etkinleştirilmiş yeni bir PostgreSQL kümesi başlatın
initdb --data-checksums -D /var/lib/postgresql/data
Not: Mevcut bir PostgreSQL kümeniz varsa, bunları çevrimdışı olarak etkinleştirmek için pg_checksums yardımcı programını kullanabilirsiniz.
Microsoft SQL Server için, PAGE_VERIFY ayarının CHECKSUM olarak ayarlandığından emin olun (modern sürümlerde varsayılandır, ancak eski sistemlerde doğrulamaya değer):
ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO
Yedeklerin Hareketsiz Halde Doğrulanması
Yedekleme depolama hedefinize ulaştığında, bütünlüğü kriptografik olarak doğrulanmalıdır. CloudSave gibi kurumsal yedekleme platformları, iletim sırasında ve hareketsiz haldeyken yedekleme bloklarının SHA-256 hash’lerini otomatik olarak hesaplar ve doğrular. Özel komut dosyalarını yönetiyorsanız, bunu manuel olarak uygulamanız gerekir:
# Yedekleme oluşturulduktan sonra SHA-256 hash'i oluşturun
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256
# Depolama sunucusundaki hash'i doğrulayın
sha256sum -c prod_db_backup.tar.gz.sha256
Veritabanına Özgü Doğrulama Teknikleri
Farklı veritabanı motorları, yedekleme yapılarının bütünlüğünü doğrulamak için yerel araçlar sunar.
PostgreSQL: pg_verifybackup
PostgreSQL 13 ile tanıtılan pg_verifybackup, pg_basebackup ile alınan fiziksel yedeklemeler için oyunun kurallarını değiştiren bir araçtır. Yedekleme sırasında oluşturulan backup_manifest dosyasını okur ve tüm dosyaların mevcut olduğunu ve sağlama toplamlarının eşleştiğini doğrular.
# Fiziksel bir temel yedekleme dizinine karşı doğrulama çalıştırın
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/
Veri dosyalarından herhangi birinde tek bir bit bile değişmişse, pg_verifybackup ölümcül bir hata verecek ve izleme sistemlerinizin DBA ekibini anında uyarmasını sağlayacaktır.
Microsoft SQL Server: RESTORE VERIFYONLY
SQL Server, bir yedekleme dosyasını gerçekten geri yüklemeden fiziksel bütünlüğünü doğrulamak için yerel bir komut sağlar. Yedekleme başlıklarını kontrol eder ve sayfa sağlama toplamlarını (yedekleme sırasında etkinleştirilmişlerse) doğrular.
RESTORE VERIFYONLY
FROM DISK = 'Z:BackupsProdDB_Full.bak'
WITH CHECKSUM;
Uyarı: RESTORE VERIFYONLY yalnızca yedekleme dosyasının okunabilir olduğunu ve fiziksel sağlama toplamlarının eşleştiğini onaylar. Mantıksal bütünlüğü garanti etmez. Mantıksal bütünlüğü sağlamak için tam bir geri yükleme yapmalı ve DBCC CHECKDB çalıştırmalısınız.
MySQL / InnoDB: Percona XtraBackup
MySQL ortamları için fiziksel yedeklemeler genellikle Percona XtraBackup tarafından gerçekleştirilir. Yedekleme işlemi dosyaların kopyalanmasından oluşur, ancak işlem günlükleri (redo logs) uygulanana kadar yedekleme tutarlı değildir. --prepare aşaması, yerleşik bir bütünlük kontrolü görevi görür.
# Yedeği hazırlamak redo log'larını uygular.
# Yedek bozuksa, bu adım başarısız olur.
xtrabackup --prepare --target-dir=/data/backups/mysql/
Altın Standart: Otomatik Geri Yükleme Testi
Sağlama toplamları ve doğrulama komutları gereklidir, ancak yeterli değildir. Bir yedeğin geçerli olduğunu kesin olarak kanıtlamanın tek yolu onu geri yüklemektir. Modern DevOps ortamlarında bu süreç tamamen otomatikleştirilmelidir.
Yedekleri kod olarak ele alarak, veritabanı geri yüklemeleriniz için bir CI/CD hattı oluşturabilirsiniz. Bu hat, geçici altyapı sağlamalı, geri yüklemeyi yürütmeli, doğrulama sorgularını çalıştırmalı ve ortamı temizlemelidir.
Otomatik Geri Yükleme Hattı Oluşturma
Aşağıda, bir PostgreSQL mantıksal dökümünü doğrulamak için cron işi veya bir CI çalıştırıcısı (GitLab CI veya GitHub Actions gibi) tarafından günlük olarak tetiklenebilecek bir Bash betiği örneği bulunmaktadır.
#!/bin/bash
set -e
BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"
echo "[INFO] Otomatik Geri Yükleme Testi Başlatılıyor..."
# 1. Geçici bir PostgreSQL konteyneri çalıştırın
docker run --name $CONTAINER_NAME
-e POSTGRES_PASSWORD=testpass
-d postgres:15
# PostgreSQL'in hazır olmasını bekleyin
echo "[INFO] Veritabanının başlatılması bekleniyor..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
sleep 2
done
# 2. Hedef veritabanını oluşturun
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"
# 3. Geri yüklemeyi gerçekleştirin
echo "[INFO] Yedek geri yükleniyor..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump
# 4. Mantıksal Doğrulama Sorgularını Çalıştırın
echo "[INFO] Doğrulama sorguları çalıştırılıyor..."
# Kullanıcılar tablosunda 10.000'den fazla kayıt olup olmadığını kontrol edin
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")
if [ "$USER_COUNT" -lt 10000 ]; then
echo "[ERROR] Mantıksal doğrulama başarısız oldu. Beklenen >10000 kullanıcı, bulunan $USER_COUNT"
# Buradan PagerDuty / Slack uyarısı tetikleyin
exit 1
else
echo "[SUCCESS] Mantıksal doğrulama başarılı. Kullanıcı sayısı: $USER_COUNT"
fi
# 5. Geçici ortamı temizleyin
echo "[INFO] Temizlik yapılıyor..."
docker rm -f $CONTAINER_NAME
echo "[INFO] Otomatik Geri Yükleme Testi Başarıyla Tamamlandı."
Neleri Doğrulamalısınız?
Otomatik geri yükleme testi yaparken, sadece veritabanının başlayıp başlamadığını kontrol etmeyin. Uygulamaya özel doğrulama sorguları çalıştırın:
1. Satır Sayıları: Temel tabloların beklenen satır sayılarına sahip olduğundan emin olun (örneğin, users tablosu boş olmamalıdır).
2. Güncel Veriler: Yedeğin eski olmadığından emin olmak için son 24 saat içinde oluşturulan kayıtları sorgulayın.
3. Referans Bütünlüğü: Mantıksal bozulmayı gösteren yetim yabancı anahtarları (orphaned foreign keys) kontrol etmek için betikler çalıştırın.
Yedekleme Anomalileri İçin İzleme ve Uyarı
Felaket gerçekleşmeden önce bozulmayı tespit etmek, güçlü bir gözlemlenebilirlik gerektirir. İkili başarı/başarısızlık durumlarının ötesinde, anomalileri tespit etmek için yedekleme işlerinizin meta verilerini izlemelisiniz.
Sezgisel İzleme
Yedekleme meta verilerinizi Prometheus’a entegre edin ve Grafana ile görselleştirin. Aşağıdaki sezgisel yöntemler için uyarılar ayarlayın:
* Ani Boyut Düşüşleri: Günlük yedeğiniz sürekli 500GB ise ve bugünkü yedek 50MB ise, iş başarıyla tamamlanmış olabilir (Exit Code 0), ancak muhtemelen boş bir şemayı yedeklemiştir.
* Süre Anomalileri: Normalde 2 saat süren bir yedekleme 5 dakikada biterse, bir şeyler atlanmış demektir. Tersine, 10 saat sürerse, bozulmaya yol açabilecek disk G/Ç bozulması yaşıyor olabilirsiniz.
* WAL/Arşiv Günlüğü Birikimi: Veritabanınız Yazma Öncesi Günlükler (WAL) oluşturuyor ancak yedekleme sistemi bunları yeterince hızlı arşivlemiyorsa, Noktasal Kurtarma (PITR) zincirinizde bir boşluk riskiyle karşı karşıya kalırsınız.
Bütünlük Kontrolleri ile 3-2-1 Kuralını Uygulama
Endüstri standardı olan 3-2-1 yedekleme kuralı (3 kopya veri, 2 farklı ortam, 1 kurum dışı), yalnızca tüm kopyalar doğrulandığında etkilidir.
CloudSave gibi kurumsal bir çözümden yararlanmak, operasyonel yükü önemli ölçüde azaltır. Her veritabanı düğümü için karmaşık bash betikleri yazmak ve sürdürmek yerine, CloudSave 3-2-1 yaşam döngüsünü otomatikleştirmek için doğrudan altyapınızla entegre olur. Fidye yazılımlarına karşı koruma sağlayan değiştirilemez (immutable) depolama sunar ve yerleşik, otomatik geri yükleme doğrulama programlarına sahiptir. CloudSave, izole edilmiş sanal alan ortamlarını otomatik olarak başlatabilir, yedeği bağlayabilir, özel SQL doğrulama betiklerinizi çalıştırabilir ve sağlık durumunu merkezi panonuza geri bildirebilir.
Sonuç
Bozuk veritabanı yedekleri, işletmeleri yok edebilecek sessiz bir katildir. Sadece bir yedekleme betiğinin Exit Code 0 değerine güvenmek tehlikeli bir kumardır.
Üretim ortamlarınızı gerçekten korumak için derinlemesine bir savunma stratejisi benimsemelisiniz:
1. Veritabanı motorunuzda sayfa düzeyinde sağlama toplamlarını etkinleştirin.
2. Yedekleme oluşturulduktan hemen sonra yerel doğrulama araçlarını (pg_verifybackup, RESTORE VERIFYONLY) kullanın.
3. Yedekleme meta verilerini (boyut, süre) sezgisel anomaliler için izleyin.
4. Günlük operasyonel hattınızın bir parçası olarak otomatik, geçici geri yükleme testini uygulayın.
Pasif bir “kur ve unut” yedekleme zihniyetinden aktif bir “sürekli geri yükleme doğrulaması” modeline geçerek, felaket kaçınılmaz olarak gerçekleştiğinde verilerinizin hazır, güvenilir ve tamamen kurtarılabilir olduğundan emin olursunuz.
