
PostgreSQL yedeğinde formatı doğru seçin: pg_restore her dosyayı açmaz

PostgreSQL yedeğinde geri yükleme aracını dosya uzantısı değil, pg_dump çıktısının biçimi belirler. PostgreSQL’in pg_dump başvurusu, varsayılan düz SQL çıktısının psql ile, custom ve directory arşivlerinin ise pg_restore ile yüklendiğini açıklar. Düz SQL dosyasına .dump adı vermek onu pg_restore arşivine dönüştürmez.
İş sırası biçimi seçmek, uygun pg_dump komutuyla yedeği almak, hedef veritabanını hazırlamak ve biçime uygun araçla geri yüklemektir. Elinizdeki yedeğin nasıl üretildiği belirsizse yalnızca dosya adına güvenmeyin: pg_restore -l komutu bir arşivin içerik listesini gösterebilir; düz SQL betiği için bu komut uygun değildir.
Hangi biçimi seçmeli?
Kararı geri yükleme sırasında ihtiyaç duyacağınız denetime göre verin. Düz SQL çalıştırılabilir bir betiktir; custom ve directory biçimleri ise arşiv girdilerini seçmeye veya sıralamaya olanak tanır.
- Düz SQL (-Fp veya varsayılan): Okunabilir bir SQL betiği istediğinizde uygundur. Çıktıyı psql çalıştırır.
- Custom (-Fc): Tek arşiv dosyası ve seçmeli geri yükleme istediğinizde uygundur. Çıktıyı pg_restore işler.
- Directory (-Fd): Yedeği paralel almak istediğinizde uygundur. Çıktı, tablo verilerini ve içerik listesini barındıran bir dizindir; geri yüklemede pg_restore kullanılır.
pg_dump tar biçiminde de arşiv üretebilir ve pg_restore bunu okuyabilir. Bu nedenle .sql veya .dump gibi adlar kesin ölçüt değildir. Özellikle başka bir ekipten gelen yedekte, kullanılan pg_dump biçimini teslim bilgisiyle veya arşivin içerik listesiyle doğrulamak komut seçimini kolaylaştırır.
pg_dump ile yedeği alın
Şu komutlarda uygulama kaynak veritabanının, yedekci ise yedeği alan rolün koşullu adıdır. Rolün dışa aktarılacak tablolara okuma erişimi olmalıdır; pg_dump eksik yetkileri aşmaz. Uzak sunucuya bağlanıyorsanız bağlantı adresi için -h, bağlantı noktası için -p seçeneklerini ekleyin.
Düz SQL için komut: pg_dump -U yedekci --no-owner --no-acl -Fp -f uygulama.sql uygulama. Buradaki --no-owner, özgün nesne sahiplerini atayan komutları; --no-acl ise kaydedilmiş erişim izinlerini betikten çıkarır. Bu seçim, aşağıdaki örnekte yedeği başka bir rolle yüklemek içindir; eski sahiplik ve izinler kendiliğinden geri gelmez.
Custom arşiv için komut: pg_dump -U yedekci -Fc -f uygulama.dump uygulama. Directory arşivini paralel almak için koşullu örnek: pg_dump -U yedekci -Fd -j 4 -f uygulama_dir uygulama. Buradaki iş sayısı örnektir; paralel yedekleme sunucuda daha fazla bağlantı ve yük oluşturur. uygulama_dir dizini komuttan önce mevcut olmamalıdır, çünkü pg_dump onu kendisi oluşturur.
Komut bitince çıkış durumunu ve standart hata çıktısındaki uyarıları inceleyin. Bir dosyanın veya dizinin oluşması, yedeğin eksiksiz alındığını tek başına göstermez. Yedekleme rolünün erişemediği nesneler varsa yetki sorununu çözmeden aynı komutu yeniden çalıştırmak sonucu değiştirmez.
Boş hedefi oluşturup geri yükleyin
Koşullu örnekte hedef veritabanı uygulama_kurtarma, geri yükleme rolü uygulama_sahibi olsun. Bu rolün veritabanı oluşturma yetkisi varsa önce createdb -U uygulama_sahibi -T template0 uygulama_kurtarma komutunu çalıştırın. Yetki başka bir yönetici rolündeyse boş hedefi o rolle oluşturup sahiplik ve geri yükleme izinlerini önceden düzenleyin.
Düz SQL için komut: psql -X -v ON_ERROR_STOP=on -U uygulama_sahibi -d uygulama_kurtarma -f uygulama.sql. PostgreSQL’in SQL yedeği yönergesi, metin dökümü için hedefin önceden template0 temel alınarak oluşturulmasını ve SQL hatasında durmak için ON_ERROR_STOP kullanılmasını açıklar. -X, yerel psql ayarlarının geri yüklemeyi etkilemesini önler.
ON_ERROR_STOP işlemi hatada durdurur, fakat daha önce başarıyla yürütülen komutları geri almaz. Betiğin tamamının tek işlemde uygulanması gerekiyorsa psql komutuna -1 seçeneğini ekleyebilirsiniz; bir hata halinde o işlem geri alınır. Uzun bir geri yüklemede bu seçimin süre ve kaynak kullanımını da hesaba katın.
Custom arşiv için komut: pg_restore -U uygulama_sahibi --no-owner --no-acl --exit-on-error -d uygulama_kurtarma uygulama.dump. Directory arşivinde son bağımsız değişken olarak uygulama.dump yerine uygulama_dir kullanın. Bu örnekler yeni hazırlanmış hedef içindir; dolu bir veritabanına aynı nesneleri yeniden oluşturmak hata veya istenmeyen çakışma doğurabilir.
Sahiplik ve erişim izinlerini ayarlayın
Arşiv örneğindeki --no-owner, nesnelerin özgün sahiplerini yeniden atamak yerine oluşturulan nesneleri geri yükleme bağlantısındaki role bırakır. --no-acl, arşivdeki GRANT ve REVOKE komutlarını uygulamaz. Uygulama başka rollerle bağlanıyorsa gerekli erişim izinlerini geri yüklemeden sonra ayrıca vermelisiniz.
Özgün sahiplik ve izinleri korumak istiyorsanız bu seçenekleri kaldırmadan önce hedef kümede ilgili rollerin bulunduğunu kontrol edin. Geri yükleme rolünün sahiplik değişikliklerini ve izinleri uygulamaya yetecek yetkileri de olmalıdır. Düz SQL yedeğinde bu karar pg_dump sırasında verilir; arşiv yedeğinde aynı seçenekler pg_restore aşamasında uygulanır.
pg_dump yalnızca seçilen veritabanını dışa aktarır; küme genelindeki roller ve tablespace tanımları bu yedeğe dahil değildir. Bunlar için pg_dumpall --globals-only kullanılabilir. Ayrı bir kümeye taşıma planında genel nesneleri hazırlamadan uygulama verilerini yüklemek, sahiplik atamaları veya tablespace bağımlılıkları yüzünden geri yüklemeyi durdurabilir.
Güvenilmeyen yedeği çalıştırmadan inceleyin
Bir dökümü geri yüklemek, içindeki SQL’i hedefte yürütür. PostgreSQL’in pg_restore başvurusu, güvenilmeyen kaynak yöneticilerinin seçtiği kodun hedefte çalışabileceği ve kısmi geri yüklemenin bu riski gidermediği konusunda uyarır. İçerik listesinde yalnızca tanıdık tablo adları görmek, yürütülecek ifadelerin güvenli olduğunu göstermez.
Kaynağına güvenmediğiniz düz SQL dosyasını çalıştırmadan önce betiği inceleyin. Custom veya directory arşivinin üreteceği SQL’i hedefe bağlanmadan görmek için pg_restore --file=inceleme.sql uygulama.dump ya da pg_restore --file=inceleme.sql uygulama_dir komutunu kullanın. Özellikle işlev tanımlarını, uzantıları ve yetki değiştiren ifadeleri değerlendirin; pg_restore -l yalnızca içerik listesini gösterdiği için bu incelemenin yerini tutmaz.
Yedeğin kapsamını doğrulayın
pg_dump, veritabanı eşzamanlı kullanılırken tutarlı bir anlık görüntü dışa aktarır; buna rağmen tek veritabanının mantıksal dökümü, üretim ortamının bütün kurtarma ihtiyaçlarını karşılamayabilir. Diğer veritabanları, küme genelindeki roller ve belirli bir ana dönme gereksinimi ayrıca ele alınmalıdır. Bu sınır, dosya biçiminden bağımsızdır.
Geri yükleme tamamlandığında komutun çıkış durumunu, beklenen şemayı, verileri ve uygulamanın kullandığı rolün erişimini kontrol edin. Böyle bir deneme, arşivin okunabildiğini göstermenin ötesinde seçtiğiniz sahiplik ve izin ayarlarının hedefte işe yarayıp yaramadığını ortaya koyar.
Ayrıca okuyun:
İlgili makaleler


Firebase mi Supabase mi? Ucuz başlangıç, gecikme faturasını gizleyebilir

Supabase Turso’yu alıyor; 150 milyon dolar satın alma bedeli değil

Windows 11 güncellemesi sorun çıkardıysa üç geri dönüş yolunu karıştırmayın

Buzzsprout mu Podbean mi? Yayın süresi ve video desteği faturayı değiştiriyor

GitHub etiketleri artık silinmeden arşivleniyor, otomasyon ise eksik
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.