Відновлення даних PostgreSQL через COPY: випадок із практики

Коли резервні копії давно не перевіряли, відновлення даних перетворюється на окрему задачу. Раніше я вже працював із відновленням Firebird та InterBase, але у липні 2014 року довелося шукати вихід із проблеми в PostgreSQL.

Помилки Page Error і резервна копія піврічної давнини

До мене звернувся давній клієнт: база PostgreSQL працювала в нього багато років, а напередодні під час входу в систему почали з’являтися помилки Page Error. Працювати стало неможливо. У pgAdmin я спробував створити резервну копію, але отримав помилки; вони виникали й під час переходу списком баз даних.

Вирішили відновитися з резервної копії. Виявилося, що остання була за грудень 2013 року: під загрозою опинилися приблизно пів року роботи. Тоді я спробував звичайний SELECT — і запит до потрібної таблиці успішно повернув дані. Ура! З’явився спосіб перенести доступну інформацію в окрему базу.

Як я переніс дані через COPY

1. Створив базу з іншою назвою та відновив у неї знайдену копію за грудень 2013 року. Перевірив вхід у застосунок — він працював.
2. Вивантажив дані з потрібних таблиць проблемної бази. Для однієї з них використав таку команду:

   copy (select * from zrp_zakaz ) to 'd:\tmp\zrp_zakaz';

3. У новій базі, відновленій зі старої копії, видалив попередній вміст відповідної таблиці перед завантаженням. Ця команда видаляє всі її рядки; у наведеному випадку вона виконувалася саме в окремій базі для відновлення:

   delete from zrp_zakaz;

4. Завантажив дані зі збереженого файла у відповідну таблицю нової бази:

   copy zrp_zakaz from 'd:\tmp\zrp_zakaz';

За результатом перевірки мені вдалося відновити роботу бази без виявленої втрати потрібної інформації. Клієнт був задоволений — саме цього й хотілося досягти.

Що важливо перевірити

Перед відновленням слід зберегти вихідний стан даних і працювати з окремою копією. Успішний SELECT до однієї таблиці не доводить цілісності всієї бази. Після перенесення потрібна перевірка повноти таблиць, зв’язків, послідовностей і роботи застосунку; під час експорту необхідно врахувати паралельні зміни даних.

COPY зі шляхом до файла працює на боці сервера PostgreSQL, а не комп’ютера з pgAdmin. Каталог має бути доступний обліковому запису сервера. Написання Windows-шляху й екранування зворотних скісних рисок потрібно звіряти з версією та параметрами SQL-сеансу. Наведені команди стосуються конкретної таблиці та шляху; перед виконанням їх потрібно звірити зі своїм середовищем.

Офіційний опис: COPY у документації PostgreSQL.