Параллельное копирование на два диска без райда - это возможно?

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

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

Либо фс с версионированием, чтобы хранить все версии всех файлов.

за один проход чтения гонять данные сразу на два диска

Кажется это довольно просто костыльнуть при помощи cat, tee и такой-то матери

https://www.gnu.org/software/coreutils/manual/html_node/tee-invocation.html

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

Можно затестить такой подход. Типа такого что-то, шобы сразу :

time xargs -n 1 cp -v /home/testfile<<<"/mnt/disk1/ /mnt/disk2/" 

Ты уж определись, тебе надёжно («с упором на отказоустойчивость»), или просто («в сторону упрощения»).

Не знаю как на других файловых системах, а если из mirror в ZFS останется только один мембер (при условии адекватного copies), пул продолжит функционировать.

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

Есть одна маленькая, но очень важная деталь: никто не гарантирует что обе идентичные команды, запущенные одновременно (с разницей в миллисекунды, но это сейчас не важно), будут читать те же файлы в той же последовательности. И если они пойдут разными путями, I/O встанет раком, а за ним и вся остальная ОС (особенно если это Linux).

грубая инженерная прикидка:

если у ТС гиг свободной памяти: при одной команде копирования кеш делится примерно пополам, то есть по 500 Мбайт на буферы чтения и записи. при скорости чтения-записи скажем 100 Мбайт/сек кеш обновляется каждые 5 сек. то бишь «квазиодновременно» это даже могут быть секунды разницы.

при двух командах будет примерно по 330 Мбайт на каждый буфер

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

от такой мелочи I/O встанет раком? ну не гони! ОСь просто медленнее будет читать входные потоки

Всем большое спасибо!
Вариант с zfs или бд не катит ввиду возможного полного отключения питания в любой момент.
Бонусом, т.к. диск может перекочевать в другой пк, то предпочтительно попользовать нтфс или ехт4

В целом проблема, видимо, решится самописанной программкой в пять строчек (блок данных в озу, из озу на нужное кол-во дисков параллельно), так будет видимо проще :-)

данных 1-2Тб

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

очевидный RAID 1 на 4 диска

в любой момент данные могут быть запороты программно

Вот в этой строке сложность больше, чем во всей остальной шапке вместе взятой. Как ты от этого собрался беречься?

очевидный RAID 1 на 4 диска

Ммм а зачем?

Вот в этой строке сложность больше, чем во всей остальной шапке вместе взятой. Как ты от этого собрался беречься?

Переодический бекап на вторые два диска, чтоб можно было откатиться
Ручной откат полностью устраивает ибо порчу данных иногда может определить только человек (если данные формально целы но их состав ставит систему раком ввиду некорректной конфигурации)

если у ТС гиг свободной памяти: при одной команде копирования кеш делится примерно пополам, то есть по 500 Мбайт на буферы чтения и записи.

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

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

С большой долей вероятности. Хотя, конечно, зависит от объёма и количества файлов.

от такой мелочи I/O встанет раком? ну не гони! ОСь просто медленнее будет читать входные потоки

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

Ммм а зачем?

Потому что 4 диска на 2ТБ меньше расходов на проектирование, тестирование и развёртывание такой дичи? Пока такая система планируется в количестве одного инстанса, нет смысла экономить спички.

Переодический бекап на вторые два диска, чтоб можно было откатиться

А. То есть порча это не условный rm -rf, а конкретный ограниченный набор едействий? И есть есть возможность или способ бэкапить нагорячую или все останавливать? Тогда, наверное, можно и так, хотя и неинтересно. Одной молнии или одной порчи ФС хватит, чтобы все накрылось.

А как тебе такой вариант: 5 дисков по 4ГБ, на них снапшоты (блочных, средствами ФС, уровнем выше — не суть), из них 2 всегда снаружи и хранятся в другом месте? Раз в неделю один вынимается, один вставляется. Так у тебя будут и online-снэпшоты, и постоянное тестирование странного требования про выемку диска, и гальваническая развязка, останутся только оффсайт-бэкап и обеспечение консистентности при вытыкании когда угодно.

То есть порча это не условный rm -rf, а конкретный ограниченный набор едействий?

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

И есть есть возможность или способ бэкапить нагорячую или все останавливать?

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

Одной молнии или одной порчи ФС хватит, чтобы все накрылось.

вот для борьбы с порчей фс там изначально планировалось два отдельных массива но вроде как массив + 2 диска выглядят еще более устойчиво

А как тебе такой вариант: 5 дисков по 4ГБ, на них снапшоты (блочных, средствами ФС, уровнем выше — не суть), из них 2 всегда снаружи и хранятся в другом месте? Раз в неделю один вынимается, один вставляется. Так у тебя будут и online-снэпшоты, и постоянное тестирование странного требования про выемку диска, и гальваническая развязка, останутся только оффсайт-бэкап и обеспечение консистентности при вытыкании когда угодно.

полный формат системы немного другой:

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

из нюансов:

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

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

п.с. если в кратце то на яве примерно так получается:

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

получается что:

• чтение с диска одно
• данных в озу = объем буфера * кол-во потоков записи
• данные пишутся параллельно
• скорость чтения = скорости записи самого медленного потока
• сихронизация тупо по очередям

можно, конечно, держать одну очередь на запись и сделать синхронизацию через семафорчики но на практике это сложнее чем кажется а если буфер всего мегабайт и потоков всего 4 то в целом страдания не стоят свечь :-)

Тебе нужен бекап!.. снимков!.. А не колхозить раид1 на 4 диска.

Тебе нужен бекап!.. снимков!.. А не колхозить раид1 на 4 диска.

да брат, я и спрашивал как делать сразу два бэкапа в один проход :-)

А снимки уже сделал?

А снимки уже сделал?

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

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