The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Объединение томов через aufs для отказоустойчивости и моментального восстановления
Объединение томов с разных физических устройств с распределением файлов/слепков
файлов на предмет отказоустойчивости и моментального восстановления в случае
нечисти по типу "шифровальщиков". Объединённый ресурс отдаётся через 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: права (любые) в гите не сохраняются. В данном случае это проблема, но
схема всё равно оказывается спасительной.
 
03.04.2019 , Автор: Gleb Kulikov , Источник: https://lists.altlinux.org/pipermai...
Ключи: aufs, overlayfs, backup, raid, disc, recover, sync
Раздел:    Корень / Администратору / Система / Диски и файлы / Резервное копирование

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, Крикет (?), 08:58, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно но наворочено так много...
    А вариант с ZFS и например снапшотами каждые 30 минут, с чисткой тех что старше недели и например оставляя ежедневные на 00.00? Не проще это?
     
     
  • 2.2, Alex_K (??), 09:37, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Понятно, проще. Ещё и сжатие можно включить :)
     
  • 2.29, glebiao (ok), 07:03, 22/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно но наворочено так много...

    это только кажется. всего 4 строки в .mount юнитах, плюс несколько простых скриптов на таймере.

    > А вариант с ZFS и например снапшотами каждые 30 минут, с чисткой

    zfs не рассматривалась из-за ограниченности по оперативной памяти

    > тех что старше недели и например оставляя ежедневные на 00.00? Не
    > проще это?

    обратите внимание, мой вариант позволяет держать непрерывную *историю*. В некоторых ситуациях, это важно.


     
  • 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 скажем
     
  • 1.6, Аноним (6), 11:22, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    overlayfs под нагрузкой действительно непредсказуем.
     
     
  • 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.

     
  • 3.19, glebiao (ok), 06:22, 22/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >с aufs, если что, точно такая же ботва, только в тыкву еще и нормальные fs оказавшиеся под ней - поскольку сервер падает в kernel panic

    за 4 года эксплуатации (и плотного тестирования до того), не было ни разу.

     
  • 1.7, нах (?), 14:17, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    АААА, отказоустойчивая aufs!
     
     
  • 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 НЕЛЬЗЯ использовать автомонтирование, даже с большим тайм-аутом. Через пол-года аптайма, в системе могут закончиться ресурсы и без перезагрузки это не решается.

     
  • 1.10, Gannet (ok), 19:49, 05/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Изврат феерический.
     
     
  • 2.21, glebiao (ok), 06:28, 22/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Изврат феерический.

    И да, и нет.

    объеденительные файловые системы штука вообще интересная.

     
  • 1.11, Аноним (11), 07:29, 07/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Похвально, автор, но слишком сложно. Делаешь прям как я в юности.
     
     
  • 2.22, glebiao (ok), 06:29, 22/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Похвально, автор, но слишком сложно. Делаешь прям как я в юности.

    наоборот, минимальными инструментами и малой кровью.

     
  • 1.12, Abu (?), 11:46, 08/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://www.mikerubel.org/computers/rsync_snapshots/

    или, мб, я что-то совсем не понимаю? (:

     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    > ну я примерно так и делаю, только вместо упражнений с хардлинками и
    > надежды что rsync как-нибудь сам разберется и не испортит, что было
    > по той ссылке - просто создаю новый снапшот. Смысла НЕ использовать
    > для архива поддерживающую их fs - уже лет пять как совсем
    > нет.

    1. я использую btrfs и её снэпшоты. Но! в разумных пределах:

      a) делать 240 - 360 снэпшотов в сутки, это экстремальное развлечение. Область метаданных переполняется моментально.
      b) согласен, btrfs уже не очень страшно доверять ответственные данные. Но если вдруг случится бэдблок (и что ещё хуже, даже не случится. просто из-за плохого контакта в интерфейсе с диском btrfs *временно* воспримет какой-то блок, как плохой), то всё, катастрофа. Вы уже не сможете воссатновить эту файловую систему. Вам придётся срочно сливать  все данные на другой носитель и пересоздавать файловую систему. Данные, скорее всего, уцелеют (возможно, за редким исключением). Но все снэпшоты Вы при этом потеряете. Плюс несколько часов простоя.

    2. Столько снэпшотов на lvm --- это даже не смешно.

    3. На zfs говорить не буду, но тут плюс ещё потребные ресурсы.

    как-то так.

     
     
  • 6.30, пох (?), 07:04, 22/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > 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 [^] [^^] [^^^] [ответить]  
  • +/
    > раз в 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 таки учли, спустя десять лет.

     
     
  • 9.35, glebiao (ok), 13:12, 22/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> раз в 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 не доверил.

     
  • 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 снапшотов,
    > у вас с математикой, похоже, тоже беда.

    о да. очень хочется спать :)

     
  • 1.13, sk134679 (??), 12:14, 08/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    https://www.seafile.com/en/home/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:



    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру
    Hosting by Ihor