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

речь идет о бэкапах около 800 баз, с сотни скулей, общий размер недельных бэкапов около 200 террабайт. (1фулл, 6 дифф, логи)Для таких размеров может быть и лента.
Ну или СХД большой.

odissseyво первых вон в Украине был злобный вирус Petya, который на многих фирмах пошифровал все что было на дискахА нельзя делать одну точку отказа.
"Не давайте пете к вам проникнуть и все будет хорошо." - гарантированная потеря информации, как обычно бывает, если надёжность сложной системы строится из предположения об отсутствии ошибок во всех её звеньях.

Храните одну копию бакапа на непосредственно серверных дисках каждого рабочего сервера, для быстрого восстановления.

Другую копию бакапа - в отдельном хранилище (ленты или СХД), притом хранение этой копии должна организовывать другая команда, со своим отдельным (не управляемым централизованно) доступом на чтение, и она же должна отвечать за состояние этих бакапов, то есть верифицировать бакапы путём восстановления их на свои, опять же независимые и управляемые отдельно, серверы.

iii2У кассеты проблемы с произвольным доступом. А линейно она читает и пишет на уровне RAID10 с 6 шпинделями.Речь о том, что её надо откуда то нести.
Если лента уже в библиотеке, то, конечно, скорость будет нормальная.

klichВ данном случае 6 терабайт очевидно не хватит.У них же 200 тб на 100 серверах, не думаю, что много сервером больше чем на 6 тб (может, вообще ни одного).

Relic HunterНа таких объемах бекапить/ресторить седствами SQL почти не реально в реальном времени. Бекапьте средствами сторожа, снепшоты/политики там разные.Несколько ТБ нереально? Да ладно, обычный объём, на скорости 1 Гб/сек всего полчаса-час.