Верно, но тогда ещё и живая миграция и перенос дисков ломаются, так что это был бы довольно серьёзный баг в qemu. Да и нет. Если вы проверяете свои бэкапы (а делать это стоит хотя бы время от времени), снимок, ссылающийся на повреждённый кусок, будет помечен как «не прошёл проверку», и битовая карта очистится. Дальше возможно два варианта:
- текущие данные по-прежнему содержат этот кусок, а повреждение будет исправлено при следующем бэкапе;
- текущие данные больше не содержат этот кусок (исходные данные изменились), повреждение уже нельзя исправить, но оно и не актуально для этого или будущих снимков.
Как видите, в этом случае вы не теряете данные, только те снимки, которые обращаются к повреждённому куску без проверки между попытками создания снимков, пострадают. Если не проверять, PBS пока не знает о повреждении.
Независимо от того, используется ли битовая карта или нет, новый снимок тоже будет повреждён, если повреждённый кусок по-прежнему входит в активный набор:
- с битовыми картами данные не читаются, если не изменялись, поэтому повреждение распространяется;
- без битовой карты (например, при резервном копировании в режиме остановки) клиент всё равно получит такой же хэш для куска и не загрузит его, а только «зарегистрирует» на сервере, так как такой кусок уже есть.
В этом случае вы теряете данные, потому что ни клиент, ни сервер не знают о повреждении и не могут с этим справиться. Даже если вы сделали (с точки зрения клиента) не инкрементальный бэкап (например, в другой namespace или в новую группу, чтобы не было предыдущих снимков), сервер может отбросить загруженный кусок, если существующий повреждённый кусок того же размера (например, повреждение — это перевёрнутый бит). Только если повреждение — это усечение или что-то, из-за чего размер не совпадает, загруженный кусок перезапишет существующий, и повреждение будет исправлено.
Итак, чтобы избежать всех этих проблем, нам нужно реализовать:
- способ заставить делать полностью полный бэкап, включая перезапись существующих кусков на сервере;
итог будет эквивалентен проверке, а затем выполнению инкрементального бэкапа без битовой карты, только при этом будет гораздо больше сетевого трафика (PVE -> PBS) и операций записи (PBS).
Поэтому, на мой взгляд, единственное, что имеет смысл — это какой-то чекбокс «очистить битовую карту» (заметьте, что вроде как уже есть возможность управлять битовыми картами через QMP, и вы можете написать хук-скрипт, который очищает битовую карту по любым нужным критериям, например, если сегодня воскресенье). Цель этого чекбокса — дать возможность понизить «быстрый инкрементальный» бэкап до «обычного инкрементального» в случае, если вы не доверяете отслеживанию изменённых блоков.
Вот тут @aaron сказал «все бэкапы — полные бэкапы», что можно переформулировать как «все снимки равны». Нет никакого отслеживания (кроме битовой карты qemu) или применения изменений, потому что на стороне PBS нет «изменений». Единственное отличие между первым «полным» и последующими инкрементальными бэкапами происходит на клиенте:
Код:
// client_thinks_chunk_is_on_server — true, если битовая карта говорит, что не менялось
// или если мы прочитали, разбили на куски и получили хэш, который уже есть в последнем снимке этой группы
if (client_thinks_chunk_is_on_server) {
register_chunk_with_server();
} else {
upload_chunk_to_server(); // загрузка и регистрация на сервере
}
В итоге нет никакой разницы в метаданных снимков или кусках — PBS не делает «дифференциальных» бэкапов, как другие решения, где инкрементальные снимки нужно применять цепочкой, чтобы получить полный бэкап. «Цепочка» (или, скорее, возможное распространение повреждённого куска) происходит полностью прозрачно благодаря базе с дедупликацией кусочков и принципу работы инкрементальных бэкапов.
Единственное решение — это проверка, а её результат должен влиять на последующие бэкапы — что PBS уже и делает.
