Комментарии 30
Насколько я слышал последнее обсуждение этих систем, все они рано или поздно показывали дырявость абстракции в самый неудачный момент. Подробностей, к сожалению, не помню.
Мне кажется для торентопомойки это абсолютно не критично.
Ну а мне всё же кажется, что лучше пересилить себя и сделать чистенький LVM)) А ещё лучше — RAID через mdadm, тогда даже избыточность для сохранности данных легко вставить. Всё же приведённые решения — откровенные костыли, и не важно, для чего они используются ;)
У LVM есть минусы: при отвале одного из дисков сносит всю файловую систему целиком, что может быть болезненным даже при не очень критичных данных. Одно дело восстанавливать информацию с одного погибшего диска и другое — с четырёх. У RAID тоже есть минусы: во-первых, он создаёт иллюзию надёжности и про резервное копирование в итоге часто забывают (к тому же тратится место), во-вторых, его не очень удобно расширять. Я, например, не знаю, как перенести массив с дисков по 1,5 ТБ на 2 ТБ, заменяя диски по очереди, а не сразу.
У LVM да, есть минусы. А RAID не создаёт иллюзию, он действительно надежен. Чем вам например 10 RAID не угодил, или скажем RAID6. Программный RAID — это просто простой способ делать ваши бекапы. Ну а расширение… Да, нужны диски одинакового объёма или же сразу полная замена массива. Не считаю это минусом, поскольку реально это не вредит ничему.
RAID любого уровня может спасти только от одной угрозы — физического выхода из строя носителя из строя. А с информацией, между тем, может случиться много чего занятного: выход из строя файловой системы, ошибка ПО или пользователя, приводящая к повреждению данных, диверсия, наконец. Причём в сумме это может оказаться гораздо более вероятным, чем подыхание диска. Таким образом фраза «программный RAID — это просто простой способ делать ваши бекапы» — не более чем миф. Если у меня будет два жёстких диска и нужно будет сделать из них максимально надёжную систему, я не стану делать из них RAID1, а поставлю один диск и буду время от времени подключать второй, чтобы скинуть на него бэкапы. А до рейда дело дойдёт, когда 1) появится больше носителей и 2) потребуется кроме надёжности обеспечить ещё и высокую доступность.
Я не страдаю паранойей, поэтому считаю что правильно организованное хранилище на рейдах не требует в основном бекапа))) Если у вас конечно не информация, представляющая гостайну. ФС восстанавливается на раз при любых ошибках (кроме откровенных диверсий, ага), привет ext3/4, ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно, а потерять пару текущих файлов из-за ошибки ПО, с ним работающего — это не страшно и от этого бекапы не спасут. РЕально конечно надо делать бекапы важных данных, а рейд скорее использовать для отказоустойчивости системы, но фанатизм в бекапах при использовании рейда проявлять явно не стоит. То есть если рассматривать организацию отказоустойчивого хранилища, то я бы начал ровно наоборот: сначала рейд, а потом если получится отдельное место для бекапа. Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад раз в 24 часа снимающимися, это чтобы защититься от случайного удаления файла пользователем вместо инкрементальных бекапов. Хотя это уменьшит скорость записи сильно, но обычно для сетевых хранилищ некритично.
> Я не страдаю паранойей, поэтому считаю что правильно организованное
> хранилище на рейдах не требует в основном бекапа
Зеркальный рэйд спасает от гибели диска, но не спасает от случайного или намеренного удаления кем-то важных данных, ведь это удаление сразу будет отзеркалено на другие диски. Именно для этого и нужен регулярный бэкап.
> хранилище на рейдах не требует в основном бекапа
Зеркальный рэйд спасает от гибели диска, но не спасает от случайного или намеренного удаления кем-то важных данных, ведь это удаление сразу будет отзеркалено на другие диски. Именно для этого и нужен регулярный бэкап.
Это правда, я для этого использую LVM со снапшотами на трое суток назад))) Просто началось всё с иллюзии надёжности RAID. Он не создаёт иллюзию, он действительно надёжен, особенно в рамках приведённой задачи. Если вам нужны бекапы в целях защиты от шаловливых ручек — то тут уже ничего не попишешь. Часто на это забивают, зачастую кстати обоснованно. Зачем например бекап серверов без пользовательских данных — непонятно. А вот рейд на них может спасти от более реальных опасностей, как то выход диска из строя например.
> Я не страдаю паранойей
А стоило бы.
> ФС восстанавливается на раз при любых ошибках
Сама ФС, скорее всего, восстановится (хотя сталкивался и с убитой напрочь ext3), только базе, которая в этот момент меняла структуру таблиц, от этого лучше не станет, если не включать журналирование данных.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
А стоило бы.
> ФС восстанавливается на раз при любых ошибках
Сама ФС, скорее всего, восстановится (хотя сталкивался и с убитой напрочь ext3), только базе, которая в этот момент меняла структуру таблиц, от этого лучше не станет, если не включать журналирование данных.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Чёрт, рано отправилось.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Ни разу не сталкивались с DELETE FROM xxx без WHERE, случайно попавшим в продакшн, поскольку программер забыл проверить дописываемую фичу? Или с утечкой пароля, из-за которой кто-то нехороший поправил ненравящиеся ему данные? Поздравляю.
> но фанатизм в бекапах при использовании рейда проявлять явно не стоит
А нафига нужны два экземпляра неправильных данных?
> Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад
Вот это уже ближе к истине.
> Зачем например бекап серверов без пользовательских данных — непонятно.
А зачем нужны сервера без пользовательских данных?
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Ни разу не сталкивались с DELETE FROM xxx без WHERE, случайно попавшим в продакшн, поскольку программер забыл проверить дописываемую фичу? Или с утечкой пароля, из-за которой кто-то нехороший поправил ненравящиеся ему данные? Поздравляю.
> но фанатизм в бекапах при использовании рейда проявлять явно не стоит
А нафига нужны два экземпляра неправильных данных?
> Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад
Вот это уже ближе к истине.
> Зачем например бекап серверов без пользовательских данных — непонятно.
А зачем нужны сервера без пользовательских данных?
Я тоже не страдал, теперь я в категории людей кто «уже делает бэкапы», после того как контроллер перестал видеть оба винта в массиве. К счастью все решилось, но несколько неприятных часов я пережил. :-D
Кажется, вы забыли тег закрыть)
НЛО прилетело и опубликовало эту надпись здесь
Для справки: в Gentoo тоже есть sys-fs/aufs2 :)
По поводу Дебиана: aufs-tools есть и в тестинге и в анстейбле. Модуль ядра также есть в 2.6.32-5, которая в тестинге по умолчанию. А вот в 2.6.34 из экспериментальной ветки уже нет.
По задаче: ещё есть btrfs, которая позволяет подключить второй том к уже существующей ФС и даже распределить данные из первого поровну по обоим. Правда, он ещё сыроват и порою падает с кернель упсами.
По задаче: ещё есть btrfs, которая позволяет подключить второй том к уже существующей ФС и даже распределить данные из первого поровну по обоим. Правда, он ещё сыроват и порою падает с кернель упсами.
как они работают с нфс? я давненько пробовал mhddfs экспортить но работало оно с ошибками, т.е. файлы прерывались в рандомные моменты. mhddfs в свою очередь еще и делает неплохую нагрузку на систему.
НЛО прилетело и опубликовало эту надпись здесь
в Ubuntu (так как LiveCD Ubuntu построен с применением этой ФС);
В каком месте она там? Вроде бы squashfs всегда использовался.
На самом деле очень большая проблема получить хранилище устойчивое к вылету одного диска с возможностью простой замены/добавления дисков. Самый простой вариант как мне кажется — это отказаться от RAID в пользу объединения через LVM и rsync критичных данных на отдельный хдд.
что только не придумают, вместо того чтобы пользоваться одним целым разделом на весь диск.
Стоит вспомнить, что ZFS лишена описанных в статье сложностей в работе по-умолчанию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объединение нескольких разделов в один без потери информации