У цьому матеріалі ми розглянемо реалізацію резервного копіювання на прикладі сервера баз даних для 1С: Підприємства, який ми описували в даній статті. Також зауважимо, що все, про що піде мова нижче однаково застосовно як до платформи Linux, так і до платформи Windows, за незначними уточненнями.
Відкриємо файл pg_hba.conf. він знаходиться в / var / lib / pgsql / data і приведемо до наступного вигляду рядок:
Для створення резервної копії скористаємося утилітою pg_dump. яка дозволяє створити дамп для зазначеної БД. Створення дампа відбувається без блокування таблиць і представдляет знімок БД на момент виконання команди. Тобто ви можете створювати дампи під час роботи користувачів, у той час як для створення резервної копії засобами 1С вам потрібен монопольний доступ до бази.
Тепер, уточнивши найменування баз на сервері створимо резервну копію бази unf14:
При необхідності можемо створити стислий дамп:
Стиснення дозволяє зменшити розмір дампов приблизно вдвічі, тому слід його использвать при передачі резервних копій по мережі інтернет або при обмеженому розмірі сховища.
Тепер розглянемо процедуру відновлення. Для прикладу будемо використовувати сервер під керуванням Windows. Ніяких істотних особливостей по роботі з PostgreSQL на різних платформах немає. Однак під Windows слід замість psql використовувати psql.bat і вказувати повний шлях до утиліт C: \ Program Files \ PostgreSQL \ Версія_СУБД \ bin. або додати цей шлях в системну змінну PATH.
Тепер заллємо отриманий дамп в тільки що створену базу unf14:
На платформі Лінукс ця команда буде виглядати так:
У нашому прикладі файл дампа знаходиться в C: \ backup і домашній директорії сответственно.
Все що тепер залишається, це через оснащення Адміністрування сервера 1С: Підприємства створити нову ІБ або змінити налаштування існуючої, вказавши на новий сервер СУБД і нову базу.
З основними командами ми розібралися і переконалися, що нічого складного в процесі резервного копіювання та відновлення баз PostgreSQL немає. Але не будемо ж ми створювати бекапи вручну. Тому перейдемо до автоматизації. Створимо Скрітпи, який буде створювати резервні копії зазначених баз і розміщувати їх на FTP-сервері. В силу певних відмінностей між платформами, створити універсальний скрипт для Windows і Linux не вийде, тому розглянемо кожну платформу окремо.
Почнемо з Linux, в нашому випадку це Ubuntu Server. Створимо файл скрипта:
і помістимо в нього наступне вміст:
У цьому матеріалі ми розглянемо реалізацію резервного копіювання на прикладі сервера баз даних для 1С: Підприємства, який ми описували в даній статті. Також зауважимо, що все, про що піде мова нижче однаково застосовно як до платформи Linux, так і до платформи Windows, за незначними уточненнями.
Відкриємо файл pg_hba.conf. він знаходиться в / var / lib / pgsql / data і приведемо до наступного вигляду рядок:
Для створення резервної копії скористаємося утилітою pg_dump. яка дозволяє створити дамп для зазначеної БД. Створення дампа відбувається без блокування таблиць і представляє знімок БД на момент виконання команди. Тобто ви можете створювати дампи під час роботи користувачів, у той час як для створення резервної копії засобами 1С вам потрібен монопольний доступ до бази.
Тепер, уточнивши найменування баз на сервері створимо резервну копію бази unf14:
При необхідності можемо створити стислий дамп:
Стиснення дозволяє зменшити розмір дампов приблизно вдвічі, тому слід його використовувати при передачі резервних копій по мережі інтернет або при обмеженому розмірі сховища.
Тепер розглянемо процедуру відновлення. Для прикладу будемо використовувати сервер під керуванням Windows. Ніяких істотних особливостей по роботі з PostgreSQL на різних платформах немає. Однак під Windows слід замість psql використовувати psql.bat і вказувати повний шлях до утиліт C: \ Program Files \ PostgreSQL \ Версія_СУБД \ bin. або додати цей шлях в системну змінну PATH.
Тепер заллємо отриманий дамп в тільки що створену базу unf14:
На платформі Лінукс ця команда буде виглядати так:
У нашому прикладі файл дампа знаходиться в C: \ backup і домашній директорії відповідно.
Все що тепер залишається, це через оснащення Адміністрування сервера 1С: Підприємства створити нову ІБ або змінити налаштування існуючої, вказавши на новий сервер СУБД і нову базу.
З основними командами ми розібралися і переконалися, що нічого складного в процесі резервного копіювання та відновлення баз PostgreSQL немає. Але не будемо ж ми створювати бекапи вручну. Тому перейдемо до автоматизації. Створимо скрипт, який буде створювати резервні копії зазначених баз і розміщувати їх на FTP-сервері. В силу певних відмінностей між платформами, створити універсальний скрипт для Windows і Linux не вийде, тому розглянемо кожну платформу окремо.
Почнемо з Linux, в нашому випадку це Ubuntu Server. Створимо файл скрипта:
і помістимо в нього наступне вміст:
Скрипт досить простий і ми не будемо розбирати його детально. Збережемо його і дамо права на виконання:
Також не забудемо створити каталог / root / backup
Перевіривши працездатність скрипта, задамо його регулярне виконання через cron.
Для платформи Windows все трохи складніше, тому що вбудований архіватор відсутня, то слід скористатися стороннім рішенням, в нашому випадку буде використовуватися 7zip. також потрібно вказувати повні шляху до бінарним файлів або додати їх в змінну PATH, ми будемо ставити цю змінну динамічно в скрипті. Ще одна складність пов'язана з використанням вбудованого ftp-клієнта, набір команд для нього необхідно підготувати у вигляді окремого файлу.
Створимо в Блокноті новий файл і розмістимо там нижченаведений текст:
Скрипт також досить простий для розуміння і повторює за структурою і логікою скрипт для Ubuntu. Задаємо змінні, встановлюємо робочу директорію і вивантажуємо туди дамп, потім створюємо архів. Наступним кроком формуємо файл з командами для FTP-з'єднання, завантажуємо архів на FTP і робимо прибирання.
Файл слід зберегти як pgsql-backup.bat і розмістити в зручному місці. Потім налаштувати його виконання за розкладом через Планувальник завдань Windows. Також не забудьте створити директорію C: \ backup (або будь-яку другою, яку ви хочете використовувати в якості робочої).
Звичайно, наші приклади не торкаюся всі можливі сценарії резервного копіювання, але ми впевнені що наведені приклади допоможуть вам створювати власні скрипти для автоматизації даного процесу.