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

"Раздел полезных советов: Объединение томов через aufs для от..."	+/–
Сообщение от auto_tips (?), 03-Апр-19, 08:58
Объединение томов с разных физических устройств с распределением файлов/слепков файлов на предмет отказоустойчивости и моментального восстановления в случае нечисти по типу "шифровальщиков". Объединённый ресурс отдаётся через Samba и NFS. Нужно было быстро решить проблему с восстановлением после попадания пользователей под "шифровальщиков". Тем не менее, решение уже показало себя весьма эффективным и буквально спасло. Дополнительно продумывались меры по повышению надёжности, так как если не по- бедности, то по понятным соображениям, организовать правильно организованный бэкап сложно: инкрементальный бэкап периодически (сильно реже разумного) сливается на отдельный, не включенный постоянно, диск и (ещё реже), делается копия на блюрэй. Общая идея: архив разбивается на две (или больше) частей. 1-ая всегда монтируется r/o и содержит холодные и редко изменяемые данные. Эта часть лежит на одной группе томов (рейд сконфигурирован так, что несколько групп томов лежат на своих физических дисках) и с неё достаточно редко делается резервная копия на блюрэй. Для изменяемых данных выделен том, который лежит на другой группе томов (читай, другом физическом диске и в ещё одном случае, на другой ноде). Для хранения состояния файлов, сделано весьма идиотское решение, но опять-таки, практика показала его полезность. Раз в 30 минут ресурс попросту сканируется и если есть изменения, комитится в Git. База гита лежит перекрёстно, на другом томе (=> другом физическом устройстве). В основном, люди работают с доковскими и автокадовскими  файлами, но как оказалось,  несмотря на очевидную неатомарность, файлы в гите не бьются. За счёт сжатия, база гита пухнет умеренно. Раз в три месяца, изменяемые части ресурса сканируются на предмет не изменявшихся за это время файлов и таковые переносятся в r/o хранилище. База гита архивируется и отправляется на хранение. За счёт того, что изменяемая часть ресурса относительно маленькая, всё работает весьма шустро и не жрёт ресурсы. Изменяемые и холодные файлы "слиты" в один ресурс через aufs. А поскольку факт "стирания"/изменения  файла в r/o хранилище aufs имитирует созданием спецфайла / копии изменяемого файла, работа с таким комбинированным хранилищем прозрачна. В то же время, при работе "шифровальщика" или (не)преднамеренном удалении, страдает весьма незначительная часть хранилища, инцидент легко разобрать руками и файлы восстанавливаются моментально. Перекрёстное хранение на разных физических устройствах r/o, r/w и слепков истории изменений файлов, делает сон значительно спокойнее: потерять cразу ВСЁ можно, но значительно менее вероятно, чем при задействовании механизмов перераспределения LVM/снапшотов btrfs. С последними тоже экспериментирую, но более осторожно. Вот как-то так. Ну и неоднократно приходилось доставать копии файлов с совсем небольшим временным лагом и/или сравнивать с "историческими". В обычной схеме со сжатым бэкапом можно было-бы рехнуться. PS: грабли, на которые можно наступить: если нужно поменять ACL/права доступа, это нельзя делать на объединённом ресурсе: aufs тупо скопирует на r/w раздел файлы из всех слоёв. Но если последовательно применить setacl ко всем слоям, изменения подхватятся и будут нормально работать. PPS: overlayfs в такой схеме работает скверно. PPPS: права (любые) в гите не сохраняются. В данном случае это проблема, но схема всё равно оказывается спасительной. URL: https://lists.altlinux.org/pipermail/sisyphus/2019-April/367... Обсуждается: http://www.opennet.dev/tips/info/3103.shtml
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от Крикет (?), 03-Апр-19, 08:58
Интересно но наворочено так много... А вариант с ZFS и например снапшотами каждые 30 минут, с чисткой тех что старше недели и например оставляя ежедневные на 00.00? Не проще это?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от Alex_K (??), 03-Апр-19, 09:37
	Понятно, проще. Ещё и сжатие можно включить :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	29. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 07:03
	> Интересно но наворочено так много... это только кажется. всего 4 строки в .mount юнитах, плюс несколько простых скриптов на таймере. > А вариант с ZFS и например снапшотами каждые 30 минут, с чисткой zfs не рассматривалась из-за ограниченности по оперативной памяти > тех что старше недели и например оставляя ежедневные на 00.00? Не > проще это? обратите внимание, мой вариант позволяет держать непрерывную *историю*. В некоторых ситуациях, это важно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	40. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 26-Окт-19, 13:25
	> это только кажется. всего 4 строки в .mount юнитах, плюс несколько простых скриптов на таймере. а если не успеете поймать момент, когда нужно выключить скрипты и они затрут r/o копию? В zfs можно хранить данные в сколько угодно snapshot-ов, только бы места хватало. с компрессией как раз место появляется > zfs не рассматривалась из-за ограниченности по оперативной памяти я не знаю что там у вас установлено, чтобы была проблема памяти в наше время, когда на серверах стоит 128-256 Г памяти обычно. но безопасность явно стоит того, чтобы потратить денег. если у Вас нет достаточно памяти, то значит её не так много и новая будет стоить копейки. > обратите внимание, мой вариант позволяет держать непрерывную *историю*. В некоторых ситуациях, это важно. удобно, если файлы - это исходный программный код наверное? для word файлов не так актуально. конечно, интересный подход у Вас получился, но немного замороченный. есть ручная работа с Вашей стороны в немалом объеме. плюс возможные проблемы с git если кто-то случайно кинет 1GB iso к примеру. Почему все пишут про zfs, потому что там все это решено. И доступ к снапшотам можно дать юзерам (он наверное и так будет там по-умолчанию, просто скрыт) чтобы Ваше время не отнимать и людям не ходить кляньчить. Не забывайте, Ваше время тоже ресурс.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

3. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от Аноним (3), 03-Апр-19, 11:04
имхо, удалённые (remote) инкрементные бэкапы по таймеру спасут отца русской демократии. плюс ценное держать в VCS и пушить в отдельное место. LVM снапшоты - слишком сложно правильно реализовать, БТРФС - заманчиво, но сомнительно. Оверлеи... выглядит переусложнённым решением, плюс локально вредитель может вайпнуть все диски.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 07:00
	> БТРФС - заманчиво, но сомнительно. btrfs умеренно используется > Оверлеи... выглядит переусложнённым решением, да нет (и не совсем оверлеи, aufs это объеденительная фс, а не оверлейная). слои дают возможность разбросать данные по устройствам и защитить их от изменений. > плюс локально вредитель может вайпнуть > все диски. против лома, нет приёма. но локальный вредитель, получивший рута, это уже совсем уж расп$%^яйсвто. Или уголовка.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от Аноним (4), 03-Апр-19, 12:54
> буквально спасло Не завидую. С таким начальством работать... Кое-где 90-е так и не закончились, видать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от Аноним (38), 03-Июн-19, 08:52
	Они нигде не закончились. Новости читай почаще.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от Alex (??), 04-Апр-19, 09:33
Был такой заказ с маздаем ... но послал такого заказчика. Хотя с самбой бы все вышло и с BTRFS скажем
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от Аноним (6), 04-Апр-19, 11:22
overlayfs под нагрузкой действительно непредсказуем.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от нах (?), 04-Апр-19, 14:21
	> overlayfs под нагрузкой действительно непредсказуем. чево это он у вас непредсказуем? У меня вот вполне предсказуем - "щас навернется. Если не навернется прям щас - значит, подождите до завтра - точно навернется" вот без нагрузки, там да, полная неопределенность - может месяц работать, а может и год, а потом опа - и в тыкву. с aufs, если что, точно такая же ботва, только в тыкву еще и нормальные fs оказавшиеся под ней - поскольку сервер падает в kernel panic С overlay2 (которая совсем не то же самое что overlay) - пока не видали, но слухи ходят, что воз и ныне там, кверху колесами, в смысле.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	18. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от 1 (??), 18-Апр-19, 14:22
	>С overlay2 (которая совсем не то же самое что overlay) - пока не видали, но слухи ходят, что воз и ныне там, кверху колесами, в смысле. Это вы путаете файловую систему overlay (она одна) и драйверы для докера overlay и overlay2.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	37. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от пох (?), 13-Май-19, 16:54
	не путает. два разных драйвера понадобились именно потому, что overlayfs в ядрах до 4.0 и в 4+ - две изрядно разные overlayfs (stable api is nonsense), а в kernel panic- то у нас падал вовсе не докер. Случилось это где-то во времена убунточки 16, к этому времени btrfs'ом для write-only данных уже вполне можно было пользоваться, поэтому лично я не стал разбираться, стало ли в новой версии лучше. Слухи ходили, что окончательного счастья так и не наступило. А вот до того, во времена еще aufs - это было даже не смешно. То есть оно грохалось просто на регулярной основе - поэтому удивляет, почему у анонима его этажерка вообще еще не рухнула. (что в самой aufs что-то исправили, это вряд ли. Те аспиранты, что ее писали, давно уже моргидж выплатили и из профессоров поувольнялись.)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	19. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:22
	>с aufs, если что, точно такая же ботва, только в тыкву еще и нормальные fs оказавшиеся под ней - поскольку сервер падает в kernel panic за 4 года эксплуатации (и плотного тестирования до того), не было ни разу.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

7. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от нах (?), 04-Апр-19, 14:17
АААА, отказоустойчивая aufs!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от Аноним (-), 05-Апр-19, 14:37
	Чего только не придумают, чтобы не юзать DragonFly BSD/HAMMER, или на худой конец классическую ZFS... Кстати, там HAMMER2 вроде как стабилизировали тоже уже - почти с пол года назад. Но для сабжа её применять лично мне пока не приходилось.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	20. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:27
	> Чего только не придумают, чтобы не юзать DragonFly BSD/HAMMER, спасибо, в *реальном* мире, преимуществ не обнаружено. Да и пересаживаться на машину времени и чувствовать себя 30 лет назад не очень охота. > или на худой > конец классическую ZFS... Про передовую zfs все наслышаны. Про её требования, тоже. Так что не всегда самое модное и передовое решение имеет смысл применять. > Кстати, там HAMMER2 вроде как стабилизировали тоже уже - почти с пол > года назад. о да. целых пол-года и конечно, уже есть десятилетия реального опыта? спасибо, но у людей, как правило, нет запасных яек.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	39. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от Аноним (38), 03-Июн-19, 09:00
	Ой расскажи что в бсд 40 лет назад?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	31. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 07:07
	> АААА, отказоустойчивая aufs! единственное, на что наступали за 4 года, это "исчезновение" файла из объединённого слоя. Наблюдалось ДВА раза, при экстремальной нагрузке. Решалось перемонтированием. И да, выяснилось, что для aufs НЕЛЬЗЯ использовать автомонтирование, даже с большим тайм-аутом. Через пол-года аптайма, в системе могут закончиться ресурсы и без перезагрузки это не решается.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от Gannet (ok), 05-Апр-19, 19:49
Изврат феерический.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:28
	> Изврат феерический. И да, и нет. объеденительные файловые системы штука вообще интересная.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от Аноним (11), 07-Апр-19, 07:29
Похвально, автор, но слишком сложно. Делаешь прям как я в юности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от glebiao (ok), 22-Апр-19, 06:29
	> Похвально, автор, но слишком сложно. Делаешь прям как я в юности. наоборот, минимальными инструментами и малой кровью.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

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

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

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

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

	17. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
	Сообщение от Abu (?), 10-Апр-19, 09:09
	Что ж, когда-нибудь и я до снапшотов дойду (: Надо будет потренироваться на досуге.
	Ответить | Правка | ^ к родителю #16 | Наверх | 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 в этом случае справится. Чтобы не справилась - надо чтобы блок действительно был битый, а не "временно", да еще и попал в метаданные.
	Ответить | Правка | ^ к родителю #24 | Наверх | 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 только усугубляют проблему (и довольно быстро становиться ясно, почему: дереву крышка).
	Ответить | Правка | ^ к родителю #30 | Наверх | 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 таки учли, спустя десять лет.
	Ответить | Правка | ^ к родителю #32 | Наверх | 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 не доверил.
	Ответить | Правка | ^ к родителю #33 | Наверх | 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 снапшотов, у вас с математикой, похоже, тоже беда.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

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

13. "Объединение томов через aufs для отказоустойчивости и момент..."	+/–
Сообщение от sk134679 (??), 08-Апр-19, 12:14
https://www.seafile.com/en/home/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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