PostgreSQL Yedekleme Stratejisi: pg_dump, Fiziksel Yedek ve WAL Arşivleme Ne Zaman Kullanılır?

PostgreSQL üzerinde çalışan bir kurumsal uygulamanın en değerli bileşeni verisidir; sunucu yeniden kurulabilir, kod depodan çekilebilir, ama kaybolan veri geri gelmez. Bu yazıda PostgreSQL için yedekleme yöntemlerini, hangisinin hangi ihtiyaca uyduğunu ve "yedek var" cümlesini "geri dönebiliyoruz" cümlesine dönüştüren pratikleri anlatıyoruz.

İki temel yöntem

Mantıksal yedek: pg_dump / pg_dumpall

Veritabanının içeriğini SQL veya özel arşiv formatında dışa aktarır. Sürümler arası taşınabilir, tek bir tabloyu geri yüklemek kolaydır, küçük ve orta boy veritabanları için yeterlidir. Dezavantajı: yedek anı ile olay anı arasındaki değişiklikler kaybolur ve büyük veritabanlarında uzun sürebilir.

# Özel formatta, sıkıştırılmış, tek veritabanı
pg_dump -Fc -Z 6 -d app -f /backups/app_$(date +%F_%H%M).dump

# Küme genelindeki roller ve ayarlar (ayrıca alınmalı)
pg_dumpall --globals-only -f /backups/globals_$(date +%F).sql

Fiziksel yedek: pg_basebackup + WAL arşivleme

Veri dizininin tutarlı bir kopyasını alır; buna WAL (write-ahead log) arşivi eklendiğinde istenen bir zaman noktasına geri dönüş (PITR) mümkün olur. "Saat 14:32'de yanlışlıkla silinen tabloyu 14:31'e geri al" senaryosunun tek yolu budur. Büyük veritabanları ve düşük veri kaybı toleransı için standart yaklaşımdır.

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'

# Temel yedek
pg_basebackup -D /backups/base_$(date +%F) -Ft -z -Xs -P

Kurumsal ortamlarda pgBackRest veya Barman gibi araçlar bu süreci yönetir: tam/artımlı yedek, saklama politikası, doğrulama ve uzak depo desteği sunar.

Hangi yöntem, hangi durumda?

İhtiyaçÖnerilen Küçük veritabanı, günlük kayıp kabul edilebilirGünlük pg_dump + uzak kopya Dakikalar düzeyinde kayıp toleransıFiziksel yedek + WAL arşivi (PITR) Tek tablo / şema geri yükleme ihtiyacıpg_dump arşiv formatı (seçmeli geri yükleme) Sürüm yükseltme öncesiHer iki yöntem birlikte

3-2-1 ve değiştirilemezlik

Üç kopya, iki farklı ortam, bir kopya başka lokasyonda. Uzak kopya için nesne depolama (S3 uyumlu servisler veya kendi MinIO kurulumunuz) yaygın seçimdir; "object lock" benzeri özelliklerle yedeklerin belirli süre silinememesi fidye yazılımı senaryosunda belirleyicidir. Uzak kopya, üretim sunucusunun kimlik bilgileriyle silinemeyecek şekilde ayrı yetkilerle korunmalıdır.

Şifreleme

Yedek dosyaları kişisel ve finansal veri içerir; aktarımda TLS, depoda şifreleme zorunludur. Anahtarın yedekle aynı yerde tutulmaması gerekir; aksi hâlde şifreleme yalnızca görünüştedir. Anahtar kaybı, yedeğin kaybı demektir; anahtar yönetimi planın parçasıdır.

Geri yükleme provası yapılmamış yedek, bir umuttur. Prova, yedeğin ilk kez gerçekten ihtiyaç duyulduğu günde yapılmamalıdır.

Geri yükleme provası: RTO ve RPO'yu ölçün

Düzenli aralıklarla yedeği ayrı bir sunucuya (veya geçici bir konteynere) geri yükleyin, uygulamayı ona bağlayıp temel işlemleri çalıştırın ve süreyi kaydedin. Ölçülen süre kurtarma hedefinizi (RTO) aşıyorsa yöntem değişmelidir. Docker ile çalışan ortamlarda prova otomatikleştirilebilir:

docker run --rm -d --name pg_restore_test -e POSTGRES_PASSWORD=test postgres:16
docker cp /backups/app_latest.dump pg_restore_test:/tmp/app.dump
docker exec pg_restore_test pg_restore -U postgres -d postgres --create /tmp/app.dump
docker exec pg_restore_test psql -U postgres -d app -c "select max(created_at) from orders;"

İzleme: yedek başarısızsa bilmek

Yedek görevinin çalıştığı değil, başarıyla tamamlandığı ve dosyanın beklenen boyutta olduğu izlenmelidir. "Son başarılı yedek 24 saatten eski" kuralı bir uyarıya bağlanmalıdır. Sessizce başarısız olan yedekler, en sık karşılaşılan felaket senaryosudur.

Supabase self-hosting notu

Kendi sunucunuzda Supabase çalıştırıyorsanız PostgreSQL yedeği tek başına yeterli değildir: depolama (storage) nesneleri, yapılandırma ve gizli anahtarlar da yedeklenmelidir; aksi hâlde veritabanı geri gelir ama dosyalar ve kimlik doğrulama yapılandırması gelmez.

Asgari plan önerisi

1. Gece pg_dump + sürekli WAL arşivi
2. Haftalık fiziksel temel yedek
3. Şifreli uzak kopya, ayrı yetkiyle, silmeye karşı korumalı
4. Üç ayda bir geri yükleme provası, süreler kayıt altında
5. Yedek başarısızlığı için uyarı

Zaman noktasına geri dönüş (PITR) adım adım

Fiziksel yedek ve WAL arşivi varsa belirli bir ana geri dönmek mümkündür. Kavramsal akış şöyledir:

# 1. Temel yedeği yeni veri dizinine açın
mkdir /var/lib/postgresql/restore && tar -xzf /backups/base_2026-10-01/base.tar.gz -C /var/lib/postgresql/restore

# 2. Kurtarma hedefini ve WAL kaynağını belirtin (postgresql.conf veya postgresql.auto.conf)
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2026-10-03 14:31:00+03'
recovery_target_action = 'promote'

# 3. recovery.signal dosyasını oluşturun ve sunucuyu bu dizinle başlatın
touch /var/lib/postgresql/restore/recovery.signal

Sunucu, WAL kayıtlarını hedef zamana kadar uygular ve ardından normal çalışmaya geçer. Bu işlem ilk kez gerçek bir olayda değil, prova ortamında denenmelidir; PITR'nin en sık başarısız olduğu nokta, WAL arşivinde eksik bir dosyadır ve bunu yalnızca prova ortaya çıkarır.

Saklama politikası: ne kadar geriye?

Günlük yedekleri bir ay, haftalık yedekleri üç ay, aylık yedekleri bir yıl saklamak yaygın bir başlangıç noktasıdır; mevzuat (muhasebe kayıtlarının saklama süresi) ve kişisel veri saklama kuralları bu politikayı şekillendirir. Dikkat: kişisel verinin silinmesi gerektiğinde yedeklerde kalan kopyalar için de bir plan olmalıdır; çoğu kurum bunu "yedek saklama süresi dolunca silinir" kuralıyla ve bu sürenin kişisel veri politikasıyla uyumlu olmasıyla çözer.

Büyük veritabanlarında pratik notlar

• pg_dump'ı paralel çalıştırmak (dizin formatı ve -j seçeneği) süreyi kısaltır.
• Büyük tablolar (log, olay kayıtları) için ayrı yedek sıklığı tanımlanabilir; her gece tüm geçmişi yedeklemek gerekmez.
• Yedek, üretim sunucusunun en yoğun saatinde değil, yük düşükken alınmalıdır; fiziksel yedekte bu etki daha azdır.
• Yedek sıkıştırma ve şifreleme CPU kullanır; sunucu kaynak planlamasına dahil edilmelidir.

Replikasyon yedek değildir

Sıcak yedek (streaming replication) yüksek erişilebilirlik sağlar; ancak yanlışlıkla silinen bir tablo saniyeler içinde replikaya da yansır. Replikasyon ile yedekleme birbirini tamamlar, birbirinin yerine geçmez. Aynı şekilde disk anlık görüntüleri (snapshot) hızlı geri dönüş sağlar ama tutarlılık için veritabanıyla koordine edilmeli ve farklı lokasyona kopyalanmalıdır.

Docker ortamında yedekleme

Docker Compose ile çalışan PostgreSQL'de yedek, konteynerin içinden değil, ayrı bir yedekleme konteyneri veya ana makinedeki zamanlanmış görevle alınmalıdır; veri birimi (volume) bağlı olduğu sürece pg_dump konteyner ağı üzerinden çalışır. Konteyner imajı sürümü ile yedek formatı uyumluluğu (pg_dump sürümü veritabanı sürümünden eski olmamalı) izlenmelidir.

# Örnek: Compose ortamında zamanlanmış pg_dump (ana makine cron'u)
0 2 * * * docker exec app_db pg_dump -U app -Fc app | gpg --encrypt -r backup@ornek > /backups/app_$(date +%F).dump.gpg

Belgeleme

Yedekleme planı yazılı olmalıdır: ne, ne sıklıkla, nereye, kim tarafından, nasıl geri yüklenir. Geri yükleme adımları, sistemi bilmeyen bir kişinin izleyebileceği kadar açık yazılmalıdır; felaket anında sistemi en iyi bilen kişi ulaşılabilir olmayabilir.

Cy Logic'in sunucu ve bulut altyapısı hizmetinde yedekleme stratejisi, kurulumun isteğe bağlı eki değil tanımlı bir bileşenidir.