Нам нужно сделать резервную копию файловой системы с большим количеством жестких ссылок. Поскольку для каждого «истинного» файла существует несколько жестких ссылок, мы хотели бы пропустить все жесткие ссылки при резервном копировании файловой системы, чтобы избежать n точных копий каждого файла.
Резервное копирование выполняется с помощью Tivoli Storage Manager Backup, и нам не удалось заставить его обрабатывать жесткие ссылки как что-либо, кроме отдельных файлов, для резервного копирования друг с другом.
Если это актуально для возможных решений, я хотел бы отметить, что жесткую ссылку можно отличить от нужного файла по имени файла:
foobarbaz-123.ext # file
foobarbaz-123-1.ext # hardlink
foobarbaz-123-2.ext # hardlink
barbazfoo-456.ext # file
barbazfoo-456-1.ext # hardlink
barbazfoo-456-2.ext # hardlink
barbazfoo-456-3.ext # hardlink
То есть, все жесткие ссылки имеют два дефиса в имени файла, тогда как в обычных файлах только один.
На сервере работает Ubuntu Linux, а файлы расположены на томе gfs в нашей SAN.
Беглое прочтение некоторых документов TSM предлагает "Не делайте этого!"
В unix «файл» - это просто запись в каталоге, которая указывает на индексный дескриптор. «Жесткая ссылка» - это когда у вас есть более одной записи каталога (указателей), указывающих на данный индексный дескриптор. По сути, эти два «файла» идентичны на 100%.
Жесткие ссылки - это хорошо отработанный и понятный механизм в unix. С ними нормально и часто сталкиваться, и для программного обеспечения резервного копирования характерно точно понимать, что такое жесткая ссылка, и делать ее резервную копию именно так, как она должна - как еще один указатель на конкретный фрагмент данных, а не как уникальный и новый фрагмент. данных, которые совпадают с другими жесткими ссылками.
Быстрый поиск в Google tsm и жестких ссылок показывает, что tsm понимает жесткие ссылки, и в документации специально предупреждают:
Проблемы могут возникнуть, если вы [создаете резервную копию | архивируете] только один файл из жестко связанной пары. Например, файлы texta и textb содержат жесткую ссылку друг на друга. Вы архивируете texta, а затем редактируете textb и вносите изменения. Если вы извлечете texta, изменения, внесенные в textb, будут потеряны.
Интересно, что, похоже, есть два разных способа резервного копирования с помощью TSM - резервное копирование и архивы, и эти два способа по-разному работают с жесткими ссылками.
резервное копирование и восстановление файлов:
Жесткая связь устанавливается, когда два файла указывают на один и тот же файл данных. Когда вы создаете резервную копию файла, который содержит жесткую ссылку на другой файл, TSM сохраняет как информацию о ссылке, так и файл данных на сервере. Если вы создаете резервную копию двух файлов, которые содержат жесткую связь друг с другом, TSM сохраняет один и тот же файл данных под обоими именами вместе с информацией о связи.
архивирование и восстановление файлов:
Когда вы архивируете файл, который содержит жесткую ссылку на другой файл, TSM сохраняет как информацию о ссылке, так и файл данных на сервере.
Из этого кажется, что вы взорвете свой сервер резервного копирования, если он выполняет «архивирование», и он будет делать то, что вы хотите, если вы «выполняете резервное копирование». Предоставьте IBM сделать это простым!
Во-первых, нет никакой разницы между «правильным файлом» и «жесткой ссылкой», жесткая ссылка - это просто другое имя для одного и того же объекта, в то время как мягкая ссылка на самом деле является файлом, содержащим указатель на настоящий файл, поэтому мягкая ссылка может пересекать границы файловой системы и жесткая ссылка не могут.
О фактической проблеме: посмотрите на опции Exclude и include-exclude-list в документация, у вас должно получиться с ними что-нибудь придумать. (лайк exclude /path/to/your/files/*-*-?.* или что-то).
Не зная ничего о Tivoli Storage Manager, было бы невозможно получить какое-либо программное обеспечение для обработки жестких ссылок по-разному с файлами, поскольку нет фактической разницы между исходным дескриптором файла и другими жесткими ссылками. (возможно, сценарий будет основан на именах файлов)
Обновитесь до TSM 6.1 и активируйте дедупликацию. (в настоящее время доступно только с типом устройства FILE, но терпение - это достоинство)