JonsnowЗдравствуйте уважаемые люди.

У меня такой вопрос имею 2 сервера( у них заканчивается место ) и они старые с 2007 и 2005 года.
Данных около 2-3 Тера. Может больше. BackUP идёт на серверные диски. Теперь такой вопрос. Покупаю два новых сервера и нужен БэкАп. И вот думаю как сделать лучше, что бы не нагружать эти два сервера, купить ещё третий и туда БэкАп или же на диски его делать?
Какой способ посоветуете? облоко нельзя(
Какие-нибудь мысли может подсказки?

С Уважением

1. Бэкапы лучше делать на локальный выделенный диск. Это ничего не "нагружает" и минимизирует риск технической ошибки.
2. Делание бэкапа по-сети - порождает еще несколько причин для ошибок. Нафига это надо?

JonsnowВладислав Колосов,
То есть 3 сервер покупать не за чем?
И Лучше на Дисках серверных хранить бэкап?
Просто на 3 сервер, можно будет сразу делать бэкап, например за день данные получили, и сразу и автоматов на 3 сервер закинуть.
А если делать на диск, то она нужно ведь будет вручную, и целую базу делать, или мне кажется?

Довольно жиденькая каша в голове.

Гавриленко Сергей Алексеевичalexeyvg,

Ядер -- 80 штук.

Сжатие бякапа в MS SQL сделано очень незатейливо.
1. Пишется обычный бякап без сжатия.
2. Применяется к файлу какой-то алгоритм сжатия.

Аналогичный эффект достигается простым включением встроенного сжатия диска NTFS.
Соответственно, нагрузка процессора будет размазана по времени.

Гавриленко Сергей Алексеевичaleks222Сжатие бякапа в MS SQL сделано очень незатейливо.
1. Пишется обычный бякап без сжатия.
2. Применяется к файлу какой-то алгоритм сжатия.Т.е. бэкап пишется _два_ раза, сначала без сжатия, а потом еще и со сжатием? Типа, включи сжатие, получи болше iops и загрузи еще и процессор?

Это лехко наблюдать воотчую. Посмотри на размер файла в процессе и после.

L_argoСледует помнить, что для успешного сжатого бекапа нужен запас места все равно как для неупакованного + некий запас.
Врете, батенька.
Для успешного сжатого бекапа достаточно запаса места равного размеру неупакованного.
Т.е. при сжатии оно пишет прямо в файл бякапа.

Гавриленко Сергей Алексеевичaleks222Это лехко наблюдать воотчую. Посмотри на размер файла в процессе и после.Это как наблюдать за тем, что происходит за забором, по надписям на нём: мало ли что там в метаданных по открытому файлу ntfs рисует. Не надо на основании этого делать какие-то выводы.

З.Ы. Тем более, кол-во переданных по сети данных (а бэкап был по сети) совпадает с размером файла бэкапа.
Надо, федя, надо. Оно ведь не только пишет - оно еще и вопит: "места нема!".
И размер необходимого места отлично коррелирует с тем, что "по открытому файлу ntfs рисует".

TaPaKaleks222,
на этом заборе пишут так:
авторBecause a compressed backup is smaller than an uncompressed backup of the same data, compressing a backup typically requires less device I/O and therefore usually increases backup speed significantly.

и про цп так

авторBy default, compression significantly increases CPU usage, and the additional CPU consumed by the compression process might adversely impact concurrent operations.

т.е. как при меньшем io можно сделать 2 операции?

Забор - фсе стерпит.
IO и CPU мне измерять лениво.
А вот если на диске меньше места, чем нужно для несжатого бякапа - бякап обламывается.
IO и CPU не помогают.

L_argoaleks222пропущено...

Врете, батенька.
Для успешного сжатого бекапа достаточно запаса места равного размеру неупакованного.
Т.е. при сжатии оно пишет прямо в файл бякапа.Каким образом сервер узнает, что места до начала бекапа недостаточно ?
Только проверив наличие места как для неупакованного. Откуда он узнает коэф. упаковки ? Ниоткуда.
Если я храню в БД видео или фотки JPEG, то база не сожмется. Но проверку на доступность места сервер делает и вероятно резервирует , чтобы потом не было неожиданностей.

Это было бы так, если бы "резервировалось сразу", но размер файла растет по мере выполнения бякапа.