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


11

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

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

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

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

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

Ответы:


7

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

На ум приходит пара вариантов:

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

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


Что вы рекомендуете для резервного копирования массивной папки?
Герман Ингальдссон,

Я думал об использовании rsync для сервера, у которого есть cronjob для регулярного выполнения cp -al для моментальных снимков ... наряду с rsync-in для получения еще большего количества копий. Как это звучит?
Герман Ингьялдссон

@HermannIngjaldsson ну, это зависит от того, как вы делаете свои резервные копии. Лично я бы просто добавил его в настройки Bacula, но я бы не советовал этого делать, если у вас нет резервной копии нескольких машин или вы уже знаете Bacula. Так что, думаю, я бы посоветовал вам сначала попробовать rsnapshot.
Дероберт

rsnapshotэто хорошо
developerbmw

4

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

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

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

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

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


2

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

Гетто Машина времени

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

Источник:

  • / Главная / flakrat

Пункт назначения:

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

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

cd /data/backup/daily

rm -rf tuesday

cp -al monday tuesday

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


0

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.