0Pricing
SQL Academy · Урок

Проверка восстановления

Резервная копия, которую нельзя восстановить, бесполезна

«Проверка восстановления» — бесплатный урок SQL Academy на CoddyKit. Это урок 3 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения SQL Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс SQL Academy содержит 4 уроков всего.

Резервная копия, которую невозможно восстановить, бесполезна

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

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

Что включает проверка восстановления?

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

Шаги таковы: 1) Получите файл резервной копии. 2) Восстановите его в изолированной среде. 3) Выполните запросы проверки. 4) Сопоставьте результаты с рабочей базой данных.

Создание базового снимка для сравнения

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

Выполните это в рабочей базе данных и запишите результаты:

SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Проверка количества строк после восстановления

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

Несоответствие сразу показывает, что данные были потеряны при резервном копировании или восстановлении, ещё до того, как вы затронете рабочую базу данных.

-- Run on the RESTORED test database
SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Проверка самых свежих данных

Количество строк подтверждает объём, но не подтверждает актуальность. Убедитесь, что восстановленная база данных содержит свежие записи: резервная копия должна отражать данные вплоть до момента её создания.

SELECT
  MAX(created_at) AS latest_order,
  MIN(created_at) AS oldest_order,
  COUNT(*)        AS total_orders
FROM orders;

Проверка ссылочной целостности

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

Используйте LEFT JOIN, чтобы обнаружить сиротские элементы заказов:

SELECT
  oi.id       AS orphaned_item_id,
  oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;

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

Для критически важных таблиц вычисляйте контрольную сумму данных, чтобы обнаружить повреждение на уровне битов. В PostgreSQL можно объединить MD5 с приведением типов для всей строки.

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

SELECT
  MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
  SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
  FROM orders
) sub;

Создание таблицы проверки восстановления

Чтобы отслеживать историю проверок восстановления, создайте отдельную таблицу журнала проверок. Записывайте каждый запуск проверки, указывая дату резервной копии, количество строк после восстановления и то, прошла ли проверка.

CREATE TABLE IF NOT EXISTS restore_validation_log (
  id             SERIAL PRIMARY KEY,
  backup_taken_at TIMESTAMP NOT NULL,
  restored_at    TIMESTAMP NOT NULL DEFAULT NOW(),
  table_name     VARCHAR(100) NOT NULL,
  expected_rows  INT NOT NULL,
  actual_rows    INT NOT NULL,
  passed         BOOLEAN NOT NULL
);

Добавление результата проверки

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

INSERT INTO restore_validation_log
  (backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
  ('2024-06-09 02:00:00', 'orders',      15482, 15482, TRUE),
  ('2024-06-09 02:00:00', 'customers',    8201,  8201,  TRUE),
  ('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);

Запрос истории проверок

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

SELECT
  backup_taken_at,
  table_name,
  expected_rows,
  actual_rows,
  passed,
  CASE
    WHEN passed THEN 'OK'
    ELSE 'MISMATCH - investigate!'
  END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;

Проверка восстановления на момент времени

Современные базы данных поддерживают восстановление на момент времени (PITR), позволяющее восстановиться к любому моменту с помощью базовой резервной копии и архивов WAL (журнала упреждающей записи).

Чтобы проверить работу PITR, восстановите базу данных на известную временную метку и убедитесь, что запись, созданная после этой временной метки, не (NOT) появляется в восстановленной базе данных:

-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctly

Быстрая проверка

Какой из следующих запросов наиболее полезен для обнаружения сиротских дочерних записей после восстановления резервной копии?

Итоги урока: проверка восстановления

В этом уроке вы узнали, почему тестирование восстановления обязательно для любой стратегии резервного копирования и как реализовать его с помощью SQL:

  • Базовые снимки — записывайте количество строк в рабочей базе данных перед проверкой.
  • Сравнение количества строк — выполняйте тот же запрос в восстановленной базе данных и сравнивайте результаты.
  • Проверка актуальности — убедитесь, что самые новые записи соответствуют ожидаемому периоду резервного копирования.
  • Ссылочная целостность — используйте LEFT JOIN для поиска сиротских дочерних строк.
  • Проверка контрольной суммы — обнаруживайте повреждение на уровне битов с помощью агрегирования MD5.
  • Таблица журнала проверок — отслеживайте каждый запуск проверки, создавая историю, пригодную для аудита.
  • Проверка PITR — убедитесь, что восстановление на момент времени выполняется на правильный момент.

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

Часто задаваемые вопросы

Урок «Проверка восстановления» бесплатный?

Да — полный текст урока «Проверка восстановления» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс SQL Academy, подпишись на CoddyKit PRO. Курс SQL Academy содержит 4 уроков всего.

Чему я научусь в уроке «Проверка восстановления»?

Резервная копия, которую нельзя восстановить, бесполезна Ты практикуешь SQL Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать SQL Academy?

Предыдущий опыт не требуется. SQL Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 3 из 4.

Сколько времени занимает урок «Проверка восстановления»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке SQL Academy?

Да. Каждый урок SQL Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Логические и физические резервные копии
  2. Восстановление на момент времени
  3. Проверка восстановления
  4. Планирование аварийного восстановления
← Назад к SQL Academy