+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Сбои восстановления, Proxmox Backup Server

DaveRR5

Guest

19.07.2020 12:15:00

Всем привет! Пытаюсь восстановить виртуальную машину, но операция не удалась, при этом на сервере PVE выдалось следующее сообщение.

Форматирование '/DataStore/images/103/vm-103-disk-0.raw', fmt=raw, размер=80530636800, новый ID тома — 'DataStore:103/vm-103-disk-0.raw'
Форматирование '/DataStore/images/103/vm-103-disk-1.raw', fmt=raw, размер=107374182400, новый ID тома — 'DataStore:103/vm-103-disk-1.raw'

Восстановление образа резервной копии Proxmox:
/usr/bin/pbs-restore --repository root@pam@pbs1:USB-Backup vm/103/2020-07-14T23:08:12Z drive-sata0.img.fidx /DataStore/images/103/vm-103-disk-0.raw --verbose --format raw --skip-zero

Подключение к хранилищу 'root@pam@pbs1:USB-Backup'
Открытие блочного устройства для цели '/DataStore/images/103/vm-103-disk-0.raw'
Начинаю восстановление снимка 'vm/103/2020-07-14T23:08:12Z'
Загрузка и проверка индекса резервной копии

Прогресс 1% (прочитано 805306368 байт, нулей 59% (482344960 байт), прошло 9 сек)
Прогресс 2% (прочитано 1610612736 байт, нулей 30% (499122176 байт), прошло 48 сек)
Прогресс 3% (прочитано 2415919104 байт, нулей 20% (499122176 байт), прошло 87 сек)
Прогресс 4% (прочитано 3221225472 байт, нулей 15% (499122176 байт), прошло 125 сек)
Прогресс 5% (прочитано 4026531840 байт, нулей 12% (499122176 байт), прошло 150 сек)
Прогресс 6% (прочитано 4831838208 байт, нулей 10% (499122176 байт), прошло 181 сек)
Прогресс 7% (прочитано 5637144576 байт, нулей 8% (499122176 байт), прошло 231 сек)
Прогресс 8% (прочитано 6442450944 байт, нулей 7% (499122176 байт), прошло 288 сек)
Прогресс 9% (прочитано 7247757312 байт, нулей 6% (499122176 байт), прошло 323 сек)
Прогресс 10% (прочитано 8053063680 байт, нулей 6% (499122176 байт), прошло 357 сек)
Прогресс 11% (прочитано 8858370048 байт, нулей 5% (499122176 байт), прошло 386 сек)

Восстановление не удалось: blob слишком мал (0 байт).
Временный том 'DataStore:103/vm-103-disk-1.raw' успешно удалён
Временный том 'DataStore:103/vm-103-disk-0.raw' успешно удалён

ОШИБКА ЗАДАЧИ: команда '/usr/bin/pbs-restore --repository root@pam@pbs1:USB-Backup vm/103/2020-07-14T23:08:12Z drive-sata0.img.fidx /DataStore/images/103/vm-103-disk-0.raw --verbose --format raw --skip-zero' завершилась с кодом 255

Я запустил проверку с PBS-сервера и получил ту же ошибку:
2020-07-19T11:01:21+01:00: verify USB-Backup:vm/103/2020-07-18T23:14:52Z
2020-07-19T11:01:21+01:00: check qemu-server.conf.blob
2020-07-19T11:01:21+01:00: check drive-sata0.img.fidx
2020-07-19T11:02:04+01:00: verify USB-Backup:vm/103/2020-07-18T23:14:52Z/drive-sata0.img.fidx failed: blob слишком мал (0 байт).

Можно ли скачать виртуальные диски и импортировать их вручную? Любая помощь очень ценится. Спасибо!
Дэйв

fabian

Guest

10.08.2020 08:30:00

@Jarvar, не мог бы ты предоставить больше информации о своей конфигурации (аппаратное обеспечение, хранилище, файловая система). Было бы интересно посмотреть логи примерно за то время, когда произошёл "сломанный" бэкап. Проблемы возникают только со старыми резервными копиями или с некоторыми, сделанными после последнего обновления пакета PBS?

Jarvar

Guest

13.08.2020 04:14:00

@fabian Моя настройка почти такая же, как у @luphi. Я сделал vzdump и скопировал его локально, чтобы также создать резервную копию на PBS, но получил ту же ошибку — blob слишком маленький. Другие мои бэкапы не виртуальных машин работают, а вот Windows Server 2016 не получается. Думаю, может, дело в дисках, которые у меня виртуальные. Один системный диск на 32 ГБ, два — DS1 и DS2. Я добавил третий USB-диск, проброшенный в PBS VM, примерно на 3,7 ТБ, сейчас делаю бэкап на него, посмотрю, изменится ли что, потому что это не виртуальный диск, а внешний. DS1 и DS2 отформатированы в EXT4, по 200 ГБ каждый. USB-диск тоже отформатировал как DS3 в EXT4. У меня Dell R340 с процессором E-2174G, 32 ГБ ECC ОЗУ без буфера, два SSD по 240 ГБ в RAID 1 на ZFS и два SSD по 960 ГБ в RAID 1 тоже на ZFS для хранения и виртуальных машин. Кроме того, всё подключено к NFS-серверу от Synology для хранения виртуальных машин и бэкапов.

Jarvar

Guest

13.08.2020 05:21:00

Обновление. Я сделал резервную копию из своей локальной сети, используя скачанный удалённый бэкап, и проверка прошла успешно. Теперь я собираюсь попробовать сделать инкрементальный бэкап с удалённого места. Образ, который у меня был, на пару дней устарел, так что на синхронизацию уйдёт время. Что касается внешнего USB, подключённого к PBS VM, локальный бэкап сработал, и проверка тоже прошла. Удалённый бэкап сейчас в процессе...

Jarvar

Guest

06.09.2020 18:02:00

У меня были несколько недель без ошибок. Однако для одной конкретной ВМ снова появилась ошибка "Blob too small". Я вернулся к последнему бэкапу ВМ без ошибок и удалил те, где были ошибки. Запустил резервное копирование с опцией Stopped — ошибка осталась. Странное поведение, потому что на другом узле, который я тоже бэкапил, возникла похожая проблема, и я её решил таким же способом... Есть идеи? Заранее спасибо.

fabian Guest	#6 0 07.09.2020 07:26:00 Ты подождал день и запустил сборщик мусора между удалением снимков и повторной попыткой создания резервной копии?

Jarvar

Guest

07.09.2020 15:17:00

@fabian Я этого не делал. Нужно ли? Я пытаюсь понять, как всё работает. Допускаю, что иногда каждая последующая резервная копия может использовать некоторые файлы из предыдущей, если считает, что изменений значимых нет. В логе указано:
107: 2020-09-07 02:30:24 INFO: резервная копия разреженная: 911,76 ГиБ (81%) всего нулевых данных
107: 2020-09-07 02:30:24 INFO: резервное копирование проходило инкрементально, повторно использовано 1,06 ТиБ (96%)
107: 2020-09-07 02:30:24 INFO: передано 1,09 ТиБ за 11532 секунды (99,2 МиБ/с)
107: 2020-09-07 02:30:24 INFO: резервное копирование ВМ 107 завершено (03:12:36)

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

Стоит ли ждать целые 24 часа между попытками?
Большое спасибо!

fabian

Guest

08.09.2020 07:29:00

Почти. Нужно сделать очистку/забыть, затем подождать 24 часа, потом выполнить GC, а после этого сделать резервное копирование. Смотрите документацию: https://pbs.proxmox.com/docs/administration-guide.html#id2. Сейчас мы внедряем механизм для пометки повреждённых чанков, чтобы клиент мог заново загрузить правильные, вместо того чтобы пропускать их — тогда эта «танцевальная» процедура больше не понадобится.

toomanylogins Guest	#9 0 14.07.2022 18:35:00 У меня была такая ошибка. Проверил резервную копию, которая пометила блоки как повреждённые. Запустил другую резервную копию. Проверка прошла успешно. Восстановление тоже прошло нормально. Спасибо.

toomanylogins Guest	#10 0 03.12.2024 17:54:00 У меня такая проблема. Я проверяю резервную копию на pbs, но есть ли способ восстановить гостевую ВМ, если сейчас отсутствует конфигурация?

fabian Guest	#11 0 04.12.2024 08:30:00 Что именно ты называешь «этой проблемой»? Если твоя резервная копия повреждена, то её невозможно восстановить обычными способами.

Jarvar

Guest

#12

02.08.2020 17:57:00

У меня тоже эта проблема с blob. Не получается восстановить бэкап виртуальной машины Windows Server 2019 Standard, который занимает 1.17 TiB. С другой стороны, у меня есть Debian VM размером 32 GiB, которую восстанавливает без проблем. Также запускаю задачу проверки на сервере PBS.

Jarvar Guest	#13 0 07.08.2020 20:26:00 Есть ли какие-то новости? Если проверка не пройдет, можно ли как-то это исправить? Или просто удалить эти бэкапы и начать заново? Важно ли, какой тип бэкапов — Snapshot, Suspend или Stop — для инкрементальных виртуалок? Спасибо.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры