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

> Periyodik base backup alıp WAL'ı sürekli S3'e arşivleyin, recovery_target_time ile hatalı ifadenin saniyeler öncesine dönün ve restore'u prova edin.

- Soruldu: 2026-06-09
- Yanıtlandı: 2026-06-12
- Soran: Yusuf
- Etiketler: veritabani, postgresql, dayaniklilik
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/veritabani-pitr-ve-wal-arsivleme-ile-felaket-oncesine-donmek/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Bir siber saldırı veya hatalı kod (örn. `WHERE` koşulu unutulmuş bir `DELETE`) sonucu üretim DB'miz tahrif oldu. Gece alınan SQL backup'ına dönersek 18 saatlik veri kaybımız olur.

DB mimarisinde WAL loglarının sürekli S3'e arşivlenmesi ve PITR altyapısı, felaket anından 3 saniye öncesine dönmemizi tam olarak nasıl sağlar? Süreci mimari olarak açıkla.


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.

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.

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.** Write-Ahead Log, DB'deki her değişikliği sırayla yazar. `archive_command` (ya da pgBackRest/WAL-G) ile bu 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'`. Postgres tam o noktada durur — yıkıcı ifadenin hemen öncesinde. "Felaketten bir an önce"ye böyle inersiniz, dün geceye değil.
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**. Doğrulanmamış bir yedek, Schrödinger'in yedeğidir — açana kadar çalışıp çalışmadığını bilmezsiniz. 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.

## İlgili Yazılar

- [PostgreSQL Her Şeye Yeter mi?](https://sade.dev/tr/journal/postgresql-her-seye-yeter-mi) — sade.dev
- [Veritabanı deadlock'larını önlemek için hangi kurallara dikkat etmeliyim?](https://www.muhammetsafak.com.tr/sor-bakalim/veritabani-deadlock-tespiti-ve-onleme-kurallari/) — Sor Bakalım
- [PostgreSQL split-brain'i quorum ve mutabakat ile nasıl önlerim?](https://www.muhammetsafak.com.tr/sor-bakalim/postgresql-split-brain-quorum-ve-mutabakat-ile-onlemek/) — Sor Bakalım
- [Sadece 'pending' satırları taranan bir kuyruk tablosunda partial index kullanmalı mıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/sadece-pending-satirlari-taranan-bir-kuyruk-tablosunda-partial-index-kullanmali-miyim/) — Sor Bakalım