Kurumsal hayatta veritabanı “sadece proje dosyası” değildir; çoğu zaman sipariş, ödeme, müşteri kayıtları gibi kritik veriler burada durur. Bu yüzden şirketler “yedek almayı” bir seçenek değil, bir operasyon standardı olarak görür.

Bu yazıda, Windows ortamında PostgreSQL için en yaygın iki yaklaşımı (komut satırı üzerinden) basit şekilde öğreneceksiniz:

• Backup (yedek almak): pg_dump

• Restore (geri yüklemek): .sql ise psql, .backup ise pg_restore

Not: Burada örnek veritabanı adı olarak sample_db kullanıyorum. Siz kendi veritabanı adınızı yazabilirsiniz.

Kurgu: Bir şirkette “neden” bu işler böyle yapılır?

Bir e-ticaret şirketi düşünün: gece boyunca siparişler, ödemeler, iade kayıtları işleniyor. Sabah operasyon ekibi rapor alacak, muhasebe mutabakat yapacak, teknik ekip logları inceleyecek.

Bu dünyada iki temel ihtiyaç vardır:

1. Her gün düzenli yedek (bir şey ters giderse geri dönmek için)

2. Test ortamına geri yükleme (güncelleme öncesi denemek için)

Bu yüzden şirketler backup/restore işini genelde CMD ile yönetir. Çünkü komut satırı:

• Daha stabil çalışır (özellikle büyük veride)

• Otomasyona uygundur (gece 02:00 yedeği gibi)

• Sunucu ortamında da aynı şekilde çalışır (GUI’ye bağlı kalmaz)

1) .sql ile yedek/geri yükleme (basit ve öğretici)

Kurumsal örnek:
“Geliştirici ekip bir tabloda değişiklik yapacak. Önce hızlı bir yedek alalım; sorun olursa geri döneriz.”

Backup almak (.sql)

"C:\Program Files\PostgreSQL\17\bin\pg_dump.exe" ^ --host "localhost" --port "5432" --username "postgres" ^ --dbname "sample_db" ^ --file "D:\backup\sample_db.sql"

Restore etmek (.sql)

"C:\Program Files\PostgreSQL\17\bin\psql.exe" ^ --host "localhost" --port "5432" --username "postgres" ^ --dbname "sample_db" ^ --file "D:\backup\sample_db.sql"

Kurumsal mantıkla: .sql ne zaman tercih edilir?

• “Hızlı bir geri dönüş planı” gerekiyorsa

• Veri küçük/orta ölçekliyse

• Öğrenme ve temel senaryolarda (staj, ders, lab ortamı) pratikse

.sql yönteminin kurumsal riskleri (büyüyünce)

• Dosya büyüdükçe restore süresi uzar

• Dev bir dosyayı yönetmek zorlaşır

• Büyük veri setlerinde süreç daha kırılgan olabilir

Özet: Basit ve anlaşılır ama çok büyük veride her zaman en iyi seçenek değildir.

2) .backup ile yedek/geri yükleme (kurumsal dünyada daha sık)

Kurumsal örnek:
“Veritabanı 80 GB. Biz bu işi daha kontrollü ve sürdürülebilir yapmalıyız. Yedek formatını daha profesyonel seçelim.”

Backup almak (.backup)

"C:\Program Files\PostgreSQL\17\bin\pg_dump.exe" ^ --host "localhost" --port "5432" --username "postgres" ^ --format=c ^ --file "D:\backup\sample_db.backup" ^ "sample_db"

Restore etmek (.backup)

"C:\Program Files\PostgreSQL\17\bin\pg_restore.exe" ^ --host "localhost" --port "5432" --username "postgres" ^ --dbname "sample_db" ^ "D:\backup\sample_db.backup"

Kurumsal mantıkla: .backup neden daha çok tercih edilir?

• Büyük veride daha “kurumsal” bir standarttır

• Yedekleme/geri yükleme süreçleri daha yönetilebilir olur

• Çok büyük DB’lerde operasyonu daha az zorlar (pratikte daha rahat)

Özet: Veri büyüdükçe şirketler genellikle .sql yerine .backup formatına kayar.

3) “80 GB’lık DB bu yöntemle yedeklenir mi?”

Evet, yedeklenir. Kurumsal pratikte kritik olan şudur:

• 80 GB gibi bir boyutta .backup daha mantıklı olur

• Yedeği mümkünse C: yerine D: gibi ayrı diske alın

• Disk alanı yeterli olmalı (yedek dosyası yer kaplar)

• SSD varsa süreç çok daha rahat ilerler

En net seçim rehberi (tek cümlelik)

• Basitlik ve öğrenme için: .sql

• Büyük veri ve kurumsal kullanım için: .backup

Sık görülen durum: “Database yok” hatası

Kurumsal senaryo: yeni sunucu kuruldu, restore atacaksınız ama DB henüz yok. Önce DB oluşturulur:

"C:\Program Files\PostgreSQL\17\bin\createdb.exe" ^ --host "localhost" --port "5432" --username "postgres" ^ "sample_db"

Sonra restore komutu çalıştırılır.