Сколько CPU и RAM вам нужно, чтобы сделать бекап?

[pansa]

и всяких специфических файловых систем вроде XFS

А в чем специфичность XFS? По ссылке не нашел совсем ничего об этом. Ну или хотя бы тогда какие ФС не-специфичны?

[Loxmatiymamont]

У каждой фс есть свои флаги и аттрибуты, который надо учитывать при работе. Конкретно у XFS это reflink. На мой взгляд очень удобная штука, которую майкрофост реализовали в своей ReFS под именем FastClone.
Я писал обзорную статью про XFS как-то: habr.com/ru/company/veeam/blog/508426

Так что с чисто технической стороны вопроса, каждая фс по своему специфична =)

[pansa]

Да, про рефлинки я знаю, пару лет использую в продакшене. Реальность использования не такая красивая, как описание, но да не об этом…
И что, ваши решения способны "понимать" рефлинки XFS? Т.е при восстановлении бэкапа он прям с рефлинками восстановится? Или специфика как раз в том, что при восстановлении я получу "разлинкованные" данные?

[Loxmatiymamont]

Наши продукты способны учитывать рефлинки при тяжёлых дисковых операциях с файлами, чтобы изменения происходили только на уровне метаданных. Различные синтетические трансформы бекапных файлов проходят на порядки быстрее + потенциальная экономия дискового места, что для бекапов совсем не последний вопрос. Я об этом и пишу в статье, о которой говорил выше.

[pansa]

А, вы используете reflink'и для себя. Ок, это хорошо и понятно (правда, как я уже писал, на проде работа с ними становится не такой красивой и быстрой). Но я интересуюсь немного с другой стороны: допустим, моё приложение активно пользуется рефлинками, соответственно, имеем некоторый весомый процент дедупликации. Ваш продукт бэкапит этот раздел. Потом случается айайай, и нам надо откатиться на бэкап. Что станет с моей дедупликацией рефлинками, она сохранится?

[Loxmatiymamont]

Вопрос интересный и ответ зависит от того как бекапить.
Если бекап будем делать на уровень ниже файловой системы, то да, все линки сохранятся. Если будем читать через файловую систему — нет. При чтении с любой дедуплицирующей системы файлы проходят регидрацию. С другой стороны, при записи обратно (ресторе), они снова будут дедуплицированы самой фс.

[pansa]

Если бекап будем делать на уровень ниже файловой системы, то да, все линки сохранятся.

Если имеется в виду, условно, dd всего раздела — то понятно, что тут сохраняется всё, там без разницы уже что под низом. Это не интересно =)

С другой стороны, при записи обратно (ресторе), они снова будут дедуплицированы самой фс.

Хм, интересно, каким образом это произойдет. Механизм рефлинков же не умеет дедупликацию по аналогии с zfs, например. ФС этого сделать не сможет. Только если ваш продукт при создании бэкапов сохранял всю информацию по рефлинкам и при откате воссаздаёт. Вот к этому я вёл изначально и вот в этом я сииииильно сомневаюсь, что вы можете делать =)

[Loxmatiymamont]

У меня нет таких глубоких знаний рефлинков, так что я не знаю в какой именно момент срабатывает переиспользование блоков. Так что могу ошибаться, да.
Но ещё раз, если был сделан образ диска, то и восстановлен он будет as is.

[MaxLK]

Вы пишите что диски бэкапятся параллельно разными потоками, однако для расчета количества процессоров учитываете только общий объем данных а не количество дисков. Не означает ли это что будет нехватка процессоров и проседание производительности? И как поведет себя ваше ПО в такой ситуации — разные диски одного сервера будут бэкапиться последовательно или параллельно на одном ЦП, задача будет пытаться распараллелиться и искать свободный ЦП, что произойдет? Где происходит дедупликация? И как она лицензируется, это базовый функционал? Вопрос в том, что если в базу это не входит, то как вы считали необходимую производительность — с дедупликацией или без? и если дедупят медиасервера — это происходит в ОЗУ или данные сбрасываются на локальный диск, или вы кидаете все на «репозиторий» и делает пост дедупликацию?

Что будет когда диск сервера это фактически примапленный лун СХД? насколько понимаю с СХД на прямую вы не работаете? каковы ваши рекомендации в такой ситуации — бэкапить через сервер, бэкапить средствами СХД, не пользоваться вашим ПО и приобрести что-то более функциональное?

что если у нас сервер БД и change rate 10% в день и данных там 10Тб и мы посчитаем количество ЦП в медиасервере на сегодня по вашей формуле — не окажемся ли мы в ситуации что через год нам придется покупать новый сервер? и так каждый год… как учесть прирост данных при сайзинге серверов для бэкапа?

[Loxmatiymamont]

Абсолютно верное замечание про диски, однако есть проблема — кроме вас никто не знает что и как устроено в вашей инфраструктуре. Грубо говоря, если в бекапном задании десять машин с одинаковым количеством более-менее равномерно заполненных дисков, мы получаем равномерную загруженность на протяжении всего процесса и нам не особо важно сколько этих дисков всего. Зато если среди этих десяти машин вдруг оказывается одна с гигантским диском, то вполне вероятна ситуация, что всё прочее уедет в бекап и большая часть системы будет простаивать, пока бекапится этот огромный диск. Поэтому тут более логичным будет вывести эту машину в отдельное задание.

С нехваткой процессоров всё просто. Чисто технически можно всё бекапить на одном ядре одного процессора. Просто это будет долго. А в случае с одной машиной с одним гигантским диском больше и не понадобится. Если всех это устраивает, то почему нет?

Разные диски бекапятся на разных ядрах без привязки к конкретному процессору. Во всяком случае так задумано. Да, бывают свои истории, например, с NUMA, но это уже надо смотреть конкретный случай. А дедупликация это базовый функционал, который есть даже в бесплатных версиях продукта.

Со многими СХД напрямую мы отлично работаем и умеем делать много интересных штук. Касательно попадания в бекап: лун замапленный прямо в ОС виртуалки мимо конфига виртуалки в бекап само-собой не попадёт. С железным сервером несколько хитрее: если обычный FC\iSCSI и ось может сделать его снапшот, то он отлично бекапится. А не зная всех деталей вашей инфраструктуры давать рекомендации я не буду. Вы всегда можете скачать триальную версию и месяц, без ограничений по функциональности, проверять все возможные варианты.

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

[LevOrdabesov]

По началу и названию статьи надеялся, что речь пойдёт об оптимизациях и интересных приёмах в обычных и необычных ситуациях.
По факту просто 4 голые цифры. Очень жаль.

48 Гб RAM. Да в ноутбуки уже больше ставят, если честно

Жжыте ещё.