Дедупликация данных в linux
Доброго времени суток.
Подскажите, пожалуйста, какие есть в linux варианты дедупликации данных на уровне файлов (или блоков).
Собираюсь использовать для хранения резервных копий (изменяемость данных за промежуток между архивациями меньше 10%).
Пока все выполняется скриптом, который проверяет есть ли изменения в копируемых файлах и если таковые есть - копирует их, а если нет - делает жесткую ссылку с уже имеющихся (можно и логическими, но жесткими, ИМНО, удобнее).
Проблему вижу в том что скрипт этот не учитывает перенос файлов из одного каталога в другой (в пределах архивируемой директории), он воспринимает эти файлы как новые и копирует их заново.
Переписать не проблема, но на сколько помню opensource, решение, чаще всего, уже где-то есть.
Пока нагуглил только lessfs и opendedup.
Первое есть в portage, оба используют fuse.
Может кто о чем-то другом слышал?
p.s.: btrfs, ну и солянку сделали, и это она умеет, правда offline'новую.
по lessfs недоволен тем что данные она сама не освобождает, т.е. после удаления файлов "кэш" не уменьшается. Может быть можно как-то через дергание файлов в .lessfs, попробую почитать.
- Для комментирования войдите или зарегистрируйтесь
Нет, на халяву промышленной
Нет, на халяву промышленной дедупликации нет.
И врядли появится в ближайшие пару лет.
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
к сожалению, это ожидаемо,
к сожалению, это ожидаемо, спасибо за ответ, значит пойду переписывать скрипт...
если для бэкапа юзать
если для бэкапа юзать squashfs, то дедупликация будет автоматическая
ps еще встречал git для бинарных файлов
squashfs: если я правильно
squashfs: если я правильно понял, то это что-то вроде архива, который можно примонтировать как read-only файловую систему.
Тогда мне такой вариант не подходит (мне нужно избежать появление дублей между срезами, а не в пределах одного среза).
Можно конечно перепаковывать после каждого нового архива, но для этого нужно буферное пространство (для распакованных файлов), а это как раз убивает всю задумку (сократить суммарный объем накопителей).
git, и другие системы контроля версий:
а разве классическая организация структуры системы контроля версии не подразумевает наличие рабочего каталога и каталога в котором хранятся либо полные версии, либо diff/delta-данные?
Если так - то это тоже не подойдет, т.к. занятое место будет (минимум) в два раза превышать необходимое - уникальные файлы будут находиться как в рабочем каталоге, так и в служебном.. Ссылок быть не может по определению - т.к. репозиторий должен позволять вносить изменения в файлы без модификации уже "закоммиченых" файлов.
там есть вариант, дописывать
там есть вариант, дописывать к уже имеющемуся файлу, тогда при монтировании каждый срез будет в своей папке
я имел ввиду тюнингованный git, заточенный под работу с бианрниамии(напишу, если вспомню название)
да, оказывается я по обоим
да, оказывается я по обоим пунктам вас не так понял, поищу и по первому и по второму.
NFS_Daemon написал(а): он
попробуй git, он отслеживает файлы по содержимому :)
Working on Gentoo Linux for Asus P535 and Qtopia :-)
ну народ, ну гит головного
ну народ, ну гит головного мозга ;)
Ниче , что scm хранит всю историю изменений, т.е объём репки может быть в 100 раз больше , чем сама экспортнутая репка ?
/тролл моде он - хорошо подумал и понял, что в винде в очередной раз есть запрашиваемое ;( /mode off
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Цитата: варианты дедупликации
http://zfsonlinux.org/
Нейтральность - высшее достижение сознания!
хм, видимо прозевал момент
хм, видимо прозевал момент когда ее поддержку (на уровне ядра) добавили в gentoo... спасибо, попробую.
NFS_Daemon
Как вариант...
gentoo-laptop lupo # eix obnam [I] app-backup/obnam Available versions: (~)1.2-r1 (~)1.3 Installed versions: 1.3(07:49:09 19.12.2012) Homepage: http://liw.fi/obnam/ Description: A backup program that supports encryption and deduplicationЯ ♥ Gentoo & Funtoo
Вашей новой идее о
Вашей новой идее о дедупликации лет сто в обед исполнится. К скрипту надо хеши прикручивать. Делаем как то так: вычисляем хеш, ищем в свалке файл с названием как хеш, ежели нет - копируем в свалку с названием хеша, делаем линк в каталоге бека, директории тупо создаем в каталоге бэка. Ссылки Имхо лучше мягкие, ибо жесткие работают в пределах одного раздела, а делать беки на одном девайсе моветон. Собственно в основном процессе ничего сложного нет, обвязку писать умучаешся (типа чистки свалки). ну и поскольку ни вы, ни я не новаторы ....
Поставте же наконец себе eix и наслаждайтесь жизнью.
Готовые системы с заявленной дедупликацией
eix app-backup/ | less
app-backup/backuppc ...
app-backup/obnam...
Я уже не говорю о дедуплицирующих архиваторах и фс
eix -sS dedup
* app-arch/zpaq
Available versions: ~4.04 ~6.10 {{debug}}
Homepage: http://mattmahoney.net/dc/zpaq.html
Description: Journaling incremental deduplicating archiving compressor
* sys-fs/lessfs
Available versions: 1.5.8 1.5.12 {{berkdb crypt debug filelog lzo memtrace}}
Homepage: http://www.lessfs.com
Description: A high performance inline data deduplicating filesystem
......
Спасибо за предложенный
Спасибо за предложенный вариант (алгоритм), я примерно так и сделал, учитывая нюансы, которые есть, возможно только у меня (лень искать кто с таким же сталкивался).
В общем же - вы желаете делать на логических - ваше право, мне удобнее на жестких, смерть винта с бекапом переживу, ибо скоро там будет не один финт а зеркало (из raid5-го конечно же, всегда теперь буду делать raid5, нужно зеркало - raid5 с двух, нужен stripe - raid5 на три диска из двух, и т.д.))
eix'ом пользуюсь, не знал о разделе app-backup
И, на счет самописного - я считаю что хорошо оптимизированный велосипед работает лучше универсального решения, т.к. минимум учитывает конкретные условия, максимум - не использует много ненужных примочек, которые в реальности не используются.
Обнам это юниксвейная
Обнам это юниксвейная утилита, ее можно пихать в скрипт. Бэкапписи имеет веб интерфейс, решение типа все-в одном. Если на шелле писать, к примеру, скрипт, обрабатывающий килотонны текста - я бы предпочел вызов "готового" решения awk/sed/(perl!!!), ибо юниксвей, нежели использование конструкций типа
wi@oit-wi ~ $ x=12345;echo ${x:0:${#x}-1}
1234
Собираюсь использовать для
ман системный администреж, раздел про типы бекапов - инкрементальные, разностные , добавочные ......, схемы бекапирования, планы бекапов и восстановлению ...., актуальность ...
И в результате размер бекапов сдувается от космических петабайтов в реальные пару гигов в сутки с стиранием их через пол года
не, я конешно понимаю , что про концепцию альтернативных файловых потоков в линуксе ничего не слышали :), но есть же аналоги виде атрибутов или что там еще, но тут все заисит от ФС.
В конце концов, про инкрементальные снапшоты вы должны были слышать
П.С вам дедупликацию или проблему места под бекапы решить ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Цитата:П.С вам дедупликацию
для себя я считал эти вопросы идентичными, но видимо ошибался.
ну, в целом да, не слышал, да и про потоки читал последний раз года два-три назад.
А какие преимущества дадут аналоги потоков? - возможность хранить все изменения в одном файле? - мне это не критично.
Перечитал первый пост. Если
Перечитал первый пост. Если речь идет о бэкапах, то инкрементальные и дифференциальные бэкапы умеет делать bacula.
Нейтральность - высшее достижение сознания!
+ Сам пользуюсь - Сложноват -
+ Сам пользуюсь
- Сложноват
- Новые версии клиента под винду теперь только за деньги
- На локалхосте выбрал бы что нить попроще. Типа тара в кроне
Цитата: - Сложноват Другие
Другие решения такого класса еще сложнее. Та же Amanda - тихий ужас
ТСу я думаю пофиг, а вообще - жалко, да
Аналогично. Но серваки проще бэкапить централизованно - особенно когда их >1 :-)
Нейтральность - высшее достижение сознания!