Можно ли добавлять файлы в место -в tar-архив?

Во-первых, это в значительной степени основано на мнении. Если вы спросите дюжину разных людей, вы, скорее всего, получите как минимум 3 -4 разных ответа.

Тем не менее, вот мое мнение по этому поводу:

  • Держите /homeотдельно от /. Основные рассуждения здесь в основном те же, что и всегда. Это затрудняет для ваших пользователей случайное использование всего пространства на /и значительно упрощает сохранение пользовательских данных, если вам нужно повторно -установить. Кроме того, он изолирует одну из самых больших частей большинства систем от остальной системы, что может быть особенно полезно для управления резервным копированием.
  • Держите /tmpи /var/tmpотдельно от /. Обе эти области используются для временного хранения, и количество изменений, которые это может вызвать в корневой файловой системе, может иметь значительное долгосрочное влияние на ее производительность. Кроме того, данные гарантированно будут временными с относительно коротким временем жизни. Это означает, что вам не следует создавать их резервные копии (, это просто пустая трата места ), и, вероятно, вы не будете копировать их при перемещении на новый диск. Тем не менее, /tmpобычно должен быть экземпляром tmpfsв наши дни, и /var/tmpобычно тоже должен быть, если вы можете разместить все, что может быть там в ОЗУ.
  • Немного противоречиво и гораздо более агрессивно, но изолируйте каталоги вашего глобального кеша от файловых систем, в которых они обычно находятся.Каноническим примером является /var/cache, но могут быть и другие, в зависимости от вашей конкретной системы. (Я думаю, что /var/cacheполностью охватывает его в Debian, хотя ). Это имеет много тех же преимуществ, что и изоляция /tmp, /var/tmpи /home, но также дает вам четкую область, для которой вам не нужно резервировать (это кеш, если приложение ломается, потому что оно не может найти там данные, это плохо написанное приложение ), и поэтому его также не нужно копировать при перемещении на новый диск.
  • Храните наборы данных отдельно от /. Это намеренно абстрактно, но включает в себя такие вещи, как страницы и данные для любых веб-сайтов, размещенных в системе, внутреннее хранилище -для любой базы данных или служб каталогов, предоставляемых системой, и другие подобные вещи. Изоляция этих данных дает два больших преимущества. Во-первых, он обеспечивает те же общие преимущества, что и разделение /homeи /. Во-вторых, это, по крайней мере, частично отделяет производительность корневой файловой системы от производительности ваших томов данных. Это также позволяет вам перемещать эти наборы данных в другие конфигурации хранения, не влияя напрямую на остальную часть системы, что может означать разницу между периодом онлайн-обслуживания (, когда сервис просто ухудшается, но не полностью отключается )и вне линии -.
  • Храните «одноразовые» данные, которые можно тривиально регенерировать или повторно получить, отдельно от других данных. Примеры включают общедоступные данные из Интернета (git-репозиториев, индексы репозиториев пакетов, образы ISO и т. д. ), а также вещи, которые настолько тривиальны, что вы не стали бы создавать их резервные копии. В основном это делается для упрощения планирования резервного копирования, но также может помочь при переходе на новый диск (, а именно, у вас нет необходимости копировать большую часть или даже все эти данные, потому что вы можете просто повторно получить/регенерировать его по мере необходимости ).
  • Храните структуры каталогов, не управляемые вашим менеджером пакетов, отдельно от тех, которые находятся под его управлением. Это не обязательно, но может значительно упростить как обновление, так и переустановку. Технически это включает в себя то, что я упомянул выше, но в данном случае я имею в виду /optи /usr/local. Обратите внимание, что/optможет содержать данные, управляемые вашим менеджером пакетов (, например, Dropbox и Google Chrome устанавливаются там ).
0
20.06.2021, 19:01
2 ответа

Примечание

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

Ответ

Итак, проблема :Вы не можете "освободить" пространство, используемое файлом, пока не закончите его чтение; поэтому стандартные подходы к помещению файлов в tarархив не могут работать, потому что это в основном:

  • прочитать свойства первого файла (имя, длину, владельца и т. д.)
  • записать заголовок, содержащий эту информацию, в файл.tar в позицию 0; этот заголовок имеет длину 512 байт
  • копировать содержимое первого файла после заголовка, дополнить нулями -дополнить до следующего кратного 512 байтам (дополнить нулями)
  • прочитать свойства второго файла
  • записать заголовок для второго файла после конца первого файла
  • скопировать содержимое второго файла, выровняв по следующему кратному 512 Б
  • наконец, удалите оба файла

Как видите,tar-архивы можно очень просто объединить. К сожалению, вы даже не можете скопировать содержимое одного файла в tar-архив, затем удалить его, а затем заархивировать следующий, потому что вам не хватит места до того, как первый закончит запись (, и нет способа POSIX усекая начало файла, который вы уже прочитали ). Итак, подход Камиля из комментариев выше не работает.

Таким образом, пока ваша файловая система не поддерживает релинковку частей файлов, это невозможно. (Единственными файловыми системами Linux, которые в настоящее время (июнь 2021 г.) поддерживают это, являются XFS и btrfs. Однако вам придется написать это программное обеспечение самостоятельно; вы захотите исследовать man ioctl_ficlonerange, что позволит вам разделить память, используемую исходными файлами и архивными файлами.)


Тем не менее, наличие tar-файла размером 100 ГБ само по себе звучит довольно бесполезно; что ты собираешься с этим делать? Вы скопируете его на другое устройство или по сети, и в этом случае вам никогда не придется иметь его на своем собственном диске!

Вы бы просто создали этот tar-архив на лету вместо того, чтобы сначала генерировать его на своем жестком диске, а затем копировать. tarвсе равно, записывает ли результат в файл, блочное устройство(tar— это сокращение от T ape Ar chive, в любом случае! )или сетевой сокет.

То, что то, что вы хотите сделать, невозможно¹, может быть удручающим -, но я думаю, что вы решаете не -проблему.

¹ если только ваши файлы не находятся в одной и той же файловой системе XFS или btrfs, и вы знаете, что такое ioctlи не хотите писать код

0
28.07.2021, 11:23

The tar archive will be uploaded to a long-term cloud storage solution (e.g. Amazon S3 Glacier Deep Archive, Google Cloud Archive Storage, etc.).

Ах! Так что вам никогда не понадобится tar-архив на вашем диске!

Вместо этого вы можете создать tar-архив на лету, загружая его на amazon S3 или куда-то еще. Кроме того, вам действительно нужно сжатие, потому что вы платите за объем.

Решение должно быть довольно простым:

tar c fileA fileB | aws s3 cp s3://mybucket/backup.tar -
    : :     :     :           :                        :
    : :     :     :           :                        \- read data from stdin
    : :     :     :           \- How to call the object
    : :     :     \- unix pipe: the stdout of the
    : :     :        tar command becoms the stdin
    : :     :        of the aws command.
    : \-----\- files to be compressed
    \--compression command

Лично, особенно когда вы говорите, что у вас есть тысячи очень маленьких файлов, накладные расходы формата tarстановятся очень значительными. Я бы рекомендовал использовать

tar c --zstd file1 file2 … file1000 | aws s3 cp s3://mybucket/backup.tar.zst -

, чтобы на лету сжимать данные. Это экономит ваше время загрузки, платное пространство на вашем облачном хостинге и, как правило, это правильное решение.

1
28.07.2021, 11:23

Теги

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