Проверка целостности данных после восстановления

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

Иногда часть данных может просто не восстановиться — например, если резервная копия оказалась повреждённой. Бывает, что структура таблиц сбивается: исчезают внешние ключи, пропадают индексы или появляются странные значения. И даже если на первый взгляд всё выглядит нормально, логи могут намекать, что база на самом деле не совсем здорова.

Проверка целостности — это как техосмотр после ремонта. Лучше уделить немного времени и убедиться, что всё работает, чем потом внезапно столкнуться с проблемой в продакшене.

Анализ логов восстановления

Когда вы восстанавливаете данные с помощью pg_restore, PostgreSQL обязательно генерирует лог. Лог содержит много полезной информации о процессе восстановления, включая предупреждения и ошибки. Вот пример команды с указанием файла для логов:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Обратите внимание на > restore_log.txt 2>&1 — это перенаправляет как стандартный вывод, так и ошибки в один файл.

Что искать в логах?

1. Ошибки. Обращайте внимание на ключевые слова вроде "ERROR" или "FATAL". Пример:

   ERROR:  relation "students" does not exist
   

2. Предупреждения. Иногда вы можете увидеть предупреждения "WARNING". Хотя они не критичны, всё же стоит прочитать их — возможно, они сигнализируют о проблемах:

   WARNING:  no privileges could be granted for table "grades"
   

3. Несовпадения данных. Проверьте, восстановились ли все ключевые объекты: таблицы, индексы, внешние ключи.

Быстрая проверка с помощью grep

Если файл логов слишком длинный (а они бывают длиной как "Война и мир"), вы можете использовать grep, чтобы искать ключевые слова:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Разбор ошибок из логов

Давайте посмотрим на реальный пример из лога:

ERROR:  constraint "fk_student_course" for relation "enrollments" does not exist
DETAIL:  Key (course_id)=(2) is not present in table "courses".

Что эта ошибка нам говорит? Она означает, что PostgreSQL пытается восстановить строку в таблице enrollments, но для неё не существует соответствующего course_id в таблице courses.

Как решить? Возможно, данные в таблице courses были повреждены или не восстановились. Вам придётся либо вручную добавить недостающие строки, либо повторить восстановление.

Использование контрольных сумм для проверки целостности

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

Контрольная сумма — это небольшое число, представляющее данные в файле. Если файл изменяется хоть на один бит, его контрольная сумма тоже изменится. Это помогает определить, был ли файл повреждён.

Для создания контрольной суммы можно использовать утилиту md5sum. Вот пример команды:

md5sum backup_file.dump

Результат будет выглядеть так:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Сравнение контрольных сумм

Если вы заранее записали контрольную сумму файла, вы можете сравнить её с текущей:

md5sum -c checksum.md5

Файл checksum.md5 должен содержать строку с контрольной суммой и именем файла:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Если контрольная сумма совпадает, вы увидите сообщение OK. Если нет — файл повреждён.

Проверка данных на уровне базы

Контрольные суммы и логи — это хорошо, но как проверить, что сами данные в порядке? Вот список стандартных действий:

1. Сравнение количества строк

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

-- Подсчёт количества строк в таблице students
SELECT COUNT(*) FROM students;

Если количество строк отличается, восстановление прошло не полностью.

2. Проверка целостности ключей

Восстановите связи между таблицами, чтобы убедиться, что все внешние ключи работают:

-- Проверка студентов, записанных на курсы
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Если запрос возвращает результат, значит, в таблице enrollments есть строки с отсутствующими курсами.

3. Сравнение данных с оригиналом

Если у вас есть копия данных (например, дамп другой базы), вы можете сравнить выборки:

-- Проверка данных из таблицы courses
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Реальные кейсы восстановления

Случай из практики: однажды администратор СУБД Bob решил восстановить данные из резервной копии после сбоя сервера. Он выполнил команду:

pg_restore -U admin -d my_database my_backup.dump

Но при анализе логов восстановление завершилось ошибкой:

ERROR:  could not create file "base/16385/pg_internal.init": No space left on device

Это означало, что на диске закончилось место. После освобождения дискового пространства и повторного восстановления данных он также обнаружил, что не все таблицы были восстановлены. К счастью, благодаря заранее сгенерированным контрольным суммам и настройке WAL архивации Bob смог полностью восстановить базу данных.

Итоги проверки целостности

В завершение проверки целостности данных после восстановления выполните следующее:

1. Проверьте логи на наличие ошибок и предупреждений.
2. Используйте контрольные суммы, чтобы убедиться в отсутствии повреждений файлов.
3. Сравните данные базы на количество строк и целостность связей.
4. Если что-то пошло не так, исследуйте ошибки и повторите процесс восстановления.

Теперь вы полностью готовы провести тщательную проверку и убедиться, что данные восстановлены так, как вы их и ожидали. Ведь главное в деле администрирования баз данных — это уверенность в своей резервной копии!