Adım Adım: Veeam v12.3 ile PostgreSQL Yedekleme ve Anında Kurtarma

Son dönemde en çok PostgreSQL yedeklemeleri ile ilgili sorular alıyorum. Aslında Veeam tarafında PostgreSQL yedekleme desteği (GUI ile) 2 yıldan uzun süredir (v12 ile birlikte) mevcut. Bu konuyu daha önce hazırladığım bir videoda ele almıştım: “V12: Veeam Explorer for Postgres – Hands-on Postgres Demo Kurulumu, Yedekleme/Kurtarma Süreçleri.” Süreçler aynı olduğu için yeni bir video yerine bu kez bir kontrol adımlarını ve sonrasında yedekleme süreci hakkında bilgi paylaşmak istedim. İlk bölüm gereksinimlerin kontrolü gibi düşünebilirsiniz, burada kendi aldığım notları ve bazı detayları aktaracağım, sizler de kendi ortamınızda kontrol ederek ilerleyebilirsiniz.

Merak edenler için: Daha önce çektiğim videoya buradan ulaşabilirsiniz.

Tabii her zaman hatırlatmadan geçmek olmaz: en güncel bilgiler için ana kaynağımız Veeam "Help"Center"’dır, helpcenter.veeam.com

Benim demo ortamımda Rocky Linux 9 üzerinde PostgreSQL 17.6 çalışıyor.

BÖLÜM 1:

PostgreSQL Ön Hazırlıklar

Yedekleme öncesi mutlaka kontrol edilmesi gereken noktalar var:

• PostgreSQL sürümü: 12–17 arası destekleniyor. Detaylar için Help Center kontrol edilmeli.
• Firewall: Kullanacağınız ortama göre port listesi değişeceği için, bileşenler arası iletişimde kullanılacak portlar mutlaka Help Center’dan doğrulanmalı.
• /opt/pg17/postgresql.conf: listen_addresses kısmını kontrol edin. Test ortamı için * olarak ayarlanabilir.
• /opt/pg17/pg_hba.conf: Bağlantı için IP ve şifre doğrulamasını kabul edecek şekilde yapılandırılmalı.

** Not: Yukarıda belirtilen path’ler sizin ortamınızda farklı olabilir. Özellikle, farklı dizinler üzerinde kurulu olan PostgreSQL instance’larını da tartışıyor olacağız. Bu path’leri çeşitli yöntemlerle bulabilirsiniz. Benim örneğimde farklı path'lerde ne yapacağımızı göstermek için /opt/pg17 olarak kullanılıyor.

#çalışan instance path'ler
ps aux | grep 'postgres'  

#veya

sudo -i -u postgres
psql -c "SHOW data_directory;"

#status
sudo systemctl status postgresql-17

VeeamPostgreSQLAgent.xml

Eğer PostgreSQL farklı bir dizine kurulmuşsa, bu path yedek alabilmek için /etc/veeam/VeeamPostgreSQLAgent.xml dosyasına eklenmelidir. Dosya mevcut değilse, kendiniz oluşturabilirsiniz.

VeeamPostgreSQLAgent için helpcenter linkimiz: https://helpcenter.veeam.com/docs/backup/vsphere/application_aware_processing.html?zoom_highlight=veeampostgresqlagent.xml&ver=120

Yedeklemeler için yetkili kullanıcı isterleri ve tanımları

Helpcenter

• Root yetkilerine yükseltilebilen bir linux kullanıcısı ve PostgreSQL içinde de superuser yetkileri.
• bu hesabın home directory'si oluşturulmuş olması gerekiyor.
• eğer mevcutta bulunan bir kullanıcıyı kullanmak istemezseniz;

#kullanıcı yarat
sudo useradd -m -s /bin/bash veeambackupsvc 
#şifre
sudo passwd veeambackupsvc  
#sudo yetki - rockylinux 
usermod -aG wheel veeambackupsvc 

Bu demo için, postgres'e bağlanarak bu kullanıcıya superuser izinleri verelim. Farklı bir superuser yetkilerine sahip kullanıcı da yedekleme sürecinde kullanabilirsiniz, peer authentication da desteklenmektedir.

Özetle, linux'de yetkili bir kullanıcı daha sonrasında da postgres'de yetkili bir kullanıcı ihtiyaçları bulunmaktadır. Biz linux'de açtığımız service hesabını yetkilendiriyor olacağız

#PostgreSQL'e bağlan ve Superuser ekle
sudo -u postgres psql
CREATE USER veeambackupsvc WITH SUPERUSER;

WAL Loglarının yedekleri için Geçici Dizin:

• Archive (WAL) log'ların yedeklenmesi için geçici bir directory alanı gerekiyor.
• PostgreSQL'i çalıştıran kullanıcı hesabının bu dizine rwx haklarının olması lazım
• Yedekleme için kullanacağımız hesabın da bu dizine rx hakları olması gerekiyor.

DİZİN OLUŞURMAYI Benim gibi unutmayın =>

#WAL log shipping için geçici alan
sudo mkdir -p /tmp/pgsql_archive 

#postgres hesabına yetki verin 
sudo chown postgres:postgres /tmp/pgsql_archive 
sudo chmod 700 /tmp/pgsql_archive

#service hesabı yetkisi yoksa
sudo setfacl -m u:veeambackupsvc:rx /tmp/pgsql_archive

#doğrulamak için 
getfacl /tmp/pgsql_archive 

PostgreSQL.conf Tanımları

Tabii WAL logları için PostgreSQL içinde de belli parametrelerin hali hazırda ayarlanmış olması gerekiyor. Kontrol amaçlı olarak;

• archive_mode parametresi "ON" olmalı
• archive_command parametresinde herhangi bir değer atanmamış olmalı
• wal_level parametresi "replica" veya "logical" olmalı.
• Helpcenter\

Bu ayarlar için, postgresql.conf içinde değişiklik yapmanız gerekebilir:

Listen_address'den konu başında bahsetmiştik. Demo ortamı olduğu için her yere açıyorum, üretim ortamı için değerlendirerek yapın.

Artık ana kontrollerimiz bitti ise şimdi yedek almakta.

BÖLÜM 2

️ Veeam Backup and Replication v12.3 ile Yedekleme Adımları

Şimdi yeterlilikler hazır (port’lar sizde). Esasında herhangi bir VM için yalnızca port ve yetki gerekiyor. Yukarıda biraz daha detaylı kontrollerimizi sağladık.

Bizim yetkili bir Linux kullanıcımız var; veeambackupsvc, bu kullanıcı PostgreSQL instance içinde superuser yetkilerine sahip. XML dosyamızı da oluşturduk (çünkü kurulum farklı bir path içinde yapıldı). Adım adım ilerleyelim. Veeam ekranlarını biliyorsanız zaten süreç aynı:

En önemli konu, yetkilendirme. Appliacation Aware açıp, Gues OS için SSH credentials'a oluşturduğumuz servis hesabını giriyoruz ve Elavate seçiyoruz:

Son olarak, Applications butonu ile WAL log ayarlarımızı ve PostgreSQL superuser kullanıcı bilgilerimizi tanımlıyoruz. Bizde aynı servis hesabı kullanıldığı için, Use Guest Credentials olarak bıraktık.

Sonrası scheduling:

🟢Veeam Arka Planda Nasıl Çalışıyor: Application-Aware Processing işaretlendiğinde aslında epey iş dönüyor: Veeam, SSH ile VM’e bağlanıyor, küçük bir bileşen (Guest Processing) deploy ediyor ve PostgreSQL’i varsayılan path’lerde arıyor. Eğer bulamazsa, bizim oluşturduğumuz XML dosyasına bakıyor. Instance tespit edildikten sonra, yedekleme öncesi veritabanı uygulama tutarlılığı için hazırlanıyor; ardından VM snapshot’ı alınıyor ve yedekleme başlıyor. Yedekleme tamamlandıktan sonra da belirlediğimiz aralıklarla WAL logları alınarak imaj backup’a ekleniyor.

Şimdi görevi çalıştırarak neler olduğunu görelim. Görev hızlıca ilerlerken, /tmp/PostgresAgent.log dizini altında Veeam log’larını ve PostgreSQL’in hangi path’lerde sırayla arandığını görebilirsiniz.

VE herşey başarılı ise zaten Disk altında artık PostgreSQL'i Explorer ile görebileceksiniz.

Kurtarma Senaryoları

Backup işin sadece yarısı. Peki kurtarma? Anlık kurtarma bizim işimiz

Yukarıdaki ekranda PostgreSQL instance seçtiğimizde Veeam Explorer for PostGreSQL acılır. Restore edeceğimiz günü seçeriz:

Ben Instant Recovery’yi göstereceğim. Burada mevcut veritabanını ezmemek için, aynı sunucuya dönsem bile “Restore to another” seçeneğini tercih ediyorum; böylece tüm ayarlar sihirbaz (wizard) içinde soruluyor.

Burada log backup alındığında, Point-in-Time slider menüsü aktif olur. Yani istediğiniz dakikaya geri dönüş yapabilirsiniz.

Bu ekrandaki Export gibi bazı gelişmiş restore seçenekleri ise staging PostgreSQL tanımını gerektirir. Çünkü export işlemi sırasında, yedekleme dosyası içerisindeki veriler, PostgreSQL’in kendi diliyle işlenir ve export veya diğer işlemler staging sunucu üzerinde gerçekleştirilir.

The account used for PostgreSQL data recovery must be a Linux user with root privileges on the target machine. Root privileges are required to mount the backed-up file system to the target server and to communicate with PostgreSQL.

Root yetkisi olması önemlidir. Çünkü yedekleme dosyaları repository’den Linux sunucuya mount edilir, okunur ve kopyalanır. Bu işlemler için root ayrıcalıkları gereklidir.

Yeni bir path seçiyorum, data3 altı tamamen boş. 5431 port'u üzerinde restore ediyor olacağım:

Instant Recovery sırasında, mount edilmiş veritabanı ilk adımda çalışırken aslında yedekleme dosyası üzerinde işlem yapıyor. Biz bu süreçte dosyaları arka planda kopyalayarak, veritabanını Linux içindeki veritabanı dosyalarından çalışabilecek duruma getiriyoruz. İşte tam bu adımda switchover gerekecek. Yani, yedekleme dosyasından çalışan veritabanını durdurup, oluşan değişiklikleri işleyip, veritabanını Linux içindeki dosyalar üzerinden mount etmemiz lazım. Bu işlemi arzu ederseniz otomatik, manuel veya planlı yapabilirsiniz:

• Auto: Tüm dosyalar kopyalanıp senkronize edildikten sonra switchover otomatik hemen yapılır.
• Manual: Switchover, kullanıcı tarafından istenilen zamanda başlatılır.
• Scheduled: Switchover belirlenen tarih ve saatte gerçekleştirilir.

Seçiminizi yaptıktan sonra Restore tuşuna basın; Veeam Explorer for PostgreSQL, instance'ı hemen calı hale getircektir:

Bu ekranda instance artık ayakta, yani saniyeler içinde hazır çalışır durumda. Instance Replice edildi, bizden switchover bekleniyor (manuel seçmiştik)

Bu süreç içinde mount işlemleri ile ilgili log'lara da /var/log/VeeamBackup altından erişebilirsiniz:

Ve son olarak kontrol edelim, yeni instance'ımız ile birlikte, restore ettiğimiz veritabanına bağlanalım:

Eğer fiziksel olsaydı: Agent ile Yedekleme

Fiziksel olsaydı, buradaki adımlardan farklı olarak veeam Agent for Linux'ü sunucuya merkezi olarak kurulmasını sağlamak olacaktı.

Sonuç

BAM BAM BAM Siz de PostgreSQL yedeklemelerinizi ve veri korumasını bir üst seviyeye çıkarın kontrolü elinize alın.

Görüşmek üzere.