PostgreSQL Yedeği Nasıl Geri Yüklenir? pg_restore ve psql Kullanımı

PostgreSQL yedeğini geri yükleme yöntemi, yedeğin hangi formatta oluşturulduğuna bağlıdır. SQL formatındaki .sql yedekleri genellikle psql ile, pg_dump -Fc kullanılarak oluşturulan custom format yedekleri ise pg_restore ile geri yüklenir.

Bu nedenle restore işlemine başlamadan önce elinizdeki yedek dosyasının formatını ve hangi veritabanına geri yükleneceğini kesin olarak belirleyin.

1. Restore işleminden önce mevcut veritabanını yedekleyin

Canlı bir veritabanı üzerinde işlem yapacaksanız mevcut durumun ayrıca yedeğini almak güvenli bir yaklaşımdır.

Örneğin custom formatta:

pg_dump -U postgres -Fc veritabani_adi -f restore-oncesi.dump

Böylece geri yükleme sırasında beklenmeyen bir problem yaşanırsa önceki duruma dönmek için ek bir kopyanız bulunur.

2. PostgreSQL araçlarını kontrol edin

Öncelikle:

psql --version

ve:

pg_restore --version

komutlarını çalıştırabilirsiniz.

Kullanacağınız PostgreSQL istemci araçlarının mevcut olduğundan emin olun.

3. SQL yedeği nasıl geri yüklenir?

Elinizde:

backup.sql

gibi düz SQL formatında bir yedek varsa genellikle psql kullanılır.

Örneğin:

psql -U postgres -d veritabani_adi -f backup.sql

Gerekirse host:

psql -h localhost -U postgres -d veritabani_adi -f backup.sql

şeklinde belirtilebilir.

Farklı PostgreSQL portu kullanıyorsanız:

psql -h localhost -p 5432 -U postgres -d veritabani_adi -f backup.sql

kullanılabilir.

4. Custom format yedeği nasıl geri yüklenir?

Yedek şu şekilde oluşturulduysa:

pg_dump -U postgres -Fc veritabani_adi -f backup.dump

geri yükleme için pg_restore kullanılır.

Örneğin:

pg_restore -U postgres -d veritabani_adi backup.dump

Gerekirse host da belirtilebilir:

pg_restore -h localhost -U postgres -d veritabani_adi backup.dump

Custom dump dosyasını doğrudan psql ile geri yüklemeye çalışmak doğru yöntem değildir.

5. Hedef veritabanı yoksa önce oluşturun

Restore edeceğiniz veritabanı henüz mevcut değilse uygun yetkiye sahip kullanıcıyla yeni bir veritabanı oluşturabilirsiniz.

Örneğin:

createdb -U postgres veritabani_adi

veya PostgreSQL içerisinde:

CREATE DATABASE veritabani_adi;

kullanılabilir.

Ardından yedeği bu veritabanına geri yükleyebilirsiniz.

6. Mevcut dolu veritabanına restore yaparken dikkat edin

Yedeği içerisinde tablolar bulunan mevcut bir veritabanına geri yüklemek:

- Tablo zaten mevcut

- Constraint zaten mevcut

- Index zaten mevcut

- Duplicate key

- Object already exists

gibi hatalara neden olabilir.

Bu nedenle restore işleminin:

- Boş bir veritabanına mı,

- Mevcut verilerin üzerine mi,

- Test amacıyla ayrı bir veritabanına mı

yapılacağını önceden belirlemek gerekir.

Production veritabanını doğrudan silip yeniden oluşturmak ciddi veri kaybına neden olabilir.

7. Önce test veritabanına geri yüklemek daha güvenlidir

Önemli bir yedeğin sağlamlığını kontrol etmek için ayrı bir test veritabanı oluşturabilirsiniz.

Örneğin:

createdb -U postgres restore_test

Ardından custom yedek için:

pg_restore -U postgres -d restore_test backup.dump

SQL yedeği için:

psql -U postgres -d restore_test -f backup.sql

kullanılabilir.

Restore tamamlandıktan sonra tabloların ve önemli kayıtların gelip gelmediğini kontrol edin.

Bu yöntem doğrudan production veritabanı üzerinde deneme yapmaktan daha güvenlidir.

8. Custom yedeğin içeriğini restore etmeden önce görüntüleyebilirsiniz

Custom format yedeğin içeriğini listelemek için:

pg_restore -l backup.dump

kullanılabilir.

Bu komut yedeğin içerisindeki nesneler hakkında bilgi edinmenize yardımcı olur.

Özellikle bilinmeyen veya eski bir backup dosyasını production ortamına geri yüklemeden önce içeriğini kontrol etmek faydalıdır.

9. Clean seçeneğini dikkatli kullanın

pg_restore mevcut veritabanı nesnelerini kaldırmaya yönelik seçenekler sunar.

Ancak production ortamında mevcut tabloları veya diğer nesneleri silen seçenekleri ne yaptığınızı tam olarak bilmeden kullanmayın.

Yanlış hedef veritabanında çalıştırılan destructive bir restore komutu ciddi veri kaybına neden olabilir.

Restore komutunu çalıştırmadan önce:

- Host

- Port

- Veritabanı adı

- Kullanıcı

- Yedek dosyası

bilgilerini tekrar kontrol edin.

10. Permission denied veya owner hataları

Başka bir PostgreSQL sunucusundan alınan yedeği geri yüklerken eski veritabanındaki kullanıcı veya owner bilgileri yeni sistemde bulunmayabilir.

Bu durumda ownership veya permission ile ilgili hatalar görülebilir.

Custom format yedeklerde ihtiyaca göre ownership davranışını değiştiren pg_restore seçenekleri kullanılabilir.

Örneğin --no-owner seçeneği bazı taşıma senaryolarında yararlı olabilir:

pg_restore --no-owner -U postgres -d veritabani_adi backup.dump

Ancak yetki yapısını değiştirmeden önce uygulamanın hangi PostgreSQL kullanıcısıyla çalıştığını kontrol edin.

11. PostgreSQL sürüm uyumluluğunu kontrol edin

Yedek farklı bir PostgreSQL ortamından geldiyse kaynak ve hedef PostgreSQL sürümlerini kontrol etmek önemlidir.

Özellikle eski ve yeni PostgreSQL sürümleri arasında taşıma yaparken kullanılan pg_dump ve restore araçlarının uyumluluğunu dikkate alın.

Sürüm kaynaklı hata alıyorsanız rastgele SQL dosyasını değiştirmek yerine PostgreSQL'in ilgili sürümleri için önerilen dump/restore yöntemini kontrol edin.

12. Restore sonrasında veritabanını kontrol edin

Komutun tamamlanması uygulamanın kesin olarak sorunsuz çalışacağı anlamına gelmez.

Restore sonrasında:

- Tablolar

- Kayıtlar

- Index'ler

- Sequence'ler

- Constraint'ler

- Uygulamanın veritabanı bağlantısı

- Kritik kullanıcı ve içerik kayıtları

kontrol edilmelidir.

Mümkünse uygulamayı test ederek temel işlemlerin çalıştığını doğrulayın.

13. Prisma kullanılan projelerde dikkat

Prisma kullanan bir Node.js projesinde PostgreSQL yedeğini geri yükledikten sonra mevcut veritabanı şemasının uygulamanın beklediği Prisma schema ve migration geçmişiyle uyumlu olması önemlidir.

Sadece prisma migrate dosyalarının bulunması gerçek kullanıcı verilerini geri getirmez.

Aynı şekilde PostgreSQL dump'ını restore etmek de uygulama kodunun ve migration durumunun otomatik olarak uyumlu olduğu anlamına gelmez.

Restore sonrasında uygulamanın veritabanı bağlantısını ve şema durumunu kontrol edin.

14. Production uygulamasında restore yaparken kullanıcı trafiğini düşünün

Canlı ve sürekli veri yazılan bir uygulamaya eski yedeği doğrudan geri yüklemek restore sırasında veya sonrasında tutarsızlıklara neden olabilir.

Örneğin restore işlemi devam ederken:

- Yeni kullanıcı kaydı

- Yeni sipariş

- Yeni forum konusu

- Yeni mesaj

- Profil değişikliği

oluşabilir.

Production restore işlemleri bu nedenle bakım planı, kesinti süresi ve veri kaybı toleransı dikkate alınarak yapılmalıdır.

15. Yedek dosyasını silmeden önce restore işlemini doğrulayın

Restore başarılı göründükten hemen sonra elinizdeki tek backup dosyasını silmeyin.

Öncelikle:

1. Veritabanına bağlanın.

2. Kritik tabloları kontrol edin.

3. Önemli verilerin geldiğini doğrulayın.

4. Uygulamayı test edin.

5. Logları kontrol edin.

6. Sorun olmadığına emin olduktan sonra yedek saklama politikanıza göre hareket edin.

SQL ve custom format için kısa özet

SQL yedeği oluşturulduysa:

backup.sql

genellikle:

psql -U postgres -d veritabani_adi -f backup.sql

ile geri yüklenir.

Custom format yedek:

backup.dump

ise genellikle:

pg_restore -U postgres -d veritabani_adi backup.dump

ile geri yüklenir.

Güvenli restore kontrol listesi

PostgreSQL yedeğini geri yüklemeden önce:

1. Yedek dosyasının formatını belirleyin.

2. Doğru sunucuya bağlandığınızı kontrol edin.

3. Doğru veritabanını seçtiğinizi doğrulayın.

4. Mevcut production veritabanının güncel yedeğini alın.

5. Mümkünse restore işlemini önce test veritabanında deneyin.

6. Hata mesajlarını kontrol edin.

7. Restore sonrasında tablo ve verileri doğrulayın.

8. Uygulamanın veritabanıyla düzgün çalıştığını test edin.

9. Tek yedek kopyasını hemen silmeyin.

Özetle, PostgreSQL yedeğini geri yüklerken .sql dosyaları için genellikle psql, custom .dump dosyaları için pg_restore kullanılır. En kritik nokta ise komutu çalıştırmadan önce hedef veritabanının doğru olduğundan emin olmaktır.

Özellikle production sistemlerinde yanlış veritabanına yapılan restore işlemi mevcut verilerin kaybolmasına neden olabileceğinden önce güncel yedek almak ve mümkünse geri yüklemeyi ayrı bir test veritabanında doğrulamak en güvenli yaklaşımdır.