0Pricing
SQL Academy · Урок

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

RPO, RTO и эксплуатационные инструкции

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

Что такое аварийное восстановление?

Аварийное восстановление (DR) — это совокупность политик, инструментов и процедур, предназначенных для восстановления жизненно важной технологической инфраструктуры и систем после стихийной или вызванной действиями человека катастрофы.

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

Целевой показатель точки восстановления (RPO)

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

Более короткий RPO требует более частого резервного копирования или непрерывной репликации. Вы можете запросить историю резервного копирования, чтобы убедиться в достижении целевого показателя RPO.

-- Check the last backup time and calculate data loss window
SELECT
  backup_id,
  backup_type,
  started_at,
  finished_at,
  EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;

Целевой показатель времени восстановления (RTO)

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

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

-- Track restore durations to validate RTO compliance
SELECT
  restore_id,
  triggered_at,
  completed_at,
  EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
  CASE
    WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
    THEN 'WITHIN RTO'
    ELSE 'RTO BREACHED'
  END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;

RPO и RTO — ключевое различие

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

  • RPO = сколько данных вы можете позволить себе потерять? (ориентирован на прошлое, измеряется временем до аварии)
  • RTO = как долго вы можете позволить себе простой? (ориентирован на будущее, измеряется временем после аварии)

Вместе они определяют окно восстановления и напрямую влияют на частоту резервного копирования, стратегию репликации и бюджет инфраструктуры.

-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
  db_name       VARCHAR(100) PRIMARY KEY,
  rpo_minutes   INT NOT NULL,
  rto_minutes   INT NOT NULL,
  tier          VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
  updated_at    TIMESTAMP DEFAULT NOW()
);

INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
  ('orders_db',    15,   60, 'CRITICAL'),
  ('analytics_db', 120, 240, 'MEDIUM'),
  ('archive_db',   480, 480, 'LOW');

Типы резервных копий

Существует три основные стратегии резервного копирования, каждая из которых по-разному сочетает скорость и объём хранилища:

  • Полная резервная копия: полный снимок всей базы данных. Создаётся дольше всего, но восстанавливается быстрее всего.
  • Дифференциальная резервная копия: только изменения после последней полной резервной копии. Умеренная скорость создания и восстановления.
  • Инкрементальная резервная копия: только изменения после последней резервной копии любого типа. Создаётся быстрее всего, но восстанавливается медленнее всего, поскольку требуется несколько файлов.

Большинство стратегий DR объединяют еженедельные полные резервные копии с ежедневными инкрементальными, чтобы сбалансировать RPO и стоимость хранения.

-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
  backup_id   SERIAL PRIMARY KEY,
  db_name     VARCHAR(100) NOT NULL,
  backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
  started_at  TIMESTAMP NOT NULL,
  finished_at TIMESTAMP,
  size_mb     NUMERIC(12, 2),
  status      VARCHAR(20) DEFAULT 'IN_PROGRESS'
);

INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
  ('orders_db', 'FULL',        '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00',   320, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00',   290, 'SUCCESS');

Восстановление на момент времени (PITR)

Восстановление на момент времени позволяет восстановить базу данных на любой конкретный момент, а не только на время создания последней резервной копии. Это достигается повторным воспроизведением журналов транзакций (WAL в PostgreSQL) поверх базовой резервной копии.

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

-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
  segment_name  VARCHAR(200) PRIMARY KEY,
  archived_at   TIMESTAMP DEFAULT NOW(),
  size_bytes    BIGINT,
  storage_path  TEXT
);

-- Find all WAL segments archived within a recovery window
SELECT
  segment_name,
  archived_at,
  ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;

Резервные базы данных и репликация

Резервная база данных (реплика) — это постоянно обновляемая копия основной базы данных, работающая на отдельном оборудовании. Она выполняет две задачи DR:

  • Горячая резервная база: может принимать запросы на чтение и переключается за считаные секунды (почти нулевой RTO).
  • Тёплая резервная база: поддерживается синхронизированной, но не обслуживает запросы; переключение занимает минуты.

Контроль отставания репликации критически важен — отстающая реплика означает, что фактический RPO хуже ожидаемого.

-- Monitor replication lag on a PostgreSQL primary
SELECT
  client_addr,
  application_name,
  state,
  sent_lsn,
  replay_lsn,
  (sent_lsn - replay_lsn) AS lag_bytes,
  EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;

Руководства по восстановлению: документирование процедур восстановления

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

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

-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
  runbook_id   SERIAL PRIMARY KEY,
  title        VARCHAR(200) NOT NULL,
  scenario     VARCHAR(100),
  version      VARCHAR(20) DEFAULT '1.0',
  last_tested  DATE,
  owner        VARCHAR(100),
  doc_url      TEXT
);

INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
  ('Full Database Restore from S3', 'total_loss',     '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
  ('Failover to Hot Standby',       'primary_down',   '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
  ('PITR to Specific Timestamp',    'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');

Журналирование выполнения руководства

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

-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
  execution_id  SERIAL PRIMARY KEY,
  runbook_id    INT REFERENCES runbook(runbook_id),
  triggered_by  VARCHAR(100),
  is_drill      BOOLEAN DEFAULT FALSE,
  started_at    TIMESTAMP NOT NULL,
  completed_at  TIMESTAMP,
  outcome       VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);

-- Report average restore time per runbook
SELECT
  r.title,
  COUNT(*) AS executions,
  ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
  MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;

Проверка DR: регулярные учения

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

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

-- Find runbooks that have not been drilled in over 90 days
SELECT
  r.runbook_id,
  r.title,
  r.scenario,
  MAX(e.completed_at) AS last_drill,
  CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
  ON e.runbook_id = r.runbook_id
  AND e.is_drill = TRUE
  AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
    OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;

Политики хранения резервных копий

Политики хранения определяют, как долго сохраняются резервные копии. Хранение каждой резервной копии навсегда расходует место впустую, а слишком быстрое удаление нарушает требования RPO и соответствия нормативам.

Распространённая политика такова: ежедневные инкрементальные копии в течение 7 дней, еженедельные полные копии в течение 4 недель и ежемесячные полные копии в течение 12 месяцев. Вы можете применять и проверять соблюдение политики хранения с помощью SQL-запросов к журналу резервного копирования.

-- Identify backups that are outside their retention window and ready to purge
SELECT
  backup_id,
  db_name,
  backup_type,
  finished_at,
  CURRENT_DATE - finished_at::DATE AS age_days,
  CASE backup_type
    WHEN 'INCREMENTAL' THEN 7
    WHEN 'DIFFERENTIAL' THEN 28
    WHEN 'FULL'         THEN 365
  END AS retention_days,
  CASE
    WHEN (CURRENT_DATE - finished_at::DATE) >
         CASE backup_type
           WHEN 'INCREMENTAL' THEN 7
           WHEN 'DIFFERENTIAL' THEN 28
           WHEN 'FULL'         THEN 365
         END
    THEN 'PURGE'
    ELSE 'KEEP'
  END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;

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

Проверьте, насколько хорошо Вы понимаете определения RPO и RTO.

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

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

  • RPO определяет максимально допустимый объём потери данных во времени; меньшее значение RPO требует более частого резервного копирования или непрерывной репликации.
  • RTO определяет, насколько быстро необходимо восстановить систему; меньшее значение RTO требует использования горячих резервных серверов и автоматического переключения.
  • Типы резервных копий — полные, дифференциальные и инкрементные — по-разному соотносят объём хранилища, скорость создания и скорость восстановления.
  • PITR (восстановление на момент времени) использует журналы транзакций для восстановления на любой точно заданный момент, защищая от случайных изменений.
  • Пошаговые инструкции описывают каждый этап процедуры восстановления; журналирование выполнений подтверждает, что достичь заданного RTO возможно на практике.
  • Регулярные учения DR — единственный способ убедиться, что резервные копии можно восстановить, а команда способна достичь целевых значений RPO и RTO в условиях реальной нагрузки.
  • Политики хранения обеспечивают баланс между стоимостью хранилища, требованиями соответствия нормам и требованиями к восстановлению.

Хорошо протестированный план DR — одна из самых ценных инвестиций, которые может сделать команда базы данных.

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

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

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

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

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

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

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

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

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

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

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

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

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