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

[РЕШЕНО] грязные/новые битмапы, Proxmox Backup Server

tonci

Guest

03.01.2021 16:42:00

Я установил PBS и TrueNas как nfs-дейстор. Настройка прошла без проблем. Но после первого полного бэкапа второй — инкрементальный — начался с "создания новых битмапов": INFO: virtio0: dirty-bitmap status: created new INFO: virtio1: dirty-bitmap status: created new. Полный бэкап занял 16 часов, а этот инкрементальный — примерно 4 часа. Очевидно, что PBS должен проходить по всему образу виртуальной машины размером 1,5 ТБ... Скорость чтения примерно 100 МиБ/с, что не так уж и "плохо", но почему он не может переключиться на fast-increment?

После накопления опыта с комбинацией pbs/nfs я так и не смог понять, когда ожидать такой сценарий, а когда — нижеследующий:
INFO: virtio0: dirty-bitmap status: OK (88.0 МиБ из 15.0 ГиБ изменено)
INFO: virtio1: dirty-bitmap status: OK (352.0 МиБ из 250.0 ГиБ изменено)
INFO: virtio2: dirty-bitmap status: OK (48.0 МиБ из 32.0 ГиБ изменено)
INFO: используется fast incremental mode (dirty-bitmap), 488.0 МиБ изменено из 297.0 ГиБ всего

Здесь система "знает разницу заранее" и передаёт только её очень быстро... Как-то я заметил, что запущенные ВМ бэкапятся с dirty-битмапами, а выключенные — с new bitmaps...?! Или, может, я просто недостаточно тестов провёл...

В каких именно ситуациях dirty-bitmaps не могут быть применены?

Спасибо заранее.
С уважением, Tonci

Dunuin

Guest

11.08.2021 22:43:00

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

fitful Guest	#3 0 11.08.2021 22:49:00 Для формата qcow2 должно быть возможно хранить постоянную битовую карту, как указано здесь: https://qemu-project.gitlab.io/qemu/interop/bitmaps.html#bitmap-persistence

voarsh

Guest

09.06.2021 03:16:00

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

fitful

Guest

11.08.2021 22:26:00

Согласно документации qcow2, возможно получить постоянную карту грязных блоков для формата диска qcow2. Поэтому я скромно спрашиваю, есть ли планы по внедрению постоянной карты грязных блоков для формата qcow2 в Proxmox?

jonasled

Guest

19.05.2021 12:08:00

Есть ли способ сохранить bitmap постоянно, потому что у меня резервные копии хранятся вне офиса, и там ограничение по скорости до 50 Мбит. Было бы здорово, если бы существовало решение, которое синхронизирует только изменения по сети.

Cookiefamily

Guest

19.05.2021 14:41:00

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

jonasled Guest	#8 0 19.05.2021 14:43:00 А, понятно. Я думал, что всё снова будет передаваться заново. Тогда всё в порядке.

tonci

Guest

19.05.2021 14:56:00

Хорошо... он будет переносить только изменённые блоки, понял! Но если нужно снова создавать dirty-bitmap, как это происходит? Что он сравнивает? Исходник с конечной точкой или исходник с предыдущей dirty-bitmap? Если destination был перемещён в другое место и подключён через более медленное соединение, такое «сравнение» может занять много времени... Так что же реально происходит, когда мы выключаем и включаем виртуальную машину? Как это влияет на время и пропускную способность?

Cookiefamily

Guest

#10

19.05.2021 17:10:00

При резервном копировании данные разбиваются на 4 МиБ "кусочки". Эти кусочки называются по их контрольной сумме. Также создаётся индексный файл со всеми кусочками, используемыми в этой резервной копии. Когда система вычисляет контрольную сумму очередного кусочка для резервного копирования, она получает индексы тех резервных копий, которые ей известны (из других групп бэкапов индексы не берутся по причине конфиденциальности). Если контрольная сумма совпадает, кусочек не передаётся. Если нет — отправляется 4 МиБ кусочек. Да, передача контрольных сумм требует немного трафика, но совсем немного. Исправьте меня, если я ошибаюсь, @proxmox-Team.

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

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

fabian

Guest

#11

12.08.2021 09:22:00

Сохранение битмапа — это не проблема, проблема в том, чтобы он оставался валидным при повторном запуске ВМ. У нас нет контроля над тем, кто или что может получить доступ к тому объему и, возможно, изменить его между запусками, а любое изменение приведет к недействительной резервной копии (и из-за особенностей инкрементных бэкапов это будет распространяться, пока недействительный(е) участок(ки) не перестанут входить в резерв).

JamesT

Guest

#12

26.08.2021 05:14:00

Просто идея — что если хэшировать файлы ВМ, ставить флаг и при следующем запуске бэкапа проверять хэш с содержимым на диске? Сегодня хэширование больших файлов для простого сравнения не занимает слишком много времени (https://stackoverflow.com/questions...um-for-large-files-in-c-sharp/1177712#1177712), и даже если бы на хэширование большого диска ВМ уходило 5-10 или даже минут в начале и в конце задания бэкапа, я с радостью бы это принял, чтобы избежать 5-6 часов обработки из-за лишней потери dirty bitmap. У меня есть пара больших файловых серверов, которые могут обрабатываться почти 15 часов, когда я их выключаю и теряю dirty bitmap. Я понимаю, что по сети передаются только инкрементные данные, но проблема в длительном времени выполнения бэкапа. Было бы здорово сделать это опцией с предупреждением: «хэширование больших файлов дисков ВМ может занять много времени».

dcsapak Guest	#13 0 30.08.2021 10:50:00 Это не имеет смысла, ты теперь читаешь диск, чтобы не читать диск?

JamesT

Guest

#14

01.09.2021 02:56:00

Спасибо, что рассмотрели мою идею =) Я не совсем уверен, какой именно метод чтения диска использует задача резервного копирования, но, как я уже говорил, если теряется dirty bitmap, процесс может занять много часов. Тогда как простой MD5-хэш (как в ссылке, которую я отправлял) вычисляется за секунды для файла в 1 ГБ, и по этим данным можно примерно прикинуть, что для файла в 1 ТБ это займет около 16-20 минут.

Если брать MD5-хэш после выключения машины, а потом повторять его прямо перед запуском, то по разнице можно понять, изменилось ли содержимое диска виртуальной машины за это время. Если хэши совпадают, то dirty bitmap всё еще актуален. Конечно, такой способ подходит не всем, ведь для больших ВМ это добавит много минут к времени выключения и запуска. Но для меня и, возможно, для некоторых других это было бы очень удобно. Например, чтобы была опция: «Сброс | Перезагрузка | Выключение | Выключение – сохранить dirty bitmap (внимание — может добавить много минут)». Я редко выключаю свои ВМ и с удовольствием согласился бы на 15-20 минут при запуске и выключении, чтобы избежать 15-часовой обработки задания резервного копирования для больших файловых серверов.

dcsapak

Guest

#15

01.09.2021 09:01:00

Резервная копия просто читает диск для бэкапа кусками по 4 МБ, единственное «особенное» — она читает блоки, которые виртуальная машина собирается записать, не по порядку (если они ещё не сохранены), чтобы была согласованная версия. Так что для многих систем хранения данных это уже максимально быстрая скорость (чтение именно 4 МБ блоками), а чтение образа диска в начале просто переносит это время на более ранний этап.

Если у вас настройка занимает часы на бэкап без dirty bitmap, то и на хеширование уйдёт столько же, но если хотите, просто попробуйте: выполните команду
time sha256sum /path/to/disk/image
не забудьте очистить кэш страниц перед запуском и убедиться, что ВМ при этом не работает.

voarsh Guest	#16 0 16.09.2021 14:44:00 Думаю, смотреть, сколько времени занимает хеширование, бессмысленно, потому что оно не будет занимать столько времени каждый раз, когда запускается резервное копирование с грязными битмапами.

dcsapak Guest	#17 0 17.09.2021 08:15:00 Нет, так не будет, но суть этой темы была в том, чтобы сохранять dirty-bitmap для машин, которые выключились. В таком случае у нас нет способов точно узнать, остаётся ли bitmap валидным, кроме как пересчитать его и сравнить. @JamesT заявил, что будет быстрее сделать хеш в начале, чем читать диск в реальном времени во время резервного копирования.

Читают тему

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