У меня на работе возникла дилемма хранения в сети.
В настоящее время мы используем систему контроля версий (SVN) для резервного копирования наших сырых файлов с наших рабочих станций в репозиторий на централизованном сервере.
После прочтения кажется, что у меня могут возникнуть проблемы с некоторыми из наших больших файлов, которые иногда достигают размера 1 гигабайт. У нас есть сотни таких файлов на репозиторий, что делает его довольно большим сверхурочным.
Есть ли лучшее программное обеспечение для использования? Я хотел бы иметь функциональность репозитория, но с более стабильной / работоспособной средой. Нам действительно нужно провести капитальный ремонт системы резервного копирования для нашего централизованного сервера.
Обновить:
Согласно запросу, ОС для Сервера и Рабочей станции - XP. При необходимости можно обновить сервер до Server 2003.
Если вы используете SVN (или любое другое программное обеспечение для управления версиями) в качестве резервное копирование систему, которую вы можете рассматривать как реальную систему резервного копирования (Baculaили, возможно, что-то коммерческое).
Вы можете продолжать проверять файлы в SVN, если они требуют контроля версий, но, по моему опыту, SVN - довольно паршивая система резервного копирования при масштабировании ...
Subversion на самом деле обладает одними из лучших способов обработки больших файлов среди всех современных систем контроля версий. Git, Mercurial, Bazaar и т. Д. Имеют архитектурные или зависящие от платформы ограничения (обычно 2 или 4 ГБ, потому что они представляют собой файлы карты памяти для выполнения различных задач). Git, вероятно, мог бы хорошо подойти для вашего варианта использования в качестве «тупого трекера контента», если вы можете иметь дело с отправкой файлов в репозиторий git на сервере, а затем совершением фиксации на сервере через скрипт. Видеть этот вопрос для получения дополнительной информации (и его ссылки о проблемах отображения памяти на разных платформах).
Более серьезная проблема заключается в том, что функции «двоичного сравнения» и сжатия, предоставляемые системами контроля версий, обычно неэффективны для большинства больших медиафайлов, поскольку они уже сжаты и сильно меняются. Например, если у вас есть два файла фильма и вы отредактируете один, чтобы удалить 4 секунды из середины, вы можете подумать, что будет легко сохранить только изменения. Но на самом деле, когда вы редактируете этот файл, даже если вы не перекодируете видео, временные коды для каждого кадра перетасовываются, в результате чего снова сохраняется почти весь файл. Возможно, вы захотите просто отключить функции сжатия и сравнения в своем инструменте, если это возможно, чтобы сэкономить на процессоре и времени резервного копирования.
Единственные большие файлы, с которыми я видел, как Subversion или Git преуспевают, - это резервные копии базы данных SQL, которые обычно имеют страничную структуру и очень мало меняются от одной резервной копии к другой. И, конечно же, файлы журналов, которые сжимаются как сумасшедшие даже с помощью gzip.
Я не уверен, что Subversion действительно предназначена для резервного копирования. Вы можете посмотреть на Acronis. Несмотря на то, что цена, безусловно, больше, чем просто домашние решения, нет ничего более удовлетворительного, чем восстановление с нуля после критического сбоя.
В основном я работаю в Linux и перешел на использование CDP-сервера R1Soft, но до этого я использовал Acronis в нашем офисе с хорошими результатами.