Это заразно видимо

Мамой клянусь последняя )

Но проверю

Подскажите, пожалуйста, что можно сделать с расписанием в таком раскладе:
VBR 9.5
Есть около 20 джобов, запускающихся в ночное время каждый день. В разные дни для них задано создание active и synthetic full.
Есть кассетная джоба, которая собирает последний фулл с репозитория. Она длится 3..5 дней.
Так получается, что после успешной записи некоего фулла на кассету, до полного завершения кассетной джобы, успевает появиться ещё один фулл (как правило, у более, чем 1 дисковой), который тоже начинает писаться на кассету, продлевая tape job, и давай время появиться новым синтетик/актив бэкапам.
Как соскочить с этого цикла?
Боюсь, сдвиг всех синтетиков на один день может сильно просадить NTFS-ный репозиторий (DAS).

писать на ленту GFS?

или обновить ленту до LTO8/9, чтобы скорость записи была выше?

а упор во что?

Серьёзно? Это где-то так работает: просто переделай половину инфраструктуры, чтобы  исправить небольшой косяк? Может, лучше винду везде переустановить?

Сделать больше ленточных заданий поменьше размером :)

Может у него привод один

инфраструктуру не переделать... сказано же:)

Да, привод один, железо/retention policy менять нельзя, так как это не в нашей компетенции (организационно и финансово)

Так пусть один, если задания сделать короче, то цепочки из них выстроить проще. По расписанию или линковкой.

Уменьшить размер резервных копий путём повышения компрессии, тоже вариант

правда и скорость РК может понизиться

и на последок - параллельный процессинг - https://helpcenter.veeam.com/docs/backup/hyperv/parallel_processing.html?ver=110

Понял, спасибо.

не переделать, а обновить, и это вполне логичное решение, что бы инфраструктура соответствовала требованиям бизнеса

Я со стороны компании-аутсорсера, поэтому вопросы обновления идут параллельно решению текущих кейсов.

а оно именно в лент упирается?