Сколько времени займёт восстановление со storage VPS

Сколько времени займёт восстановление со storage VPS

Восстановление со storage VPS занимает столько времени, сколько нужно самому медленному звену цепочки, чтобы передать ваш объём данных. Формула короткая: объём делить на реально измеренную скорость, плюс время на распаковку, проверку и запуск сервисов. Самое медленное звено почти никогда не находится в дисках хранилища. Обычно это ваш канал на приём или ограничение исходящего трафика на стороне провайдера.

Это число почти никто не считает заранее. Бэкап на 4 ТБ настроен, restic отрабатывает по расписанию, уведомления об успешных запусках приходят. Нет ответа только на один вопрос: если завтра основной сервер исчезнет, через сколько часов данные снова будут на месте. Обычно ответ измеряется не часами, а сутками, и узнают его в самый неудачный момент.

Бэкап без измеренного времени восстановления даёт не план, а надежду.

Посчитайте это число сегодня. Оно меняет вашу схему хранения сильнее, чем выбор между restic и borgbackup, потому что определяет, где данные лежат, а не чем они упакованы.

Арифметика: объём делить на скорость

Провайдеры считают каналы в мегабитах, а файлы измеряются в мегабайтах. Делите на 8. Порт 100 Мбит/с даёт максимум 12,5 МБ/с, то есть около 45 ГБ в час при полной загрузке.

[
  {
    "label": "50 \u041c\u0431\u0438\u0442/\u0441",
    "hrs_1tb": 44.4,
    "hrs_5tb": 222.2
  },
  {
    "label": "100 \u041c\u0431\u0438\u0442/\u0441",
    "hrs_1tb": 22.2,
    "hrs_5tb": 111.1
  },
  {
    "label": "200 \u041c\u0431\u0438\u0442/\u0441",
    "hrs_1tb": 11.1,
    "hrs_5tb": 55.6
  },
  {
    "label": "500 \u041c\u0431\u0438\u0442/\u0441",
    "hrs_1tb": 4.4,
    "hrs_5tb": 22.2
  },
  {
    "label": "1000 \u041c\u0431\u0438\u0442/\u0441",
    "hrs_1tb": 2.2,
    "hrs_5tb": 11.1
  }
]

В таблице выше чистая арифметика, а не измерение: терабайт взят как 1 000 000 000 000 байт, канал загружен на 100 процентов, потерь и пауз нет. Реальное восстановление идёт медленнее всегда. На 100 Мбит/с один терабайт едет 22.2 часа, а пять терабайт 111.1 часов, почти пять суток непрерывной загрузки. На 50 Мбит/с те же пять терабайт превращаются в 222.2 часов, это больше девяти суток. Гигабитный канал даёт 2.2 часа на терабайт, но гигабит нужен на обоих концах: и у хранилища, и там, куда вы восстанавливаете.

Подставьте свои значения. Объём возьмите из репозитория, скорость из собственного теста, а не из рекламы провайдера. Полученное число часов и есть ваш реальный RTO (recovery time objective, целевое время восстановления).

Почему узким местом оказываются не диски

Цепочка восстановления длинная, и медленным может быть любое её звено.

• Диски хранилища. На storage VPS почти всегда стоят HDD, линейное чтение у них приемлемое, а миллион мелких файлов упирается в число операций в секунду. Чего ждать от такой конфигурации, разобрано в том, какую скорость диска реально показывает storage VPS.
• Сеть провайдера. Слово «безлимит» часто означает ограничение скорости после некоторого объёма или размытое правило честного использования. Что за этим стоит, разобрано в обещании безлимитного трафика.
• Маршрут между странами. Вечером трансграничные стыки загружены сильнее всего, и одна и та же выгрузка идёт с разной скоростью в 03:00 и в 21:00.
• Ваш канал на приём. Домашние 100 Мбит/с редко бывают полностью свободными, а рабочие часто ограничены на уровне офисного роутера.
• Диск, куда вы пишете. Восстановление это операция записи, и медленный целевой том останавливает всё остальное.
• Процессор. restic расшифровывает данные и проверяет контрольные суммы, поэтому на одном vCPU упор иногда происходит в CPU раньше, чем в сеть.

Отдельно стоит понимать, почему одно соединение медленнее восьми. Скорость одного потока TCP ограничена размером окна, делённым на RTT (round trip time, время оборота пакета), а при потерях окно уменьшается и растёт обратно тем дольше, чем больше RTT. На маршруте в другую страну это заметно сразу. Проверяется за минуту: запустите тест с одним потоком и с восемью. Если восемь потоков дают заметно больше, ограничение живёт в задержке и потерях, а не в ширине канала, и восстанавливать нужно параллельно.

Как измерить свою скорость восстановления

Все числа должны быть вашими. Опубликованные скорости описывают чужой маршрут в чужое время суток. Если репозиторий ещё не настроен, начните с настройки бэкапов restic на VPS, а потом возвращайтесь к измерениям.

sudo apt update && sudo apt install -y restic iperf3 rclone

Сначала задержка.

ping -c 20 storage.example.com

В итоговой строке rtt min/avg/max/mdev вас интересует значение avg. Оно показывает длину маршрута во времени. Чем оно больше, тем хуже будет работать одно соединение и тем важнее параллельные потоки.

Теперь пропускная способность в нужную сторону.

# на storage VPS
iperf3 -s

# на машине, куда вы будете восстанавливать
iperf3 -c storage.example.com -R -t 30 -P 1
iperf3 -c storage.example.com -R -t 30 -P 8

Ключ -R разворачивает тест: сервер отдаёт, клиент принимает. Это совпадает с направлением восстановления, поэтому измерять надо именно так. Закройте порт 5201 файрволом сразу после теста, чтобы не оставлять открытый сервис без нужды.

Самое честное измерение делается на настоящих данных.

export RESTIC_REPOSITORY=sftp:backup@storage.example.com:/srv/restic
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic snapshots
restic stats --mode restore-size latest

Команда stats с режимом restore-size показывает, сколько места займут файлы после восстановления. Это числитель вашей формулы, и он больше размера репозитория, потому что репозиторий сжат и дедуплицирован.

mkdir -p /srv/restore-test
time restic restore latest --target /srv/restore-test \
  --include /etc --include /var/lib/postgresql
du -sh /srv/restore-test

Разделите объём из вывода du на время из вывода time. Получится ваша скорость в МБ/с на этом маршруте, в этот час, на этом типе файлов. Запишите её. Если данные лежат не в restic, измерение делается тем же способом через rclone.

rclone copy storage:backups/latest /srv/restore-test --transfers 8 --progress

Флаг --progress печатает текущую скорость и оценку оставшегося времени, а --transfers 8 качает восемь файлов одновременно. Сравните вывод с --transfers 1, и вы увидите ту же разницу, что показал тест с параллельными потоками.

Что меняет расстояние до хранилища

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

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

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

Разделите данные на уровни: час, сутки, неделя

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

• Уровень «час». SSH-ключи, docker-compose.yml, файлы .env, конфиги nginx, дампы баз данных. Это единицы гигабайт, и они должны лежать не только на storage VPS, но и на вашем ноутбуке.
• Уровень «сутки». Рабочие данные: домашние каталоги, документы, почта, тома приложений.
• Уровень «неделя». Медиатека, фотоархив, старые снапшоты, всё, без чего можно прожить неделю.

Маленький критичный набор дублируйте локально. Восстановление пяти гигабайт конфигов с диска ноутбука занимает минуты и не зависит ни от какого канала. Второй экземпляр важных данных в другом месте описан в схеме с двумя репозиториями restic, и именно она превращает «единственная копия далеко» в «быстрая копия рядом плюс дешёвая копия далеко». Заодно она закрывает вопрос из разбора того, считается ли storage VPS бэкапом: одна копия в одном месте бэкапом не является, каким бы большим ни был диск.

Восстанавливайте выборочно, а не всё сразу

restic умеет отдавать отдельные файлы и каталоги. Это главный способ уложиться в час вместо суток.

restic restore latest --target /srv/app --include /var/lib/app/config
restic dump latest /etc/nginx/nginx.conf > /root/nginx.conf.restored

Если непонятно, что именно нужно, смонтируйте репозиторий и посмотрите глазами.

sudo apt install -y fuse3
mkdir -p /mnt/restic
restic mount /mnt/restic

Каталог /mnt/restic/snapshots/latest выглядит как обычная файловая система, и копировать из него можно любым привычным инструментом. Данные качаются по мере чтения, поэтому ls отрабатывает мгновенно, а cp большого файла идёт со скоростью вашего канала. Размонтировать можно сочетанием Ctrl+C в том же терминале.

Порядок восстановления важнее скорости. Сначала возвращается то, что поднимает сервис: compose-файл, переменные окружения, дампы баз. Тома с пользовательскими файлами едут следом, уже при работающем сайте. Последовательность и подводные камни такого восстановления разобраны в восстановлении и обновлении стека Docker Compose. Для фотоархива логика та же: бэкап и восстановление Immich показывает, что база и оригиналы возвращаются разными путями и с разной скоростью.

Поднимите новый сервер рядом с хранилищем

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

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

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

Проверка по расписанию и журнал измерений

Скорость, измеренная один раз в марте, ничего не говорит о сентябре. Маршруты меняются, провайдер меняет правила, ваш объём растёт. Поставьте проверку в календарь: раз в месяц частичное восстановление, раз в квартал полное восстановление одного важного набора на чистую машину.

time restic check --read-data-subset=1/12

Эта команда скачивает и проверяет двенадцатую часть данных репозитория. Она делает два дела сразу: подтверждает, что данные читаются, и даёт честное измерение маршрута на реальном трафике.

Результат записывайте в файл рядом с конфигами бэкапа и держите его в git.

2026-09-09 03:10  restore-test  42 GB  3120 s  13,5 MB/s  ночь
2026-09-09 21:40  restore-test  42 GB  5580 s   7,5 MB/s  вечер

Числа в примере ничего не говорят о вашем маршруте. Значение имеет только ваша строка и то, как она меняется от месяца к месяцу. Падение скорости вдвое за квартал это повод писать в поддержку заранее, а не в день аварии.

Если восстановление превращается в фоновую задачу на несколько суток, ограничьте его скорость, чтобы остальная работа не встала.

restic --limit-download 20000 restore latest --target /srv/restore

Значение задаётся в КиБ/с. Перегруженный канал с потерями отдаёт меньше, чем тот же канал с разумным ограничением, поэтому такой флаг иногда ускоряет процесс, а не замедляет.

Как выбирать локацию под скорость восстановления

Цена за терабайт видна на сайте, скорость восстановления не видна нигде. Спрашивайте о ней до оплаты.

• Попросите тестовый файл или адрес для iperf3 и померьте со своей машины, а не через внешний сервис проверки скорости.
• Спросите прямо, есть ли ограничение исходящей скорости, после какого объёма оно включается и что написано мелким шрифтом про честное использование.
• Проверьте маршрут в вечерние часы, а не только днём.
• Посмотрите, есть ли у провайдера обычные VPS в той же локации: туда можно будет восстановиться быстро.

Остальные пункты выбора собраны в чек-листе выбора storage VPS, а размер, который вам действительно нужен, считается в разборе необходимого объёма хранилища. Общая роль такой машины в схеме резервного копирования описана в использовании VPS как удалённой цели для бэкапов.

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

Что вы увидите, когда восстановление ломается

Репозиторий не открывается. restic пишет wrong password or no key found и останавливается. Пароль исчез вместе с сервером, на котором лежал. Пароль и ключи должны храниться отдельно от бэкапа и отдельно от боевой машины: как их держать и чем шифровать, разобрано в шифровании данных на storage VPS.

Соединение не устанавливается. ssh: connect to host storage.example.com port 22: Connection timed out означает, что до хранилища не доходят пакеты. Обычные причины: ключ был только на умершей машине, адрес нового сервера не внесён в список разрешённых у провайдера, порт закрыт сетевым файрволом панели. Проверьте доступ с запасной машины заранее, а не в день аварии.

Скорость падает, появляются повторы. restic печатает строки вида:

Load(<data/1a2b3c4d5e>, 0, 0) returned error, retrying after 552.330144ms: ...

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

Место кончилось на середине. no space left on device останавливает восстановление, и половина файлов остаётся лежать на диске. Восстановленные данные почти всегда занимают больше, чем репозиторий, потому что он сжат и дедуплицирован. Сравните вывод restic stats --mode restore-size с выводом df -h до запуска.

Файлов много, а байтов мало. Восстановление миллиона мелких файлов упирается в операции с файловой системой, а не в канал: скорость в МБ/с при этом низкая, и это ожидаемо. Такой набор данных измеряйте отдельным тестом, иначе план, построенный на средней скорости, окажется слишком оптимистичным.

FAQ

Как посчитать, сколько времени займёт восстановление?

Возьмите объём из restic stats --mode restore-size latest и разделите его на скорость, которую вы измерили собственным тестовым восстановлением. Помните про деление на 8: канал 100 Мбит/с в идеале даёт 12,5 МБ/с, то есть около 45 ГБ в час. Прибавьте время на разворачивание баз, запуск сервисов и переключение DNS. Полученное число часов и есть ваш реальный RTO.

Почему скачивание идёт медленнее обещанного порта?

Причин несколько, и они складываются. Одно соединение TCP ограничено размером окна, делённым на время оборота пакета, поэтому на длинном маршруте оно не разгоняется: сравните iperf3 -P 1 и iperf3 -P 8. Провайдер может ограничивать исходящую скорость после некоторого объёма. Мелкие файлы упираются в операции диска, а не в канал. restic ещё и расшифровывает данные, поэтому на одном vCPU процессор иногда заканчивается раньше сети.

Что восстанавливать первым?

То, без чего сервис не запускается: ключи, конфиги, compose-файлы, дампы баз данных. Это единицы гигабайт, и они возвращаются за минуты, если лежат ещё и локально. Пользовательские файлы и медиатеку восстанавливайте после того, как сервис уже работает, через restic restore с фильтром --include или через restic mount.

Что лучше, дешёвое хранилище далеко или дорогое рядом?

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

Как часто нужно проверять восстановление?

Раз в месяц делайте частичное восстановление одного набора и записывайте измеренную скорость. Раз в квартал восстанавливайте важный набор целиком на чистую машину. Команда restic check --read-data-subset=1/12 читает часть данных по-настоящему и заодно измеряет маршрут. Проверка, которая ни разу не запускалась, проверкой не считается.