Если я поместил старые проекты в tarballs
если вы действительно
хотите максимально заблокировать этого пользователя,
создайте виртуальную машину. На самом деле chroot не изолирует этот процесс.
Если реальная виртуальная машина слишком тяжелая, возможно, вам стоит взглянуть на контейнеры Linux , облегченную версию виртуальной машины. Однако сложнее настроить.
Если вам нужно что-то еще более легкое, вы можете попробовать настроить SELinux. Может быть, даже сложнее настроить, но он должен делать именно то, что вы хотите
chroot не предназначен для использования в качестве меры безопасности, и есть различные способы обойти его.
Архивирование старых каталогов, к которым вы редко обращаетесь в качестве tarballs, определенно может улучшить производительность файловой системы резервного копирования.
Интересно, является ли это документально подтвержденным феноменом (эталоном?)
На самом деле это не столько "документированный феномен", сколько естественное следствие необходимости сканировать файловую систему и исследовать каждый файл один за другим, чтобы определить, нужно ли его резервное копирование.
Можно сократить частоту резервного копирования , как предлагает Фахим Мита , но вам может показаться проблематичным поддерживать несколько резервных копий с разной частотой (для часто обновляемого и старого архивного материала) или поддерживать списки исключений файлов и тому подобное. Если вы действительно не планируете нуждаться в доступе к этим каталогам в ближайшее время, я думаю, что это отличная идея, чтобы разобрать их. Я делал это много раз по одной и той же причине.
Я провел небольшой эталон на каталог клонированных репос - много маленьких файлов.
Вот параметры:
17002 files
4.9G
46 root directories
tar command: tar cf (no compression)
rsync command: rsync -aH --delete --stats
и результаты:
локальный rsync в пустой каталог (распакованные файлы):
real 5m36.447s
user 0m34.692s
sys 0m56.390s
Second local rsync (unpacked files):
real 0m6.810s
user 0m2.257s
sys 0m3.363s
время Tarring:
real 1m14.648s
user 0m14.278s
sys 0m2.175s
локальный rsync в пустой каталог (распакованный файлы):
real 2m6.355s
user 0m20.799s
sys 0m21.122s
Локальный rsync в пустой каталог (упакованный файлы):
real 0m0.125s
user 0m0.005s
sys 0m0.011s
Так кажется, что Tarring довольно значительно улучшает производительность. Что вполне удивительно, так это то, что Tarring + второй локальный rsync взять вместе меньше времени, чем первый локальный rsync.
Tarring также вполне значительно увеличивает скорость бегалей NO-OP RSYNC.
Я также пытался сделать Tarring с сжатием. Tarring с GZIP занял около 10 минут, LZOP не делал намного лучше (я остановил его примерно в 7 минутах). Согласно хорошему графику в http://www.linuxjournal.com/article/8051?page=0,2 , сжатие не улучшит мою пропускную способность, если самая медленная ссылка я собираюсь быть Использование является USB-кабель (прибл. 20 Мбит / с).
Rsync должен каждый раз проверять все эти файлы и папки. Это требует времени, производительности и нагрузки на сеть. Если поместить каждый проект в тарбол, то это будет означать одну проверку файла вместо тысяч. Это также экономит место.