Никак.
Это копия файлов базы.
Никакого "norecovery" - просто копия.
Как если ты остановил сервер и скопировал."Бакап виртуалки" тут условно называют.
Понятно, что копия файлов цепочку не прервёт, но она и следов в msdb, в backupset и backupmediafamily, не оставит.

Я не знаю, что именно прерывает цепочку, может, что то из систем виртуализации, или виндовый системный бакап, или какая то купленная система бакапирования, но бакап, сделанный через VSS, с backupset.is_copy_only = 0, сделанный для базы ТС - это факт. И это конечно не бакап, который автор делает в скрипте или плане обслуживания.
Вот с ним ТС и надо разбираться. Скажем, смотреть всякие журналы, опираясь на время в backupset.

Проблема же не в цепочке в msdb. Иначе всё бы легко решалось её редактированием.
Проблема в том, что в файлах данных БД в поле differential_base_lsn записан не тот LSN, который записан в файле бакапа

А записала его наверняка та самая программа, которая сделала запись в msdb.
Впрочем, это неважно, записи в msdb нужны, только что бы заполнить окошечки в SSMS, так то команда restore database и её подобные msdb не пользуются (что должно быть понятно даже тем, кто ни разу не имел дело с MSSQL, ведь бакапы, полные, дифф, логи, можно восстановить на новом инстансе, на котором msdb пустая)


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

Там же всё по LSN бъётся.

Или сами разберитесь:
Выполните запрос

где C:\tmp\db1.bak - имя файла вашего дифф бакапа, и сравните LSN, кто за кем стоял.
Ну и для других файлов, которые вам интересны.
И увидите, коррелируют ли LSN из файлов полного бакапа, дифф бакапов, LSN из "виртуального" бакапа, и из других записей из запроса.
И в какой момент эта корреляция сбилась.
Там идёт строгая цепочка LSN, "сдал-принял", всё понятно будет.

Само собой, если запись о виртуальном бакапе не оставляет LSN прежним, то это не какая то там "фейковая запись, а на самом деле копирование чего то постороннего", а полноценный бакап, со всеми вытекающими (в том числе с вытекающими из copy_only=0).

Ой, а в документации врут, похоже?
Что же означают опции -vssFull и -vssCopy, интересно? И не поставил ли случаем админ у D.NeeZ_K опцию -vssFull, не понимая её смысла (Full же побогаче будет, поставлю её :-) )?

Не понял фразу, что вы имеете в виду?

Я писал про две опции запуска утилиты. Запуск с правильной опцией перестал разрывать цепочки, или нет? Что после запуска с правильной опцией показывает скрипт ?

Нашёл, что можно сиквелу принудительно указать, что бы он не делал полные бакапы для wbadmin, либо что бы тот обходил сиквел стороной:
So we found two solutions.
1. Stop and disable the SQL writer service. With this VSS will not able to take the SQL server database backup but still takes the VM backup.
2. Add below registry key [HKEY_LOCAL_MACHINESOFTWAREMICROSOFTBCDRAGENT]
"USEVSSCOPYBACKUP"="TRUE" This will force the VSS to take COPY_ONLY backup which will not break the backup chain
https://www.sqlservercentral.com/blogs/ghost-is-taking-full-backup-and-breaking-my-backup-chain-be-careful-with-azure-vm-backup-on-vm-having-sql-server-installation