Korhan Köseoğlu — altyapı yöneticisi. 18+ yıllık Linux, açık kaynak, sistem, ağ ve DevOps tecrübesiyle elde ettiğim sahadan çıkarımlar ışığında: bir PostgreSQL yedeğinin gerçekten işe yarayıp yaramadığını anlamak için sadece dosyaların varlığını kontrol etmek yetmez. Bu yazıda, geri dönüş senaryolarını düzenli olarak test etmenin neden kritik olduğunu, hangi düzeylerde doğrulama yapılması gerektiğini ve pratik bir test betiğiyle nasıl otomatikleştirebileceğinizi anlatıyorum.
Neden yedek testi gerekli? - Yedek alma süreci, işletme mantığı ve ortam değişkenleri sebebiyle çoğu zaman "alındı" raporu verir ama geri dönüş başarısız olabilir. Örnek nedenler: izin farklılıkları, WAL uyumsuzlukları, eksik konfigürasyon, dosya bozulması, versiyon uyuşmazlıkları. - Gerçek bir olayda (üretim veritabanı geri dönüşü gerektiğinde) zaman baskısı altında sorun çözmek zordur. Önceden denenmiş ve otomatikleştirilmiş bir prosedür hayat kurtarır. - Test yalnızca teknik doğrulama değil; ekiplerin süreçleri ve dokümantasyonu da sınanır.
Doğrulama seviyeleri (pratik yaklaşım) 1. Yedek bütünlüğü: alınan dosyaların bozulmadığının kontrolü — checksum/sha256 gibi. 2. Teknik geri dönüş: yedeğin bir test sunucusunda restore edilip veritabanının açılması. 3. Mantıksal doğrulama: iş mantığına göre kritik tabloların ayıklanıp beklenen satır sayısı/ölçütlerle karşılaştırılması. 4. İzlenebilir restore: WAL veya PITR gerekiyorsa, restore sonrası belirli bir LSN/ts'ye geri dönüp tutarlılığın sağlanması. 5. Uç vaka senaryoları: schema değişiklikleri, versiyon farkları, disk doluluk, eksik WAL gibi durumlarda restore testi.
Pratik ipuçları ve tuzaklar - Versiyon uyuşmazlığı: yedeği farklı minor/major PostgreSQL sürümünde restore etmeye çalışmak beklenmedik hatalar üretebilir. Testlerinizde kullanılan PostgreSQL sürümlerini açıkça kaydedin. - pg_basebackup ile alınan fiziksel yedekleri, aynı platform/OS üzerinde test edin. Farklı platformlarda permission/selinux/acl problemleri çıkar. - Logical dump (pg_dump) yedekleri schema/role bilgisi içermez; role/user yaratımı ve izinleri test prosedürünüze ekleyin. - WAL arşivleriyle PITR kullanıyorsanız, arşiv akışının eksiksiz ve zamanında olduğundan emin olun; arşiv kaybı restoreyi imkansız kılar. - Otomasyon önemli ama insanlı kurulumları da periyodik olarak prova edin — ekip bir kriz anında ne yapacağını bilmelidir.
Kısa kod örneği — restore ve basit doğrulama (bash) Aşağıdaki örnek, bir pg_dump arşivini geçici bir Docker PostgreSQL örneğine restore edip temel bir sorgu çalıştırarak kontrol eder. Bu örnek eğitim ve otomasyon başlangıcı içindir; üretimde güvenlik/konfigürasyon ihtiyacına göre uyarlayın.
#!/usr/bin/env bash set -euo pipefail
DUMP_FILE="/backups/latest.sql.gz" PG_IMAGE="postgres:15" CONTAINER_NAME="pg-restore-test-$$" PG_PORT=55432
if [[ ! -f "$DUMP_FILE" ]]; then echo "Yedek bulunamadı: $DUMP_FILE" >&2 exit 2 fi
Başlat: geçici konteyner docker run -d --name "$CONTAINER_NAME" -e POSTGRES_PASSWORD=pass -p ${PG_PORT}:5432 ${PG_IMAGE} trap "docker rm -f ${CONTAINER_NAME} >/dev/null 2>&1" EXIT
Docker'ın açılmasını bekle echo "Postgres başlatılıyor..." until docker exec "$CONTAINER_NAME" pg_isready -U postgres >/dev/null 2>&1; do sleep 1 done
Restore echo "Yedek restore ediliyor..." gunzip -c "$DUMP_FILE" | docker exec -i "$CONTAINER_NAME" psql -U postgres
Basit doğrulama: kritik tablo ve satır sayısı CRITICAL_QUERY="SELECT count(*) FROM public.users;" # Örnek; kendi kontrolünüzü koyun COUNT=$(docker exec -i "$CONTAINER_NAME" psql -U postgres -t -c "$CRITICAL_QUERY" | tr -d '[:space:]')
if [[ -z "$COUNT" ]]; then echo "Doğrulama başarısız: sorgudan sonuç alınamadı" >&2 exit 3 fi
echo "Doğrulama tamam: users satır sayısı = $COUNT" echo "Test başarılı."
Bu örnekte: - Yedek sıkıştırılmış SQL dump olarak bekleniyor. Fiziksel yedekler veya PITR için farklı adımlar gerekir. - "public.users" yerine sizin kritik tablolarınızı ve doğrulama kriterlerinizi koyun. - Sık sık çalıştırılan otomatik testler için CI/CD boru hattına entegre edin, ancak üretim verilerini kullanırken gizlilik ve veri koruma kurallarına uyun.
Kontrol listesi — restore testi yaparken hızlı rehber - [ ] Backup dosyası var mı? (lokasyon, izinler) - [ ] Backup checksum doğrulandı mı? (sha256/sha512) - [ ] Backup meta verisi (Postgres sürümü, zaman damgası) kaydedildi mi? - [ ] Restore işlemi test ortamında başarıyla tamamlandı mı? (sunucu açıldı, DB erişilebilir) - [ ] Temel sağlık sorguları çalışıyor mu? (ör. kritik tablolar, triggerler, fonksiyonlar) - [ ] Transaction log / WAL ile PITR gerekiyorsa hedef zaman/LSN'ye ulaşılabiliyor mu? - [ ] Kullanıcı/rol/izinler doğru şekilde yeniden oluşturuldu mu? - [ ] Versiyonlar arası uyumsuzluk testi yapıldı mı? (planlı yükseltmeler öncesi) - [ ] Otomatikleştirilmiş testler periyodik olarak çalıştırılıyor mu? (örn. haftalık/aylık) - [ ] Test sonuçları kaydediliyor ve bildirim/alarmlar var mı? - [ ] Ekip ve iletişim planı (disaster playbook) güncel mi ve prova edildi mi?
Saha çıkarımları (öz) - En sık gözlenen hata: yedek alındı ama restore script'inin beklentileri (roles, extensions) eksik. Uzun vadede bu, yedek alma prosedürüne role/extension dump'ını eklemeyi zorunlu kılıyor. - Otomasyonun işe yaraması için doğrulama kriterleri gerçekçi ve iş odaklı olmalı. Yalnızca "veritabanı açıldı" demek yeterli değil; iş koşullarını karşılayan birkaç anahtar sorgu çalışmalı. - Test frekansı risk bazlı belirlenmeli: yüksek değişim ve kritik veriye sahip sistemlerde daha sık; daha statik sistemlerde daha seyrek ama düzenli.
Kapanış Yedek almak kadar önemli olan, o yedeklerin gerçekten işe yaradığına güvenebilmektir. Düzenli restore tatbikatları, otomasyon ve iş odaklı doğrulama ile gerçek felaket anında zamana ve itfaya sahip olursunuz. Bu taslak, kendi ortamınız için uyarlanabilir bir başlangıç noktasıdır — her ortamın kendine has gereksinimleri vardır; bunları belirleyip test planınızı ona göre genişletin.
Not: Örnekler eğitsel amaçlıdır. Üretim ortamlarında güvenlik, erişim ve veri gizliliği politikalarınızı ihlal etmeden testler yapın ve test verilerini anonimleştirin.