WAL arşivleme ve PITR ile felaketten saniyeler öncesine nasıl dönerim?

Kısa cevap: Gecelik dump’lar 18 saatlik bir RPO (kabul edilebilir veri kaybı penceresi) demek — üretimde bu kabul edilemez. PITR (Point-in-Time Recovery) bu boşluğu kapatır ve sizi hatalı ifadenin saniyeler öncesine geri götürür.

Kısa cevap

Mantık şu: bir base backup + o andan itibaren her değişikliğin sıralı kaydı (WAL) varsa, istediğiniz tam ana kadar “ileri sararak” geçmişi yeniden inşa edebilirsiniz. RPO ve RTO hedeflerini nasıl belirlediğimi, aktif-pasif senaryoyla birlikte felaket kurtarma kaydında ele almıştım; PITR o hedeflerin veritabanı ayağıdır.

Neden

1. Write-Ahead Log, DB’deki her değişikliği sırayla yazar. Bu sıralı kayıt dışarıya arşivlendiği sürece, base backup ile şu an arasındaki her işlem geri oynatılabilir durumda kalır — kayıp penceresi yedek aralığına değil, arşivleme gecikmesine iner.

2. recovery_target_time sizi tam istediğiniz ana bırakır. Postgres belirlediğiniz noktada durur — yıkıcı ifadenin hemen öncesinde. “Felaketten bir an önce”ye böyle inersiniz, dün geceye değil.

3. Doğrulanmamış bir yedek, Schrödinger’in yedeğidir. Açana kadar çalışıp çalışmadığını bilmezsiniz; kurtarma prova edilmemişse elinizde bir yedek değil, bir varsayım vardır.

Ne yapmalı

1. Periyodik base backup alın. Düzenli aralıklarla tutarlı bir tam yedek (base backup) alın. Bu, kurtarmanın başlangıç noktasıdır; WAL replay’i bu temelin üstüne uygulanır.

2. WAL’ı sürekli S3’e arşivleyin. archive_command (ya da pgBackRest/WAL-G) ile WAL segmentlerini üretildikçe S3’e atın. Böylece base backup ile şu an arasındaki her işlemin kaydı dışarıda, güvende durur.

3. recovery_target_time ile tam ana kadar replay edin. Kurtarırken base backup’ı geri yükleyin, sonra WAL’ı belirlediğiniz hedefe kadar oynatın: recovery_target_time = '...hatalı DELETE'den 3 saniye öncesi'.

4. Restore’u mutlaka prova edin. WAL arşivleme açık ve test edilmiş olmalı, base backup’lar bir takvime bağlı olmalı. En kritiği: kurtarmayı periyodik prova edin. Bunu elle yazmayın; pgBackRest ya da WAL-G kullanın.

Sonuç: Base backup + sürekli WAL arşivleme (S3’e) + test edilmiş PITR — 18 saatlik kaybı saniyelere indirir. Üretim DB’sinde sadece gecelik dump’a güvenmek, bir gün gelecek hatalı bir DELETE’te sizi saatlerce veri kaybıyla baş başa bırakır; PITR’ı bugünden kurun ve restore’u prova edin.