Почему бэкап загрузился, а восстановление не заканчивается

Копирование в S3 завершилось успешно, но восстановление виртуальной машины из Proxmox Backup Server останавливается с error reading a body from connection? Это означает, что программа не смогла полностью прочитать тело HTTP-ответа. По одной этой строке нельзя определить, повреждена ли резервная копия: нужно установить, кто оборвал передачу и на каком участке.

Восстановление проходит по цепочке S3 → PBS → Proxmox VE → диск восстановленной ВМ. Проверяйте её по журналам обеих систем. При ошибках чтения S3 сначала проверьте состояние сервиса и ограничения его API, затем повторите попытку с ограничением нагрузки на S3 endpoint. Если требуется отделить загрузку из облака от восстановления ВМ, синхронизируйте нужную копию в обычный локальный datastore — хранилище резервных копий PBS — и восстанавливайте уже оттуда.

Успешная запись не проверяет весь этот путь. Инкрементальный бэкап может отправить сравнительно мало новых данных, а восстановление потребует прочитать множество ранее сохранённых блоков — chunks. Ошибка способна проявиться только на большом диске или при длительном чтении.

Для какой схемы подходит инструкция

Ниже рассматривается штатный S3 backend PBS: объектное хранилище подключено через S3 endpoint — настройку доступа к API хранилища, а datastore использует его вместе с локальным кэшем. В PBS 4.2 поддержка S3 вышла из статуса technology preview. Ограничение количества S3-запросов появилось в PBS 4.2.4; в старых версиях соответствующего параметра может не быть.

Если каталог обычного datastore загружается в облако через rclone или S3 подключён как файловая система через FUSE, порядок восстановления другой. Сначала нужно получить согласованную полную копию datastore средствами этой схемы. Настройки штатного S3 endpoint не управляют rclone и сторонними шлюзами.

Что сделать до следующей попытки

1. Зафиксируйте нужную копию. Запишите datastore, namespace (пространство имён), тип и ID гостя, дату snapshot — точки восстановления. В PBS откройте Datastore → Content и включите защиту выбранного snapshot от удаления. Защита в PBS не отменяет правила автоматического удаления объектов у S3-провайдера.
2. Сохраните журналы неудачного восстановления. Нужны время с часовым поясом, задача восстановления PVE и связанная задача чтения PBS. Не ограничивайтесь последней строкой restore failed.
3. Подготовьте отдельное место для проверки. Восстанавливайте под свободным VMID, на хранилище с достаточным запасом, без автоматического запуска. Перед первым запуском отключите сетевые интерфейсы или подключите их к изолированной сети.
4. Проверьте ключ шифрования. Если резервная копия зашифрована на стороне клиента, нужен исходный ключ. Пароль S3 и новый ключ PBS его не заменяют.

Не удаляйте рабочую ВМ ради повторного теста. Не очищайте вручную .chunks и содержимое bucket. Удаление объектов может затронуть сразу несколько копий, которые используют общие chunks.

Как найти участок, на котором обрывается восстановление

На PBS от имени root сохраните версии пакетов:

proxmox-backup-manager versions --verbose

На узле Proxmox VE, где выполняется восстановление:

pveversion -v

Откройте полный журнал задачи Restore в PVE и журнал соответствующей задачи в PBS. Дополнительно на PBS посмотрите сообщения сервиса за время ошибки. В примере выбрано последнее двухчасовое окно; для давнего сбоя задайте нужные дату и время:

journalctl -u proxmox-backup-proxy --since "2 hours ago" --no-pager
journalctl -k --since "2 hours ago" --no-pager

Первый журнал помогает увидеть ошибки обращения к S3. Второй — нехватку памяти, сбои диска и файловой системы. Сопоставляйте записи по времени: сообщение на PVE может быть следствием более раннего сбоя на PBS.

Если одновременно падают Verify на PBS и Restore на PVE с одинаковой ошибкой S3, сначала исследуйте участок PBS → S3. Если PBS читает без ошибок, а PVE сообщает об отказе записи на целевой диск, начинайте с хранилища PVE. Строка reader finished successfully в журнале PBS ещё не означает, что задача восстановления ВМ завершилась успешно.

Для старой установки запланируйте обновление пакетов PBS и клиента PVE из штатных репозиториев вашей ветки, сохранив конфигурацию и доступ к консоли. В обработке S3 уже исправлялись ошибки, но отдельный патч для Verify не обязательно меняет поведение Restore. Обновление не устраняет недоступность объекта или аварию провайдера: после него всё равно нужен повторный тест.

Какие ограничения менять: скорость чтения и количество запросов

Лимит скорости в окне восстановления PVE управляет не тем же участком, что настройки S3 endpoint. PBS может продолжать обращаться к объектному хранилищу иначе, чем предполагает ограничение на стороне получателя.

В обсуждении февраля 2026 года пользователь с PBS 4.1.2 и Backblaze B2 восстанавливал небольшой диск, но получал сбой на диске объёмом 4 ТБ. Увеличение ресурсов и кэша не завершило восстановление. После ограничения скорости именно на S3 endpoint примерно до 50 МБ/с пользователь сообщил об успехе; операция заняла 32 часа. Это результат одной конфигурации, а не универсальная настройка.

На время диагностического запуска оставьте одно восстановление и перенесите конкурирующие задания Verify, Sync и другие интенсивные обращения к тому же S3. В PBS откройте Configuration → Remotes → S3 Endpoints, выберите используемый endpoint и запишите исходные ограничения.

Сначала ограничьте загрузку из S3. Например, следующий тестовый лимит составляет 50 MiB/s, то есть 50 мебибайт в секунду. Замените my-s3 на ID своего endpoint:

proxmox-backup-manager s3 endpoint update my-s3 --rate-in 50MiB

Повторите восстановление того же snapshot. Если оно завершилось, настройка дала рабочий результат для этой нагрузки. Если только продвинулось дальше прежней точки, причина ещё не считается устранённой.

Когда ограничение полосы не помогает, проверьте лимит запросов. Множество небольших объектов может создавать высокую частоту обращений даже при скромной скорости передачи. В PBS 4.2.4 и новее есть общий лимит для пассивных запросов GET и HEAD:

proxmox-backup-manager s3 endpoint update my-s3 --limit-passive-requests 100

100 — пример диагностического значения, не рекомендация для любого провайдера. Выбирайте его с учётом квот и остальных клиентов того же аккаунта. rate-in ограничивает байты в секунду, а limit-passive-requests — запросы в секунду. rate-out относится к отправке данных в S3.

Меняйте по одному параметру и проверяйте итог задачи. Настройки endpoint могут повлиять и на другие datastore, которые используют его. После диагностики верните записанные значения. Если оба ограничения до теста отсутствовали, их можно удалить:

proxmox-backup-manager s3 endpoint update my-s3 --delete rate-in --delete limit-passive-requests

Откройте настройки повторно и убедитесь, что сохранено ожидаемое состояние. В обсуждении PBS 4.2.4 пользователи обнаружили ошибку, при которой очистка поля лимита через интерфейс не удаляла значение.

Если сбой повторяется и при очень низкой нагрузке, продолжать уменьшать скорость бессмысленно без новых данных. В другом случае августа 2026 года даже лимит 10 запросов в секунду не убрал ошибку. Автор затем сообщил, что Wasabi подтвердил замедление хранилища во время работ.

Должен ли кэш PBS вмещать всю виртуальную машину

Нет. У штатного S3 datastore локальный каталог содержит метаданные, сведения о chunks и кэш данных. ВМ может быть больше этого кэша. В документации PBS рекомендуется ориентир 64–128 GiB для локального кэша, но требуемый объём зависит от числа копий, метаданных и нагрузки.

На PBS найдите путь datastore и проверьте файловую систему. Имена ниже условные: в командах df используйте значение поля path своей конфигурации.

proxmox-backup-manager datastore show s3-store
df -h /mnt/pbs-s3-cache
df -i /mnt/pbs-s3-cache

Первый df показывает место, второй — доступность inode на файловых системах с соответствующим ограничением. Это структуры учёта файлов: свободные гигабайты не помогут, если создавать новые файлы уже нельзя. При исчерпании места или inode расширьте хранилище либо освободите место за счёт заведомо посторонних данных; не удаляйте chunks вручную.

Сообщение found empty chunk ... overwriting для штатного S3 datastore может быть нормальным: PBS оставляет пустой файл-маркер после вытеснения chunk из кэша и снова заполняет его при загрузке. Само по себе оно не доказывает потерю данных в S3. Это объяснение нельзя переносить на пустые chunks обычного локального datastore.

Увеличивайте RAM при подтверждённой нехватке памяти, а кэш — при выявленной нехватке места или требованиях к производительности. Произвольное увеличение ресурсов не исправляет HTTP 504 на стороне объектного хранилища.

Что покажет Verify и почему его недостаточно

В PBS откройте Datastore → Content, найдите нужный snapshot и запустите его проверку через действие Verify. Проверьте журнал: должно выполняться чтение данных, а не только пропуск ранее проверенной копии. В заданиях Verify за это отвечает настройка Ignore verified.

Проверка штатного S3 datastore обращается к S3 в обход локального кэша. Поэтому успешный Verify нельзя автоматически объяснить тем, что данные уже лежали на PBS. Однако он проверяет доступность и целостность резервных данных в момент запуска. Он не проверяет весь путь восстановления, загрузку ОС и работоспособность приложения.

Результат трактуйте так:

• Verify завершился с ошибкой чтения S3. Сначала решайте проблему доступа или передачи. Не объявляйте копию повреждённой только по сетевой ошибке.
• Повторяется ошибка целостности одного объекта. Сохраните его идентификатор, исключите неполное чтение и проверяйте независимую копию.
• Verify успешен, Restore падает. Сравните время, нагрузку, путь передачи и ошибки записи на PVE. Следующий полезный тест — восстановление через локальный datastore.

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

Как сначала скачать копию в локальный datastore PBS

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

Локальный datastore и кэш S3 — разные вещи. Для локального datastore нужны все chunks выбранных копий и метаданные. Размер последнего инкрементального бэкапа не показывает, сколько места потребуется. При отсутствии точного расчёта планируйте место исходя из полного объёма выбранных дисков с запасом. Отдельно требуется место на PVE для восстановленных дисков.

Ниже пример для одного PBS: исходный S3 datastore называется s3-store, ВМ имеет ID 100, snapshot находится в корневом namespace. Локальный datastore будет называться restore-local. Все команды выполняются на PBS от root. Один и тот же S3 datastore нельзя одновременно подключать к двум активным PBS.

1. Подготовьте отдельный смонтированный диск или файловую систему. В примере точка монтирования — /mnt/restore-disk:

findmnt /mnt/restore-disk
df -h /mnt/restore-disk

Убедитесь, что отображается именно выделенное хранилище и оно доступно для записи. Если findmnt не показывает ожидаемое монтирование, остановитесь: иначе данные могут попасть на системный раздел PBS. В новом пустом каталоге создайте обычный datastore:

proxmox-backup-manager datastore create restore-local /mnt/restore-disk/pbs-restore

2. Создайте разовое задание локальной синхронизации:

proxmox-backup-manager sync-job create recover-vm100 \
  --remote-store s3-store \
  --store restore-local \
  --group-filter group:vm/100 \
  --max-depth 0 \
  --transfer-last 1 \
  --remove-vanished false

proxmox-backup-manager sync-job run recover-vm100

Здесь --remote намеренно отсутствует: источник находится на том же PBS. --remote-store задаёт источник, --store — получателя. Автоматическое удаление копий получателя отключено, расписание не задано.

Ограничение примера: --transfer-last 1 переносит последний snapshot группы. Для более старой даты увеличьте число до нужной глубины или уберите этот параметр, чтобы перенести группу целиком; заранее пересчитайте место. Для контейнера замените фильтр на group:ct/100. Если источник находится, например, в namespace production, добавьте --remote-ns production; без --ns получатель остаётся в корневом namespace.

3. Проверьте не только статус задания, но и результат. В restore-local → Content должен появиться нужный ID и правильная дата snapshot. Успешное задание с нулём подходящих групп не означает, что копия загружена: исправьте namespace или фильтр и повторите запуск.

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

proxmox-backup-manager verify restore-local --ignore-verified false

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

4. Подключите локальный datastore к PVE. В Datacenter → Storage → Add → Proxmox Backup Server задайте новый Storage ID, адрес этого PBS и datastore restore-local. Сверьте fingerprint сертификата PBS. В PBS через Configuration → Access Control → Permissions выдайте учётной записи PVE права чтения нового хранилища: например, роль DatastoreReader на /datastore/restore-local. При использовании API token проверьте разрешения и пользователя, и токена.

Если исходная копия зашифрована, в настройках нового подключения импортируйте соответствующий исходный ключ. На исходном PVE ключ обычно находится в /etc/pve/priv/storage/<STORAGE-ID>.enc. Не генерируйте новый вместо утраченного. Сохраните исходный ключ отдельно от узла, который восстанавливаете.

Выберите загруженный snapshot на новом хранилище PVE и выполните обычное полное восстановление под свободным VMID. Для диагностического запуска оставьте Live Restore и автоматический запуск выключенными. После успешной синхронизации чтение этой локальной копии уже не зависит от S3.

Не заменяйте Sync копированием каталога S3-кэша в обычный datastore: в кэше могут находиться только метаданные, маркеры и часть данных.

Что делать, если ограничения и локальная синхронизация не помогают

При повторных 5xx или разрывах чтения проверьте статус S3-провайдера и наличие собственного proxy, VPN или шлюза между PBS и S3. Если такой посредник есть, выполните разрешённый тест по прямому маршруту. TLS-проверку при этом не отключайте.

Когда известен точный проблемный объект, полезно проверить его полное скачивание с самого PBS. Условный пример для уже установленного AWS CLI и заранее настроенного профиля pbs-check с теми же правами чтения:

aws --profile pbs-check \
  --endpoint-url https://s3.example.net \
  s3api get-object \
  --bucket YOUR_BUCKET \
  --key 'EXACT_OBJECT_KEY' \
  /mnt/restore-disk/s3-object-test.bin

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

Если полная загрузка тоже обрывается, проблема воспроизводится вне механизма восстановления PBS. Передайте провайдеру время, Request ID, регион, ключ объекта и ошибку. Если скачивание проходит, это ещё не доказывает ошибку PBS: одиночный запрос отличается от длительной нагрузки восстановления. Сравнивайте условия и журналы. Успешный HEAD или просмотр списка объектов не заменяет полную загрузку.

При подтверждённом NoSuchKey выясните, не удалило ли объект lifecycle-правило и доступна ли его прежняя версия или другая резервная копия. При переходе объекта в архивный класс может потребоваться предварительное извлечение по правилам провайдера. Один потерянный chunk способен затронуть несколько snapshot. Снижение скорости и повторный Verify не создадут утраченные данные.

В обращение в поддержку приложите версии PBS/PVE, точное время с часовым поясом, размер гостевой системы, дату snapshot, журналы обеих задач, применённые лимиты и результат одиночного чтения. Не отправляйте secret key S3, пароли и ключи шифрования бэкапов.

Сколько времени, места и трафика потребуется

Для грубой оценки делите фактически скачиваемый объём на измеренную устойчивую скорость. Например, передача 1 TiB при непрерывных 50 MiB/s занимает около 5 часов 50 минут. Это расчёт только передачи: проверки, задержки API, повторные запросы, обработка chunks и запись восстановленной ВМ увеличат общее время.

Уточните у S3-провайдера оплату исходящего трафика, GET/HEAD и извлечения из архивных классов. Повторные Verify и Restore могут снова читать данные из облака. Для схемы с предварительной загрузкой добавьте стоимость локальных дисков и время синхронизации. Если свободного места нет, используйте другую площадку для локального datastore или устраняйте причину сбоя прямого восстановления; не освобождайте место удалением единственной рабочей системы.

Для отдельного PBS и локального хранения копий можно подобрать выделенный сервер HSTQ. При подборе укажите полный объём копий, требуемое время восстановления и направление передачи из S3. Объём дисков, условия трафика и состав администрирования нужно согласовать под эту схему; администрирование у HSTQ оформляется дополнительной услугой.

Как убедиться, что восстановление действительно работает

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

• Проверен конкретный snapshot с нужной датой, а не случайная маленькая копия.
• Полное восстановление в PVE завершилось успешно; нет непрочитанных дисков и необъяснённых предупреждений.
• ВМ или контейнер запущены в изолированной сети. Проверены файловая система, нужные файлы, база данных и само приложение.
• Восстановление зашифрованной копии выполнено с ключом из отдельно сохранённого резервного комплекта.
• Измеренное время укладывается в допустимый простой, а расходы на такую операцию понятны.

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