Команда tar --append завершается ошибкой «Cannot update compressed archives», а задание резервного копирования с типом append внезапно раздувает хранилище — именно с таких симптомов обычно начинается знакомство с режимом добавления в архив. Тип архива append означает, что новые данные дописываются в конец уже существующего архивного файла, а не создают архив заново. Этот режим встречается и в классических архиваторах, и в системах резервного копирования, где набор данных пополняется инкрементально.
Понимание того, как работает добавление, критично для безопасности данных: при неправильном использовании append можно получить архив с дублирующимися версиями файлов, нечитаемый индекс или битую структуру, которую невозможно распаковать штатными средствами. Ниже разберём принцип работы, поддержку в популярных форматах и типичные ошибки.
Что означает тип архива append
В контексте архивации термин append (от англ. «добавить в конец») описывает операцию, при которой новые файлы или блоки данных присоединяются к существующему архиву без его полной перезаписи. Это принципиально отличается от создания нового архива: исходная структура сохраняется, а свежие данные занимают место после уже записанных.
Важно различать два разных применения термина. Во-первых, это режим обновления архива в архиваторах вроде tar, где файлы физически дописываются в конец файла-контейнера. Во-вторых, в системах резервного копирования (Bacula, Bareos, некоторые NAS-утилиты) append может обозначать тип задания или тома, при котором сессии бэкапа последовательно дописываются на один носитель или в один файл-хранилище, пока тот не заполнится.
Ключевая особенность режима — добавление не удаляет и не заменяет старые версии файлов внутри архива. Если файл с тем же именем уже есть в архиве, после append в нём окажутся обе копии, и при распаковке, как правило, будет извлечена последняя записанная. Это одновременно и преимущество (сохраняется история), и источник проблем (неконтролируемый рост размера).
Как работает добавление на уровне формата
Формат tar устроен как последовательность блоков: заголовок файла, затем его содержимое, затем заголовок следующего файла. Такая линейная структура позволяет дописывать данные в конец без перестройки всего архива — достаточно найти конец полезных данных (до завершающих нулевых блоков) и продолжить запись. Именно поэтому tar исторически поддерживает ключ -r (--append).
Иная ситуация с форматами, использующими централизованный индекс. В ZIP в конце файла хранится центральный каталог со смещениями всех записей, поэтому «добавление» фактически означает перезапись хвоста файла с обновлением каталога. В 7z заголовок может быть сжат и зашифрован целиком, и модификация архива требует пересборки индекса. Практический вывод: возможность и цена операции append напрямую зависят от внутреннего устройства формата.
Append эффективен только в потоковых форматах без единого сжатого индекса. Чем сложнее структура заголовков, тем дороже обходится «добавление» — вплоть до полной перезаписи архива.
Поддержка append в популярных архиваторах
Поведение режима добавления заметно различается между инструментами. Сводная картина по распространённым форматам приведена ниже — она помогает заранее выбрать подходящий инструмент под задачу пополняемого архива.
| Формат / инструмент | Поддержка append | Особенности |
|---|---|---|
| tar (несжатый) | Полная, ключ -r | Дописывает файлы в конец; старые версии не удаляются |
| tar.gz / tar.bz2 | Нет | Сжатый поток нельзя дополнить штатно; требуется распаковка и пересборка |
| ZIP | Условная | Обновление через перезапись центрального каталога |
| 7z | Через обновление | Утилита пересобирает индекс; при solid-сжатии фактически перепаковывает блоки |
| RAR | Через обновление | Поддерживает добавление файлов, но это не «чистое» дописывание |
⚠️ Внимание: попытка применить
tar -rк сжатому архиву (.tar.gz, .tgz) приведёт к ошибке либо к повреждению файла. Сжатый поток gzip нельзя дописать «в середину» — сначала архив распаковывается, затем пересобирается заново. Перед операцией проверьте тип файла командойfile имя_архива.
Практика: добавление файлов в tar-архив
Базовый сценарий выглядит просто: у вас есть несжатый архив backup.tar, и в него нужно добавить новую папку с логами. Используется ключ -r совместно с -f (указание файла архива):
tar -rf backup.tar /var/log/myapp/Проверить, что данные действительно попали в архив, можно просмотром содержимого без распаковки: tar -tf backup.tar. В списке появятся как старые, так и свежедобавленные записи. Если файл с тем же путём уже существовал, вы увидите его дважды — это нормальное поведение режима append, а не ошибка.
☑️ Безопасное добавление в архив
Для удаления устаревших дублей в tar предусмотрен отдельный ключ --delete, но он работает только с несжатыми архивами и физически перестраивает файл. Если архив большой, операция может занять заметное время — планируйте её вне пиковой нагрузки.
Если архив нужно регулярно пополнять и при этом сжимать, используйте связку: ведите рабочий несжатый tar для append-операций, а сжатую копию создавайте отдельно по расписанию. Так вы получите и быстрое добавление, и экономию места на хранении.
Append в системах резервного копирования
В корпоративных системах бэкапа термин приобретает дополнительный смысл. В Bacula и её форке Bareos тома (volumes) по умолчанию работают в режиме append: каждая новая задача резервного копирования дописывает свои данные в конец тома, пока тот не достигнет лимита по размеру, времени или числу заданий. После исчерпания лимита том переводится в состояние, запрещающее дальнейшую запись, и используется следующий.
Такой подход экономит ресурсы: не нужно создавать отдельный файл под каждую сессию, а последовательная запись дружелюбна к ленточным накопителям, где перемотка и случайный доступ крайне медленны. Собственно, сам формат tar и логика append исторически выросли из эпохи ленточных архивов — отсюда и потоковая структура.
- 📼 Ленточные библиотеки — append является естественным режимом записи на ленту.
- 💾 Дисковые пулы — пополняемые тома упрощают ротацию и учёт сессий.
- 🔄 Инкрементные копии — только изменённые данные дописываются к существующему набору.
- 🗄️ Долгосрочное хранение — история версий сохраняется внутри одного контейнера.
Типичные проблемы и их диагностика
Самая частая жалоба — архив растёт быстрее, чем ожидалось. Причина почти всегда в том, что append не заменяет старые версии: при каждом добавлении изменённого файла его полная копия дописывается заново. Диагностика проста: сравните tar -tf архив | sort | uniq -d — дублирующиеся пути покажут, какие файлы накапливаются в нескольких версиях.
Вторая типичная ситуация — повреждение структуры после прерванной операции добавления. Если запись оборвалась на середине (сбой питания, нехватка места), в конце архива может остаться обрезанный блок. Признаки: ошибки чтения при распаковке, несовпадение контрольных данных, отказ архиватора показать содержимое. Восстановление такого файла — задача нетривиальная; надёжнее иметь копию до операции append.
⚠️ Внимание: никогда не выполняйте append в единственный экземпляр архива с критичными данными. Операция записи в конец файла при сбое способна повредить и ранее записанное содержимое. Сначала копия — потом добавление.
Почему нельзя дописать в сжатый архив напрямую
Алгоритмы сжатия (gzip, bzip2, xz) обрабатывают данные как единый поток, где каждый блок зависит от предыдущего контекста. Дописывание данных в конец сжатого потока требует корректного завершения старого потока и начала нового — штатные утилиты этого не делают. Формально gzip допускает конкатенацию нескольких сжатых потоков, но поддержка такой структуры со стороны tar и архиваторов не гарантирована, поэтому стандартная практика — распаковать, дополнить и сжать заново.
Когда append — плохой выбор
Есть сценарии, где режим добавления создаёт больше проблем, чем решает. Если архив должен быть компактным и предсказуемым по размеру — накопление дублей противопоказано. Если требуется гарантированная целостность каждой копии — лучше независимые полные архивы с контрольными суммами. Если данные распаковываются часто и выборочно — линейный формат с дублями замедляет извлечение.
- 🚫 Частые обновления одних и тех же файлов — архив раздувается дублями.
- 🚫 Требование компактности — пересборка с нуля эффективнее.
- 🚫 Передача по сети — получателю придётся скачивать избыточные версии.
- 🚫 Дедупликация на стороне хранилища — дубли внутри архива мешают ей работать.
В таких случаях разумнее рассмотреть инструменты со встроенной дедупликацией и снапшотной моделью — например, restic или borg, где «добавление» реализовано на уровне блоков данных, а не сырых файлов. Там повторно добавленные неизменённые данные не занимают место повторно.
Append — инструмент для сценариев «записал и забыл»: логи, ленты, инкрементные тома. Для часто обновляемых и компактных архивов выбирайте пересборку или дедуплицирующие системы бэкапа.
Частые вопросы о типе архива append
Чем append отличается от update в архиваторах?
Append дописывает файлы в конец архива безусловно, даже если они там уже есть. Update (например, ключ -u в tar) добавляет файл только если его версия новее уже записанной. Однако в tar обе операции не удаляют старые копии физически — разница лишь в условии добавления.
Можно ли добавить файлы в архив .tar.gz?
Штатно — нет. Сжатый поток нельзя дополнить ключом -r. Необходимо распаковать архив, добавить файлы в несжатый tar и сжать заново. Либо изначально вести несжатый архив для пополнения.
Почему после append архив стал в два раза больше?
Потому что старые версии файлов не удаляются: если вы добавили изменённый файл, в архиве теперь две его полные копии. Проверить дубли можно командой tar -tf архив | sort | uniq -d.
Что значит append в настройках Bacula или Bareos?
Это режим тома, при котором каждое новое задание резервного копирования дописывает данные в конец существующего тома, пока не сработают заданные администратором ограничения (размер, срок, число заданий). После этого том закрывается для записи.
Безопасно ли прерывать операцию append?
Нет. Прерывание записи может оставить в конце архива обрезанный блок и сделать часть данных нечитаемой. Перед операцией с ценным архивом создайте его копию, а прерванный файл проверяйте на целостность до любых дальнейших действий.