PostgreSQL yedek ve geri yükleme: dosya değil kurtarma planı

Kimler için?

Kendi PostgreSQL ve mobil backend ortamını işleten ekipler.

Başlamadan önce

Ayrı test veritabanı, korunan backup alanı ve yetkili operasyon hesabı.

1. Kaybolabilecek veri ve kesinti hedefini yazın

RPO, kabul edilebilir veri kaybı aralığını; RTO ise hizmeti geri getirme hedefini anlatır. Günde bir kopya almak çok daha kısa RPO beklentisini karşılamaz. Büyük bir veritabanının geri yüklenmesi, sadece dosyayı indirme süresi değildir; indeks, doğrulama ve uygulama açılışı da süreye girer. Hedefleri ürünün kritik işlemleriyle birlikte belirleyin.

2. Yedek kapsamını envantere dönüştürün

SQL verisi, roller, extension, storage nesneleri ve uygulama yapılandırması ayrı öğelerdir. PostgreSQL dump’ı yüklenen kullanıcı fotoğraflarını otomatik içermez. Şifreleme anahtarını kaybederseniz şifreli değerlerin yedeği tek başına işe yaramayabilir. Sırları korunan ayrı bir yöntemle saklayın; backup ile herkesin okuyabildiği aynı dizine kopyalamayın.

3. Mantıksal backup örneği

Aşağıdaki komutlar yalnızca size ait ayrı test ortamına uyarlanmalıdır. Parolayı komut satırına yazmayın; uygun izinli password file veya onaylı credential yöntemi kullanın. Sürüm ve extension uyumunu kontrol edin. Mantıksal dump yaklaşımı her RPO/RTO için yeterli değildir; sürekli arşivleme ve point-in-time recovery farklı bir işletme planıdır.

umask 077
pg_dump -h 127.0.0.1 -U app_backup -d app_test -Fc -f app_test.dump
createdb -h 127.0.0.1 -U app_operator app_restore_test
pg_restore -h 127.0.0.1 -U app_operator -d app_restore_test --no-owner app_test.dump
# Production veritabanının üzerine geri yüklemeyin.

4. Ayrı ortamda gerçek restore deneyi yapın

Yedeği hedef test ortamına geri yükleyin; sadece pg_restore çıkış kodunu kontrol ederek bitirmeyin. Kullanıcı girişini, kayıt okuma/yazmayı, kritik ilişki ve dosya erişimini deneyin. Sayımlar başlangıç kontrolüdür; örnek kayıt değerleri ve ilişki tutarlılığı da gerekir. Ortamın gerçek e-posta, push veya ödeme göndermesini önleyin; restore testi kullanıcıya bildirim üretmemelidir.

5. Kopyaları aynı arızaya bağlı bırakmayın

Aynı disk üzerindeki dump, o disk kaybolduğunda kaybolur. Kopyaları ayrı erişim sınırı ve arıza alanında tutun; şifreleme, retention ve silme yetkisini planlayın. Yedek işi başarısız olduğunda alarmın nereye gittiğini test edin. Sağlayıcının ücretsiz yedekleme ifadesi, uygulamanızın ihtiyacına uygun kurtarma kanıtı değildir.

6. Kurtarma raporu ve sorumluyu kaydedin

Test tarihi, kullanılan kopya, geri yükleme süresi, doğrulanan akışlar ve eksik öğeleri yazın. Bir kişinin yokluğunda adımların izlenebilir olması gerekir. Düzenli tekrar sıklığını veri değişimi ve iş riskine göre belirleyin. Uygulama Cloud bugün müşteri yedek/restore servisi sunmaz; bu rehber kendi ortamınıza uygulanacak bir kontrol planıdır.

• Backup hata alarmı çalışıyor.
• Restore production’dan ayrı ortamda yapıldı.
• Dosya ve SQL ilişkileri doğrulandı.
• RPO/RTO hedefleri ölçülen sonuçla karşılaştırıldı.