Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
А почему нет cp в последующих тестах? Скажем, копировать поверх только изменившиеся файлы (по дате).
Несколько удивляют цифры 3-го прохода у rshapshot.
Согласно тесту N1 копирование 11090МБ занимает около 8 минут, или средняя скорость при текущем наборе — файлов 23мб/сек. Что в общем-то похоже на правду при большом количестве мелких файлов.
Далее выясняем, что на «обход каталога» без самой операции копирования (только создание хардлинков) тратится около 10 сек.
А вот на 3-м проходе требуется скопировать 13267МБ-11090МБ=2177Мб «новых данных», но на это тратится только 31 сек. Из них операция аналогичная предыдущей из N2 должна занять 10 сек. Значит на само копирование новых файлов потрачено 21 сек. И скорость получается уже 103Мб/сек, что намного превышает скорость первоначального копирования из N1.
Либо файлы оказались в дисковом кэше, либо rshaphot определил, что в новом каталоге находятся копии файлов из соседнего каталога, и тоже создал хардлинки, не проводя фактического копирования.
Другого объяснения так сильно подскочившей скорости копирования у меня нет. Как можете прокомментировать этот момент?
Согласно тесту N1 копирование 11090МБ занимает около 8 минут, или средняя скорость при текущем наборе — файлов 23мб/сек. Что в общем-то похоже на правду при большом количестве мелких файлов.
Далее выясняем, что на «обход каталога» без самой операции копирования (только создание хардлинков) тратится около 10 сек.
А вот на 3-м проходе требуется скопировать 13267МБ-11090МБ=2177Мб «новых данных», но на это тратится только 31 сек. Из них операция аналогичная предыдущей из N2 должна занять 10 сек. Значит на само копирование новых файлов потрачено 21 сек. И скорость получается уже 103Мб/сек, что намного превышает скорость первоначального копирования из N1.
Либо файлы оказались в дисковом кэше, либо rshaphot определил, что в новом каталоге находятся копии файлов из соседнего каталога, и тоже создал хардлинки, не проводя фактического копирования.
Другого объяснения так сильно подскочившей скорости копирования у меня нет. Как можете прокомментировать этот момент?
Да, методика тестирования с дублированием папки выбрана крайне неудачная, тут вы правы. Проведу повторное тестирование с действительно новыми файлами для rsnapshot. rdiff-backup вроде можно не перепроверять, ему не полегчает
Скорее всего — оказались в дисковом кеше.
Алгоритм работы там простой — переименовали старую папку в более старую, сделали копирование из неё в новую хардлинками, сделали rsync --delete поверх в новую папку.
У rsnapshot есть очень большой минус — ему нужны хардлинки. Поэтому любой бекап можно инициировать со стороны бекапного сервера с rsnapshot, но нельзя инициировать со стороны клиента и заливать на удалённое что-то по, например, sftp. Единственная альтернатива тут — маунтить sftp через sshfs, создать там образ, замаунтить его как loopback — но это решение имеет очень много накладных расходов и неудобств.
Алгоритм работы там простой — переименовали старую папку в более старую, сделали копирование из неё в новую хардлинками, сделали rsync --delete поверх в новую папку.
У rsnapshot есть очень большой минус — ему нужны хардлинки. Поэтому любой бекап можно инициировать со стороны бекапного сервера с rsnapshot, но нельзя инициировать со стороны клиента и заливать на удалённое что-то по, например, sftp. Единственная альтернатива тут — маунтить sftp через sshfs, создать там образ, замаунтить его как loopback — но это решение имеет очень много накладных расходов и неудобств.
Дублирование оказалось не при чем, повторное тестирование с 2,5ГБ реально новых файлов показало, что они кэшируются и поэтому быстро перекладываются rsnapshot'ом в папку бэкапа (предварительно дергал папки для тестов из рабочих каталогов проекта, этим и приукрасил результат)
Из практики: ZFS (snapshot+send) позволяет бэкапить несколько миллионов мелких файлов без простоя сервиса и за разумное время.
lsyncd + tar раз в неделю на бэкапном хранилище должны спасти галактику.
Во-первых, требуются ежедневные бэкапы, а не «раз в неделю»
В-вторых, изменений за сутки сейчас около 30 тысяч файлов. А нужен неплохой запас.
В-третьих, этот вариант рассматривался и был отброшен — habrahabr.ru/post/132098/
В-вторых, изменений за сутки сейчас около 30 тысяч файлов. А нужен неплохой запас.
В-третьих, этот вариант рассматривался и был отброшен — habrahabr.ru/post/132098/
Минимальная продакшн-конфигурация — 584 тысячи вложенных директорий. А lsyncd навешивает inotify'и на каждую директорию. Сделать это сразу для всего дерева невозможно. Памяти, 584 тысячи нотифаев, съедают относительно немного, около 200 Мб (из 16 ГБ имеющихся), но вот процесс этот занимает 22 минуты.
Во-первых, можете делать ежедневные бэкапы. Про неделю я сказал к примеру.
Во-вторых, в указанной статье одних только директорий почти 600 тысяч. А у Вас всего файлов 900к. Так что не думаю, что вы бы столкнулись с большими проблемами в этом плане.
Во-вторых, в указанной статье одних только директорий почти 600 тысяч. А у Вас всего файлов 900к. Так что не думаю, что вы бы столкнулись с большими проблемами в этом плане.
В-третьих, возможно, стоит подумать — а действительно ли вам критически важны все эти файлы? К примеру, нельзя ли бэкапить только сами большие картинки, а превьюшки генерить при восстановлении из бэкапа? Текстовые же данные удобнее хранить в какой-нибудь VCS.
Запас нужен. Проект из моей статьи только стартовал. Что будет дальше — мне сложно спрогнозировать. Но готовиться надо к худшему )) Задача была именно всё бэкапить и в случае краха немедленно развернуть на другом сервере. А генерить превьюшки и прочие манипуляции — лишние телодвижения для программистов. Меня за такое по голове не погладят. Текстовые данные удобно хранятся в git, вы правы
Если хочется в случае беды «немедленно развернуть рядом», то лучше для этого иметь хот-резерв сервер на который всё синхронизируется:)
А развёртывание такого кол-ва файлов, наверное, может быть сопоставимо по времени с разворачиванием основных и последующей генерацией динамических. Но тут спорить не стану — было бы неплохо протестировать.
А развёртывание такого кол-ва файлов, наверное, может быть сопоставимо по времени с разворачиванием основных и последующей генерацией динамических. Но тут спорить не стану — было бы неплохо протестировать.
У нас на сервере 1.5 ТБ мелких файлов (картинки в основном). Полная синковка на новый сервер занимает 1 день. Lsync справляется на «ура». Данные актуализируются практически моментально на 4 серверах.
Но, на данный момент ищем и выбираем распределенную файловую систему для всего этого дела, а-ля mogilefs.
Но, на данный момент ищем и выбираем распределенную файловую систему для всего этого дела, а-ля mogilefs.
70млн файлов общим объемом, в сыром виде, 2Тб резервирую с помощью duplicity. Мне нравится.
емнип, натыкался на него во время поиска инструментария. От создателя rdiff-backup утилитка вроде.
Про авторство — не в курсе, тоже на python, бэкапит в dropbox, s3, etc не считая «стандартных». Полный бэкап — медленно, инкрементальный — быстро + решает проблему конского IO на запись мелких файла за счет сжатия и/или создания tar томов. С восстановлением, естественно, возни чуть больше.
А как восстановление, после большого количества инкрементальных бэкапов?
От числа diffов не зависит скорость восстановления, вместе с бэкапом хранится «индекс» того, в каком томе что находится. Не хочу думать, что случиться если его потерять.
Ну ок, а если окажется что «всё» равномерно распределено по всем томам?
Моя твоя не понимать.
Есть «индекс» со списком файлов, их атрибутами и томом в котором файл лежит. При создании diff (инкремент) сравниваются текущее дерево и «индекс», изменившиеся файлы пишутся в новые тома, а «индекс» дополняется. При восстановлении, по «индексу» ищутся тома в которых лежит либо нужный файл, либо собирается список томов для воссоздания дерева по дате бэкапа.
Есть «индекс» со списком файлов, их атрибутами и томом в котором файл лежит. При создании diff (инкремент) сравниваются текущее дерево и «индекс», изменившиеся файлы пишутся в новые тома, а «индекс» дополняется. При восстановлении, по «индексу» ищутся тома в которых лежит либо нужный файл, либо собирается список томов для воссоздания дерева по дате бэкапа.
Самое лучшее решение задачи бекапа множества небольших файлов — размещения их на разделе с ZFS и использование zfsbackup. Работает очень быстро (цифры не дам, не снимал), позволяет удобно и быстро восстанавливать выборочно файлы из архива, когда использовался tar всё было на несколько порядков дольше.
Это всё здорово, но статья про Linux, а там вроде ZFS не stable. btrfs тоже, а LVM не все хотят ставить.
Я использовал под Linux, ZFS on FUSE, упоминания о нестабильности не видел, работало четыре года как часы.
FUSE — уже значит что практически ни для него нельзя применять на production. имхо.
Пробовал в продакшене «ZFS on Linux» как основа ноды для MooseFS (для теста только на одной ноде, летом уже был как стейбл).
через пару недель откатился на ext4.
+ пару процентов дает больше места с компрессией и включенной дедупликацией
— много ест памяти
— работает существенно медленнее
— ест процессор больше
— иногда посте ребутов были проблемы с поднятием
через пару недель откатился на ext4.
+ пару процентов дает больше места с компрессией и включенной дедупликацией
— много ест памяти
— работает существенно медленнее
— ест процессор больше
— иногда посте ребутов были проблемы с поднятием
rsnapshot — есть ещё проблемка что после каждого инкрементальный бэкапа в системе будет появляться 900тыс новых файлов (inode'ов).
хорошо бы ещё Duplicity и DAR потестить, последний мне кажется понадёжнее и попродуманнее будет.
хорошо бы ещё Duplicity и DAR потестить, последний мне кажется понадёжнее и попродуманнее будет.
При созданиии хардлинков новые inode не создаются. Хардлинк указывает на тот же самый inode. Будут создаваться только директории для всех этих файлов.
Что-то да, я напутал совсем. inode один и тот же, но место в директории занимают. Когда у меня были миллионы мелких файлов в rsnapshot'е, со временем бэкап стал очень медленным, пожирал много disk IO или disk cache, я это связывал именно с занимаемым место в файловой системе и кэше, а так же из-за операции rm -rf (unlink) которая постоянно выполняется над миллионами хардлинков, возможно она медленнеая на EXT4. Отказался от rsnapshot только из-за этого.
Bacula не пробовали? У меня конечно объёмы не такие внушительные, но работает отлично, умеет инкрементально бэкапить.
Благодарю за статью. У самого подобная задача стоит, давно хотел провести исследование на предмет её решения.
Для домашних целей думаю сделать банальный rsync на NILFS2. Версионность при этом будет обеспечиваться средствами NILFS2 и, что приятно, храниться будет не сконфигурированное число снапшотов N, а сколько влезает.
Интересно было бы посмотреть сравнение с таким вариантом.
Интересно было бы посмотреть сравнение с таким вариантом.
Попробовал и разочаровался. Когда пришёл nilfs_cleanerd, то потёр все чекпоинты. Наверно, оставил бы чекпоинты моложе protection_period, но у меня этот параметр был выставлен в один час, не понять.
Также, возможно, остались бы снапшоты, но в снапшоты у меня на тот момент ни один чекпоинт превращён не был.
В общем на автоматические хранение влезающего на диск количества чекпоинтов с nilfs можно не рассчитывать. При таких раскладах, пожалуй, лучше rsync на btrfs и делать снапшоты его средствами.
Также, возможно, остались бы снапшоты, но в снапшоты у меня на тот момент ни один чекпоинт превращён не был.
В общем на автоматические хранение влезающего на диск количества чекпоинтов с nilfs можно не рассчитывать. При таких раскладах, пожалуй, лучше rsync на btrfs и делать снапшоты его средствами.
rsnapshot, написанный на C, базируется на rsync.
о.О На perl он написан. Весь, целиком и полностью. пруф. (:
rsnapshot — отличная вещь, но у него есть один нюанс, с которым пришлось столкнуться и немного повозиться. Если бэкапите rsnapshot'ом и процесс бэкапа, я надеюсь, работает у вас не под рутом, имейте в виду, что как только в данных появится директория без прав на запись, бэкап будет падать. Но это не баг, это фича.
При подобном кейсе (очень много мелких бинарных файлов) можно попробовать обойтись простым rsync-ом. Но это imho — нужно пробовать
С подключением. Минус rsnapshot'а в отсутствии сжатия. Можно попробовать решить подобную проблему посредством файловой системы с сжатием или использование архива в качестве фс, но тут встает вопрос динамически изменяемого размера бэкапа.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бэкап большого количества мелких файлов