Организация хранения большого количества небольших файлов в нескольких контейнерах с одной точкой монтирования. Как?
Есть примерно 1,5 терабайта аудио данных (аудиобиблиотеки, музыка и др) как в lossy так и в lossless, на данный момент файлов больше 200 тысяч. Есть как простаивающие данные, так и часто обновляющиеся (изменяются и добавляются новые). Эти данные бэкапятся в облако (зеркалятся между разными облачными дисками). Раньше (и пока что сейчас) данные хранились и бекапились в открытом виде (имею ввиду как есть - обычными файлами), чтобы их можно было просматривать/пользоваться (как в облаке так и локально) и редактировать.
Так как данных становится все больше, такой вариант хранения и бэкапов больше не устраивает, сейчас загрузка по сети занимает очень много времени (больше недели всей аудиотеки), при значительных изменениях (условно от 50Гб, хотя может быть и больше) частичная загрузка/синхронизация тоже идет долго. Фактически, при доступных 100Мбит/с средняя скорость загрузки ~13Мбит/с (это уже при отключении сверки файлов по md5).
Хочу перейти на хранение в динамических контейнерах (как локально, так и в облаке) и работать только локально примонтировав контейнер. Но тут появляется другая проблема хранения и передачи одного большого контейнера, который может легко запороться если начнутся проблемы с жестким диском и в целом тоже неудобен. Поэтому vhd, veracrypt и подобные решения не подходят.
Сейчас безуспешно ищу контейнер, который может разбиваться на части определенного размера и будет монтироваться как один диск, и в идеале будет безошибочно монтироваться при отсутствующих частях, допустим есть битый файл контейнера (часть контейнера), и контейнер будет монтироваться и работать корректно, но с отсутствием данных из битого файла. Есть ли вообще такой контейнер, который умеет так? Из систем используется как windows (10 версия), так и linux.
Я в принципе готов руками создавать отдельные контейнеры, заполнять их, главное чтобы они монтировались как один диск. Вроде как есть вариант хранения в нескольких vhd в soft raid 0, но даже если это работает все сломается при выходе из строя хотя бы одного контейнера
Почему же? Загружать/скачивать и сверять 2000 небольших файлов или один контейнер с этими файлами
Если бы файлы у вас были действительно небольшими - килобайты, десятки килобайт, то да.
А с файлами от мегабайта и более никакого выигрыша не будет.
По поводу проверки - нормальные утилиты бэкапа ориентируются на атрибут "архивный" - файлы которые не изменялись, не читаются и не проверяются.
А вот в случае с контейнером - при малейшем изменении контейнера придется перечитывать весь контейнер.
rclone
Попробуйте zpaq. На файлах такого размера вполне неплохо себя показывает.
У вас там дубли в коллекции есть?
По опыту - бэкап файловой шары размером более четырех террабайт занимает очень немного времени. Ну и файлов там явно больше 300тыс.
Если первый бэкап - тут в любом случае прилично по времени, а потом изменения буквально десяток минут. Время зависит от объема измененных данных.
Ну и такой момент - я не знаю как rclone работает. Что будет если вы переместите 10 файлов общим размером 30мегабайт из одной папки в другую? Он 30мегабайт в архив загонит, или нет?
Фактически, при доступных 100Мбит/с средняя скорость загрузки ~13Мбит/с
А вы уверены что облачное хранилище куда вы грузите в принципе способен принимать файлы с большей скоростью?
Насколько я понимаю - 100мбит/с это тариф в интернет, а 13мбит/с это скорость загрузки в облако.
И еще момент - скорость бэкапа может очень сильно падать, если вы делаете его напрямую в облако.
Обычно гораздо быстрее сделать бэкап на локальный диск, а потом залить его в облако.
А так - он у вас будет мелкими порциями в облако закидывать, скорость просядет.
Думаю все проблемы из-за того что бэкап идет сразу в облако
Все верно поняли + бекапятся они как есть, без запаковки
Ну и такой момент - я не знаю как rclone работает. Что будет если вы переместите 10 файлов общим размером 30мегабайт из одной папки в другую? Он 30мегабайт в архив загонит, или нет?
Тут проблема больше в самих облаках, а не в инструментах. Какие то облачные хранилища позволяют/предоставляют нужные api, какие-то нет. У rclone грубо говоря отдельные конфиги под каждый поддерживаемый облачный диск, и исходя из того с каким облачным диском производится работа, такой и будет функционал. На примере перемещения: если облако поддерживает перемещение (предоставляет такую возможность), то 10 файлов будут просто перемещены на стороне сервера, иначе будет удаление и перезалив в новую папку
А вы уверены что облачное хранилище куда вы грузите в принципе способен принимать файлы с большей скоростью?
Да, и на прием и на отдачу, проблема вот только с аудио - это получается самые мелкие файлы и самое большое количество из всего что заливается в облако, более мелкие файлы (документы, исходники и др) бекаплю архивами
Попробуйте zpaq. На файлах такого размера вполне неплохо себя показывает.
У вас там дубли в коллекции есть?
Дублей нет, про zpaq понял, если хранить не в открытом виде, то вполне интересная штука, и на независимые блоки делит как понял
Обычно гораздо быстрее сделать бэкап на локальный диск, а потом залить его в облако.
А так - он у вас будет мелкими порциями в облако закидывать, скорость просядет.
Если заливать эти файлы по расписанию без паковки как есть, то с локального бекапа в облако они же будут загружаться так же долго. Нет, резон в локальном бекапе конечно есть (и в плане отслеживания изменений и в плане скорости), и для себя считаю что он обязателен, но пока так как есть (как обычно, на что-то сейчас есть ресурсы и выделяются, на что-то пока нет)
Тут проблема больше в самих облаках, а не в инструментах.
Нет, тут проблема чисто в инструменте.
Например если мы бэкапим чем нибудь вроде zpaq - делаем бэкап, потом перемещаем 2тб из одной папки в другую - и снова делаем бэкап - второй бэкап будет в десяток килобайт размером. Не важно куда вы будете его - в облако, на фтп, или на локальный диск.
zpaq это дедупликатор и архиватор в одном флаконе. Умеет как дедупликацию так и сжатие.
У него есть очень полезная штука для организации бэкапов - файл индексов.
Т.е вы можете сделать первый бэкап, залить его в облако, а локально оставить только индекс.
В результате вам не нужно хранить весь бэкап локально, можно частями сливать в облако и удалять локальные бэкапы. Для работы нужен только небольшой индексный файл, где хранятся хэши всех блоков в архиве.
zpaq это дедупликатор и архиватор в одном флаконе. Умеет как дедупликацию так и сжатие.
У него есть очень полезная штука для организации бэкапов - файл индексов.
Т.е вы можете сделать первый бэкап, залить его в облако, а локально оставить только индекс.
В результате вам не нужно хранить весь бэкап локально, можно частями сливать в облако и удалять локальные бэкапы. Для работы нужен только небольшой индексный файл, где хранятся хэши всех блоков в архиве
Исчерпывающе, как раз хотел уточнить это. Спасибо, буду использовать
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.