Сколько времени восстанавливается терабайт: замер RTO на своих собственных данных

MAATRIX

В регламенте написано «RTO — 4 часа». Цифра выглядит солидно, её утвердили, её показывают клиентам и аудиторам. Проблема в том, что это число почти никогда не проверено на практике — его либо взяли с потолка, либо посчитали по паспортной скорости диска и канала, не учтя, что реальный процесс восстановления состоит из нескольких последовательных стадий, каждая из которых может оказаться узким местом. Единственный способ узнать настоящий RTO — взять терабайт своих данных, восстановить его на практике и засечь время каждого этапа.

Почему цифра из регламента не значит ничего

RTO (Recovery Time Objective) — это плановое время, за которое система должна вернуться к работе после сбоя. В большинстве компаний эта цифра берётся одним из двух способов: либо её продиктовал бизнес («нам нужно 2 часа простоя, максимум»), либо её вычислили по формуле «объём данных / заявленная скорость диска». Оба способа дают число, которое имеет крайне слабое отношение к тому, что произойдёт в реальности.

Проблема формульного расчёта в том, что он обычно учитывает только одну стадию — копирование файлов, и то по паспортной скорости, которая на практике почти никогда не достигается. За кадром остаются: скорость чтения именно с того хранилища, где реально лежит бэкап (а не с локального SSD, на котором тестировали диск), время на распаковку и расшифровку, конкуренция за I/O с другими процессами на восстанавливаемом сервере, и — для баз данных — время на накатку журналов транзакций, которое может по длительности сравняться с самим копированием файлов или превысить его.

Разница между расчётным и измеренным RTO обычно вскрывается в худший возможный момент — во время реальной аварии, когда переиграть уже нельзя. О том, как экономия на хранилище бэкапов незаметно превращается в лишние часы простоя, мы разбирали в статье «Цена восстановления: считаем не хранение бэкапа, а время возврата в строй». Здесь фокус на другом — как получить не оценочную, а измеренную цифру.

Из чего физически складывается время восстановления

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

1. Чтение бэкапа с источника. Если бэкап лежит на удалённом объектном хранилище или на другом сервере, скорость чтения ограничена сетевым каналом между хранилищем и целевой машиной, а не скоростью диска, на котором бэкап физически записан. Локальный тест «а у меня диск читает быстро» здесь не работает — измерять нужно именно тот путь, по которому пойдёт восстановление в реальном сценарии.
2. Распаковка и расшифровка. Если бэкап сжат (gzip, zstd, xz) и/или зашифрован (gpg, age, встроенное шифрование инструмента бэкапа), эта стадия съедает CPU, а не диск или сеть. Однопоточный gzip на большом архиве может оказаться узким местом даже при быстром диске и быстрой сети — вся цепочка упирается в один процессорный поток.
3. Запись на целевой диск. Скорость записи на диск, куда разворачивается терабайт, — отдельная переменная. HDD и SETA-массив с медленной случайной записью резко отличаются от NVMe, и если восстанавливаете на «запасной» сервер с более слабым хранилищем, чем боевой, — это законная часть измерения, а не погрешность.
4. Проверка целостности. Контрольные суммы файлов, проверка манифеста бэкапа, у некоторых инструментов — встроенная верификация после restore. Эту стадию часто вообще не закладывают в расчёт RTO, хотя на терабайте она может занять заметное время сама по себе.
5. Накатка журналов (только для БД). Восстановление файлового дампа или базового бэкапа СУБД — это ещё не консистентное состояние на нужный момент времени. Дальше применяются WAL (PostgreSQL) или бинарные логи (MySQL/MariaDB), и время этой стадии зависит не от объёма данных, а от количества и интенсивности транзакций с момента базового бэкапа — то есть от того, сколько времени прошло, а не от того, сколько весит терабайт.

Как измерить: тестовое восстановление с секундомером

Единственный надёжный метод — реальный прогон на изолированном стенде, максимально близком по характеристикам к боевому серверу (или, если ресурсов на точную копию нет, хотя бы с честной поправкой на разницу в дисках и сети). Формула здесь не нужна — нужен time и лог по стадиям.

Общая последовательность для файлового бэкапа:

# засекаем восстановление целиком
time tar -xzf backup-2026-08-full.tar.gz -C /mnt/restore-test

# то же самое, но с разбивкой по стадиям через pv —
# видно текущую скорость и суммарное время каждого шага
pv backup-2026-08-full.tar.gz | tar -xzf - -C /mnt/restore-test

Если бэкап зашифрован, стадии распаковки и расшифровки стоит замерить отдельно друг от друга — иначе непонятно, что тормозит:

# отдельно: расшифровка в файл
time gpg --decrypt backup-2026-08-full.tar.gz.gpg > backup-2026-08-full.tar.gz

# отдельно: распаковка расшифрованного архива
time tar -xzf backup-2026-08-full.tar.gz -C /mnt/restore-test

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

iostat -x 5      # загрузка и очередь на диске
sar -n DEV 5      # пропускная способность сети
top -o %CPU       # не упёрлись ли в однопоточную распаковку

Для восстановления через специализированный инструмент бэкапа замер делается так же — оборачиваете команду restore в time и параллельно снимаете диск/сеть/CPU:

time restic restore latest --target /mnt/restore-test
# или
time borg extract /mnt/backup-repo::2026-08-28 --target /mnt/restore-test

Результат такого прогона — не одна цифра «RTO = X часов», а таблица по стадиям: сколько заняло чтение, сколько распаковка, сколько запись, сколько проверка. Эта раскладка нужна не для отчётности, а чтобы понимать, что оптимизировать в первую очередь, если текущее время не устраивает.

Терабайт по стадиям: где на практике уходит время

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

Если вы всё же хотите ориентир для планирования — держите в уме, что при последовательном (не параллельном) прохождении всех пяти стадий терабайт данных восстанавливается заметно дольше, чем «объём / скорость диска», которую обычно закладывают в регламент. Насколько дольше — зависит от узкого места в вашей конкретной цепочке, и узнать это можно только прогоном, описанным выше.

Недооценённые этапы: проверка целостности и накатка журналов

Два этапа систематически выпадают из расчёта RTO, потому что их легко не заметить, когда тестируешь восстановление «на глаз», а не по стадиям.

Проверка целостности. После восстановления файлов правильная практика — сверить контрольные суммы или прогнать встроенную проверку инструмента бэкапа (restic check, borg check --repository-only, сверка sha256sum по манифесту). Без этого шага вы восстанавливаете данные, в целостности которых не уверены — а на терабайтном объёме именно эта стадия часто занимает столько же времени, сколько сама распаковка, потому что требует полного прохода по всем файлам ещё раз. Подробнее о промежуточных уровнях контроля, которые не требуют полного восстановления каждый раз, — в статье «Как проверить, что бэкап рабочий, не восстанавливая всё».

Накатка журналов транзакций. Это самый недооценённый этап именно потому, что его длительность не связана с объёмом бэкапа. Базовый бэкап PostgreSQL восстанавливается за предсказуемое время, а вот применение WAL до нужной точки — процесс, зависящий от количества транзакций, совершённых между базовым бэкапом и моментом сбоя:

# PostgreSQL: после разворачивания базового бэкапа
# сервер сам применит WAL при старте, если настроен restore_command
touch /var/lib/postgresql/16/main/recovery.signal
systemctl start postgresql
# прогресс накатки смотрим в логе
tail -f /var/log/postgresql/postgresql-16-main.log

# MySQL/MariaDB: накатка бинарных логов поверх xtrabackup
xtrabackup --prepare --target-dir=/mnt/restore-test
xtrabackup --copy-back --target-dir=/mnt/restore-test
mysqlbinlog --start-datetime="2026-08-28 03:00:00" \
  mysql-bin.000512 mysql-bin.000513 | mysql -u root -p

Если между базовым бэкапом и моментом сбоя прошли сутки активной работы базы, накатка журналов за этот период может занять сравнимое с самим восстановлением файлов время — и именно эту цифру регламентный расчёт «объём / скорость диска» не учитывает вообще. Практический разбор восстановления БД с частичными сценариями и point-in-time recovery — в статье «Восстановление базы данных из бэкапа: практика».

Как тестировать регулярно, не мешая продакшену

Разовый замер даёт снимок RTO на сегодня, но инфраструктура меняется: растёт объём данных, меняется скорость канала до хранилища бэкапов, добавляются новые таблицы и индексы. Число, измеренное полгода назад, устаревает так же, как и расчётная формула, если его не пересчитывать.

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

#!/bin/bash
# test-restore.sh — запускается по расписанию на отдельном сервере
START=$(date +%s)

restic restore latest --target /mnt/restore-test --tag prod-db

END=$(date +%s)
echo "$(date): restore took $((END-START)) seconds" >> /var/log/restore-drill.log

# проверка целостности после восстановления
restic check --read-data-subset=10%

# crontab на тестовом сервере — раз в неделю, ночью
0 3 * * 0 /opt/scripts/test-restore.sh

Такой прогон одновременно решает две задачи: даёт свежую цифру RTO и проверяет, что сам бэкап рабочий, а не просто существует. Второе не менее важно первого — бэкап, который нельзя восстановить, не спасает независимо от того, сколько времени заняло бы восстановление. Готовый почасовой сценарий для команды, если вы хотите не автоматический прогон, а совместные учения с разбором результатов, — в статье «Репетиция восстановления: сценарий учений на час».

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

Частые вопросы