PostgreSQL Yedeklerini Gerçekten Geri Yükleyebilmek: pgBackRest Kurulumu
Müşterilerden devraldığım küçük Postgres kurulumlarının çoğunda aynı yedeğin bir versiyonu var: her gece pg_dump çalıştıran, gzip'e gönderen ve dosyayı bir klasöre bırakan, belki rclone ile dışarıya senkronize eden bir cron job. Yedek gibi görünüyor. Her gece hatasız çalışıyor. Ve uzun zamandır kimse oradan bir şey restore etmeyi denememiş.
İşte sorun da bu. pg_dump bir başlangıç noktası olarak gayet iyi, ama veritabanı birkaç GB'ı geçtiği anda gerçek limitlere çarpıyorsunuz: dump her ay biraz daha uzun sürüyor, çalıştığı süre boyunca yük bindiriyor, ve tek bir dump dosyası size günde tam olarak bir restore noktası veriyor. Öğleden sonra bir şeyler ters giderse, dün geceki duruma dönüyorsunuz ve o zamandan beri olan her şeyi kaybediyorsunuz. Point-in-time recovery yok, ve dump tabanlı yedekler onlarca GB'a geldiğinde ölçeklenmiyor.
pgBackRest'e geçiş
pgBackRest bunun çoğunu, fazladan altyapı gerektirmeden çözüyor. Full, differential ve incremental yedekler alıyor, point-in-time recovery için WAL'ı sürekli arşivliyor, multi-core makinelerde daha hızlı yedekler için parallel processing destekliyor, ve local disk'e, S3 uyumlu storage'a ya da ikisine birden yazabiliyor.
Tek bir küçük sunucu için kullandığım setup kabaca şöyle:
# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
repo1-retention-diff=4
[main]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432
Sonra postgresql.conf'ta WAL arşivlemeyi açıyoruz:
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
Stanza'yı oluşturup ilk full backup'ı çalıştırıyoruz:
sudo -u postgres pgbackrest --stanza=main stanza-create
sudo -u postgres pgbackrest --stanza=main --type=full backup
Bundan sonra, haftada bir full backup ve diğer günler incremental backup düzeni, repo boyutunu kontrol altında tutarken her gün için bir restore noktası ve daha ince taneli ihtiyaçlar için sürekli WAL sağlıyor:
# Pazar: full backup
0 2 * * 0 postgres pgbackrest --stanza=main --type=full backup
# Pzt-Cmt: incremental
0 2 * * 1-6 postgres pgbackrest --stanza=main --type=incr backup
Herkesin atladığı kısım
Yukarıdakilerin hiçbiri, ondan hiç restore etmediyseniz bir anlam taşımıyor. Bunun için özel olarak küçük bir ikinci VPS tutuyorum: ayda bir, en son backup'ı çekiyor, pgbackrest --stanza=main --delta restore çalıştırıyor, Postgres'i başlatıyor, ve üzerinde birkaç sağlık kontrolü yapıyorum, en büyük tabloların satır sayıları, güncel bir updated_at timestamp'i. Baştan sona belki yirmi dakika sürüyor, ve restore'un kendisinin ne kadar sürdüğünü not ediyorum.
O sayı, gerçek restore süresi, sizin asıl recovery time objective'iniz, bir runbook'ta yazan değil. Bir müşteri için bunu ilk yaptığımda, restore tahmin ettiğimden epey uzun sürdü, sadece hedef VPS'in disk throughput'u yüzünden. Bunu sakin bir öğleden sonra öğrenmek, gerçek bir kesinti sırasında öğrenmekten çok daha iyi.
Off-site kopyalar nereye giriyor
repo1 direkt S3 uyumlu storage'a yazabilir, Backblaze B2 ve Wasabi ikisi de iyi çalışıyor ve maliyet bunu atlamak için bir bahane olmayacak kadar ucuz. Gerçekten uykumu kaçıracak her şey için, ikinci bir repo tanımı off-site storage'a gidiyor, böylece sadece kötü bir deploy değil, host'un tamamen gitmesi de yedekleri yanında götürmüyor.
Restore edilmemiş bir yedek, bir yedek değil, bir umuttur. pgBackRest, bir config dosyası ve birkaç cron satırıyla sizi "gerçekten restore edilebilir" durumuna büyük ölçüde getiriyor; restore denemesi de kalan boşluğu kapatıyor.