`cp -al` snapshot, чьи жесткие ссылки будут перенаправлены на новый файл при редактировании

Я пытаюсь регулярно делать снимки массивной папки.

Я читал здесь: http://www.mikerubel.org/computers/rsync_snapshots/#Incremental
что cp -al делает снимок папки, просто копируя жесткие ссылки.

Это здорово, но проблема в том, что в этом снимке, если я меняю файл, он изменяется во всех моментальных снимках. Вместо этого я хотел бы, чтобы система создавала новый файл для изменения и ссылалась на него. Таким образом, каждый снимок не станет недействительным при редактировании первого файла.

Как я могу это достичь?

ps Я пробовал rsync -a --delete --link-dest=../backup.1 source_directory/ backup.0/ , но у него такая же проблема.

Вот как работают жесткие ссылки. Но есть способы обойти это:

На ум приходит пара опций:

  • Используйте файловую систему с поддержкой файлов для копирования на запись, например btrfs . Конечно, если бы вы использовали btrfs, вы бы просто использовали свои собственные снимки … Если ваша файловая система поддерживает его, вы можете использовать cp --reflink=always . К сожалению, ext4 не поддерживает это.
  • Поделитесь только жесткими ссылками на свои снимки, а не с оригиналом. То есть, в первый раз, когда вы видите данную версию файла, скопируйте его в моментальный снимок. Но в следующий раз свяжите его с тем, что было в предыдущем снимке. (Не знаю, какую программу я использовал для этого – десять лет назад, но поиск включает в себя dirvish, obnam, storebackup и rsnapshot)
  • В зависимости от того, как ваши файлы изменяются, вы можете гарантировать, что для их изменения используется параметр temp / rename для записи, тогда это приведет к поломке жесткой ссылки, поэтому версия в снимке останется нетронутой. Это менее безопасно, поскольку ошибки могут повредить ваш снимок.
  • Сделайте снимки LVM всей файловой системы.

Конечно, есть и другой вариант – используйте правильную систему резервного копирования. Большинство из них могут управлять только резервным копированием измененных файлов.

То, что вы ищете, – это форма копирования на запись , где несколько файлов, имеющих один и тот же контент, используют одно и то же пространство на диске, пока один из них не будет изменен. Жесткие ссылки реализуют только copy-on-write, если приложение, выполняющее запись, удаляет файл и создает новый файл с тем же именем (что обычно делается путем создания нового файла под другим именем, а затем перемещения его на место). Приложение, которое вы используете, очевидно, не делает этого: оно перезаписывает существующий файл.

Некоторые приложения могут быть настроены для использования стратегии замены. Некоторые приложения используют стратегию замены по умолчанию, но используют стратегию перезаписи, когда видят файл с несколькими жесткими ссылками, чтобы не нарушать жесткие ссылки. Текущая технология моментального снимка будет работать, если вы можете настроить приложение вместо замены на замену.

Fl-cow изменяет программы для систематического использования стратегии замены файлов с несколькими жесткими ссылками.

Кроме того, вы можете хранить ваши файлы в файловой системе, которая выполняет операции копирования и записи или дедупликации, или имеет функцию моментального снимка, а не беспокоиться о жестких ссылках: Btrfs или Zfs . В зависимости от вашей схемы секционирования, использование снимков LVM может быть опцией.

Моя рекомендация – использовать соответствующий инструмент моментального снимка. Сделать надежное резервное копирование на удивление сложно. Вы, вероятно, хотите rsnapshot .

Ниже приведен скрипт ruby, который я написал, который обертывает «cp -al» и rsync в хороший скрипт, который можно запускать вручную или через cron. Назначение может быть локальным или удаленным (через ssh):

Гетто Timemachine

Основной ответ на ваш вопрос, как упоминалось в предыдущем комментарии, источник должен быть отделен от жестких ссылок. Ex, предположите ежедневную резервную копию вашего домашнего каталога:

Источник:

  • / Главная / flakrat

Место назначения:

  • / Данные / резервного копирования / ежедневно
    • /понедельник
    • /вторник
    • / среда
    • /Четверг

Жесткие ссылки создаются путем запуска «cp -al» против вчерашней резервной копии. Скажем, утро вторника, когда вы запускаете его:

cd /data/backup/daily

rm -rf tuesday

cp -al monday tuesday

rsync -a --delete /home/flakrat /data/backup/daily/tuesday/

Надеюсь, это поможет, Майк

rdiff-backup, похоже, делает то, что вы хотите, проверьте это.

Используя rsync, вы должны сначала создать полную резервную копию, не используя жесткие ссылки. Следующая резервная копия может указывать на предыдущую резервную копию и жесткую ссылку на нее. Таким образом, ваши резервные копии не связаны с вашими рабочими файлами (те, которые вы изменяете). Пример. Если моя предыдущая резервная копия была такой резервной копией папки.01, мой сценарий резервного копирования сначала увеличивал бы папки, переименовывая их на один, поэтому backup.01 становится backup.02. Затем скрипт создает новую пустую папку под названием backup.01. он затем перепрограммировал новую резервную копию в новую папку и жесткую ссылку на backup.02, чтобы только новые файлы занимали какое-то место в резервной копии. Команда rsync будет выглядеть примерно так: rsync -rlt sourcepath backuppath / backup.01 –link-dest = backuppath / backup.02

Таким образом, вы можете видеть, все жесткие ссылки происходят на пути резервного копирования. Таким образом, вам не нужно беспокоиться о копировании при записи при изменении файлов в исходном пути.