Gerçekten Geri Yükleyebileceğiniz PostgreSQL Yedekleri: pgBackRest Kurulumu

Müşterilerden devraldığım küçük Postgres kurulumlarının çoğu tamamen aynı yedekleme stratejisine sahip olur. Genelde her gece pg_dump çalıştıran, çıktıyı gzip'e yönlendiren, dosyayı rastgele bir klasöre atan ve belki de rclone ile başka bir yere kopyalayan bir cron görevidir.

Dışarıdan bakıldığında tıpatıp bir yedeğe benzer. Her gece hiç hata vermeden çalışır. Tek sorun şudur ki: Çok uzun zamandır kimse o dosyadan geri yükleme (restore) yapmayı denememiştir.

pg_dump bir temel (baseline) olarak gayet iyidir, ancak veritabanı birkaç gigabaytı geçtiği saniye çok gerçek sınırlarla karşılaşır. Dump işlemi her geçen ay daha da uzun sürer. Çalıştığı süre boyunca sunucuya ciddi bir yük bindirir. En önemlisi, tek bir dump dosyası size günde tam olarak bir tane kurtarma noktası (recovery point) verir. Öğleden sonra saat 3'te feci bir şey ters giderse, dün geceye geri dönersiniz ve aradan geçen süredeki her şeyi kalıcı olarak kaybedersiniz. Zamanda belirli bir noktaya geri dönüş (point-in-time recovery) yoktur ve dump tabanlı yedekler onlarca gigabaytlık verilerle uğraşmaya başladığınızda kesinlikle düzgün ölçeklenmez.

pgBackRest'e Geçiş

pgBackRest fazla bir altyapı gerektirmeden bunların neredeyse tamamını çözer. Tam (full), fark (differential) ve artımlı (incremental) yedeklemeleri zahmetsizce halleder. WAL (Write-Ahead Log) dosyalarını sürekli olarak arşivler, böylece gerçek bir point-in-time recovery elde edersiniz. Çok çekirdekli makinelerde çok daha hızlı yedekleme için paralel işlemeyi destekler ve arşivleri doğrudan yerel diske, S3 uyumlu bir depolamaya veya aynı anda her ikisine birden gönderebilir.

Tek, küçük bir sunucu için standart olarak kullandığım yapılandırma (config) kabaca şuna benzer:

# /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

Ardından postgresql.conf içinde WAL arşivlemeyi etkinleştirirsiniz:

archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'

Stanza'yı oluşturun ve en ilk tam yedeklemeyi (full backup) manuel olarak tetikleyin:

sudo -u postgres pgbackrest --stanza=main stanza-create
sudo -u postgres pgbackrest --stanza=main --type=full backup

Bu ilk kurulumdan sonra, haftada bir tam yedek ve haftanın geri kalan günlerinde artımlı (incremental) yedek alacak şekilde bir zamanlama yapmak depo boyutunuzu son derece yönetilebilir tutar. Bu sayede her gün için sağlam bir kurtarma noktasına sahip olursunuz, ayrıca daha ince ayarlı geri yüklemeler için de sürekli bir WAL arşiviniz olur.

# Pazar: tam yedek (full)
0 2 * * 0 postgres pgbackrest --stanza=main --type=full backup
# Pzt-Cmt: artımlı (incremental)
0 2 * * 1-6 postgres pgbackrest --stanza=main --type=incr backup

Neredeyse herkesin atladığı o adım

Daha önce hiç geri yükleme yapmadıysanız yukarıdaki konfigürasyonun hiçbir önemi yoktur.

Sadece bu iş için elimde küçük bir ikincil VPS tutuyorum. Ayda bir kez en son yedeği çeker, pgbackrest --stanza=main --delta restore komutunu çalıştırır ve Postgres'i başlatır. Ardından en büyük tablolardaki satır sayılarına (row count) veya yakın tarihli bir updated_at zaman damgasına (timestamp) bakmak gibi birkaç temel mantık (sanity) sorgusu çalıştırırım. Baştan sona yirmi dakika falan sürer ve geri yükleme işleminin kendisinin tam olarak ne kadar sürdüğünü bir kenara not alırım.

O belirli sayı—yani gerçek dünyadaki o asıl geri yükleme süresi—sizin gerçek RTO (Recovery Time Objective) değerinizdir. Bir yerlerdeki bir operasyon defterine (runbook) yazılmış hipotetik bir sayı değildir. Bir müşteri için bu tatbikatı (drill) ilk yaptığımda, hedef VPS'teki fiziksel disk okuma/yazma (throughput) limitleri yüzünden geri yükleme tahmin ettiğimden belirgin şekilde daha uzun sürmüştü. Bu acı gerçekle olay anında (incident) değil, sakin bir Çarşamba öğleden sonrasında yüzleşmek inanın çok daha iyidir.

Bu durum site dışı (off-site) kopyaları nerede bırakıyor?

repo1, doğrudan S3 uyumlu bir nesne depolamasını (object storage) işaret edecek şekilde yapılandırılabilir. Backblaze B2 ve Wasabi'nin her ikisi de istisnai derecede iyi çalışır ve atlamak için maliyeti bahane edemeyeceğiniz kadar ucuzdur.

Gerçekten uykumu kaçırabilecek kadar kritik bir veritabanı için, sadece site dışı depolamayı işaret eden ikinci bir repo tanımı daha yapılandırırım. Bu şekilde, sadece kötü bir deploy değil, tam bir sunucu (host) çökmesi yaşandığında bile, yedeklerin tek kopyası sunucuyla birlikte kara deliğe sürüklenmemiş olur.

Hiç geri yükleme yapmadığınız bir yedek sadece bir umuttur, yedek değildir. pgBackRest, basit bir yapılandırma dosyası ve birkaç cron girdisi ile sizi "gerçekten geri yüklenebilir" olmaya büyük ölçüde yaklaştırır. Aylık olarak yapacağınız geri yükleme tatbikatı ise o aradaki boşluğu tamamen kapatır.