У меня есть два каталога резервных копий, которые находятся в одной файловой системе на моем сервере резервного копирования. Первый называется "clone" — он содержит клон моего ноутбука, который удаленно обновляется каждую ночь через rsync. Второй называется "backup" — это еженедельный снимок rsync только важных частей clone. Для экономии места "backup" создается как жесткие ссылки на clone вместо копий с использованием --link-dest:
rsync -avum --link-dest=/clone /clone/ /backup
Теперь я хочу также использовать опцию --backup для копирования старых версий измененных файлов из резервной копии в область хранения, на случай, если они мне понадобятся или я случайно удалю что-то важное. Это прекрасно работает без --link-dest:
rsync -avumb --backup-dir=/holding/2016_10_22 /clone/ /backup
Однако это создает копии измененных файлов в резервной копии, тратя место - мне нужны жесткие ссылки. Но если я добавлю параметр --link-dest обратно:
rsync -avumb --backup-dir=/holding/2016_10_22 --link-dest=/clone /clone/ /backup
...тогда толькоудаленоФайлы резервируются. Измененные файлы молчаливо жестко связываются. Причина (я полагаю) в том, что --link-dest разделяет логику --copy-dest. То есть, если исходный файл не изменился относительно файла copy-dest (или link-dest), то он не передается, а вместо этого копируется/связывается из каталога copy/link-dest в целевой каталог. Поскольку я использую исходный каталог как каталог link-dest, все не удаленные файлы остаются "неизменными" и обрабатываются молча.
Я мог бы сделать это в два этапа: сначала --backup без --link-dest, затем снова --link-dest без --backup. (Более новые версии rsync заменят идентичные файлы жесткими ссылками.) Но я бы предпочел сделать все это сразу.
Есть ли способ использовать --backup, создавая только жесткие ссылки? (На самом деле мне нужен «обычный» rsync с жесткими ссылками вместо передачи файлов. Мое использование --link-dest кажется немного хаком, учитывая предполагаемую логику этой опции.)
Бонусный вопрос: похоже, на странице руководства указано, что предпочтительнее использовать --link-dest только для пустых целей:
Этот вариант лучше всего работает при копировании в пустую иерархию назначения, поскольку существующие файлы могут получить измененные атрибуты, и это может повлиять на альтернативные файлы назначения через жесткие ссылки. Кроме того, перечисление изменений может стать немного запутанным.
Немного о том, что перечисление становится "запутанным", немного неопределенно. Действительно ли использование --link-dest на непустой цели "опасно", если предположить, что меня не слишком волнуют атрибуты файла? Может ли кто-нибудь привести пример?
решение1
Как уже упоминалось выше, в итоге я провел процесс в два этапа.
src = the "live" clone directory, a mirror of my laptop = primary backup
dst = the weekly snapshot of important parts clone
trashdir = the items from src that don't exist in dst, because they have since been deleted, sorted into date-stamped directories
cmd = ("rsync -avumb --stats --delete --delete-excluded --filter='merge %s' --backup-dir=%s %s %s" %
(filterfile, trashdir, src, dst))
cmd = ("rsync -avum --stats --delete --delete-excluded --filter='merge %s' --link-dest=%s %s %s" %
(filterfile, src, src, dst))
На первом этапе создается резервная копия важных частей клона, а также сохраняются файлы, удаленные с момента последнего резервного копирования, в trashdir. (Есть причины, по которым мне нужна эта промежуточная резервная копия только выбранных файлов, и я хочу, чтобы она обновлялась только еженедельно.)
Второй шаг преобразует файлы в резервной копии в жесткие ссылки, указывающие на клон. Результатом является то, что резервная копия занимает нулевое фактическое пространство. trashdir по определению не является жестко связанными файлами, поскольку он состоит только из файлов, которые были удалены из клона и резервной копии.
Я не совсем уверен, нужны ли флаги --delete-excluded (особенно во второй команде). Я оставил их там, на случай, если я изменю filterfile, который определяет, какие части клона следует игнорировать при создании резервной копии.
Я обнаружил, что за пять лет trashdir вырос примерно до размера clone, поэтому общий размер = clone x2, что для меня приемлемо, учитывая, что у меня есть шестилетняя история удаленных файлов, и я могу легко обрезать их по дате.
В дополнение к вышесказанному, у меня есть скрипт, который запускается cp -alдля копирования clone примерно в месяц с датированными вращающимися жесткими ссылками-снимками. Это покрывает меня для файлов, которые были изменены, а не удалены. Общий размер за месяц, кажется, составляет около половины размера clone.
Таким образом, общее дисковое пространство составляет примерно 2,5% от клона, и у меня есть:
- сам клон, обновляемый каждую ночь
- резервная копия выбранных файлов, которая стабильна в течение недели
- месячный объем версий клонированных снимков
- удаленные файлы за шесть лет
Я считаю, что это довольно хорошая защита от потери исходного диска, перезаписи файла и необходимости использования более старой версии, а также удаления файла и необходимости его использования позже.
Это немного запутанно и, вероятно, этого можно было бы добиться с помощью стороннего программного обеспечения, но мне это подходит и построено на низкоуровневых инструментах, которые вряд ли исчезнут или существенно изменят функциональность.
(@gsl - На самом деле, спасибо за запрос на обновление. Я обнаружил, что один из моих скриптов сломался, когда я обновился до python3, и не запускался уже пару месяцев. Мне нужно уделять больше внимания журналам ошибок!)
Однако я все еще определенно заинтересован в способах оптимизации этого процесса, так что не стесняйтесь комментировать, если то, что я делаю, можно сделать более простым способом.