LINUX.ORG.RU
ФорумAdmin

Чем заменить LVM для бекапирования?

 


0

3

Понадобилось снова собрать NAS для бекапирования данных с десктопа.
Когда на десктопе был один небольшой диск, то это вообще не составляло проблемы - такой же диск ставился в NAS.

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

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

Стоит только сыпанутся одному диску, то потеряются данные не только на нем, но с большой вероятностью и часть данных на целом диске.
Поэтому везде рекомендуют использовать LVM совместно с RAID, но это затратно под дискам и в данном случае не имеет никакого смысла.

Может быть есть другая технология для бекапирования, более устойчивая к сбоям, чем LVM?

★★★★★
Ответ на: комментарий от chukcha

Многие из вас, к сожалению, так и не поняли исходные условия задачи: - есть 2 диска и все. Точка.

Ну так и надо было сразу задачу ставить: «У меня есть ненужные данные, которые обязательно потеряются. Как мне потерять их так, чтобы виноват оказался ЛОР, а не я?».

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

Никому, диски - априори расходники.

Именно так.

Я таскал то, что не продавалось у нас.

а такое бывало?

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

Душевненько, красиво и с огоньком!

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

а такое бывало?

Ага. У меня есть пару тазиков, набитых рапторами :) На что их менять - хз. У нас их нет давно, а на ebay до сих пор продаются из ZIP-ов.

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

Ох шайтан. Вспомнил, тоже было дело, все реже могли железки найти для спец софта... софт перепилили, волосы стали шелковистее :)

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

яннп, разверните вашу мысль пожалуйста.

anc ★★★★★
()

Может быть есть другая технология для бекапирования, более устойчивая к сбоям, чем LVM?

Делай бэкап бэкапа

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

Воткнешь pci sata контроллер в слот pci и всё. Вообще не вопрос. Но вообще ещё раз скажу что тебе нужен LVM. Для неважных данных которые ты хочешь потерять организовываешь linear волюм. Для важных зеркало. Всё это в одном lvm. И потом можешь спокойнл распределять пространство как необходимо. В линуксе lvm уже давно musthave.

no-dashi-v2 ★★★
()
Ответ на: комментарий от no-dashi-v2

no-dashi-v2

Воткнешь pci sata контроллер в слот pci и всё. Вообще не вопрос.

Во-первых, уже говорил, скажу еще раз:

- есть 2 диска и все. Точка.

И материнка - тоже на два порта. И покупать что-то еще нет возможности.
А была бы, так купил сразу большой диск и у ЛОРа не спрашивал.
Но тут вспомнил - где-то завалялись аж 4 штуки древних SATA-контроллеров, и тоже PCI, как и материнка - чудесное совпадение из глубины веков :=)
Когда-то игрался с ними, но потом забросил, потому что они не аппаратные, а полу-софтовые, и какого-то выигрыша от них по сравнению с mdadm не обнаружил. Может, плохо искал?

Но вообще ещё раз скажу что тебе нужен LVM. Для неважных данных которые ты хочешь потерять организовываешь linear волюм. Для важных зеркало. Всё это в одном lvm.

Дружище, а можно с этого места поподробнее?

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

Вот смотри, объяснение для чайников. Есть диски sda 500gb и sdb 300gb. Я хочу организовать хранение кучи киношек с торрентов и фото. Первое не жалко а второе жалко. Что я делаю:

vgcreate storage /dev/sda /dev/sdb

Создаю raid1 lvcreate –type raid1 -n mirrored -L 50G storage

И вот у меня raid1 на 50гб юзабл размера. У меня осталось 450гб на одном диске и 250 на втором. Я создаю волюм под торренты размером 600гб:

lvcreate -L 400G -n torrents /dev/sda ; lvextend -L +200G /dev/storage/torrents /dev/sdb

Мои торренты будут раскиданы по двум дискам, 400гб на большом и 200гб на маленьком. И ещё по 50гб на каждом диске осталось. Которые я потом могу отдать хоть под raid1 расширив протекченый волюм, хоть торрентовый диск. В общем там возможностей маневрировать много.

Могу например подключить трети диск по усб, включить его в лвм и перенести на него всё с маленького диска, в фоновом режиме за ночь. А маленький диск выкинуть.

А если у меня один диск умрёт то конечно торренты я потеряю а фотки - нет.

Или совсем экзотика, я создам вместо одного диска с торрентами два, каждый на своём диске - и объединю их через unionfs. И это будут два разных диска видимых как одна фс. И если один умрёт потеряются только файлы на нем.

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

no-dashi-v2 ★★★
()
Ответ на: комментарий от chukcha

Да, все это требует знания матчасти и некоторого планирования. Но оно того стоит

no-dashi-v2 ★★★
()
Ответ на: комментарий от chukcha

Идея интересная, конечно, но для моего случая не подходит по той же причине, когда как хранилище используются 2 винта без рейдов и LVM, из-за чего приходится включать ^моск^ и думать - где важные данные, а где нет.
А мне не хочется размышлять над ними и тратить время, мне надо так: запустил бекап - и забыл, он сам все это должен сделать сам автоматически.

Тем не менее, в твоей идее заинтересовало вот что:
- отбрасываем RAID и делаем только LVM, причем не striped, а [linear].

Что будет с данными при потере одного винта?

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

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

mhddfs или mergerfs, при сбое одного из дисков будут потеряны только файлы расположенные на сбойном диске.

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

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

Это понял

mhddfs или mergerfs

А это не понял :=) По русски можно?

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

Гм. Прочел 2 раза, и если правильно понял, этот драйвер позволяет объединить, например, два диска, в один общий без всяких там LVM?

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

а rsnapshot обязателен ??
мож просто сделать инкрементальный архив со сжатием.

Может быть есть другая технология для бекапирования, более устойчивая к сбоям, чем LVM?

накопители, разнесенные по разным машинам (а еще лучше географически далеких) :)

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

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

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

мож просто сделать инкрементальный архив со сжатием.

И в чем будет выгода?

это драйвер объединяет файловые системы, а не носители.

Как это помягше сказать ;=) Пусть не носители, пускай файловые системы, в моем случае это без разницы, имхо?

Главное, что если отвалится диск в RAID 0 или в LVM, то всем данным наступит полный песец, потому что в них файлы размазываются, т.е. делятся, между дисками.

А вот при использовании mhddfs или mergerfs, если правильно понял, файлы помещаются на том или другом диске целиком, и при отказе одного диска файлы, оставшиеся на другом диске, будут полностью целыми?

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

мож просто сделать инкрементальный архив со сжатием.

И в чем будет выгода?

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

Главное, что если отвалится диск в RAID 0 или в LVM, то всем данным наступит полный песец, потому что в них файлы размазываются, т.е. делятся, между дисками.
А вот при использовании mhddfs или mergerfs, если правильно понял, файлы помещаются на том или другом диске целиком, и при отказе одного диска файлы, оставшиеся на другом диске, будут полностью целыми?

так тебе RAID или объединение пространств двух носителей ??
если «отвалится» вся машина со всеми дисками, то никакой RAID не поможет.
вероятность умирания всех составляющих компа, к примеру при попадании молнии или обрушении/затопления помещения, не нулевая :) и т.д.
если ты стремишься к защищенности данных, то такое тоже надо продумывать :)

у меня старый комп собирает бекапы с фирмы на старый диск. в соседнем корпусе стоит еще один старый компутер со старым диском, на который syncthing’ом бекапы дублируются.
вероятность одновременного умирания двух дисков на разнесенных машинах очень низка.
надо бы еще в облако дубль настроить. для полноценности 3-2-1.
ну и двд директору в сейф писать. это конечно больше для показушничества :)

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

в размере бекапа. у тебя ж место заканчивается

зато rsnapshot умно работает, экономя место за счет ссылок, и можно сделать хоть 20 откатов сеансов бекапов - это тоже очень важно.
А вот умеет ли он еще и сжимать, не помню, надо глянуть.

так тебе RAID или объединение пространств двух носителей ??

Хитрый вопрос, сходу не ответишь ;=)
В-общем, так:
- на десктопе стоит винт на 2 ТБ
- в запасе есть 2 винта по 1 ТБ и старый комп для бекапа, в который воткну эти два винта, больше винтов в него не воткнешь, портов всего 2.
Рассчитываю, что бекапный комп целиком не грохнется, только один из винтов.

Бекап буду отправлять, как обычно, по SSH.
Раньше, как когда дестопный винт был на тоже 1 ТБ, проблем не было - рсинкал на бекапный комп данные и все дела.

Проблема возникла, когда для дестопа купил винт на 2 ТБ, и теперь непонятно, как организовать работу 2-х дисков на бекапном компе.

Из всего здесь обсуждаемого мне больше всего понравилась идея с mhddfs или mergerfs, спасибо No, что подсказал!

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

Вот подтверждение моих догадок:

Насчёт «потерять все данные» - так это во все времена лечилось только бэкапом. И именно с mergefs теряются не все, как в LVM со сдохшим винтом или RAID0.

Такое меня вполне устраивает, невзирая на тормоза FUSE.
Осталось выяснить, в чем разница между mhddfs и mergerfs и какой из них лучше подходит.

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

значит объединение места :)
в объединении файловых систем даже эквивалент RAID1 для отдельных файлов можно сделать :)

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

приходится включать ^моск^ и думать - где важные данные, а где нет

А ты ищешь волшебную программу, которая при копировании сама будет определять, важные данные или нет? И сама будет класть важные данные на более устойчивый винт?

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

значит объединение места :)

Места, места :=)

в объединении файловых систем даже эквивалент RAID1 для отдельных файлов можно сделать :)

Загадками говорите :=)

А ты ищешь волшебную программу, которая при копировании сама будет определять, важные данные или нет?

У меня все данные важные, поэтому разбираться незачем, а главное некогда.
А уж что из них пропадает, это уж как попадет - фортунас-с! :-)
В любом случае это лучше, чем RAID 0 или LVM.

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

первый монтируешь /mnt/disk1 второй в /mnt/disk2
файловое содержимое объединяешь в /mnt/union_disk
при записи файла в /mnt/union_disk/path/to/file он записывается в один дисков.

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

если «уж пропадет, так пропадет» это значит файлы не важны :)

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

файловое содержимое объединяешь в /mnt/union_disk

Это речь идет об объединении с помощью mhddfs/mergerfs?
Или это уже другая тема пошла?

chukcha ★★★★★
() автор топика

dd предлагали уже?

Может быть есть другая технология для бекапирования, более устойчивая к сбоям, чем LVM?

Ок, тогда рисунки пустыни Наска, идолы острова Пасхи, е-пирамиды. Все остальное полумеры и jbod на подкроватном NAS хватит всем. А в кровавом Ынтерпрайзе у тебя не будет такого вопроса, т.к. на коленке NASы по дешману там не собирают и все твои быдлорейды из быдлодисков там тоже не при делах :)

slackwarrior ★★★★★
()

Поэтому везде рекомендуют использовать LVM совместно с RAID, но это затратно под дискам и в данном случае не имеет никакого смысла.

Если диски у тебя не SAS и рейд не аппаратный, это возня в песочнице и надувание щок :)

slackwarrior ★★★★★
()

А причем тут LVM ?

Десктоп 1 большой диск

NAS - 2 мелких диска в raid0 (Не нравится raid лепи 2 диска в LVM один фиг)

Все.

P.S. Ты просто делаешь диск десктопа == дискам НАС и все, как ты это сделаешь не важно.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 2)

А вот пожалуйста, в продолжение темы mhddfs / mergerfs:

1) Человек, у которого проблемами схожи с моими, взял да собрал для дома/для семьи файлопомойку на основе mergerfs и накатал статью
- mergerfs: прозрачное объединение дисков (файловых систем), где подробно описал настройку - спасибо ему!

2) В статье mhddfs: объединение нескольких файловых систем в одну большую виртуальную за 2020 г. предостерегли от использования mhddfs - что ж, спасибо!

3) И наконец, в статье mergerfs VS mhddfs сравниваются обе утилиты, но я мало что из нее понял, кроме бОльшей популярности mergerfs.

И mhddfs, и mergerfs есть в официальных репах Debian 10 - так что можно тестировать! :=)

Upd.

NAS - 2 мелких диска в raid0 (Не нравится raid лепи 2 диска в LVM один фиг)

Товарисч так и не понял, что произойдет при отказе диска в raid0 или LVM по сравнению с mergerfs.

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

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

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

Даже xfsdump это умеет

Интересная идея! А кроме xfsdump какой еще есть, чтобы еще лучше?

Вообще при обсуждении mergefs наткнулся на мнение, что вместо него, тормозного, использовать шуструю самоделку на симлинках.
И как это можно сделать?

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

А кроме xfsdump

Почитал о вашем xfsdump и понял, что это предполагает использование вместо привычной и надежной файловой системы ext4 файловой системы XFS.
О ее надежности до сих пор противоречивые слухи ходят, в-общем, не все однозначно.

Так может, тогда уж лучше использовать ZFS, которая¸ имхо, тоже умеет заниматься бекапированием?
И о преимуществах которой чуть ли легенды слагают :=) -

Что такое ZFS? И почему люди от неё без ума?
Идеальный бэкап за пять минут с ZFS

Если сравнивать возможности Rsync и кастомных скриптов для синхронизации с ZFS, у них не будет ни шанса.
Комбинируем плюсы выше: инкрементальные консистентные бэкапы + мгновенные снапшоты + программный RAID + отправка бэкапов из коробки = идеальный инструмент, объединяющий в себе мощный функционал и огромную производительность.
Чтобы добиться подобного привычным инструментарием, понадобится оркестрировать кучу сервисов с многочисленными точками отказа.

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

Только кажется, и XFS, ZFS в данном случае не подходят, потому что они копируют файловые системы, т.е. слепки, а мне нужно совсем другое -

- выбранные каталоги с файлами

Т.е. выборочно, а не грести все подряд.

Надо было назвать так:

- Чем заменить LVM для бекапирования каталогов/файлов?

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

потому что они копируют файловые системы, т.е. слепки, а мне нужно совсем другое - выбранные каталоги с файлами

Т.е. выборочно, а не грести все подряд.

Это не так. Читайте внимательнее документацию.

i586 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.