LINUX.ORG.RU

подскажите со способом архивирования файлов


0

1

привет.

имеется структура каталогов, содержащая от миллиона до двух мелких файлов. файлы, в основном не превышают в размере 1 кб. как правило - 400-700 байт.

проблема в том, что архивация этих файлов занимает невероятно много времени, и основной время это ожидание ввода-вывода.

подскажите, каким образом можно производить бэкапирование, чтоб сократить время?

благодарен.

★★★

два вопроса:
1. где описание текущей схемы
2. почему не tar

zolden ★★★★★ ()
Ответ на: комментарий от zolden

1. где описание текущей схемы

да, неподумал... сейчас tar и используется. и именно на него уходит почти все время. на сжатие полученного тарболла уходит приблизительно 8 процентов времени относительно времени создания тарболла.

niXman ★★★ ()
Ответ на: комментарий от vahtu

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

niXman ★★★ ()
Ответ на: комментарий от niXman

Ты слишко расплывчато пишешь. Так что история успеха.

Хост: debian stable. Куча виртуалок ~120Гб.

В 00 паковались все образы. tar+gzip паковал медленно. Пришлось использовать 7zip. Выиграл час.

как думаете, при использовании RAID, на сколько получится сократить время бэкапирования?

На 0 150МБ/сек.

vahtu ()

2 миллиона * 1кб = 1Gbyte

Выделить отдельный раздел (lvm, чтобы можно было нарастить по мере надобности) для этих файлов и бэкапить его через dd (снапшот)

Если нет lvm, то сделать ФС в файле (losetup или mount -o loop) и бэкапить этот файл-ФС

sdio ★★★★★ ()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от vahtu

лень гуглить, но, как мне помнится 7zip не рекомендован для продакшена

zolden ★★★★★ ()
Ответ на: комментарий от Lighting

А почему бы не воспользоваться tmpfs?

Ты о чем?

sdio ★★★★★ ()
Ответ на: комментарий от sdio

Ну, держать эти файлы в памяти. Или, что даже удобнее, использовать squashfs и/или aufs.

Lighting ★★★★★ ()
Ответ на: комментарий от Lighting

Если пара независимых хранилищ, и есть root права, чтобы сменить юзера, то рулит. А вообще ты прав: даже в man'е так написано.

vahtu ()
Ответ на: комментарий от Lighting

Они же не временные, а постоянные, надо будет при загрузке в память перекидывать и постоянно с диском синхронизировать. Не нужно. Достаточно вынести их с основной ФС (привет тем кому достаточно /, /home и swap и кому не нужен LVM), на выделенный logical volume (partition) и бэкапить весь раздел (dd)

sdio ★★★★★ ()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от sdio

Ну, всё-таки такие бекапы сложно назвать гибкими. А сквош и обновить можно.

Lighting ★★★★★ ()
Ответ на: комментарий от Lighting

такие бекапы сложно назвать гибкими

Речь не о гибкости, а о времени (скорости).

sdio ★★★★★ ()
Ответ на: комментарий от niXman

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

zolden ★★★★★ ()
Ответ на: комментарий от Lighting

Это почему нельзя назвать гибкими? Можно и назад примаунтить..

Tanger ★★★★★ ()
Ответ на: комментарий от zolden

показывай уж всю схему полностью

какие еще моменты интересуют? не описывать же все и полностью =)

такая еще подсказка, вдруг важно: файлы не удаляются. только добавляются и изменяются.

niXman ★★★ ()
Ответ на: комментарий от niXman

команду которой таришь покажи
это понятно, что не все твои тысячи миллионов разные между бэкапами, поэтому инкрементальный бэкап или использование append у tar'а могут дать большой выигрыш

zolden ★★★★★ ()
Ответ на: комментарий от Lighting

Смонтировать - допустим, но не изменить же.

Изменить что? Бэкап? Зачем его менять то?

sdio ★★★★★ ()
Ответ на: комментарий от zolden

поэтому инкрементальный бэкап

по метаданным пройтись и занимает массу времени. попробуй ls -l на таком кол-ве файлов.

sdio ★★★★★ ()
Ответ на: комментарий от sdio

да я не спорю, что dd будет быстрее, но если нет возможности сделать отдельный раздел, то надо перебирать варианты

zolden ★★★★★ ()
Ответ на: комментарий от sdio

по метаданным пройтись и занимает массу времени.

именно. я же об этом в топике написал.

niXman ★★★ ()
Ответ на: комментарий от Lighting

А почему нет? Или я что-то не понимаю?

Идея - взять создать с помощью dd файл на 2-3 гб , создать там fs, примонтировать, записать все эти миллионы файлов туда, отмнонтировать и переместить файл в директорию с бекапами (можно сжать).

Tanger ★★★★★ ()
Ответ на: комментарий от Tanger

создать там fs, примонтировать, записать все эти миллионы файлов туда, отмнонтировать и переместить файл в директорию с бекапами (можно сжать).
записать все эти миллионы файлов туда, отмнонтировать и переместить файл в директорию
записать ... отмнонтировать ... переместить

И в чем выгода? Каждый день будете гонять в файл-ФС миллионы файлов? Вы все неправильно поняли. Файлы надо перенести на небольшую фс один раз, а в бэкап лить один большой файл — образ файловой системы.

sdio ★★★★★ ()
Ответ на: комментарий от sdio

Каждый день будете гонять в файл-ФС миллионы файлов

а если rsync?
миллионы файлов то будет только в первый раз, дальше - легче

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Не. rsync все-равно должен каждый раз просмотреть размер и дату каждого файла и в худшем случае еще и посчитать контр.сумму по содержимому.

sdio ★★★★★ ()
Ответ на: комментарий от sdio

Файлы надо перенести на небольшую фс один раз, а в бэкап лить один большой файл — образ файловой системы.

так и сделаю. спасибо. вопрос закрыт.

niXman ★★★ ()
Ответ на: комментарий от Lighting

Может тогда лучше SSD? Не придется заливать каждый раз в оперативку.

YAR ★★★★★ ()

а вот для таких задач рулит ZFS =) и снапшоты.

Komintern ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.