İçeriğe geç
Blog

PostgreSQL yedekleme stratejileri: pg_dump'tan PITR'ye

Üretim PostgreSQL ortamları için pgBackRest, WAL archive, point-in-time recovery ve restore tatbikatı stratejileri.

Tarih
Yazar Murat Haktanır
Okuma süresi 2 dk

“Yedeğimiz var” sözünün gerçek anlamı: restore tatbikatımız var. Yedek almak kolaydır; geri yüklemenin ilk denemesini gerçek olayda yapmak felakettir.

Yedekleme tipleri

PostgreSQL için pratikte 3 yedek tipi vardır:

  1. Logical (pg_dump): SQL veya custom format dosyası. Esnek; ama point-in-time geri yüklemez. Büyük DB’lerde saatler sürebilir.
  2. Physical (file-system): Veri dosyalarının kopyası. Hızlı; tutarlılık için pg_basebackup kullanılır.
  3. WAL archive + base: Sürekli WAL akışı + periyodik base. Point-in-time recovery (PITR) mümkündür.

Üretim için 3. seçenek standarttır; pg_dump tek başına yeterli değildir.

pgBackRest — fiili standart

Mono kurulumlarında pg_basebackup yerine pgBackRest öneriyoruz. Sebepleri:

  • Paralel yedek (multi-thread); 1 TB DB için 30 dk yerine 4 dk.
  • Incremental + differential yedek; depolama tasarrufu.
  • Encrypt + compress dahili.
  • Multi-repository desteği (örn. lokal NFS + uzak S3).
  • Restore doğrulama komutu hazır.

Asgari pgbackrest.conf:

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=...

repo2-type=s3
repo2-path=/pgbackrest
repo2-s3-bucket=mono-pgbackup
repo2-s3-endpoint=garage.mono-cloud.local
repo2-s3-region=tr-ist-1
repo2-retention-full=12

[main]
pg1-path=/var/lib/postgresql/16/main
process-max=4

Yedek planı (3-2-1 kuralı)

Klasik kural: 3 kopya, 2 farklı medya, 1 off-site.

Tavsiyemiz:

  • Full yedek: haftada 1 (Pazar gecesi).
  • Differential yedek: günde 1 (gece).
  • WAL archive: gerçek zamanlı, hem lokal hem S3 (Garage / Cloudflare R2).
  • Saklama: Lokal 14 gün, off-site 12 hafta full (3 ay).

PITR senaryosu

Müşteri “saat 14:23’te yanlış silme yaptık” diyorsa:

# 1. Backup'tan restore (en yakın full)
pgbackrest --stanza=main --type=time \
  "--target=2026-04-22 14:22:00" \
  --target-action=promote restore

# 2. PostgreSQL başlat; recovery.signal otomatik
systemctl start postgresql@16-main

WAL’lar 14:22’ye kadar replay edilir, 1 saniye geri sayımdan önce stop. Veriniz dakikalar içinde geri.

Restore tatbikatı şart

Bir yedek “test edilmedikçe yedek değildir”. Mono müşteri SLA’larında şu maddeler standart:

  • Aylık otomatik restore tatbikatı (boş ortam, full restore).
  • Çeyrekte 1 GameDay; ekip yedek olmadan restore senaryosu çalıştırır.
  • Yıllık DR senaryosu; bölgesel kayıp simülasyonu.

Otomatik tatbikat akışı:

#!/bin/bash
set -euo pipefail

# Boş bir host'a en güncel backup'ı restore et
pgbackrest --stanza=main --delta restore --target-action=promote

# Bir SQL ile sayım kontrolü
psql -d production -c "SELECT count(*) FROM orders WHERE created_at > now() - interval '1 day'"

# Slack'e raporla

Yaygın hatalar

  • Sadece pg_dump. Büyük DB’lerde restore süresi RTO’yu aşar.
  • WAL archive yok. PITR yapılamaz; tek alternatif son full backup; 24 saat veri kaybı.
  • Lokal-only repo. Bölgesel olay durumunda yedek de kayıp.
  • Tatbikatsız. Olay anında ilk kez restore denemek = panik.

Sıradaki adımlar

PostgreSQL yedekleme planınızı bağımsız değerlendirmemizi isterseniz, Özgür yazılım veritabanı dönüşümü kapsamında 1 haftalık keşif çalışmamız ile mevcut RPO/RTO hedeflerinizi gerçekleştirilebilir hale getiriyoruz.

veritabanıoperasyon