А для начала предположим, что где-то в безопасном отдалении от того самого пользователя существует небольшой сервер, в котором если и будут выходить из строя диски, то по крайней мере от внутренних причин и не все одновременно. И также предположим, что в нём есть отдельный физический диск, над которым можно издеваться как угодно, не затрагивая основную систему. Так будет заметно проще.

Тогда на этом самом диске будет храниться специальный каталог-источник всего-всего, разложенного по категориям. (При беглом подсчёте их получилось выделить около тринадцати.) И в зависимости от размера локального накопителя и некоторых других особенностей, на терминалах каждая категория будет либо монтироваться, либо синхронизироваться, либо игнорироваться. А содержимое смонтированных или синхронизированных категорий будет раскладываться в $HOME или символическими (или жёсткими) ссылками, или с помощью bind mounts, или монтированием через OverlayFS, или чем-нибудь ещё вроде VCSH. Или даже всем одновременно и понемногу. Раскладываться они будут конечно же не руками (ну то есть может быть и руками, но путаницы от этого будет скорее всего больше, чем пользы), а программой. Программа эта будет уметь помимо раскладывания проходиться по содержимому $HOME и выводить статус каждого каталога: к какой категории относится, чем и зачем создан, синхронизирован с источником или только локальный, возможен ли перенос в источник (если только локальный). А для показа статуса ей придётся сверяться с некоей базой данных обо всех значимых каталогах, которую необходимо будет первоначально наполнить вручную. И в случае отсутствия записей о каком-нибудь каталоге она будет предлагать добавить информацию о нём вручную или повесить на него какой-нибудь inotify-мониторинг, чтобы увидеть, какая же программа к нему обращается (если это вдруг неочевидно). Но это уже начались детали и тонкости.

Ах да, есть даже очень ранний прототи... нет, скорее просто размышление на тему, но так как программирование на самом деле освоить не столь легко, как это может показаться по некоторым репликам из интернета Шокирующая истина!, то можно считать, что пока вовсе ничего и нет.

И теперь, ну... можете сказать что-нибудь! Не нужно, всё это глупость, ничего не выйдет

>>208091

>Можете сказать что-нибудь.

'man lvm'
А клиент-серверная архитектура не нужна там, где можно без неё обойтись.
c: juran

автоматические бэкапы
/thread

>>208094
Ну и как тут поможет LVM, если бы хотелось, условно говоря, подмонтировать по сети отдельный LV? И как тут обойтись без клиент-серверной архитектуры, если единственным накопителем на терминале вполне может оказаться флэшка на 4 или 8 гигабайт, засинхронизировать на которую всё желаемое просто физически не выйдет?

>>208095
Автоматические бэкапы чего? Ведь смысл как раз в том, чтобы было необязательно размещать локально всю подлежащую резервному копированию информацию, и можно было обойтись сетевым монтированием удалённого источника.

А вообще, это такой бэкап наоборот. На удалённом диске будет храниться не резервная копия, а... резервный оригинал. Вместо того, чтобы (периодически) копировать данные с локального диска куда-нибудь ещё, мы частично монтируем и частично синхронизируем удалённое хранилище, объединяя его таким образом с локальным. Локальное хранилище рассматривается почти как кэш, данные с которого вместе с ним самим могут пропасть вообще в любой момент потому что пользователь — бака. И вот тогда можно будет достать любой подручный носитель, например ту самую флэшку на 4 или 8 гигабайт, и воссоздать на нём ту же самую систему с теми же самыми данными и настройками. Если это будет терминал с большим локальным накопителем, то на него просто будет синхронизировано больше категорий. Если флэшка, то наоборот, больше будет смонтировано, чем скопировано. Или как-то так.

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

В третий раз! Носитель с корневой ФС сломался уже в третий раз! И скорее всего сломается и в четвёртый, потому что на сей раз пришлось поставить систему на диск с битыми блоками. И он уже выдаёт ошибки чтения. Btrfs с дублированием данных, конечно, пока спасаает, но... Нет, это совершенно невыносимо. Но на этот раз «резервный оригинал» и расставленные симлинки отчасти помогли. Отчасти — потому что были расставлены руками и как попало. А значит, идея стоит того, чтобы развивать её и дальше!

Кстати говоря, как-то так вышло, что в этот раз на всё это безобразие была установлена NixOS. И как бы это сказать... Это великолепно! Вся система вместе с демонами, пакетами и настройками вырастает заново из одного почти декларативного файла конфигурации, как из семечка! Именно то, чем хотелось бы дополнить «резервный оригинал». Правда, пакетов всё равно не хватает, писать новые сложно, выходить за пределы предусмотренного разработчиками тоже очень сложно, и вообще не без странностей в премногом количестве. Но идея замечательная!

Но мы немного отвлеклись. Итак, категории, на которые можно, пусть и достаточно условно, разбить всю-всю нашу информацию:

• Системные пакеты
• Системная конфигурация
• Системный кэш
• Пользовательский кэш
• Пользовательская конфигурация
• Обычные пользовательские данные
• Данные пользовательских программ
• Данные системных программ
• Пароли и приватные ключи
• Скачанное из пиринговых сетей
• Скачанное вручную
• Установленные игры
• Игровые сохранения
• Секретная категория: Сохранённое с Ычана

Каждую из них можно оценить по пяти характеристикам: Размер, Критичность, Уникальность, Специфичность, Восстановимость. И при помощи среднего значения от этих оценок решать, что монтировать, что синхронизировать, и что игнорировать в зависимости от объёма локального носителя. Например, если какая-то из этих категорий нам очень-очень важна, крайне уникальна, почти невосстановима и при том занимает не так много места, то она будет обязательно продублирована на каждом терминале. А если, наоборот, она не так уж и важна и/или легко восстановима, да ещё и к тому же специфична для конкретного терминала, то там она и останется.