Верно ли, что реализация rsync по умолчанию в Synology DSM 4.3 не может обрабатывать «огромные» объемы данных и может нарушить управление версиями / дедупликацию? Может быть, любая из переменных (см. подробная информация ниже) может сделать это намного сложнее?
Изменить: я не ищу ничего, кроме ответа, если приведенные выше утверждения не имеют смысла или могут быть правдой.
Подробная информация:
На работе у нас в офисе работает Synology NAS. Этот NAS используется несколькими дизайнерами, из которых они непосредственно работают. У них есть запущенные проекты, которые состоят из стоковых фотографий с высоким разрешением, больших файлов PSD, PDF-файлов и прочего. У нас есть папка размером ок. Размером 430 ГБ, который состоит только из текущих проектов. Эта папка должна еженедельно копироваться в центре обработки данных через наше интернет-соединение.
Вся наша ИТ-инфраструктура обрабатывается третьей стороной, которая утверждает, что наша резервная копия начинает формировать определенный размер («100 ГБ +»), когда стандартная реализация DSM (4.3) rsync не может обрабатывать огромный объем данных для онлайн-резервное копирование (на одной из машин в их центре обработки данных). Они говорят, что резервная копия содержит около 10 ТБ данных, потому что у rsync есть проблемы с «управлением версиями / дедупликацией» (срок хранения: 30 дней), и он выходит из строя.
По этой причине они предлагают использовать «профессиональную службу резервного копирования в Интернете», что значительно увеличивает наши затраты на гигабайт резервного копирования в Интернете.
Rsync сам по себе не подавляется большими размерами файлов или "слишком много" файлов. В зависимости от вашей ситуации может быть (но маловероятно), что задание rsync каждую неделю занимает более 1 недели, в результате чего новое задание rsync начинается до завершения предыдущего задания rsync.
Среди ИТ-специалистов общеизвестно, что передача тонны маленьких файлов занимает намного больше времени, чем передача нескольких очень больших файлов при всех прочих равных (такая же скорость интернета, такая же количество данных и т. д. Взгляните на это ("Передача миллионов изображений") в качестве примера обсуждения переполнения стека, а также этого ("Что быстрее и почему: передача нескольких небольших файлов или нескольких больших файлов?") в качестве примера обсуждения здесь, на Serverfault.
Таким образом, проблема может заключаться в том, что вам следует сжать файлы / папки перед запуском rsync, а затем скопировать сжатый файл в удаленный центр обработки данных. Это в любом случае сэкономит вам расходы на хранение данных вне офиса, хотя и открывает еще одну банку червей.
Первым шагом, конечно же, будет определение времени выполнения задания rsync. Затем выясните, нужно ли вам изменить методологию резервного копирования, предварительно сжав данные или перейдя на альтернативное решение для резервного копирования.
Кстати, на момент публикации Synology DSM 5.1 является последней версией, а 5.2 находится в стадии бета-тестирования. Вам следует выполнить обновление до DSM 5.1, если вы еще этого не сделали. Это точно не повредит вашей ситуации.