pandoc продолжает жаловаться на символ не-utf8, хотя кажется, что нет символа не-utf8
Дополнительные функции в gtar имеют концептуальную проблему и не могут работать правильно во всех случаях. Когда я попытался проверить дополнительные функции на Star в 2004 году, gtar рано потерпел неудачу и не мог быть протестирован вообще.
Вы пробовали инкрементное резервное копирование star?
Freebsd использует звезду для резервного копирования zfs, и это прекрасно работает, так как freebsd исправил некоторые старые ошибки ядра.
gtar имеет несколько проблем с инкрементным резервным копированием:
Важные метаданные большего размера находятся не в архивах резервных копий, а в отдельном файле, который создается в результате использования поставщика
gtarконкретная опция-g. В случае полного сбоя системы весьма вероятно, что этот файл будет утерян (по крайней мере, в его самой последней версии). Однако наличие этого файла отдельно от резервных копий не является реальной проблемой. Настоящая проблема в том, что этот файл не может отслеживать переименования.Архивы резервных копий из gtar не содержат информации о переименованных файлах. Есть просто след, который позволяет предположить, что имя файла, которое не упоминается в новом архиве, но присутствует в текущей файловой системе, должно быть исчезло и, таким образом, было удалено.
gtar необходимо заархивировать полное дерево каталогов со всем содержимым, если каталог на верхнем уровне был переименован. Это делает приращение gtar огромным, и это может легко привести к переполнению целевой файловой системы во время операции восстановления.
У gtar есть проблемы с файлами, не относящимися к каталогам, которые меняют тип файла между двумя инкрементными.
gtar не может обработать переименование каталога с последующим созданием нового каталога с предыдущим именем.
Таким образом, я не смог запустить первоначальный ручной тест с gtar, который я создал в сентябре 2004 года для star.
Star с другой стороны использует базовый алгоритм, который известен своей верностью уже 35 лет, поскольку он был разработан для ufsdump / ufsrestore в 1981 году. Инкрементное резервное копирование Star работает следующим образом:
Есть файлы dumpdates, которые записывает не более чем отметку времени, уровень и файловую систему для каждого полного или инкрементного дампа.
Каждый tar-архив содержит все метаданные, необходимые для отслеживания всех изменений в файловой системе между двумя резервными копиями. Помимо всех измененных файлов, звездочка архивирует список имен файлов для всех измененных каталогов вместе с соответствующими номерами inode. Это позволяет отслеживать все удаления файлов и все переименования файлов в любое время для любого инкрементного резервного копирования.
Когда star восстанавливает файловую систему из резервных копий, она создает базу данных с записями для всех извлеченных объектов, которые содержат имя файла, исходный номер inode из резервной файловой системы и новый номер inode, который используется в извлеченной файловой системе. Это позволяет звездочке отслеживать все изменения между двумя инкрементами.
Когда вы переименовываете каталог на верхнем уровне файловой системы, star просто нужно сделать резервную копию корневого каталога и переименованного каталога с его метаданными, но ни одного файла из содержимого этого каталога.
Star использовался для ежедневного кумулятивного инкрементного резервного копирования и восстановления файловых систем Berlios (обычно 2-10 ГБ измененных данных в день) в течение 10 лет и никогда не приводил к сбоям.
Прежде чем вы начнете использовать gtar для резервного копирования, вы можете сначала запустить аналогичные тесты восстановления.
Кстати: вот сценарий, который проверяет, как GNU tar выходит из строя при инкрементном восстановлении: Можно ли использовать tar для полных резервных копий системы?