План выхода со storage VPS: как забрать свои данные

Что такое план выхода со storage VPS

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

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

Ниже пять частей плана и чек-лист, который закрывается за неделю. Речь только о данных. Выбор площадки по задержке и правовому режиму разобран в отдельном материале про задержку и право при аренде storage VPS. Здесь задача другая: сделать уже сделанный выбор обратимым.

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

Сценарии почти всегда бытовые, а не драматические.

• Карта перестала проходить у зарубежного провайдера, автосписание не прошло, аккаунт ушёл в suspend.
• Провайдер свернул работу в регионе и дал тридцать дней на вывоз данных.
• Аккаунт заблокирован из-за спора по платежу, и переписка с поддержкой идёт вторую неделю.
• Почтовый ящик, на который зарегистрирован аккаунт, недоступен, а код двухфакторной аутентификации (второй фактор входа) приходит именно туда.
• Тариф пересчитали, и хранение перестало быть выгодным.

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

Как хранить данные в переносимом формате

Переносимый формат это репозиторий, который описывает себя сам. Репозиторий restic это обычный каталог: файл config, каталоги keys/, data/, index/, snapshots/. Скопируйте этот каталог куда угодно, и restic прочитает его без участия провайдера.

sudo apt update && sudo apt install -y restic
restic version
restic -r sftp:u123456@storage.example.com:/srv/restic init
restic -r sftp:u123456@storage.example.com:/srv/restic backup /srv/data
restic -r sftp:u123456@storage.example.com:/srv/restic snapshots

restic snapshots должен показать строку со снимком: ID, дату, имя хоста и пути. Пустой список сразу после успешного backup означает, что вы смотрите в другой репозиторий, проверьте строку после -r. Базовая настройка расписания и исключений разобрана в руководстве по резервному копированию на VPS с restic.

Пакет из репозитория дистрибутива отстаёт от текущего релиза, иногда на год. Статический бинарник со страницы релизов https://github.com/restic/restic/releases работает на любом Linux и обновляется командой restic self-update. Один файл без зависимостей это уже часть плана выхода: его можно положить рядом с копией данных и запустить на чужой машине.

Самодостаточность репозитория проверяется двумя командами.

restic -r /srv/restic cat config
restic -r /srv/restic check --read-data-subset=10%

cat config печатает версию формата и параметры чанкера, то есть всё, что нужно другой копии restic для чтения. check проверяет структуру и дополнительно перечитывает десять процентов реальных данных, поэтому ловит тихую порчу файлов, которую индекс не видит. Сообщение Fatal: unable to open config file означает, что по указанному пути репозитория нет, а не что он повреждён.

BorgBackup решает ту же задачу иначе, и выбор между ними разобран в сравнении restic и BorgBackup. Для плана выхода у Borg важна одна деталь.

borg init --encryption=repokey-blake2 ssh://u123456@storage.example.com/./borg
borg create --stats --compression zstd,3 ssh://u123456@storage.example.com/./borg::{hostname}-{now} /srv/data
borg list ssh://u123456@storage.example.com/./borg

При repokey ключ шифрования лежит внутри репозитория и защищён парольной фразой, поэтому он уезжает вместе с данными. При keyfile ключ лежит только в ~/.config/borg/keys на клиенте, и смерть клиента означает потерю репозитория, даже если сами файлы целы. Для выхода repokey надёжнее.

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

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

У restic и Borg нет процедуры восстановления пароля. Это не строгость поддержки, а следствие устройства: парольная фраза расшифровывает мастер-ключ, а без мастер-ключа содержимое data/ неотличимо от случайных байтов. Забытый пароль равен уничтоженным данным.

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

Сделайте пароль машинным и положите его в файл с правами 600.

sudo install -m 600 /dev/null /root/.restic-pass
openssl rand -base64 32 | sudo tee /root/.restic-pass > /dev/null
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic -r sftp:u123456@storage.example.com:/srv/restic snapshots

Теперь вынесите копию наружу. Файл с паролем шифруется отдельной фразой, которую вы помните, и уезжает на носитель, никак не связанный с провайдером.

age -p -o restic-pass.age /root/.restic-pass
age -d -o restic-pass.txt restic-pass.age

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

У restic к одному репозиторию можно добавить второй пароль, не трогая первый. Это нужно, когда доступ должен быть у коллеги или у второй машины.

restic -r /srv/restic key list
restic -r /srv/restic key add

У Borg ключ экспортируется явно, в том числе в вид, пригодный для печати.

borg key export ssh://u123456@storage.example.com/./borg ~/borg-key.txt
borg key export --paper ssh://u123456@storage.example.com/./borg

Бумажная копия выглядит архаично, но она не зависит ни от аккаунта, ни от диска, ни от срока жизни флешки. Что и на каком уровне шифровать, разобрано в руководстве по шифрованию данных на storage VPS.

Сколько времени займёт полная выгрузка данных

Сначала узнайте объём. restic stats --mode raw-data показывает, сколько байт реально лежит в репозитории после дедупликации и сжатия, а не сумму размеров исходных файлов. Именно это число вам придётся тянуть по проводу.

restic -r sftp:u123456@storage.example.com:/srv/restic stats --mode raw-data

Дальше арифметика. Один терабайт это восемь миллионов мегабит, поэтому время в секундах равно 8 000 000, делённым на скорость канала в мегабитах в секунду.

[
  {
    "label": "10 \u041c\u0431\u0438\u0442/\u0441",
    "hours": 222
  },
  {
    "label": "50 \u041c\u0431\u0438\u0442/\u0441",
    "hours": 44
  },
  {
    "label": "100 \u041c\u0431\u0438\u0442/\u0441",
    "hours": 22
  },
  {
    "label": "300 \u041c\u0431\u0438\u0442/\u0441",
    "hours": 7
  },
  {
    "label": "1 \u0413\u0431\u0438\u0442/\u0441",
    "hours": 2
  }
]

На канале 10 Мбит/с терабайт едет 222 ч, это больше девяти суток непрерывной загрузки. На 100 Мбит/с получается 22 ч, на гигабите 2 ч. Все 5 строк посчитаны для полной утилизации канала, то есть это нижняя граница времени, а не ожидаемая.

Реальная скорость всегда ниже паспортной. На длинном маршруте одно TCP-соединение упирается в задержку и размер окна, поэтому один поток редко забирает весь канал. Дальше вмешивается диск на стороне провайдера: на дешёвых тарифах под хранение это большие механические диски, и чего от них ждать, разобрано в обзоре реальной скорости дисков на storage VPS. Планируйте от 60 до 70 процентов паспортной цифры.

Лучше не планировать, а измерить. Восстановите один каталог под time и разделите его объём на потраченные секунды.

time restic -r sftp:u123456@storage.example.com:/srv/restic restore latest \
  --target /var/tmp/restore-probe --include /srv/data/photos

Отдельно проверьте трафик. Слово «безлимитный» в тарифе обычно означает отсутствие счёта за гигабайты, но не отсутствие ограничения скорости после порога, и выгрузка терабайта как раз этот порог находит. Что скрывается за формулировками, разобрано в материале о том, что на самом деле означает безлимитный трафик.

Зачем вторая копия у другого провайдера

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

restic умеет копировать снимки между репозиториями, сохраняя историю.

export RESTIC_PASSWORD_FILE=/root/.restic-pass2
export RESTIC_FROM_PASSWORD_FILE=/root/.restic-pass
restic -r sftp:u77@second.example.net:/srv/restic init \
  --from-repo sftp:u123456@storage.example.com:/srv/restic --copy-chunker-params
restic -r sftp:u77@second.example.net:/srv/restic copy \
  --from-repo sftp:u123456@storage.example.com:/srv/restic

--copy-chunker-params задаёт новому репозиторию те же параметры нарезки, что у исходного, поэтому дедупликация продолжает работать и копия не раздувается. Без этого флага каждый блок нарежется по-своему, и вы заплатите за место дважды.

Зеркало через rclone тоже работает, но решает другую задачу.

rclone sync /srv/restic second:storage/restic --transfers 8 --checkers 16 --progress
rclone check /srv/restic second:storage/restic --one-way

rclone sync делает побайтовую копию, поэтому переносит на вторую сторону и повреждения, и последствия ошибочного restic forget --prune. Независимый второй репозиторий со своим индексом и своим расписанием удаления от этого защищён: авария на одной стороне не доезжает до другой. Схема с двумя независимыми репозиториями и разными политиками хранения описана в разборе двух репозиториев restic.

Как отрепетировать восстановление

Репозиторий, из которого ни разу не восстанавливали, это гипотеза. Одна репетиция превращает её в факт и показывает пробелы, пока они ничего не стоят.

Перед бэкапом снимите контрольные суммы источника.

cd /srv/data
find . -type f -print0 | xargs -0 sha256sum > /srv/manifest.sha256

Потом восстановите всё на чистую машину и сверьте.

mkdir -p /var/tmp/restore-test
restic -r sftp:u123456@storage.example.com:/srv/restic restore latest --target /var/tmp/restore-test
cd /var/tmp/restore-test/srv/data
sha256sum -c /srv/manifest.sha256

sha256sum -c должен вывести OK для каждой строки и завершиться с кодом 0. Любое FAILED это либо повреждённый блок, либо файл, который менялся во время бэкапа. Второе типично для баз данных: снимок файла работающей СУБД восстанавливается, но открывается с ошибкой, потому что бэкап поймал середину транзакции. Лечится дампом перед копированием, а не настройками restic.

Для быстрой выборочной проверки удобнее смонтировать репозиторий, если на машине есть FUSE.

mkdir -p /mnt/restic
restic -r sftp:u123456@storage.example.com:/srv/restic mount /mnt/restic

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

Чек-лист на неделю

1. Найдите данные, которые лежат не в репозитории restic или Borg, и перенесите их туда.
2. Выполните restic check --read-data-subset=10% и запишите, сколько времени это заняло.
3. Снимите объём командой restic stats --mode raw-data и посчитайте часы выгрузки по своей реальной скорости.
4. Создайте зашифрованную копию пароля и сразу расшифруйте её обратно для проверки.
5. Положите эту копию туда, где нет ни аккаунта провайдера, ни почтового ящика этого аккаунта.
6. Заведите второй репозиторий у другого провайдера и запустите первый restic copy.
7. Восстановите один каталог на чистую машину и сверьте контрольные суммы.
8. Запишите адреса репозиториев, места хранения ключей и порядок действий в файл на десять строк и держите его вместе с ключами.

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

FAQ

Что делать, если аккаунт у провайдера уже заблокирован, а данные внутри?

Сначала проверьте, отвечает ли ещё SSH или SFTP. Блокировка биллинга часто гасит веб-панель, но оставляет сам сервер работать до конца оплаченного периода. Если доступ есть, немедленно запускайте выгрузку через rclone sync или restic copy на любую машину со свободным местом, начиная с самых важных путей. Если доступа нет, остаётся переписка с поддержкой, и её исход вам не подконтролен. Именно поэтому вторая копия делается заранее.

Где хранить пароль от репозитория restic?

Не в том аккаунте, где лежат данные, и не в почтовом ящике, на который этот аккаунт зарегистрирован. Рабочая схема: файл с правами 600 на машине, которая делает бэкапы, зашифрованная копия (age -p) на носителе вне облака и бумажная распечатка в физическом месте. У restic нет восстановления пароля: без парольной фразы мастер-ключ не расшифровывается, и репозиторий остаётся набором случайных байтов.

Сколько времени займёт выгрузка терабайта?

По арифметике на 100 Мбит/с выходит примерно 22 ч, на 10 Мбит/с примерно 222 ч. Это нижняя граница, посчитанная для полной загрузки канала. Реально закладывайте от 60 до 70 процентов паспортной скорости, потому что мешают задержка, число потоков и диски на стороне провайдера. Измерьте своё значение: восстановите один каталог под time и разделите объём на секунды.

Достаточно ли скопировать репозиторий на второй сервер через rclone?

Это лучше, чем ничего, но зеркало повторяет и ошибки. Повреждённый блок, случайный restic forget --prune или удаление снимков доедут до копии при следующей синхронизации. Независимая вторая копия делается командой restic copy в отдельный репозиторий со своим индексом и своим расписанием удаления, тогда авария на одной стороне не переносится на другую.

Нужен ли план выхода, если провайдер надёжный?

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