Восстановление данных после сбоя

Сбои бывают разные: аппаратные отказы, отключения электричества, ошибки в коде или, что бывает нередко, случайное удаление базы данных нерадивым админом, который решил очистить "что-то старое". В таких ситуациях резервные копии и грамотно отработанный процесс восстановления становятся вашей "волшебной палочкой".

Давайте начнем разбирать процесс восстановления по шагам, как мы подошли бы к сборке IKEA-шкафа: без паники и строго по инструкции.

Шаг 1. Анализ причины сбоя

Прежде чем мчаться на всей скорости восстанавливать данные, важно понять, что именно произошло.

1. Ошибка приложения или базы данных?
   Проверьте логи вашего приложения и PostgreSQL (обычно их можно найти в /var/log/postgresql/ или аналогичной директории в зависимости от вашей ОС). Найдите индикаторы ошибок.

2. Аппаратная неисправность?
   Если сервер физически поврежден (например, проблемы с жестким диском), то сперва убедитесь, что оборудование исправно. Если ваш диск поврежден, подключите другой и восстановите всё с него.

3. Проблемы с сетью или доступом?
   Если сбой вызван сетью — ваш сервер, скорее всего, пока не требует восстановительных операций.

4. Человеческий фактор:
   Признайтесь... кто-то выполнил DROP DATABASE? Если да, у нас ещё есть шанс восстановить данные с резервной копии.

Помните, что точное понимание причин сбоя поможет избежать его в будущем.

Шаг 2. Проверка доступности резервных копий

Настало время убедиться, что у нас есть правильный бэкап. Найдите последние резервные копии базы данных, которые вы создавали с помощью pg_dump или pg_basebackup. Проверьте их целостность. Если вы ещё не знаете, как это сделать, вот краткое напоминание:

• Используйте команду ls -l для проверки размера ваших файлов. Если файл оказался подозрительно маленьким, это может быть признаком проблемы.
• Проверьте файл с помощью команды file. Например:

  file backup_file.sql
  

  Вы должны увидеть информацию о файле, указывающую, что это SQL-дамп.

Для архива tar проверьте его извлекаемость:

tar -tf backup.tar

Никаких ошибок? Отлично! Мы готовы двигаться дальше.

Шаг 3. Остановка PostgreSQL

Перед началом восстановления важно остановить сервер PostgreSQL, чтобы обезопасить процесс. Сделать это можно с помощью следующей команды (под админом сервера):

sudo systemctl stop postgresql

Остановка базы данных гарантирует, что никакие процессы не мешают восстановлению.

Шаг 4. Подготовка новой базы данных для восстановления

Если ваша база данных была полностью удалена или повреждена, сначала создайте её заново. Пример команды:

createdb -U postgres new_database

Замените new_database на имя вашей базы.

Шаг 5. Восстановление резервной копии

Рассмотрим два основных сценария восстановления:

1. Если вы используете бэкап SQL (pg_dump): Для восстановления используйте команду

   psql -U username -d new_database -f backup_file.sql
   

• username — ваш пользователь PostgreSQL.
• new_database — база данных, куда будут импортированы данные.
• backup_file.sql — ваш файл резервной копии.

2. Если вы используете бинарный бэкап (pg_basebackup или pg_dump с custom):
   Для восстановления используйте:
   

   pg_restore -U username -d new_database backup_file.dump
   

   Обратите внимание, что эти бэкапы не в текстовом формате, а содержат "упакованные" данные.

Дополнительно:

• Если в бэкапе только данные, используйте --data-only.
• Если нужно восстановить только структуру, добавьте --schema-only.

Шаг 6. Запуск PostgreSQL и тестирование

После выполнения команды восстановления запустите сервер:

sudo systemctl start postgresql

Теперь необходимо провести тесты. Попробуйте подключиться к восстановленной базе данных через psql или pgAdmin. Выполните несколько выборок, чтобы проверить корректность данных:

SELECT * FROM your_table_name LIMIT 10;

Если всё выглядит нормально, поздравляю: данные восстановлены!

Шаг 7. Проверка целостности данных

После восстановления важно проверить, что данные целостные. Например:

1. Сравните количество строк в таблицах с бэкапами:

   SELECT COUNT(*) FROM your_table_name;
   

   Сравните результат с записями в резервной копии (если есть).

2. Используйте контрольные суммы: Если вы раньше создавали контрольные суммы для таблиц, сейчас самое время сверить их:

   md5sum backup_file.sql
   

3. Проверьте связи между таблицами: Убедитесь, что восстановленные связи FOREIGN KEY работают корректно.

Шаг 8. Тестирование приложения

Теперь проверьте работоспособность вашего приложения, которое использует эту базу данных. Пробежитесь по основным сценариям работы. Есть ли ошибки? Всё ли корректно отображается?

Примеры реальных ошибок восстановления

Теперь давайте разберем несколько кейсов, чтобы показать, как можно избежать проблем:

1. Несовместимость версий PostgreSQL.
   Представьте, что бэкап был сделан на версии 12, а сервер обновился до версии 15. При восстановлении вы встретите ошибки.
   Решение: используйте ту же версию PostgreSQL, что и для создания бэкапа, либо обратитесь к документации о совместимости: PostgreSQL Documentation.

2. Повреждённый бэкап . Если ваш бэкап был поврежден, часть данных может быть утеряна.
   Решение: используйте репликацию бэкапов (например, хранение нескольких версий).

3. Ошибка при восстановлении конкретной таблицы.
   Если вы восстанавливаете конкретную таблицу, но остальные зависимости (например, внешние ключи) отсутствуют, процесс может завершиться ошибкой.
   Решение: всегда восстанавливайте таблицы в правильном порядке, начиная с родительских.