Если я использую
tar«S--listed-incrementalон будет делать обратное тому, что я пытаюсь.
Это хорошо, что ты понимаешь это. Я вижу плюсы и минусы в любом направлении (я не буду обсуждать их здесь). Технически возможно полностью изменить процесс:
- Переименуйте
backup-Nвbackup-(N+1)looping от N max до 0. - Восстановите полную резервную копию (сейчас
backup-1) во временный каталог. - Создать
backup-0из текущих данных с новым файлом снимка. - Удалить
backup-1(предыдущая полная резервная копия). - Рассматривайте временный каталог как «новую» версию. Создайте
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 года. Я не знаю, является ли это хорошей рекомендацией в настоящее время.