| 1.1, Крикет (?), 08:58, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно но наворочено так много...
А вариант с ZFS и например снапшотами каждые 30 минут, с чисткой тех что старше недели и например оставляя ежедневные на 00.00? Не проще это?
| | |
| |
| 2.29, glebiao (ok), 07:03, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
 > Интересно но наворочено так много...
это только кажется. всего 4 строки в .mount юнитах, плюс несколько простых скриптов на таймере.
> А вариант с ZFS и например снапшотами каждые 30 минут, с чисткой
zfs не рассматривалась из-за ограниченности по оперативной памяти
> тех что старше недели и например оставляя ежедневные на 00.00? Не
> проще это?
обратите внимание, мой вариант позволяет держать непрерывную *историю*. В некоторых ситуациях, это важно.
| | |
| |
| 3.40, Всем Анонимам Аноним (?), 13:25, 26/10/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> это только кажется. всего 4 строки в .mount юнитах, плюс несколько простых скриптов на таймере.
а если не успеете поймать момент, когда нужно выключить скрипты и они затрут r/o копию? В zfs можно хранить данные в сколько угодно snapshot-ов, только бы места хватало. с компрессией как раз место появляется
> zfs не рассматривалась из-за ограниченности по оперативной памяти
я не знаю что там у вас установлено, чтобы была проблема памяти в наше время, когда на серверах стоит 128-256 Г памяти обычно. но безопасность явно стоит того, чтобы потратить денег. если у Вас нет достаточно памяти, то значит её не так много и новая будет стоить копейки.
> обратите внимание, мой вариант позволяет держать непрерывную *историю*. В некоторых ситуациях, это важно.
удобно, если файлы - это исходный программный код наверное? для word файлов не так актуально.
конечно, интересный подход у Вас получился, но немного замороченный. есть ручная работа с Вашей стороны в немалом объеме. плюс возможные проблемы с git если кто-то случайно кинет 1GB iso к примеру.
Почему все пишут про zfs, потому что там все это решено. И доступ к снапшотам можно дать юзерам (он наверное и так будет там по-умолчанию, просто скрыт) чтобы Ваше время не отнимать и людям не ходить кляньчить. Не забывайте, Ваше время тоже ресурс.
| | |
|
|
| 1.3, Аноним (3), 11:04, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
имхо, удалённые (remote) инкрементные бэкапы по таймеру спасут отца русской демократии. плюс ценное держать в VCS и пушить в отдельное место. LVM снапшоты - слишком сложно правильно реализовать, БТРФС - заманчиво, но сомнительно. Оверлеи... выглядит переусложнённым решением, плюс локально вредитель может вайпнуть все диски.
| | |
| |
| 2.28, glebiao (ok), 07:00, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> БТРФС - заманчиво, но сомнительно.
btrfs умеренно используется
> Оверлеи... выглядит переусложнённым решением,
да нет (и не совсем оверлеи, aufs это объеденительная фс, а не оверлейная).
слои дают возможность разбросать данные по устройствам и защитить их от изменений.
> плюс локально вредитель может вайпнуть
> все диски.
против лома, нет приёма.
но локальный вредитель, получивший рута, это уже совсем уж расп$%^яйсвто. Или уголовка.
| | |
|
| 1.4, Аноним (4), 12:54, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> буквально спасло
Не завидую. С таким начальством работать... Кое-где 90-е так и не закончились, видать.
| | |
| 1.5, Alex (??), 09:33, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Был такой заказ с маздаем ... но послал такого заказчика.
Хотя с самбой бы все вышло и с BTRFS скажем
| | |
| |
| 2.8, нах (?), 14:21, 04/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> overlayfs под нагрузкой действительно непредсказуем.
чево это он у вас непредсказуем? У меня вот вполне предсказуем - "щас навернется. Если не навернется прям щас - значит, подождите до завтра - точно навернется"
вот без нагрузки, там да, полная неопределенность - может месяц работать, а может и год, а потом опа - и в тыкву.
с aufs, если что, точно такая же ботва, только в тыкву еще и нормальные fs оказавшиеся под ней - поскольку сервер падает в kernel panic
С overlay2 (которая совсем не то же самое что overlay) - пока не видали, но слухи ходят, что воз и ныне там, кверху колесами, в смысле.
| | |
| |
| 3.18, 1 (??), 14:22, 18/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>С overlay2 (которая совсем не то же самое что overlay) - пока не видали, но слухи ходят, что воз и ныне там, кверху колесами, в смысле.
Это вы путаете файловую систему overlay (она одна) и драйверы для докера overlay и overlay2.
| | |
| |
| 4.37, пох (?), 16:54, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
не путает. два разных драйвера понадобились именно потому, что overlayfs в ядрах до 4.0 и в 4+ - две изрядно разные overlayfs (stable api is nonsense), а в kernel panic- то у нас падал вовсе не докер.
Случилось это где-то во времена убунточки 16, к этому времени btrfs'ом для write-only данных уже вполне можно было пользоваться, поэтому лично я не стал разбираться, стало ли в новой версии лучше. Слухи ходили, что окончательного счастья так и не наступило.
А вот до того, во времена еще aufs - это было даже не смешно. То есть оно грохалось просто на регулярной основе - поэтому удивляет, почему у анонима его этажерка вообще еще не рухнула. (что в самой aufs что-то исправили, это вряд ли. Те аспиранты, что ее писали, давно уже моргидж выплатили и из профессоров поувольнялись.)
| | |
|
| 3.19, glebiao (ok), 06:22, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>с aufs, если что, точно такая же ботва, только в тыкву еще и нормальные fs оказавшиеся под ней - поскольку сервер падает в kernel panic
за 4 года эксплуатации (и плотного тестирования до того), не было ни разу.
| | |
|
|
| |
| 2.9, Аноним (-), 14:37, 05/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Чего только не придумают, чтобы не юзать DragonFly BSD/HAMMER, или на худой конец классическую ZFS...
Кстати, там HAMMER2 вроде как стабилизировали тоже уже - почти с пол года назад. Но для сабжа её применять лично мне пока не приходилось.
| | |
| |
| 3.20, glebiao (ok), 06:27, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Чего только не придумают, чтобы не юзать DragonFly BSD/HAMMER,
спасибо, в *реальном* мире, преимуществ не обнаружено. Да и пересаживаться на машину времени
и чувствовать себя 30 лет назад не очень охота.
> или на худой
> конец классическую ZFS...
Про передовую zfs все наслышаны. Про её требования, тоже. Так что не всегда самое модное и передовое решение имеет смысл применять.
> Кстати, там HAMMER2 вроде как стабилизировали тоже уже - почти с пол
> года назад.
о да. целых пол-года и конечно, уже есть десятилетия реального опыта? спасибо, но у людей, как правило, нет запасных яек.
| | |
|
| 2.31, glebiao (ok), 07:07, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> АААА, отказоустойчивая aufs!
единственное, на что наступали за 4 года, это "исчезновение" файла из объединённого слоя.
Наблюдалось ДВА раза, при экстремальной нагрузке.
Решалось перемонтированием.
И да, выяснилось, что для aufs НЕЛЬЗЯ использовать автомонтирование, даже с большим тайм-аутом. Через пол-года аптайма, в системе могут закончиться ресурсы и без перезагрузки это не решается.
| | |
|
| |
| 2.21, glebiao (ok), 06:28, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Изврат феерический.
И да, и нет.
объеденительные файловые системы штука вообще интересная.
| | |
|
| |
| 2.22, glebiao (ok), 06:29, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Похвально, автор, но слишком сложно. Делаешь прям как я в юности.
наоборот, минимальными инструментами и малой кровью.
| | |
|
| |
| 2.14, пох (?), 22:33, 08/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
"какой только хрени люди не делают", только чтоб не уметь пользоваться нормальными снапшотами и умеющими их fs...
| | |
| |
| 3.15, abu (?), 01:55, 09/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Снапшоты снапшотами, я не против них. Я про другое - если городить городьбу (а ведь у автора тут городьба) то проблема - копировать файлы на сторонний носитель, чтобы не добрался =шифровальщик=. Простейший вариант (еще одним из условий была быстрота, а то не спасет) - делать rsync те же 30 минут. То, что по ссылке предложено с глубиной в несколько дней складывать копии rsync'a - это уже на любителя, хотя, в спокойном варианте, как простой бэкап, у меня, например, работает достаточно давно, еще и место экономится за счет хардлинков.
Или так делать (rsync шары, в которой работают) нельзя и надо непременно делать вот это:
=
Для хранения состояния файлов, сделано весьма идиотское решение, но опять-таки, практика показала его полезность. Раз в 30 минут ресурс попросту сканируется и если есть изменения, комитится в Git. База гита лежит перекрёстно, на другом томе (=> другом физическом устройстве). В основном, люди работают с доковскими и автокадовскими файлами, но как оказалось, несмотря на очевидную неатомарность, файлы в гите не бьются. За счёт сжатия, база гита пухнет умеренно.
=
?
Я вот именно это никак понять не могу.
| | |
| |
| 4.16, нах (?), 10:30, 09/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
ну я примерно так и делаю, только вместо упражнений с хардлинками и надежды что rsync как-нибудь сам разберется и не испортит, что было по той ссылке - просто создаю новый снапшот. Смысла НЕ использовать для архива поддерживающую их fs - уже лет пять как совсем нет.
| | |
| |
| 5.17, Abu (?), 09:09, 10/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
Что ж, когда-нибудь и я до снапшотов дойду (: Надо будет потренироваться на досуге.
| | |
| 5.24, glebiao (ok), 06:42, 22/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ну я примерно так и делаю, только вместо упражнений с хардлинками и
> надежды что rsync как-нибудь сам разберется и не испортит, что было
> по той ссылке - просто создаю новый снапшот. Смысла НЕ использовать
> для архива поддерживающую их fs - уже лет пять как совсем
> нет.
1. я использую btrfs и её снэпшоты. Но! в разумных пределах:
a) делать 240 - 360 снэпшотов в сутки, это экстремальное развлечение. Область метаданных переполняется моментально.
b) согласен, btrfs уже не очень страшно доверять ответственные данные. Но если вдруг случится бэдблок (и что ещё хуже, даже не случится. просто из-за плохого контакта в интерфейсе с диском btrfs *временно* воспримет какой-то блок, как плохой), то всё, катастрофа. Вы уже не сможете воссатновить эту файловую систему. Вам придётся срочно сливать все данные на другой носитель и пересоздавать файловую систему. Данные, скорее всего, уцелеют (возможно, за редким исключением). Но все снэпшоты Вы при этом потеряете. Плюс несколько часов простоя.
2. Столько снэпшотов на lvm --- это даже не смешно.
3. На zfs говорить не буду, но тут плюс ещё потребные ресурсы.
как-то так.
| | |
| |
| 6.30, пох (?), 07:04, 22/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> 1. я использую btrfs и её снэпшоты. Но! в разумных пределах:
> a) делать 240 - 360 снэпшотов в сутки, это экстремальное
это просто какая-то болезнь.
Зачем нужны снапшоты раз в четыре минуты, как вообще потом найти среди них нужный даже если нужны, и что там такое уникальное хранится - даже спрашивать не буду.
Но если у вас от этого переполняется какая-то там "область метаданных" (нет у btrfs такой выделенной области, метаданные там размазаны по диску ровным слоем, root tree на то и tree) - вы, вероятнее всего, бредите. Отдельно расскажите чем "метаданные" снапшота отличаются от "метаданных" копии сделанной волшебным rsync, учитывая что там те же самые ссылки на те же самые файлы.
> b) согласен, btrfs уже не очень страшно доверять ответственные данные.
ответственные - страшно. Но то что вот так снапшотят - это не ответственные, это безответственные.
А у меня и того проще - это архив. Его можно потерять весь, если это случается не каждый день а раз в году - крайне маловероятно что именно в этот момент он понадобится - у нас все еще есть то, что туда архивируется. Буду следующие пятнадцать минут особенно с ним осторожен - пока переформатируется раздел и создается свежая копия.
> воспримет какой-то блок, как плохой), то всё, катастрофа. Вы уже не
надо бы проверить, но что-то мне подсказывает, что fsck в этом случае справится. Чтобы не справилась - надо чтобы блок действительно был битый, а не "временно", да еще и попал в метаданные.
| | |
| |
| 7.32, glebiao (ok), 08:04, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Зачем нужны снапшоты раз в четыре минуты,
раз в 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 только усугубляют проблему (и довольно быстро становиться ясно, почему: дереву крышка).
| | |
| |
| 8.33, пох (?), 10:53, 22/04/2019 [^] [^^] [^^^] [ответить] | +1 +/– | раз в 30 минут это не 360 в сутки, а всего 48 Да, любая fs и даже lvm выдержат... текст свёрнут, показать | | |
|
|
|
| 5.25, glebiao (ok), 06:50, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> ну я примерно так и делаю, только вместо упражнений с хардлинками
И да. никаких хардлинков (какие хардлинки между устройствами?) тут нет.
Идея в том, что данные автоматически дублируются на разные физические носители:
r/o слой на одном физ. устройстве,
r/w слой или слои на другом (гих) физ. устройстве(ах),
хранилище гита на 1-ом или 3-ем. Последнее обеспечивает историю.
и само собой получается, что данные хранятся на разных физических устройствах. Одновременный выход из строя сразу двух, это уже достаточно маловероятно.
а история с малым шагом, позволяет с высокой колокольни плевать на шифровальщиков. Время полного восстановления --- минуты, из которых бОльшая часть времени уходит не на восстановление собственно данных, а на накатывание заново owner:gid и ACL/EA, которые, к сожалению, гит принципиально не хранит.
| | |
|
| 4.26, glebiao (ok), 06:54, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> копировать
> файлы на сторонний носитель, чтобы не добрался =шифровальщик=.
Это происходит автоматически, за счёт слоёв aufs и гита, каждый из которых находятся на разных носителях (для физической надёжности) или хотя, бы, перекрёстно (из тех-же соображений). Слои и хранилище гита лежат на разных физических носителях, не видных по сети. Клиенты видят только суммарный слой. Манипулировать историей они не могут.
Случай попадания шифровальщика непосредственно в систему сервера не рассматриваем, так как от лома нет приёма.
| | |
|
| 3.27, glebiao (ok), 06:56, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> "какой только хрени люди не делают", только чтоб не уметь пользоваться нормальными
> снапшотами и умеющими их fs...
240 - 360 снэпштов в сутки, 11160 снэпшотов в месяц и потом всё-это в какой-то архив...
Вы уверены в разумности такого решения?
| | |
|
| 2.23, glebiao (ok), 06:34, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> http://www.mikerubel.org/computers/rsync_snapshots/
> или, мб, я что-то совсем не понимаю? (:
да. сколько нужно дисковых ресурсов, чтобы в течении разумного времени держать 8 - 12(раб. часов)*30(минут) = 240 - 360 копий в сутки? Сколько нужно ресурсов, чтобы держать эти копии в течении месяцев/лет (история изменений файлов)?
решений с гитом извратное, но делает в точности то-же самое(!) весьма компактно и автоматически.
| | |
| |
| 3.34, пох (?), 10:59, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> да. сколько нужно дисковых ресурсов, чтобы в течении разумного времени держать 8
> - 12(раб. часов)*30(минут) = 240 - 360 копий в сутки? Сколько
> нужно ресурсов, чтобы держать эти копии в течении месяцев/лет (история изменений
> файлов)?
вы лучше расскажите, сколько нужно "ресурсов", чтобы хотя бы угадать, какое именно изменение вам нужно в этой громадной мусорке.
А ресурсов надо, внезапно, ровно на количество уникальных байтиков во всей этой свалке, никакого волшебства ваш гит не умеет.
8 рабочих часов со снапшотами через 30 минут - это 16 снапшотов, у вас с математикой, похоже, тоже беда.
| | |
| |
| 4.36, glebiao (ok), 13:18, 22/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> вы лучше расскажите, сколько нужно "ресурсов", чтобы хотя бы угадать, какое именно
> изменение вам нужно в этой громадной мусорке.
про количество снимков уже извинился, недосып.
Про мусорку: людям, иногда, нужно достать файл по состоянию на месяц позапрошлого года.
> А ресурсов надо, внезапно, ровно на количество уникальных байтиков во всей этой
> свалке, никакого волшебства ваш гит не умеет.
Разумеется. И разумеется, не умеет. Но умеет некоторое сжатие (хотя и считается, что с двоичными объектами работает неэффективно) и умеет удобно работать с историей.
Замена гита на снапшоты, да ради бога. Но тогда исчезает возможность разместить хранилище на _другом_ устройстве и "бесплатно", в довесок к истории, получить дополнительную надёжность.
> 8 рабочих часов со снапшотами через 30 минут - это 16 снапшотов,
> у вас с математикой, похоже, тоже беда.
о да. очень хочется спать :)
| | |
|
|
|
|