Backup PostgreSQL у pgAdmin 4 на Mac вирішуємо помилки версій у 2026

Зіткнулися з Failed при спробі зробити бекап у pgAdmin? Я вирішив цю проблему за 15 хвилин.

Спойлер: Вся справа в актуальних утилітах та правильних Binary Paths для macOS.

📚 Зміст статті

• 📌 Як я зрозумів, що щось йде не так
• 📌 Пастка з --large-objects: де я спотикнувся
• 📌 Версія сервера 17 проти моєї 15: чому це проблема?
• 📌 Мій метод оновлення PostgreSQL на Mac M1
• 📌 Налаштування Binary Paths: де ховається магія
• 💼 Мій чек-лист для ідеального бекапу
• 💼 Чи живий мій файл? Як я перевіряв результат
• 💼 Як я налаштував безкоштовне автозбереження
• ❓ FAQ від мене
• ✅ Висновки

📌 Як я зрозумів, що щось йде не так

Перше, що я зрозумів: pgAdmin досить «мовчазна» програма. Коли резервне копіювання переривається, ви не бачите пояснень у головному вікні. Я знайшов вихід — потрібно відкрити вкладку Dashboard, знайти активний процес у списку та натиснути на іконку «ока» (Details).

У логах я побачив, що система намагалася запустити команду:

/Applications/pgAdmin 4.app/Contents/SharedSupport/pg_dump ....

Це і була головна зачіпка — програма намагалася використати вбудовану утиліту версії 15 для бази даних PostgreSQL 17 на Railway. Код помилки 1 у цьому випадку означає критичний збій через несумісність версій.

📌 Пастка з --large-objects: де я спотикнувся

Мій досвід: Навіть якщо у вас свіжий pgAdmin, він може використовувати старі вбудовані скрипти.

Я вирішив це просто: у налаштуваннях самого бекапу перейшов на вкладку Data Options і вимкнув Blobs. Це прибрало зайвий прапор з команди, і процес пішов далі, але... мене чекала нова перешкода.

📌 Конфлікт версій: Server mismatch (17 vs 15)

Тут я зіткнувся з жорстким правилом екосистеми PostgreSQL: зворотна сумісність працює лише в один бік. Ви можете використовувати нову утиліту для бэкапу старої бази, але ніколи не навпаки. Оскільки сучасні хмарні хостинги (як Railway) оновлюються автоматично, мій локальний софт просто застарів, поки я спав.

Як виглядає ця помилка в логах:

Якщо ви побачили подібний текст, значить ви потрапили в ту ж пастку, що і я:

pg_dump: error: aborting because of server version mismatch
pg_dump: error: server version: 17.6; pg_dump version: 15.4

Чому це важливо розуміти

У кожній новій версії PostgreSQL з'являються нові типи даних або системні каталоги. Старий pg_dump просто не знає про їхнє існування і "панікує", щоб не створити пошкоджений файл бэкапу.

• ✔️ Правильно: pg_dump v17 + Server v15 (Працює)
• ❌ Неправильно: pg_dump v15 + Server v17 (Помилка mismatch)

Висновок: Не намагайтеся "вмовити" стару програму працювати з новою базою — просто оновіть локальні інструменти до актуальної версії.

📌 Встановлення актуального PostgreSQL на Mac M1

Як я це зробив

Відкрийте термінал і виконайте наступні кроки:

1. Встановіть пакет: brew install postgresql@17
2. Перевірте наявність файлу: Після встановлення переконайтеся, що файл існує за шляхом: ls /opt/homebrew/opt/postgresql@17/bin/pg_dump

Для Mac на базі Apple Silicon (M1/M2/M3) це ідеальний варіант, оскільки Homebrew використовує шлях /opt/homebrew/, що працює нативно та не конфліктує зі старими системними файлами Intel.

Можливі проблеми при встановленні:

📌 Налаштування Binary Paths: де ховається магія

Це був момент істини. Навіть після встановлення нового софту, pgAdmin продовжував використовувати старий pg_dump, «зашитий» всередині програми. Я вручну вказав йому шлях до версії 17.

Важливі нюанси налаштування:

• ✔️ Set as default: У вікні налаштувань я натиснув на круглу кнопку (radio button) зліва від версії 17. Без цього синього кружечка pgAdmin не зрозуміє, що цей шлях тепер основний.
• ✔️ Перезавантаження: Після натискання кнопки "Save" я закрив вікно створення бекапу і відкрив його знову, щоб налаштування підхопилися.

Порада: Якщо у списку немає рядка для PostgreSQL 17, просто впишіть шлях у рядок для PostgreSQL 16 або в саме верхнє поле — pgAdmin все одно буде запускати той файл, який лежить за вказаним шляхом.

💼 Мій чек-лист для ідеального бекапу

Який формат обрати? (Мій гайд)

У pgAdmin є кілька варіантів виводу даних. Ось як я обираю потрібний:

Мій особистий чек-лист:

• ✔️ Назва файлу: Я завжди натискаю на іконку папки та прописую ім'я файлу вручну, додаючи дату: db_backup_2025_12_24.backup.
• ✔️ Права доступу: Я зберігаю файл у папку "Документи" або на Робочий стіл. Якщо вибрати системну папку, pgAdmin просто видасть помилку без пояснень.
• ✔️ Data Options: Я перевіряю, щоб перемикач Blobs був вимкнений (сірий), щоб не "зловити" помилку синтаксису, про яку писав вище.

💼 Чи живий мій файл? Як я перевіряв результат

Багато хто лякається, коли відкриває .backup файл і бачить незрозумілі символи. Не панікуйте! Це особливість стисненого формату. Якщо ви хочете бачити чистий SQL-текст (назви таблиць, INSERT-команди), вам потрібно було обрати формат Plain перед початком процедури.

На що я дивлюсь у файлі:

Навіть у бінарному файлі можна натиснути Cmd + F (або Ctrl + F) і знайти ключові слова:

• 🔍 Назви ваших таблиць: Наприклад, public.users або public.posts.
• 🔍 Системні команди: Шукайте ALTER TABLE або CREATE INDEX.

Мій висновок: Якщо ви знайшли назви своїх сутностей серед «сміття» — вітаю, ваші дані успішно упаковані та готові до відновлення у будь-який момент!

💼 Як я налаштував безкоштовне автозбереження

Навіщо платити за функцію, яку ваш Mac може виконувати самостійно? Все, що нам потрібно — це вбудована програма Automator та одна потужна команда в терміналі.

Крок 1. Підготовка пароля (файл .pgpass)

Щоб скрипт не запитував пароль щоразу, його треба зберегти в секретному файлі. Відкрийте термінал і введіть:

nano ~/.pgpass

Вставте туди дані вашої бази у форматі: хост:порт:база:користувач:пароль. Збережіть (Ctrl+O) та закрийте (Ctrl+X). Потім обов'язково встановіть права доступу:

chmod 0600 ~/.pgpass

Крок 2. Налаштування в Automator

Я створив "Календарне нагадування" (Calendar Alarm) в Automator і додав дію "Run Shell Script". Ось команда, яку я використовую:

/opt/homebrew/opt/postgresql@17/bin/pg_dump \
--file "/Users/ВАШЕ_ІМ'Я/Documents/backups/db_$(date +%Y%m%d).backup" \
--host "your_host" \
--port "your_port" \
--username "your_username" \
--no-password \
--format=c "your_database_name"

Чому це працює:

• ✔️ Автоматизація: Скрипт автоматично додає дату до назви файлу (наприклад, db_20251224.backup).
• ✔️ Надійність: Завдяки прапору --no-password та файлу .pgpass, процес проходить без жодного кліку з мого боку.
• ✔️ Гнучкість: Ви можете налаштувати будь-який час у додатку "Календар" (наприклад, 3:00 ночі).

Порада Переконайтеся, що ваш Mac не "спить" у призначений час, або встановіть у налаштуваннях енергозбереження дозвіл на короткочасне пробудження для виконання завдань.

❓ Часті питання (FAQ)

1. Що робити, якщо шлях /opt/homebrew/ не знайдено?

Скоріш за все, у вас або не встановлений Homebrew, або ви використовуєте старий Mac на базі Intel.

Порада: Спробуйте виконати команду which pg_dump у терміналі. Вона покаже точний шлях, де лежить ваша утиліта. Якщо ви на Intel, шлях зазвичай буде /usr/local/bin/pg_dump. Якщо ж ви на M1/M2 і шляху немає — просто перевстановіть пакет postgresql@17.

2. Чи можна відновити базу з бекапу версії 17 на сервері з версією 15?

Ні, PostgreSQL не підтримує «даунгрейд» через бекапи. Ви не можете розгорнути файл, створений у новішій версії, на старішому сервері.

Порада: Завжди тримайте локальну версію такою ж, як на сервері, або на один крок попереду. Якщо потрібно перенести дані на старішу базу, використовуйте формат Plain (SQL) замість Custom.

3. Чому автоматичний бекап через Automator не спрацював?

Найчастіша причина — Mac пішов у «глибокий сон».

Порада: В налаштуваннях macOS (Battery або Energy Saver) увімкніть опцію “Wake for network access”. Також перевірте права на папку, куди зберігається бекап.

4. Чи безпечно зберігати пароль у файлі .pgpass?

Так, якщо ви правильно встановили права доступу chmod 0600 ~/.pgpass. Це означає, що лише ваш користувач може читати цей файл.

Порада: Це стандартна практика для серверів та автоматизації. Головне — ніколи не додавайте цей файл у Git-репозиторії.

5. Що краще: формат Custom чи Plain SQL?

Для щоденного резервного копіювання — однозначно Custom. Він менший за розміром і дозволяє відновлювати окремі таблиці.

Порада: Використовуйте Plain лише тоді, коли потрібно вручну редагувати SQL перед відновленням.

✅ Висновки

• 🔹 Досвід: «Мовчазні» помилки pgAdmin — це сигнал перевірити Binary Paths, а не причина для паніки.
• 🔹 Гнучкість: Homebrew + postgresql@17 вирішують 90% проблем сумісності.
• 🔹 Економія та контроль: Власна автоматизація замість платних сервісів — надійно і безкоштовно.

Головна думка

Не бійтеся «забруднити руки» в терміналі — іноді це єдиний спосіб змусити софт працювати так, як вам потрібно у 2026 році.