1

Я немного знаком с тем, как использовать флаг tar --listed-incremental для создания инкрементных резервных копий. Конечным результатом является файл backup-0 который имеет первую полную резервную копию, а затем backup-1 , backup-2 , ..., backup-x с изменениями в порядке резервного копирования.

В прошлом я использовал rsync и hard-links для создания резервных копий, где backup-0 - это текущее состояние, а в каждой папке backup-x есть файлы, относящиеся к этой резервной копии. В основном то, что описано http://www.mikerubel.org/computers/rsync_snapshots/ и http://www.admin-magazine.com/Articles/Using-rsync-for-Backups/(offset).

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

Таким образом, идея состоит в том, чтобы иметь растущий список файлов примерно так:

  • backup-0.tar.bz2 - это текущая резервная копия и будет самой большой, потому что это полная резервная копия
  • backup-1.tar.bz2 - это вчерашняя резервная копия, но в ней будут только те файлы, которые отличаются от текущих (backup-0.tar.bz2)
  • backup-2.tar.bz2 - это резервная копия, созданная два дня назад, но в ней будут только те файлы, которые отличаются от вчерашних (backup-1.tar.bz2)
  • backup-3.tar.bz2 - ...
  • backup-4.tar.bz2 - ...
  • backup-5.tar.bz2 - ...

Если это не имеет смысла, надеюсь, это будет.

Первый раз:

  1. $ touch /tmp/file1
  2. $ touch /tmp/file2
  3. сделать backup-0.tar.bz2

На этом этапе backup-0.tar.bz2 имеет /tmp/file1 и /tmp/file2 .

Второй раз:

  1. $ touch /tmp/file3
  2. $ rm /tmp/file2
  3. .. сделать магию

С этой точки зрения:

  • backup-0.tar.bz2 есть /tmp/file1 и /tmp/file3
  • backup-1.tar.bz2 имеет /tmp/file2 ; у него нет file1 потому что он не изменился, поэтому он находится в backup-0.tar.bz2

Третий раз:

  1. $ touch /tmp/file1
  2. $ touch /tmp/file4
  3. .. сделать магию

С этой точки зрения:

  • backup-0.tar.bz2 есть /tmp/file1 , /tmp/file3 и /tmp/file4
  • backup-1.tar.bz2 есть файл /tmp/file1 поскольку он был изменен.
  • backup-2.tar.bz2 есть /tmp/file2

Вот так:

|       | first time | second time | third time              |
|-------|------------|-------------|-------------------------|
| file1 | backup-0   | backup-0    | backup-0 and   backup-1 |
| file2 | backup-0   | backup-1    | backup-2                |
| file3 |            | backup-0    | backup-0                |
| file4 |            |             | backup-0                |

Я подумал, что это один из способов подойти к этому, но мне это кажется ужасно неэффективным. Может быть, есть функции / флаги, которые я могу использовать, чтобы сделать это более эффективным.

  1. первый раз = backup-0
  2. второй раз
    1. переименовать backup-0 в backup-1
    2. взять backup-0
    3. удалить из backup-1 что соответствует backup-0
  3. третий раз
    1. переименовать backup-1 в backup-2
    2. переименовать backup-0 в backup-1
    3. взять backup-0
    4. удалить из backup-1 что соответствует backup-0
  4. четвертый раз
    1. переименовать backup-2 в backup-3
    2. переименовать backup-1 в backup-2
    3. переименовать backup-0 в backup-1
    4. взять backup-0
    5. удалить из backup-1 что соответствует backup-0

Я чувствую, что это последний шаг (удалить из backup-1 что соответствует backup-0), который неэффективен.

У меня вопрос, как я могу это сделать? Если я использую tar --listed-incremental это будет делать то, что я пытаюсь сделать.

|источник

1 ответ1

0

Если я использую tar --listed-incremental это будет делать то, что я пытаюсь сделать.

Это хорошо, что ты понимаешь это. Я вижу плюсы и минусы в любом направлении (я не буду обсуждать их здесь). Технически возможно полностью изменить процесс:

  1. Переименуйте backup-N в backup-(N+1) циклы от N max до 0.
  2. Восстановите полную резервную копию (теперь backup-1) во временную директорию.
  3. Создайте backup-0 из текущих данных с новым файлом снимка.
  4. Удалить backup-1 (предыдущая полная резервная копия).
  5. Рассматривайте временный каталог как "новую" версию. Создайте backup-1 качестве инкрементной резервной копии, предоставляя файл снимка с предыдущего шага. (Обратите внимание, что вам нужно сменить рабочий каталог с текущего на временный, чтобы относительные пути остались прежними).

Вы можете задаться вопросом, будет ли это сохранять старые (сохраненные) файлы backup-N согласованными с новыми. Разумное сомнение, так как в руководстве говорится:

-g , --listed-incremental=FILE
Обработка новых инкрементных резервных копий в формате GNU. FILE - это имя файла снимка, в котором tar хранит дополнительную информацию, которая используется для определения того, какие файлы изменились с момента предыдущего инкрементного дампа, и, следовательно, должен быть сброшен снова. Если FILE не существует при создании архива, он будет создан, и все файлы будут добавлены в результирующий архив (дамп уровня 0 ). Чтобы создать инкрементные архивы с ненулевым уровнем N , создайте копию файла снимка, созданного на уровне N-1 , и используйте его в качестве FILE .

Поэтому предлагается, чтобы файл снимка обновлялся полностью с момента полного резервного копирования, как если бы вам нужно было перестраивать файлы backup-N каждый раз, когда вы выполняете полное резервное копирование. Но потом:

При перечислении или извлечении фактическое содержимое FILE не проверяется, оно требуется только из-за синтаксических требований. Поэтому обычной практикой является использование /dev/null вместо него.

Это означает, что если вы извлекаете файлы backup-N в возрастающей последовательности, чтобы получить состояние с какого-то времени назад, любой файл backup-M (M> 0) ожидает только наличия действительного состояния M-1 . Не имеет значения, получено ли это состояние из полной или инкрементной резервной копии, дело в том, что эти состояния должны быть одинаковыми в любом случае. Поэтому не должно иметь значения, создали ли вы файл backup-M на основе полной резервной копии (как вы это сделаете, каждая backup-M будет начинаться как backup-1 где backup-0 - полная резервная копия) или на основе цепочки инкрементные резервные копии (как предполагает руководство).

Я понимаю, что ваша цель - сохранить backup-0 как актуальную полную резервную копию и иметь возможность "вернуться в прошлое" с backup-0 , backup-1 , backup-2 ,… Если вы хотите сохранить эти файлы в "тупом" облачном сервисе, вам нужно будет аккуратно переименовать их в соответствии с процедурой, заменить backup-1 и каждый раз загружать полностью новую backup-0 . Если ваши данные огромны, то загрузка полной резервной копии каждый раз будет проблемой.

По этой причине желательно иметь "умный" сервер, который может создавать текущую полную резервную копию каждый раз, когда вы загружаете инкрементную резервную копию "из прошлого в настоящее". Я использовал rdiff-backup несколько раз:

rdiff-backup копирование одного каталога в другой, возможно, по сети. Целевой каталог заканчивается копией исходного каталога, но дополнительные обратные различия хранятся в специальном подкаталоге этого целевого каталога, поэтому вы все еще можете восстановить файлы, потерянные некоторое время назад. Идея состоит в том, чтобы объединить лучшие функции зеркала и инкрементного резервного копирования. rdiff-backup также сохраняет подкаталоги, жесткие ссылки, файлы dev, разрешения, владение uid/gid, время модификации, расширенные атрибуты, acls и вилки ресурсов. Кроме того, rdiff-backup может работать в полосе пропускания по каналу, например, rsync .

Обратите внимание, что программное обеспечение не обновлялось с 2009 года. Я не знаю, хорошая ли это рекомендация в настоящее время.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .