LINUX.ORG.RU
ФорумAdmin

Оцените архиватор (дедупликатор) hashget для бэкапов. (архив менее 1%)

 , , , ,


5

1

Привет!

Поглядите пожалуйста мой новый «велосипед» - дедупликатор hashget. Начнем сразу с интриги:

Сравнение

Data sampleunpacked size.tar.gzhashget .tar.gz
Wordpress-5.1.143 Mb11 Mb ( 26% )155 Kb ( 0.3% )
Linux kernel 5.0.4934 Mb161 Mb ( 20% )4.7 Mb ( 0.5% )
Debian 9 (LAMP) LXC VM724 Mb165 Mb ( 23% )4.1 Mb ( 0.5% )

Предыстория

Всегда когда целиком бэкапил виртуалку, у меня было некоторое ощущение неправильности. С одной стороны, никогда нельзя просто сохранить только нужное (например, /etc, /home, /root и /var/www), потому что при восстановлении из такого бэкапа либо надо будет что-то сделать (поставить/настроить пакет какой-то), либо что-то забудешь положить в архив, например, утилитку из /usr/local/bin. А нужно - чтобы из архива автоматически получить точно ту же исходную систему, без «жаль забыл еще то и это в бэкап включить».

С другой стороны, паковать всю машину с файлами apache, mysql (о! базы mysql еще забыл в предыдущем списке) - получается примерно гигабайт исходных данных даже на скромную чистую LAMP машинку где еще нет ничего ценного. Очень большой overhead.

И еще у бэкапов есть важное свойство - делаем мы их регулярно, храним их (и оплачиваем хранение) каждый день. А вот восстанавливаемся из них - раз в 5 лет. Соответственно, лишний гиг каждого бэкапа обходится довольно дорого.

Hashget

Hashget - делает только дедупликацию. То есть, смотрит, какие из файлов для архивации можно при восстановлении просто скачать (то есть, их для вас уже кто-то надежно хранит) и подготавливает exclude file для tar (опция -X). Например, файлы из пакета apache - в бэкап не пойдут. Файлы из wordpress тоже почти все не пойдут. Но если вы что-то пропатчили (и эти новые файлы отличаются от дистрибутивных) - то эти файлы будут в архиве.

Распаковка делается в два шага автоматом, сначала tar -x …, затем hashget -u … . Он автоматом выкачает то что нужно, положит по нужным путям, выставит те же атрибуты. Вот в примере выше, крошечные архивы по 150Kb / 4M - аналогичны таким же .tar.gz архивам по 160Mb.

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

В результате

Бэкапы - гораздо меньше. Их можно делать каждый день и хранить хоть все. Это дешево. Можно пересылать по почте, в телеграм-чате, хоть на флоппи-дисках. Заливать на Amazon Glacier и забывать о них. Разложить в десяток разных мест на разных материках, чтобы даже после ядерной войны они сохранились. Все равно это все будет стоить копейки.

Вопрос

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

Интересны любые отзывы и вопросы по hashget’у.



Последнее исправление: xen0n (всего исправлений: 1)

Это называется «инкрементальный бекап». Где-то лежит полная версия и ты бекапишь только разницу

futurama ★★★★★
()

Что делать, когда файлы нужных версий станут недоступными ?
По сути изобрели инкрементальный бэкап.

Deleted
()
Ответ на: комментарий от futurama

Да, так и есть. Все уже украдено до нас :-) Только в качестве фулл (базового) бэкапа - сам Интернет, репозитории вендоров.

Обычный инкрементальный бэкап не развернуть без полного (То есть, нужно хранить, например. 1 Гиг полного + 10 Мб дельты. Потерялось что-то = потерялось все). Тут нам нужно хранить только дельту. Фулл хранится за счет debian.org, kernel.org с высокой надежностью.

Тут просто - одной командой запаковал, по scp залил на сервер(а) (очень быстро, так как бэкап короткий). Просто, как с .tar.gz, но меньше и быстрее и с примерно той же надежностью.

xen0n
() автор топика
Ответ на: комментарий от Deleted

@bdfy важное замечание, да. Не нужно, чтобы они становились недоступными. :-)

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

Для примера - у ubuntu нет движка снапшотов. Если для пакета в ubuntu вышло обновление, то скоро вы прежний не найдете в репозиториях. Но вот для debian - есть. Можно хоть с четверки (Etch) восстановиться. Если вдруг дебиан закроется или закроет проект снапшотов - нужно будет в тот же день сделать полный бэкап, для надежности.

Абсолютной надежности нет (и полный бэкап на собственном сервере так же ведь может пропасть, себе тоже доверять сильно не стоит). Но мне кажется, что когда я храню свои бэкапы дома и на дешевой VPSке - их надежность ниже, чем те данные, которые хранятся на kernel.org, snapshot.debian.org итд. Всякое брендовое железо, рейды, дублирование, итд. В общем, мы же знаем их статистику «даунтаймов» за все время. На мой взгляд - она вполне надежна. *Более надежна*, чем могу себе позволить организовать я сам. Мы перекладываем яйца в более надежную корзину.

Можно по другому на это посмотреть. Это - инкрементальный бэкап, где пользователь хранит 4мегабайтную дельту а вот базовый бэкап хранит kernel.org с его впечатляющим бюджетом для обеспечения надежности.

Но если пофантазировать про зомби-апокалипсис, мир, где (к примеру) проект Debian исчез - точно ли нам в таком мире нужно будет восстанавливать debian'овские виртуалки без апдейтов и секьюрити патчей? Я в таком мэд-макс мире без Дебиана на CentOS перейду :-)

xen0n
() автор топика
Ответ на: комментарий от xen0n

Так,так,так. На серверах вордпрессы всякие лежат в архивах. Пакеты дебиана лежат в deb пакетах, что по сути тоже архивы. Каким образом это будет сверяться с распакованным содержимым ?

Deleted
()
Ответ на: комментарий от DELIRIUM

@DELIRIUM ну где-то 9 лет ежедневной проверки надежности помогли бы развеять ваши сомнения? Вот проекты snapshot.debian.org, kernel.org - прошли ее.

.deb пакет 9-летней давности как был доступен по одному адресу, так и доступен сейчас. И был доступен всегда (может быть с перерывом на 2 минуты при ребуте).

linux kernel - linux-1.0.tar.gz от 1994 года - доступен. Четверть века уже.

Если уж что и выглядит не очень надежным, это тот комп, куда я сейчас свои бэкапы сваливаю :-) По крайней мере, я скорее ожидаю, что он сдохнет, чем kernel.org.

xen0n
() автор топика
Ответ на: комментарий от Deleted

@bdfy при распаковке?

hashget архив выглядит так - это обычный .tar.gz без дублированных файлов, + один файл .hashget-restore.json с метаинформацией.

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

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

Сразу опишу что будет в хитрых случаях.

1) В пакете есть config, вы его поправили на машине. Так как его хеш теперь уникальный, он просто пойдет в архив (не будет вырезан)

2) Какой-то файл переименовали/скопировали. /bin/ls скопировали в /usr/local/bin/my-cool-ls - Оба файла будут сокращены при паковке и восстановлены при распаковке из того же оригинала.

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

В общем, основная идея - мы знаем хэши файлов, и на месте вырезанного файла может оказаться только файл с тем же хешем.

xen0n
() автор топика
Ответ на: комментарий от xen0n

Допустим у меня есть файл с md5 хэшем ceed8613dc17b9f648a67f10fab81849. Какой пакет будешь скачивать ?
А с таким хэшем ec948921979ff47422adc8394673930d ?

Deleted
()

можно при восстановлении просто скачать

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

Нафиг-нафиг, купить диск дешевле, чем потерять время на доступности файла.

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

@bdfy Что будет скачиваться - определяется при запаковке.

При распаковке - заранее известно, что будет скачиваться (по url'ам из секции packages), они и только они.

А при запаковке - есть несколько алгоритмов.

В общем случае всегда «по локальной базе». То есть (сейчас - просто предположим, ниже по тексту поясню как это достигается) локально есть база хешей и пакетов, откуда можно извлечь этот хеш. Если файл не найден ни в одном пакете - он просто идет в архив как есть, как и в случае с обычным .tar.gz.

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

Теперь, как формируется локальная база:

1. Самый простой понятный путь - вручную. просто с ключом --submit указывается URL, скачивается и индексируется. Все. Теперь hashget знает, какие файлы можно по этому адресу скачать.

2. Эвристики. Например, для дебиана, если hashget видит, что он пакует дебиан (по файлу /var/lib/dpkg/status), из него он видит, какие пакеты установлены. Дальше запрашивает с snapshot.debian.org эти пакеты, индексирует их и потом уже сокращает файлы.

Есть эвристика чтобы обнаруживать исходный код Linux - https://gitlab.com/yaroslaff/hashget-kernel_org , отдельным пакетом, чтобы легко можно было на ее примере свои делать.

3. Хэш-сервер. Это опциональная штука, чисто для ускорения (адрес сервера можно поставить свой или отключить). Если например, эвристика обнаружила дебиановский пакет abc_1.0_amd64.deb, то она запрашивает хеш-сервер по этой сигнатуре пакета. Если на нем есть пакет - она сразу скачивает индексный файл (несколько килобайт). Это чтобы быстрее индексировать и меньше грузить snapshot.

Все индексы (они оч маленькие, по сравнению с самими данными) хранятся локально (можно удалить). Поэтому первая упаковка debian, например, может занять какое-то время (пока он проиндексирует все пакеты). Вторая будет очень быстрой (быстрее .tar.gz - так как паковать меньше). А если через неделю систему обновят, то при следующей упаковке, на этапе индексации обнаружатся 3-5-10 новых пакетов и переиндексируются только они.

xen0n
() автор топика
Ответ на: комментарий от mord0d

@mord0d Это верно, без интернета ни восстановить бэкап не получится. Ни проапдейтить старую систему из бэкапа.

Да и даже если все таки восстановил вебсервер из бэкапа, какой в нем толк, если интернета нет? :-)

Это скорее решение для будущего, ну когда везде интернет будет, в каждом дата-центре. В XXI веке может быть...

xen0n
() автор топика
Ответ на: комментарий от xen0n

При распаковке - заранее известно, что будет скачиваться

Нет распаковщика на C. На «голой» системе не «распакуешь». Это минус.

Deleted
()
Ответ на: комментарий от xen0n

Сколько времени и дискового пространства занимает первичное индексирование? Сколько времени занимает распаковка? Насколько простое использование этой тулзы, не нужно ли осваивать 100500 настроек?

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

@futurama. Так и есть. Теперь одной командой можно делать очень маленькие дельты, и не хранить базу. При этом надежность базы = надежности больших, дорогих проектов (debian, kernel, wordpress), что обычно выше, чем надежность доступная небольшой компании.

xen0n
() автор топика
Ответ на: комментарий от Deleted

@zvezdochiot да, нужен python, третий (т.е. с будущего года - уже единственный). apt-get install python3-pip.

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

xen0n
() автор топика
Ответ на: комментарий от xen0n

Если речь о распаковке виртуалок, то питон и hashget и база нужны на хост-машине.

Да, разумеется. Но всё равно это будет восприниматься как минус. Причём значительный. К распаковщикам всегда повышенные требования.

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

@goingUp

Сейчас специально для теста (ноут, i7, но довольно хилый, у меня десктоп старый на i5 гораздо быстрее)

root@braconnier:~# time hashget --pack /var/lib/lxc/mydebvm/rootfs/ -zf /tmp/mydebvm.tar.gz --exclude var/cache/apt var/lib/apt/lists
Development hashget hashdb repository
https://gitlab.com/yaroslaff/hashget
STEP 1/3 Indexing...
pulled libhtml-tagset-perl_3.20-3_all
pulled libedit2_3.1-20160903-3_amd64
...
pulled netbase_5.4_all
Indexing done in 71.23s. 0 local + 222 pulled + 0 new = 222 total packages
STEP 2/3 prepare exclude list for packing...
saved: 8515 files, 216 pkgs, size: 445.8M. Download: 98.7M
STEP 3/3 tarring...
/var/lib/lxc/mydebvm/rootfs/ (687.2M) packed into /tmp/mydebvm.tar.gz (4.0M)

real	2m22,922s
user	0m31,845s
sys	0m4,590s

Индексирование заняло 70 секунд на 222 пакета, потому что они все с хешсервера пришли. Вся запаковка - 2:23 (=143 секунды).

Повторный запуск (индексы уже локально) - 27 секунд:

# time hashget --pack /var/lib/lxc/mydebvm/rootfs/ -zf /tmp/mydebvm.tar.gz --exclude var/cache/apt var/lib/apt/lists
Development hashget hashdb repository
https://gitlab.com/yaroslaff/hashget
STEP 1/3 Indexing...
Indexing done in 0.66s. 222 local + 0 pulled + 0 new = 222 total packages
STEP 2/3 prepare exclude list for packing...
saved: 8515 files, 216 pkgs, size: 445.8M. Download: 98.7M
STEP 3/3 tarring...
/var/lib/lxc/mydebvm/rootfs/ (687.2M) packed into /tmp/mydebvm.tar.gz (4.0M)

real	0m26,739s
user	0m22,935s
sys	0m2,573s

tar занял 1m22s (82s):

root@braconnier:~# time tar -czf /tmp/mydebvm-tar.tar.gz --exclude var/cache/apt --exclude var/lib/apt/lists -C /var/lib/lxc/mydebvm/ .

real	1m22,493s
user	1m22,044s
sys	0m2,353s

Итого, при уже готовых индексах, hashget по скорости в три раза быстрее, и делает архивы в 40 раз меньше. :-)

Размер базы после индексирования:

root@braconnier:/var/cache/hashget/hashdb/_cached# du -sh
1,7M	.
(1.7 мегабайта - это на те 222 пакета, которые у нас получились по тестовой машине)

Вся запаковка делается одной командой, ключи -z, -f, --pack - довольно понятные, не сложнее tar'а. --exclude - для еще большего удобства, работают примерно как у tar. (только у tar, чтобы заэксклюдить 2 каталога, надо дважды опцию повторить, а у hashget надо 1 раз с двумя каталогами. ну как в примере выше).

Если какие-то сложности не нужны и нужно только паковать debian'ы - то в общем-то и все. (Более сложное - это если свой хешсервер держать, например)

xen0n
() автор топика
Ответ на: комментарий от xen0n

решение для будущего

Учитывая рост цен на интернет, в будущем цена за интернет будет сопоставима с WAP (с учётом безлимита можно высчитать среднюю цену за мегабайт из среднего потребления трафика). Не очень хорошее решение на будущее.

У каждого своё будущее. Кто-то верит в распределённые сети, кто-то в общественный интернет, кто-то в ARM на десктопе или тонкие клиенты.

А tar как был, так и останется. ☺

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

@zvezdochiot согласен. Распаковщик там довольно простую задачу делает (прочитать json, скачать, посчитать хеши, разложить по каталогам, сделать chmod/chown/chgrp). Основная сложность - при упаковке. (Распаковать, при желании и усердии - можно даже вручную, без hashget, через wget / sha256sum / cp)

Можно будет потом отдельно сделать на C шустрый распаковщик, если проект будет востребован.

xen0n
() автор топика
Ответ на: комментарий от xen0n

Интересная идея получается, особенно если кто-то поднимет публичный хешсервер, надо будет на досуге потыкать.

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

@goingUp - спасибо! Ну вот там по дефолту мой публичный хешсервер и используется. Но - он только для дебиана.

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

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

А вот если кто-то знает какие-то проекты, где объемы большие (а сами проекты - надежные) - тогда я в хешсервер или через плагины добавил бы их.

xen0n
() автор топика
Ответ на: комментарий от xen0n

А вот если кто-то знает какие-то проекты, где объемы большие

Не совсем то, но... Если hashget впарить java-девелопменам, это им оч подойдёт. И они сами не заметят, как у них появятся наконец чётко обозначенные зависимости.

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

@zvezdochiot

Тут на LORе всего 5 тэгов можно (и нельзя новые «изобретать»). Приходится выбирать. Тут еще теги интересные - «архиватор» и «архивация» (разные теги).

А что именно в java такого специфичного по зависимостям?

Кстати, hashget не всегда именно зависимости ищет (в нашем обычном понимании), он именно по хешам связь устанавливает. Например, если у нас в базе нет wordpress, зато есть debian'овские пакеты, и мы запакуем wordpress - то небольшая экономия будет - он догадается, что файлы типа LICENSE можно взять из дебиановских пакетов. Для архивации - это хорошо, пофиг откуда они, главное, чтобы данные совпадали. Но вот если рассматривать это как зависимости - то будет странно, что wordpress от какого-нибудь vim-basic зависит :-)

xen0n
() автор топика
Ответ на: комментарий от xen0n

А что именно в java такого специфичного по зависимостям?

Кстати, hashget не всегда именно зависимости ищет (в нашем обычном понимании), он именно по хешам связь устанавливает.

Так за то и речь. В java нигде эти самые зависимости толком не прописываются (только если автор проявил инициативу и внес их в Manifest), а тут они будут определяться в полуавтоматическом режиме. А пакеты у них «жирные», если что.

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

А репозитории где-то централизованно держат?

Тут важно, чтобы если мы проиндексировали файл и запомнили, что он доступен по такому-то адресу (.../abc-1.2.3.tar.gz), то чтобы мы его и через год смогли там же найти и с тем же контентом. Чтобы он «статичным» был.

xen0n
() автор топика
Ответ на: комментарий от xen0n

А репозитории где-то централизованно держат?

Вот с этим беда. Каждый плодит свою помойку. Например: iText

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Linux kernel 5.0.4 934 Mb 161 Mb ( 20% ) 4.7 Mb ( 0.5% )

Что-то много получилось. В такой концепции достаточно урла и чексуммы.

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

@greenman это про restore файл (с метаинформацией, который в .tar.gz добавляется)?

если мы знаем, что для распаковки нам надо скачать coreutils-8.26-3, от откуда нам знать, куда положить /bin/ls оттуда? Что если пользователь его правил, заменил, поменял пермишшны, или сделал копию в другом каталоге? Для надежности - проще все данные для распаковки хранить в архиве.

Вот для тестовой машины .hashget-restore.json весит в чистом виде 3.1Мб всего и 462Kb после gzip. Таких объемов не жалко :-)

xen0n
() автор топика
Ответ на: комментарий от xen0n

Для надежности - проще все данные для распаковки хранить в архиве.

Вопрос такой возник: если вдруг нет сети, но есть все необходимые архивы(пакеты) локально, как приспособить эту тулзу под данную ситуэйшен?

Deleted
()
Ответ на: комментарий от greenman

@greenman Не обратил внимание на цитату, сейчас только понял.

В общем, урла бы хватило, если бы мы точно заранее знали, что его хватит. Например, если в каталог положить запакованное ядро (.tar.xz), просто 1 большой файл, то и архив будет очень маленьким. (url, сумма, перминшны, юзер-группа).

Сейчас проверил: .tar.gz - 401 байт. при распаковке, в нем один .hashget-restore.json размером в 660 байт

А так как оно распакованное, то хранится метаинфо по каждому сокращенному файлу (а их там очень много). Кроме того, индексируются и сокращаются только файлы от 10Кб, не меньше. Мелочь остается.

xen0n
() автор топика
Ответ на: комментарий от Deleted

@zvezdochiot: По прямому пути - надо чтоб все таки было. (Если локально хранить и хэшгет и все пакеты - особого профита нет)

Но если почему-то нужно извратиться:

можно после tar распаковки отредактировать .hashget-restore.json, хоть даже sed'ом, чтобы все ссылки поправить, например, с https://snapshot.debian.org/ на http://localhost/

Либо через прокси сервер зарулить их на локальное хранилище. В общем, нужен какой-то маппинг snapshot урлов на те, которые у нас доступны.

У restore файла очень простая структура, там легко разобраться.

Чтобы именно с файловой системы брал (чтобы cp делал, вместо скачивания) - такой функции нет, но это легко обходится - в дереве пакетов запустить: python3 -m http.server и вот у нас уже локальное HTTP хранилище. Можно его же внутри компании использовать, чтобы одно центральное для всех машин сети.

Более правильный путь для такого извращения:

Чтобы не извращаться - лучше сразу тогда поднять какой-то свой HTTP репозиторий пакетов, и индексировать их оттуда, а не из snapshot.debian.org (так как по задумке должны приватные пакеты индексироваться), Тогда распаковка будет обычная, просто «hashget -u /path»

xen0n
() автор топика
Ответ на: комментарий от xen0n

можно после tar распаковки отредактировать .hashget-restore.json

Не оч лаконичное решение. Не лучше ли добавить опцию, типа --local path/to/archive, чтобы «и овцы целы, и волки сыты» были? Что бы без этой опции hashget работал по стандартной схеме, а с этой опцией поверял сначала path/to/archive?

Если локально хранить и хэшгет и все пакеты - особого профита нет

Профит есть. Хранить пакеты и «примочки» к ним логичнее хранения пакетов и «копий» пакетов, и гораздо логичнее хранения «не пойми чего».

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

@zvezdochiot: да, не самое простое, согласен. Просто я не планировал, что такой путь реально востребован будет.

Наверное, он и не будет, но вот для успокоения - может быть и лучше сделать, чтоб был. Как парашют у пилота - не чтобы прыгать, а чтоб не волноваться. :-)

Но тут надо подумать еще. Вариант с --local кажется простым. Еще думаю, может быть сделать восстановление по новой HashDB.

Например, умер snapshot.debian.org. Зато где-то есть помойка с пакетами оттуда. Мы ее индексируем. И при восстановлении - если snapshot url не сработал - то ищем, где еще их взять, по hashdb находим, что они есть на этой помойке, скачиваем оттуда. Нужно подумать, как красивее и надежнее и универсальнее будет.

xen0n
() автор топика
Ответ на: комментарий от Deleted

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

Сейчас есть такая терминология:

Пакет (Package) - тот «вендорский» файл, что скачивается по сети и из него можно извлечь другие файлы.

HashPackage (и Индекс) - это индекс этого пакета, маленький, в нем URL где скачать пакет и хеши файлов, которые внутри.

HashDB - это локальная база множества HashPackage.

xen0n
() автор топика
Ответ на: комментарий от xen0n

Не понял про примочки и копии.

Есть deb-пакет. Ты распаковал его что-то изменил в нём под конкретно себя. Способы хранения в этом случае следующие:

  • deb-пакет + «примочки» (hashget);
  • deb-пакет + «копия» пакета;
  • «не пойми чего», что самому надо будет копировать в систему.
Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

имхо стоит добавить хеш-запись из шаред сетей типа DC++.
там все выложенные файлики уже имеют хеш-сумму, т.е. можно не мудрить со своими базами хешей. плюс можно произвести быстрый поиск по это сумме.

и вся сеть подключенная dc++ сеть становится твоим репозиторием. добавление новых файлов элементарное и вполне логичное. размер базы файлов при использовании DHT неограниченн. всё упрется лишь в известность технологии и програмки.

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

deb-пакет - в составе виртуалки? (например, поставили апач и настроили конфигурацию, изменили конфиги, добавили файлы).

И мы говорим сейчас о задаче хранении бэкапов этой виртулки?

Зачем вообще нам выгодно хранить все .deb файлы локально и как-то отдельно? Не проще ли тогда просто тупо .tar.gz делать (как деды делали)?

В чем профит какой-то другой схемы, если пакеты локально все равно держим?

Я не понял, почему hashget относится к «deb-пакет + примочки». хэшгетовский «дельта» архив (так будем для определенности называть, как с дифференциальными) - он как раз тем и хорош, что там сокращено все, что можно из deb взять.

xen0n
() автор топика
Ответ на: комментарий от xen0n

Зачем вообще нам выгодно хранить все .deb файлы локально и как-то отдельно?

Потому что это опционально. Можно хранить, а можно не хранить. А hashget будет работать «одинаково» в обоих вариантах.

Deleted
()
Ответ на: комментарий от pfg

@pfg: да, красивая идея. Хотя и сложная, как мне кажется.

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

Но вот тут риск есть: Debian нам гарантирует, что его snapshot будет жить. Это достаточно надежно. Много лет живет стабильно. Если вдруг помрет даже - мы про это узнаем.

А что если какая-то старая версия пакета будет только у «Васи»? И Вася потом ее сотрет...

Ну и я знаю, что у меня есть склонность делать свои велосипеды, не хотелось бы еще и P2P сеть свою изобретать. Может быть есть какая-то готовая (не просто технология, а именно сеть) которая подходит под эти цели?

xen0n
() автор топика
Ответ на: комментарий от Deleted

На какой странице дело дойдёт до переизобретения торрентов и DHT?

Торрент не подойдёт, он поблочный, а не пофайловый.

См. тред Посоветуйте BitTorrent-клиент

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

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

Мне видится практичной такая схема - для небольшой компании есть свой пул пакетов (по сети или локальный). Каким-то образом, нам нужно его автоматически пополнять (напр, запаковали виртуалку - тут же все пакеты, которые на ней - положили в пул, если их там не было). А при распаковке - из него берем.

В hashget есть HTTP GET кеш (чистится - hashget-admin --clean cacheget). Все что он однажды скачал (например, при индексировании) хранится в нем. Если от root - то в /var/cache/CacheGet/ . Можно просто тот же хеш использовать, как вариант. Но идейно как-то не очень красивым кажется.

xen0n
() автор топика
Ответ на: комментарий от xen0n

Тогда в случае с хранением, есть еще проблема, как собирать эти файлы.

Есть пара простых правил:

  • «Проблемы индейцев шерифа не е**»
  • «Хорошая» программа должна выполнять простые и понятные действия, но выполнять их должна хорошо.
Deleted
()
Ответ на: комментарий от xen0n

в чем сложность ??

взять произвольный файл посчитать для него dc++хеш, поискать в DC++ сети этот хеш. если он найден (допустим в настройках прописано некоторое минимальное количество хешей в сети) то считать файл известным и вместо файла положить указание что файл надо качнуть из dc++сети.

от твоей системы урл-ссылок отличается только транспортом и размещение базы хешей. все остальное тоже самое.

сервер на машине запускать не надо, большинство п2п систем прекрасно работают без серверов - это одна из их фитч.

вероятность что некоторые пакеты дебиан переместит/поменяет ссылку ненулевая. пакеты, образы и прочее из старых репозиториев по прошествии определенного времени может скинуть куда-нить на old.download.debian или что подобное.

потому и говорю о параметре «минимальное количество хешей в сети». в п2п облаках известные и интересные многим вещи хранятся отлично.

dc++ e2k имхо подойдут но давно в многообразии п2п не ковырялся, прям вот точно не скажу.

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

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.