Я работаю в области биоинформатики, и мы храним множество очень больших файлов, которые никогда не меняются - геномы растений, считывания геномов и т. Д. Мы постоянно получаем новые данные этого типа, и размер наших резервных копий стремительно растет.
На мой взгляд, не имеет смысла делать резервные копии этих больших файлов все время, достаточно трех-пяти раз. Есть ли что-то вроде резервных копий с отслеживанием состояния, в которых хранятся файлы, которые уже являются «безопасными» (уже на 5 лентах или около того, с использованием, возможно, хэшей файлов), а затем только резервные копии остальных?
Я погуглил и ничего не нашел.
Спасибо!
Какой-то вариант инкрементное резервное копирование будет работать для этого. Или, возможно, вы можете регулярно откладывать архивные ленты, содержащие статические данные, чтобы уменьшить ежедневную нагрузку на резервное копирование.
Обычно это решается либо с помощью инкрементного резервного копирования (резервное копирование всех файлов с момента последнего резервного копирования), либо с помощью дифференциального резервного копирования (всех файлов с момента последнего полного резервного копирования). В руководстве по Gnu Tar (разделы 5.2 и 5.3) есть краткое обсуждение этого типа резервного копирования. Однако это не решает вашу проблему с минимальным количеством копий каждого файла.
Другой вариант, если вы хотите получить точный снимок системы при каждой резервной копии, но при этом сэкономить место, - это использовать резервные копии снимков rsync (выполните поиск снимка rsync в Google, есть несколько статей и инструментов, которые реализуют это). В основном это использует rsync для создания копий в удаленную систему (или внешний диск) и использует жесткие ссылки на файлы, которые не меняются между каждым резервным копированием, для экономии места. Чтобы получить несколько копий, вы должны выполнить синхронизацию резервного диска с другим резервным диском.
Но если вы хотите, чтобы все это происходило на ленте, единственное, что мне известно, это коммерческие инструменты резервного копирования, такие как Tivoli. Вы можете изучить Bacula, который, я думаю, также поддерживает минимальное количество копий, но я еще не использовал его.
Что-то, что скоро будет доступно, - это инструмент резервного копирования, над которым я работал сам. Мне нужно собрать немного больше документации и очистить код, прежде чем размещать его на github, но в основном он выполняет инкрементальные резервные копии в стиле моментальных снимков, отслеживая файлы по хешу MD5 и сохраняя каталог моментальных снимков того, что система выглядит при каждой резервной копии. Это также, как побочный эффект, выполняет дедупликацию на уровне файлов при резервном копировании нескольких хостов на один сервер резервного копирования. Если вам интересно, я вернусь позже и обновлю этот пост, как только у меня будет загружена начальная версия этого инструмента (при условии, что продвижение ваших собственных проектов не противоречит политике здесь - если это так, мои извинения).
Сохраняйте импортируемые файлы в соответствии с датой их получения. Выполните жесткую привязку их к макету, в котором вы хотите их использовать. Сделайте резервную копию каталогов за последние 5-7 дней.
Храните данные в разных местах и используйте разные стратегии резервного копирования. Я работал в огромной компании, и даже там была установка для петабайта данных.
Что-то вроде:
/master для файлов, которые практически неизменяемы. Некоторые пользователи обычно загружают туда большие файлы. Резервное копирование выполнялось раз в месяц;/data для всех остальных файлов. были ссылки на /master файлы. Это копировалось каждую ночь.