Организация хранения большого количества небольших файлов в нескольких контейнерах с одной точкой монтирования. Как?

Question

[wcyb]

Есть примерно 1,5 терабайта аудио данных (аудиобиблиотеки, музыка и др) как в lossy так и в lossless, на данный момент файлов больше 200 тысяч. Есть как простаивающие данные, так и часто обновляющиеся (изменяются и добавляются новые). Эти данные бэкапятся в облако (зеркалятся между разными облачными дисками). Раньше (и пока что сейчас) данные хранились и бекапились в открытом виде (имею ввиду как есть - обычными файлами), чтобы их можно было просматривать/пользоваться (как в облаке так и локально) и редактировать.
Так как данных становится все больше, такой вариант хранения и бэкапов больше не устраивает, сейчас загрузка по сети занимает очень много времени (больше недели всей аудиотеки), при значительных изменениях (условно от 50Гб, хотя может быть и больше) частичная загрузка/синхронизация тоже идет долго. Фактически, при доступных 100Мбит/с средняя скорость загрузки ~13Мбит/с (это уже при отключении сверки файлов по md5).

Хочу перейти на хранение в динамических контейнерах (как локально, так и в облаке) и работать только локально примонтировав контейнер. Но тут появляется другая проблема хранения и передачи одного большого контейнера, который может легко запороться если начнутся проблемы с жестким диском и в целом тоже неудобен. Поэтому vhd, veracrypt и подобные решения не подходят.

Сейчас безуспешно ищу контейнер, который может разбиваться на части определенного размера и будет монтироваться как один диск, и в идеале будет безошибочно монтироваться при отсутствующих частях, допустим есть битый файл контейнера (часть контейнера), и контейнер будет монтироваться и работать корректно, но с отсутствием данных из битого файла. Есть ли вообще такой контейнер, который умеет так? Из систем используется как windows (10 версия), так и linux.

Я в принципе готов руками создавать отдельные контейнеры, заполнять их, главное чтобы они монтировались как один диск. Вроде как есть вариант хранения в нескольких vhd в soft raid 0, но даже если это работает все сломается при выходе из строя хотя бы одного контейнера

Answer 1

[АртемЪ]

Да никак.
Во первых контейнеров с такими характеристиками не существует.
Во вторых контейнеры тут ничем не помогут.

Фактически, при доступных 100Мбит/с средняя скорость загрузки ~13Мбит/с (это уже при отключении сверки файлов по md5).

Контейнеры тут ничем не помогут.

С файлами без контейнеров работать проще и быстрее.

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

Чем бэкапите?

Думаю все проблемы из-за того что бэкап идет сразу в облако.

Comments

[wcyb]

Да никак.
Во первых контейнеров с такими характеристиками не существует.

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

Контейнеры тут ничем не помогут.

Почему же? Загружать/скачивать и сверять 2000 небольших файлов или один контейнер с этими файлами

С файлами без контейнеров работать проще и быстрее.

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

Чем бэкапите?

rclone

[АртемЪ]

wcyb,

Почему же? Загружать/скачивать и сверять 2000 небольших файлов или один контейнер с этими файлами

Если бы файлы у вас были действительно небольшими - килобайты, десятки килобайт, то да.
А с файлами от мегабайта и более никакого выигрыша не будет.
По поводу проверки - нормальные утилиты бэкапа ориентируются на атрибут "архивный" - файлы которые не изменялись, не читаются и не проверяются.
А вот в случае с контейнером - при малейшем изменении контейнера придется перечитывать весь контейнер.

rclone

Попробуйте zpaq. На файлах такого размера вполне неплохо себя показывает.
У вас там дубли в коллекции есть?

По опыту - бэкап файловой шары размером более четырех террабайт занимает очень немного времени. Ну и файлов там явно больше 300тыс.
Если первый бэкап - тут в любом случае прилично по времени, а потом изменения буквально десяток минут. Время зависит от объема измененных данных.

Ну и такой момент - я не знаю как rclone работает. Что будет если вы переместите 10 файлов общим размером 30мегабайт из одной папки в другую? Он 30мегабайт в архив загонит, или нет?

Фактически, при доступных 100Мбит/с средняя скорость загрузки ~13Мбит/с

А вы уверены что облачное хранилище куда вы грузите в принципе способен принимать файлы с большей скоростью?
Насколько я понимаю - 100мбит/с это тариф в интернет, а 13мбит/с это скорость загрузки в облако.

И еще момент - скорость бэкапа может очень сильно падать, если вы делаете его напрямую в облако.
Обычно гораздо быстрее сделать бэкап на локальный диск, а потом залить его в облако.
А так - он у вас будет мелкими порциями в облако закидывать, скорость просядет.

[wcyb]

Думаю все проблемы из-за того что бэкап идет сразу в облако

Все верно поняли + бекапятся они как есть, без запаковки

Ну и такой момент - я не знаю как rclone работает. Что будет если вы переместите 10 файлов общим размером 30мегабайт из одной папки в другую? Он 30мегабайт в архив загонит, или нет?

Тут проблема больше в самих облаках, а не в инструментах. Какие то облачные хранилища позволяют/предоставляют нужные api, какие-то нет. У rclone грубо говоря отдельные конфиги под каждый поддерживаемый облачный диск, и исходя из того с каким облачным диском производится работа, такой и будет функционал. На примере перемещения: если облако поддерживает перемещение (предоставляет такую возможность), то 10 файлов будут просто перемещены на стороне сервера, иначе будет удаление и перезалив в новую папку

А вы уверены что облачное хранилище куда вы грузите в принципе способен принимать файлы с большей скоростью?

Да, и на прием и на отдачу, проблема вот только с аудио - это получается самые мелкие файлы и самое большое количество из всего что заливается в облако, более мелкие файлы (документы, исходники и др) бекаплю архивами

Попробуйте zpaq. На файлах такого размера вполне неплохо себя показывает.
У вас там дубли в коллекции есть?

Дублей нет, про zpaq понял, если хранить не в открытом виде, то вполне интересная штука, и на независимые блоки делит как понял

Обычно гораздо быстрее сделать бэкап на локальный диск, а потом залить его в облако.
А так - он у вас будет мелкими порциями в облако закидывать, скорость просядет.

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

[АртемЪ]

Тут проблема больше в самих облаках, а не в инструментах.

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

zpaq это дедупликатор и архиватор в одном флаконе. Умеет как дедупликацию так и сжатие.
У него есть очень полезная штука для организации бэкапов - файл индексов.
Т.е вы можете сделать первый бэкап, залить его в облако, а локально оставить только индекс.
В результате вам не нужно хранить весь бэкап локально, можно частями сливать в облако и удалять локальные бэкапы. Для работы нужен только небольшой индексный файл, где хранятся хэши всех блоков в архиве.

[wcyb]

zpaq это дедупликатор и архиватор в одном флаконе. Умеет как дедупликацию так и сжатие.
У него есть очень полезная штука для организации бэкапов - файл индексов.
Т.е вы можете сделать первый бэкап, залить его в облако, а локально оставить только индекс.
В результате вам не нужно хранить весь бэкап локально, можно частями сливать в облако и удалять локальные бэкапы. Для работы нужен только небольшой индексный файл, где хранятся хэши всех блоков в архиве

Исчерпывающе, как раз хотел уточнить это. Спасибо, буду использовать

Answer 2

[athacker]

Вариант хранения всех файлов в облаке с монтированием локально по WebDAV вам не подойдёт? Винда умеет WebDAV-хранилища монтировать как локальный диск.

Comments

[wcyb]

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

Answer 3

[wcyb]

Почти полностью удовлетворяющий вариант пока додумал следующий: каждый конечный каталог проектов и группированных коллекции превратить в динамический vhd и монтировать как папку, воссоздав при этом скелет каталогов до целевых каталогов. Схема примерно такая:

main
-- projects
---- project1.vhd folder
---- project2.vhd folder
---- ...
-- sub1
---- sub1_1
------ library1.vhd folder
------ library2.vhd folder
------ ...
---- collection1.vhd folder
---- ...
-- music
---- discography1.vhd folder
---- ... 
-- ...

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

единственное что в процессе создания/редактирования временных файлов в одном проекте может быть под 300Гб и более, и есть вероятность потерять весь проект при битом файле, то есть, проблема с небольшими файлами решилась, но появилась проблема с большими файлами - по идее решается руками с нарушением структуры каталогов...

ну и в любом случае загружать/скачивать в таком случае придется больше, чем обычно, что конечно минус, но на практике будет в разы быстрее при работе в пределах одного проекта. Правка 2-3 файлов в относительно большом контейнере конечно выливается в провальный сценарий

Answer 4

[loderunner84]

присмотреться к Synology