Alexander UsAlexander UsКстати и птичках: у меня прекрасно идёт большая (второстепенная) база ~2-3ТБ на внешний USB2.0 диск.
Насчёт "прекрасно" я конечно погорячился, но идёт, скажем удовлетворительно.Чего бы ей прекрасно не идти? Только скорость маленькая, 20 мб/сек, соответственно бакап за сутки не успевает сделаться.
Поэтому пришлось извратиться с рид-онли файлгруппами и частичными бакапами, благо для бизнес-логики типичных хранилищ они хорошо могут применяться. А за сутки красота, 150 суточных гигабайт ложатся в 50 гиговый бакап, время занимает пару часов.

ColГавриленко Сергей Алексеевич]А можно ссылку на рекомендации? На те, где поясняется, от чего зависит кол-во потоков, в которое делается бэкап. А то вот у нас средняя скорость снятия бэкапа получается 600-650 Мб/сек. С компрессией. В один несчастный файл. Может, все-таки, базовый параллелизм зависит не от кол-ва destination-файлов, а от кол-ва файлов данных БД?

Да ладно, докумант так и называется "Optimizing Backup and Restore Performance in SQL Server":
https://technet.microsoft.com/en-us/library/ms190954(v=sql.105).aspx one thread is assigned to each backup device

П.С>
Тема топика все-же рестор, я же говорю везде о процедуре "бакап-рестор", я к тому что читать на ресторе тоже надо ;)По моему, там совсем про другое, о чём говорится в начале документа - об ограничении скорости одного устройства бакапа, и преодолении этого ограничения путём бакапа на множество устройств.

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

Col alexeyvg
Я нигде и не говорил об ограничениях ядра, изначально если Вы конечно помните я говорил о распареллеливании процедуры бакап-рестора, что собственно делается при помощи множества файлов. ;)Вы говорили тут 21111792 именно про ограничения ядра, и как это ограничение преодолеть, загрузив бакапом (рестором) множество ядер, то есть распаралелив именно процессорную нагрузку, а не нагрузку IO.