https://www.opennet.me/openforum/vsluhforumID3/117006.html Объединение томов с разных физических устройств с распределением файлов/слепков файлов на предмет отказоустойчивости и моментального восстановления в случае нечисти по типу "шифровальщиков". Объединённый ресурс отдаётся через Samba и NFS.<br><br>Нужно было быстро решить проблему с восстановлением после попадания пользователей под "шифровальщиков". Тем не менее, решение уже показало себя весьма эффективным и буквально спасло. Дополнительно продумывались меры по повышению надёжности, так как если не по-<br>бедности, то по понятным соображениям, организовать правильно<br>организованный бэкап сложно: инкрементальный бэкап периодически (сильно реже разумного) сливается на отдельный, не включенный постоянно, диск и (ещё реже), делается копия на блюрэй.<br><br>Общая идея: архив разбивается на две (или больше) частей. 1-ая всегда<br>монтируется r/o и содержит холодные и редко изменяемые данные. Эта часть лежит на одной группе томов (рейд сконфигурирован так, что несколько групп томов лежат на своих физических дисках) и с неё доста https://www.opennet.me/openforum/vsluhforumID3/117006.html#40 Sat, 26 Oct 2019 10:25:42 GMT &gt; это только кажется. всего 4 строки в .mount юнитах, плюс несколько простых скриптов на таймере.<br><br>а если не успеете поймать момент, когда нужно выключить скрипты и они затрут r/o копию? В zfs можно хранить данные в сколько угодно snapshot-ов, только бы места хватало. с компрессией как раз место появляется<br><br>&gt; zfs не рассматривалась из-за ограниченности по оперативной памяти<br><br>я не знаю что там у вас установлено, чтобы была проблема памяти в наше время, когда на серверах стоит 128-256 Г памяти обычно. но безопасность явно стоит того, чтобы потратить денег. если у Вас нет достаточно памяти, то значит её не так много и новая будет стоить копейки. <br><br>&gt; обратите внимание, мой вариант позволяет держать непрерывную *историю*. В некоторых ситуациях, это важно.<br><br>удобно, если файлы - это исходный программный код наверное? для word файлов не так актуально.<br><br>конечно, интересный подход у Вас получился, но немного замороченный. есть ручная работа с Вашей стороны в немалом объеме. плюс возможные проблемы с git если к https://www.opennet.me/openforum/vsluhforumID3/117006.html#39 Mon, 03 Jun 2019 06:00:29 GMT Ой расскажи что в бсд 40 лет назад?<br> https://www.opennet.me/openforum/vsluhforumID3/117006.html#38 Mon, 03 Jun 2019 05:52:31 GMT Они нигде не закончились. Новости читай почаще.<br> https://www.opennet.me/openforum/vsluhforumID3/117006.html#37 Mon, 13 May 2019 13:54:50 GMT не путает. два разных драйвера понадобились именно потому, что overlayfs в ядрах до 4.0 и в 4+ - две изрядно разные overlayfs (stable api is nonsense), а в kernel panic- то у нас падал вовсе не докер.<br><br>Случилось это где-то во времена убунточки 16, к этому времени btrfs'ом для write-only данных уже вполне можно было пользоваться, поэтому лично я не стал разбираться, стало ли в новой версии лучше. Слухи ходили, что окончательного счастья так и не наступило.<br><br>А вот до того, во времена еще aufs - это было даже не смешно. То есть оно грохалось просто на регулярной основе - поэтому удивляет, почему у анонима его этажерка вообще еще не рухнула. (что в самой aufs что-то исправили, это вряд ли. Те аспиранты, что ее писали, давно уже моргидж выплатили и из профессоров поувольнялись.)<br><br> https://www.opennet.me/openforum/vsluhforumID3/117006.html#36 Mon, 22 Apr 2019 10:18:16 GMT &gt; вы лучше расскажите, сколько нужно "ресурсов", чтобы хотя бы угадать, какое именно <br>&gt; изменение вам нужно в этой громадной мусорке.<br><br>про количество снимков уже извинился, недосып.<br><br>Про мусорку: людям, иногда, нужно достать файл по состоянию на месяц позапрошлого года.<br><br>&gt; А ресурсов надо, внезапно, ровно на количество уникальных байтиков во всей этой <br>&gt; свалке, никакого волшебства ваш гит не умеет.<br><br>Разумеется. И разумеется, не умеет. Но умеет некоторое сжатие (хотя и считается, что с двоичными объектами работает неэффективно) и умеет удобно работать с историей.<br><br>Замена гита на снапшоты, да ради бога. Но тогда исчезает возможность разместить хранилище на _другом_ устройстве и "бесплатно", в довесок к истории, получить дополнительную надёжность.<br><br>&gt; 8 рабочих часов со снапшотами через 30 минут - это 16 снапшотов, <br>&gt; у вас с математикой, похоже, тоже беда.<br><br>о да. очень хочется спать :)<br> https://www.opennet.me/openforum/vsluhforumID3/117006.html#35 Mon, 22 Apr 2019 10:12:20 GMT &gt;&gt; раз в 30 минут, не надо утрировать.<br>&gt;раз в 30 минут это не 360 в сутки, а всего 48. <br><br>Да, извиняюсь. С недосыпу написал чушь.<br><br>&gt;The requested URL /articles/f/a/q/FAQ_1fe9.html was not found on this server.<br><br>статья моментально гуглится.<br><br>&gt;для btrfs сабвольюм это просто каталог, очередной, с некоторыми дополнительными атрибутами, &gt;а его содержимое - просто рефлинки, которых может быть абсолютно любое количество. <br><br>Не уверен. Насколько я понял эту механику, подтом, это отдельное дерево, плюс кросс-линки. И если переборщить, вся механика упрётся рогом задолго до того, как некуда будет писать метаданные, просто по скорости обхода.<br><br>&gt;&gt; Я на это наступил. Возможно, просто "повезло".<br>&gt;возможно не просто, а что-то было снова сделано странно.<br><br>Нет. На btrfs был корень ноутбучной системы, без всяких изысков.<br>Единственным изыском, можно считать, разве что compress=lzo,autodefrag,commit=120. Но без последних двух, работать с btrfs вообще нереально :)<br>Диск hdd. От тряски слегка нарушился контакт sata. Про https://www.opennet.me/openforum/vsluhforumID3/117006.html#34 Mon, 22 Apr 2019 07:59:38 GMT &gt; да. сколько нужно дисковых ресурсов, чтобы в течении разумного времени держать 8 <br>&gt; - 12(раб. часов)*30(минут) = 240 - 360 копий в сутки? Сколько <br>&gt; нужно ресурсов, чтобы держать эти копии в течении месяцев/лет (история изменений <br>&gt; файлов)?<br><br>вы лучше расскажите, сколько нужно "ресурсов", чтобы хотя бы угадать, какое именно изменение вам нужно в этой громадной мусорке.<br><br>А ресурсов надо, внезапно, ровно на количество уникальных байтиков во всей этой свалке, никакого волшебства ваш гит не умеет.<br><br>8 рабочих часов со снапшотами через 30 минут - это 16 снапшотов, у вас с математикой, похоже, тоже беда.<br><br> https://www.opennet.me/openforum/vsluhforumID3/117006.html#33 Mon, 22 Apr 2019 07:53:04 GMT &gt; раз в 30 минут, не надо утрировать. <br><br>раз в 30 минут это не 360 в сутки, а всего 48. <br>Да, любая fs и даже lvm выдержат 48 штук (если, конечно, вы потрудитесь снести уже ненужные вчерашние.<br><br>&gt; https://btrfs.wiki.kernel.org/articles/f/a/q/FAQ_1fe9.html<br><br>The requested URL /articles/f/a/q/FAQ_1fe9.html was not found on this server.<br><br>ubuntu-server:/srv&gt; btrfs fi df .<br>Data, single: total=214.01GiB, used=213.67GiB<br>System, DUP: total=8.00MiB, used=48.00KiB<br>Metadata, DUP: total=3.00GiB, used=2.10GiB<br>GlobalReserve, single: total=414.80MiB, used=0.00B<br><br>а сколько тут снапшотов - я хз, поскольку не вижу смысла их считать - делается новый бэкап - новый снапшот. Насколько я понимаю, для btrfs сабвольюм это просто каталог, очередной, с некоторыми дополнительными атрибутами, а его содержимое - просто рефлинки, которых может быть абсолютно любое количество. <br>Оно, наверное, когда-нибудь лопнет (и будет прибито и пересоздано), но не от количества снапшотов точно.<br><br>&gt; Я на это наступил. Возможно, просто "повезло" https://www.opennet.me/openforum/vsluhforumID3/117006.html#32 Mon, 22 Apr 2019 05:04:31 GMT &gt;Зачем нужны снапшоты раз в четыре минуты, <br><br>раз в 30 минут, не надо утрировать. <br><br>потому. что работает много людей. 30 минут оказалось комфортным минимумом, если вдруг "ж стрясается".<br><br>&gt;как вообще потом найти среди них нужный даже если нужны,<br><br>поэтому и была попытка хранить историю в гите.<br><br>&gt;Но если у вас от этого переполняется какая-то там "область метаданных" (нет у btrfs такой &gt;выделенной области, метаданные там размазаны по диску ровным слоем, root tree на то и tree) &gt;- вы, вероятнее всего, бредите.<br><br>https://btrfs.wiki.kernel.org/articles/f/a/q/FAQ_1fe9.html<br><br>btrfs fi df .<br>Data, single: total=77.01GiB, used=43.83GiB<br>System, DUP: total=8.00MiB, used=16.00KiB<br>Metadata, DUP: total=3.00GiB, used=384.92MiB<br>GlobalReserve, single: total=96.56MiB, used=0.00B<br><br>а это на томе с 4 снэпшотами .qcow2:<br><br>"свободного места" 79G из 200G,<br>Data, single: total=125.01GiB, used=120.66GiB<br>System, DUP: total=8.00MiB, used=16.00KiB<br>Metadata, DUP: total=1.00GiB, used=957.70MiB<br>GlobalReserve, single: total=14