Инкрементные резервные копии с tar, где текущий файл имеет самые последние, а предыдущие файлы имеют только разные версии

353
IMTheNachoMan

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

В прошлом я использовал rsyncжесткие ссылки для создания резервных копий, где указано backup-0текущее состояние, и в каждой backup-xпапке есть файлы, относящиеся к этой резервной копии. В основном то, что обрисовано в общих чертах http://www.mikerubel.org/computers/rsync_snapshots/ и http://www.admin-magazine.com/Article/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«S --listed-incrementalон будет делать обратное тому, что я пытаюсь.

1
Как это сделать Если я использую `tar`'s` --listed-incremental`, это будет делать то, что я пытаюсь сделать. IMTheNachoMan 5 лет назад 0

1 ответ на вопрос

0
Kamil Maciorowski

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

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

  1. Переименуйте backup-Nв backup-(N+1)looping от 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 года. Я не знаю, является ли это хорошей рекомендацией в настоящее время.

Благодарю. Это может работать, но для полного извлечения временного каталога потребуется много места. У меня есть идея сделать то, что я хочу, и я работаю над сценарием. 1) сбросить инвентаризацию файлов в резервную копию, включая время и размер мода 2) архивные файлы, включая файлы инвентаризации, а затем позже 1) извлечь файл инвентаризации из архива 2) взять новый файл инвентаризации 3) сравнить два файла 4) извлечь различные файлы и поместить в новый архив. IMTheNachoMan 5 лет назад 0

Похожие вопросы