Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Раздел полезных советов: Объединение томов через aufs для от..., auto_tips (?), 03-Апр-19, (0) [смотреть все] Интересно но наворочено так много А вариант с ZFS и например снапшотами каждые, Крикет (?), 08:58 , 03-Апр-19, (1) // Понятно, проще Ещё и сжатие можно включить , Alex_K (??), 09:37 , 03-Апр-19, (2) это только кажется всего 4 строки в mount юнитах, плюс несколько простых скрип, glebiao (ok), 07:03 , 22-Апр-19, (29) // а если не успеете поймать момент, когда нужно выключить скрипты и они затрут r o, Всем Анонимам Аноним (?), 13:25 , 26-Окт-19, (40) имхо, удалённые remote инкрементные бэкапы по таймеру спасут отца русской демо, Аноним (3), 11:04 , 03-Апр-19, (3) // btrfs умеренно используетсяда нет и не совсем оверлеи, aufs это объеденительная, glebiao (ok), 07:00 , 22-Апр-19, (28) Не завидую С таким начальством работать Кое-где 90-е так и не закончились, в, Аноним (4), 12:54 , 03-Апр-19, (4) // Они нигде не закончились Новости читай почаще , Аноним (38), 08:52 , 03-Июн-19, (38) Был такой заказ с маздаем но послал такого заказчика Хотя с самбой бы все вы, Alex (??), 09:33 , 04-Апр-19, (5) overlayfs под нагрузкой действительно непредсказуем , Аноним (6), 11:22 , 04-Апр-19, (6) // чево это он у вас непредсказуем У меня вот вполне предсказуем - щас навернется, нах (?), 14:21 , 04-Апр-19, (8) // Это вы путаете файловую систему overlay она одна и драйверы для докера overlay, 1 (??), 14:22 , 18-Апр-19, (18) // не путает два разных драйвера понадобились именно потому, что overlayfs в ядрах, пох (?), 16:54 , 13-Май-19, (37) за 4 года эксплуатации и плотного тестирования до того , не было ни разу , glebiao (ok), 06:22 , 22-Апр-19, (19) АААА, отказоустойчивая aufs , нах (?), 14:17 , 04-Апр-19, (7) // Чего только не придумают, чтобы не юзать DragonFly BSD HAMMER, или на худой коне, Аноним (-), 14:37 , 05-Апр-19, (9) // спасибо, в реальном мире, преимуществ не обнаружено Да и пересаживаться на ма, glebiao (ok), 06:27 , 22-Апр-19, (20) // Ой расскажи что в бсд 40 лет назад , Аноним (38), 09:00 , 03-Июн-19, (39) единственное, на что наступали за 4 года, это исчезновение файла из объединённ, glebiao (ok), 07:07 , 22-Апр-19, (31) Изврат феерический , Gannet (ok), 19:49 , 05-Апр-19, (10) // И да, и нет объеденительные файловые системы штука вообще интересная , glebiao (ok), 06:28 , 22-Апр-19, (21) Похвально, автор, но слишком сложно Делаешь прям как я в юности , Аноним (11), 07:29 , 07-Апр-19, (11) // наоборот, минимальными инструментами и малой кровью , glebiao (ok), 06:29 , 22-Апр-19, (22) http www mikerubel org computers rsync_snapshots или, мб, я что-то совсем не п, Abu (?), 11:46 , 08-Апр-19, (12)   // какой только хрени люди не делают , только чтоб не уметь пользоваться нормальны, пох (?), 22:33 , 08-Апр-19, (14)   // Снапшоты снапшотами, я не против них Я про другое - если городить городьбу а в, abu (?), 01:55 , 09-Апр-19, (15)   // ну я примерно так и делаю, только вместо упражнений с хардлинками и надежды что , нах (?), 10:30 , 09-Апр-19, (16)   Что ж, когда-нибудь и я до снапшотов дойду Надо будет потренироваться на досу, Abu (?), 09:09 , 10-Апр-19, (17)   1 я использую btrfs и её снэпшоты Но в разумных пределах a делать 240 - 36, glebiao (ok), 06:42 , 22-Апр-19, (24) +1   это просто какая-то болезнь Зачем нужны снапшоты раз в четыре минуты, как вообщ, пох (?), 07:04 , 22-Апр-19, (30) +1   раз в 30 минут, не надо утрировать потому что работает много людей 30 минут о, glebiao (ok), 08:04 , 22-Апр-19, (32)   раз в 30 минут это не 360 в сутки, а всего 48 Да, любая fs и даже lvm выдержат , пох (?), 10:53 , 22-Апр-19, (33) +1   Да, извиняюсь С недосыпу написал чушь статья моментально гуглится Не уверен На, glebiao (ok), 13:12 , 22-Апр-19, (35)   И да никаких хардлинков какие хардлинки между устройствами тут нет Идея в то, glebiao (ok), 06:50 , 22-Апр-19, (25)   Это происходит автоматически, за счёт слоёв aufs и гита, каждый из которых наход, glebiao (ok), 06:54 , 22-Апр-19, (26)   240 - 360 снэпштов в сутки, 11160 снэпшотов в месяц и потом всё-это в какой-то а, glebiao (ok), 06:56 , 22-Апр-19, (27)   да сколько нужно дисковых ресурсов, чтобы в течении разумного времени держать 8, glebiao (ok), 06:34 , 22-Апр-19, (23)   // вы лучше расскажите, сколько нужно ресурсов , чтобы хотя бы угадать, какое имен, пох (?), 10:59 , 22-Апр-19, (34)   // про количество снимков уже извинился, недосып Про мусорку людям, иногда, нужно , glebiao (ok), 13:18 , 22-Апр-19, (36)   https www seafile com en home , sk134679 (??), 12:14 , 08-Апр-19, (13) 1,3,4,5,6,7,10,11,12,13

Сообщения

[Сортировка по времени | RSS]

12. "Объединение томов через aufs для отказоустойчивости и моментального восстановления "	+/–
Сообщение от Abu (?), 08-Апр-19, 11:46
http://www.mikerubel.org/computers/rsync_snapshots/ или, мб, я что-то совсем не понимаю? (:
Ответить | Правка | Наверх | Cообщить модератору

	14. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от пох (?), 08-Апр-19, 22:33
	"какой только хрени люди не делают", только чтоб не уметь пользоваться нормальными снапшотами и умеющими их fs...
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от abu (?), 09-Апр-19, 01:55
	Снапшоты снапшотами, я не против них. Я про другое - если городить городьбу (а ведь у автора тут городьба) то проблема - копировать файлы на сторонний носитель, чтобы не добрался =шифровальщик=. Простейший вариант (еще одним из условий была быстрота, а то не спасет) - делать rsync те же 30 минут. То, что по ссылке предложено с глубиной в несколько дней складывать копии rsync'a - это уже на любителя, хотя, в спокойном варианте, как простой бэкап, у меня, например, работает достаточно давно, еще и место экономится за счет хардлинков. Или так делать (rsync шары, в которой работают) нельзя и надо непременно делать вот это: = Для хранения состояния файлов, сделано весьма идиотское решение, но опять-таки, практика показала его полезность. Раз в 30 минут ресурс попросту сканируется и если есть изменения, комитится в Git. База гита лежит перекрёстно, на другом томе (=> другом физическом устройстве). В основном, люди работают с доковскими и автокадовскими  файлами, но как оказалось,  несмотря на очевидную неатомарность, файлы в гите не бьются. За счёт сжатия, база гита пухнет умеренно. = ? Я вот именно это никак понять не могу.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от нах (?), 09-Апр-19, 10:30
	ну я примерно так и делаю, только вместо упражнений с хардлинками и надежды что rsync как-нибудь сам разберется и не испортит, что было по той ссылке - просто создаю новый снапшот. Смысла НЕ использовать для архива поддерживающую их fs - уже лет пять как совсем нет.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от Abu (?), 10-Апр-19, 09:09
	Что ж, когда-нибудь и я до снапшотов дойду (: Надо будет потренироваться на досуге.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Объединение томов через aufs для отказоустойчивости и момент..."	+1 +/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:42
	> ну я примерно так и делаю, только вместо упражнений с хардлинками и > надежды что rsync как-нибудь сам разберется и не испортит, что было > по той ссылке - просто создаю новый снапшот. Смысла НЕ использовать > для архива поддерживающую их fs - уже лет пять как совсем > нет. 1. я использую btrfs и её снэпшоты. Но! в разумных пределах:   a) делать 240 - 360 снэпшотов в сутки, это экстремальное развлечение. Область метаданных переполняется моментально.   b) согласен, btrfs уже не очень страшно доверять ответственные данные. Но если вдруг случится бэдблок (и что ещё хуже, даже не случится. просто из-за плохого контакта в интерфейсе с диском btrfs *временно* воспримет какой-то блок, как плохой), то всё, катастрофа. Вы уже не сможете воссатновить эту файловую систему. Вам придётся срочно сливать  все данные на другой носитель и пересоздавать файловую систему. Данные, скорее всего, уцелеют (возможно, за редким исключением). Но все снэпшоты Вы при этом потеряете. Плюс несколько часов простоя. 2. Столько снэпшотов на lvm --- это даже не смешно. 3. На zfs говорить не буду, но тут плюс ещё потребные ресурсы. как-то так.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	30. "Объединение томов через aufs для отказоустойчивости и момент..."	+1 +/–
	Сообщение от пох (?), 22-Апр-19, 07:04
	> 1. я использую btrfs и её снэпшоты. Но! в разумных пределах: >   a) делать 240 - 360 снэпшотов в сутки, это экстремальное это просто какая-то болезнь. Зачем нужны снапшоты раз в четыре минуты, как вообще потом найти среди них нужный даже если нужны, и что там такое уникальное хранится - даже спрашивать не буду. Но если у вас от этого переполняется какая-то там "область метаданных" (нет у btrfs такой выделенной области, метаданные там размазаны по диску ровным слоем, root tree на то и tree) - вы, вероятнее всего, бредите. Отдельно расскажите чем "метаданные" снапшота отличаются от "метаданных" копии сделанной волшебным rsync, учитывая что там те же самые ссылки на те же самые файлы. >   b) согласен, btrfs уже не очень страшно доверять ответственные данные. ответственные - страшно. Но то что вот так снапшотят - это не ответственные, это безответственные. А у меня и того проще - это архив. Его можно потерять весь, если это случается не каждый день а раз в году - крайне маловероятно что именно в этот момент он понадобится - у нас все еще есть то, что туда архивируется. Буду следующие пятнадцать минут особенно с ним осторожен - пока переформатируется раздел и создается свежая копия. > воспримет какой-то блок, как плохой), то всё, катастрофа. Вы уже не надо бы проверить, но что-то мне подсказывает, что fsck в этом случае справится. Чтобы не справилась - надо чтобы блок действительно был битый, а не "временно", да еще и попал в метаданные.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 08:04
	>Зачем нужны снапшоты раз в четыре минуты, раз в 30 минут, не надо утрировать. потому. что работает много людей. 30 минут оказалось комфортным минимумом, если вдруг "ж стрясается". >как вообще потом найти среди них нужный даже если нужны, поэтому и была попытка хранить историю в гите. >Но если у вас от этого переполняется какая-то там "область метаданных" (нет у btrfs такой >выделенной области, метаданные там размазаны по диску ровным слоем, root tree на то и tree) >- вы, вероятнее всего, бредите. https://btrfs.wiki.kernel.org/articles/f/a/q/FAQ_1fe9.html btrfs fi df . Data, single: total=77.01GiB, used=43.83GiB System, DUP: total=8.00MiB, used=16.00KiB Metadata, DUP: total=3.00GiB, used=384.92MiB GlobalReserve, single: total=96.56MiB, used=0.00B а это на томе с 4 снэпшотами .qcow2: "свободного места" 79G из 200G, Data, single: total=125.01GiB, used=120.66GiB System, DUP: total=8.00MiB, used=16.00KiB Metadata, DUP: total=1.00GiB, used=957.70MiB GlobalReserve, single: total=144.03MiB, used=0.00B >надо бы проверить, но что-то мне подсказывает, что fsck в этом случае справится. Чтобы не >справилась - надо чтобы блок действительно был битый, а не "временно", да еще и попал в >метаданные. Я на это наступил. Возможно, просто "повезло". Детально не исследовал. Нет, любые попытки restore только усугубляют проблему (и довольно быстро становиться ясно, почему: дереву крышка).
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Объединение томов через aufs для отказоустойчивости и момент..."	+1 +/–
	Сообщение от пох (?), 22-Апр-19, 10:53
	> раз в 30 минут, не надо утрировать. раз в 30 минут это не 360 в сутки, а всего 48. Да, любая fs и даже lvm выдержат 48 штук (если, конечно, вы потрудитесь снести уже ненужные вчерашние. > https://btrfs.wiki.kernel.org/articles/f/a/q/FAQ_1fe9.html The requested URL /articles/f/a/q/FAQ_1fe9.html was not found on this server. ubuntu-server:/srv> btrfs fi df . Data, single: total=214.01GiB, used=213.67GiB System, DUP: total=8.00MiB, used=48.00KiB Metadata, DUP: total=3.00GiB, used=2.10GiB GlobalReserve, single: total=414.80MiB, used=0.00B а сколько тут снапшотов - я хз, поскольку не вижу смысла их считать - делается новый бэкап - новый снапшот. Насколько я понимаю, для btrfs сабвольюм это просто каталог, очередной, с некоторыми дополнительными атрибутами, а его содержимое - просто рефлинки, которых может быть абсолютно любое количество. Оно, наверное, когда-нибудь лопнет (и будет прибито и пересоздано), но не от количества снапшотов точно. > Я на это наступил. Возможно, просто "повезло". возможно не просто, а что-то было снова сделано странно. метаданные дублируются, если диск rotational и специально не отключить (обратите внимание на DUP в вашем собственном примере), и защищены контрольной суммой, насколько я понимаю.  Опыт ext3 таки учли, спустя десять лет.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 13:12
	>> раз в 30 минут, не надо утрировать. >раз в 30 минут это не 360 в сутки, а всего 48. Да, извиняюсь. С недосыпу написал чушь. >The requested URL /articles/f/a/q/FAQ_1fe9.html was not found on this server. статья моментально гуглится. >для btrfs сабвольюм это просто каталог, очередной, с некоторыми дополнительными атрибутами, >а его содержимое - просто рефлинки, которых может быть абсолютно любое количество. Не уверен. Насколько я понял эту механику, подтом, это отдельное дерево, плюс кросс-линки. И если переборщить, вся механика упрётся рогом задолго до того, как некуда будет писать метаданные, просто по скорости обхода. >> Я на это наступил. Возможно, просто "повезло". >возможно не просто, а что-то было снова сделано странно. Нет. На btrfs был корень ноутбучной системы, без всяких изысков. Единственным изыском, можно считать, разве что compress=lzo,autodefrag,commit=120. Но без последних двух, работать с btrfs вообще нереально :) Диск hdd. От тряски слегка  нарушился контакт sata. Проявилось репортом о бэдблоке от btrfs (!) (ни смарт, ни тесты, бедов не нашли). Полностью восстановить данные не получилось, более того, любая попытка стандартным (faq/wiki btrfs) образом что-то исправить, приводила к ухудшению. Снапшоты делу  не помогли, так как файлы, повреждённые в основном дереве, не были изменены относительно снэпшотов и как и можно было ожидать, так-же оказались недоступны. Кончилось форматом и переустановкой. К счастью, /home btrfs не доверил.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:50
	> ну я примерно так и делаю, только вместо упражнений с хардлинками И да. никаких хардлинков (какие хардлинки между устройствами?) тут нет. Идея в том, что данные автоматически дублируются на разные физические носители: r/o слой на одном физ. устройстве, r/w слой или слои на другом (гих) физ. устройстве(ах), хранилище гита на 1-ом или 3-ем. Последнее обеспечивает историю. и само собой получается, что данные хранятся на разных физических устройствах. Одновременный выход из строя сразу двух, это уже достаточно маловероятно. а история с малым шагом, позволяет с высокой колокольни плевать на шифровальщиков. Время полного восстановления --- минуты, из которых бОльшая часть времени уходит не на восстановление собственно данных, а на накатывание заново owner:gid и ACL/EA, которые, к сожалению, гит принципиально не хранит.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	26. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:54
	> копировать > файлы на сторонний носитель, чтобы не добрался =шифровальщик=. Это происходит автоматически, за счёт слоёв aufs и гита, каждый из которых находятся на разных носителях (для физической надёжности) или хотя, бы, перекрёстно (из тех-же соображений). Слои и хранилище гита лежат на разных физических носителях, не видных по сети. Клиенты видят только суммарный слой. Манипулировать историей они не могут. Случай попадания шифровальщика непосредственно в систему сервера не рассматриваем, так как от лома нет приёма.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	27. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:56
	> "какой только хрени люди не делают", только чтоб не уметь пользоваться нормальными > снапшотами и умеющими их fs... 240 - 360 снэпштов в сутки, 11160 снэпшотов в месяц и потом всё-это в какой-то архив... Вы уверены в разумности такого решения?
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	23. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:34
	> http://www.mikerubel.org/computers/rsync_snapshots/ > или, мб, я что-то совсем не понимаю? (: да. сколько нужно дисковых ресурсов, чтобы в течении разумного времени держать 8 - 12(раб. часов)*30(минут) = 240 - 360 копий в сутки? Сколько нужно ресурсов, чтобы держать эти копии в течении месяцев/лет (история изменений файлов)? решений с гитом извратное, но делает в точности то-же самое(!) весьма компактно и автоматически.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	34. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от пох (?), 22-Апр-19, 10:59
	> да. сколько нужно дисковых ресурсов, чтобы в течении разумного времени держать 8 > - 12(раб. часов)*30(минут) = 240 - 360 копий в сутки? Сколько > нужно ресурсов, чтобы держать эти копии в течении месяцев/лет (история изменений > файлов)? вы лучше расскажите, сколько нужно "ресурсов", чтобы хотя бы угадать, какое именно изменение вам нужно в этой громадной мусорке. А ресурсов надо, внезапно, ровно на количество уникальных байтиков во всей этой свалке, никакого волшебства ваш гит не умеет. 8 рабочих часов со снапшотами через 30 минут - это 16 снапшотов, у вас с математикой, похоже, тоже беда.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 13:18
	> вы лучше расскажите, сколько нужно "ресурсов", чтобы хотя бы угадать, какое именно > изменение вам нужно в этой громадной мусорке. про количество снимков уже извинился, недосып. Про мусорку: людям, иногда, нужно достать файл по состоянию на месяц позапрошлого года. > А ресурсов надо, внезапно, ровно на количество уникальных байтиков во всей этой > свалке, никакого волшебства ваш гит не умеет. Разумеется. И разумеется, не умеет. Но умеет некоторое сжатие (хотя и считается, что с двоичными объектами работает неэффективно) и умеет удобно работать с историей. Замена гита на снапшоты, да ради бога. Но тогда исчезает возможность разместить хранилище на _другом_ устройстве и "бесплатно", в довесок к истории, получить дополнительную надёжность. > 8 рабочих часов со снапшотами через 30 минут - это 16 снапшотов, > у вас с математикой, похоже, тоже беда. о да. очень хочется спать :)
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема