“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:
- Logical (pg_dump): SQL veya custom format dosyası. Esnek; ama point-in-time geri yüklemez. Büyük DB’lerde saatler sürebilir.
- Physical (file-system): Veri dosyalarının kopyası. Hızlı; tutarlılık için
pg_basebackupkullanılır. - 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.