Алексей Пьянов

Без пример конфига и не зная, что у Вас задублировалось, можно только гадать о том, что происходит реально.

Пример настроек, с комментариями, приведены тут:
https://www.altlinux.org/Pam_mount

Надо учесть, что в Linux отличается идеология монтирования сетевых ресурсов от Windows.

В windows, сетевые ресурсы монтируются в сессию пользователя. Если два пользователя одновременно зайдут в систему, у них может быть свой разный набор подключены дисков. Один пользователь не увидит, какие диски подключены у другого.

В Linux - диски монтируются в систему. Пользователь инициирует подключение, но все подключенные диски видны всем пользователям, которые залогинены в систему (в том числе и по ssh).

Пофайловвй бэкап нужен для восстановления при дизастере? Нет, такой бэкап не подойдет.
Если нужно восстановить как было (прям всё) - тогда проще делать снимок lvm и его отправлять на сервер бэкапов. Потом с этого же снимка можно раскатать все.
Но все же, докер директории я бы не бэкапил, а этом же прелесть докера - взял и развернул где угодно тоже самое приложение. Если в контейнер смонтированы директории с какими-то файлами - бэкапить эти директории. Если это база в докере - бэкапить средствами базы.

сам разобрался, может кому пригодится
отключил касперского и все заработало

Это не всё, но... Двигайся по вопросам в порядке очерёдности.

Путём перебора и экспериментов выяснил, что этим функционалом обладает Recuva.
Но у меня при восстановлении не сохранялась структура каталога - оказалось нужно внимательнее смотреть настройки. Отметил нужный чекбокс - всё восстанавливается как надо (конечно из того, что можно).

Более того из всех программ сборки 2k10 только она видела то, чего не видели другие программы (R-Studio, несколько разновидностей Active@, и ещё парочку.)

Если утрировать, то кубер - это сервис по запуску контейнеров + виртуальная сеть поверх всех машин в кластере.

1. Если копнуть чуть глубже - вы можете в конфиге указать "хочу постоянное хранилище для базы". Какое именно это хранилище будет (S3, файлопомойка, перфокарты) - уже задача того кто кластер обслуживает. Или "запускать 1 веб и 1 редис на каждом физическом сервере" - этим будет заниматься кубер. Или "хочу 8 ядер для каждого экземпляра приложения". Заведовать ресурсами тоже будет кубер, как и перетаскивать приложения с сервера на сервер в отсутствии ресурсов (и перестраивая при этом сетевые запросы). И запускать новые экземпляры приложения в зависимости от нагрузки на процессор - тоже будет он. Считайте что это docker swarm на стероидах.

2. Если вам достаточно docker-compose и одного-двух серверов - ничего страшного в этом нет. Это не "зашквар" жить без кубера - он вообще специализированный инструмент, как и сами контейнеры.

3. Если вам хватает пары тройки серверов где вы можете запустить docker compose - вы в порядке (если можете нагрузку балансировать). Если уже не хватает - ну, пора запастись кофе и на пару недель впереться в мир Подов и Деплойментов

В любом случае, Kubernetes - это не серебряная пуля как некоторым кажется. Можно, конечно, и одно приложение туда перетащить, но надо ли вам тратить ресурсы на поддержку - решать вам.

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

- Если приложение, в котором вы сравниваете производительность, написано для Винды и только потом портировано на Linux, то вы можете увидеть даже падение производительности. И то же самое наоборот: если приложение или сервис изначально сделаны для Linux, то тут может быть разница уже в его сторону. Типичный пример - Docker

- Производительность хорошо оптимизированных приложений, которые выжимают все соки из CPU/GPU будет примерно одинакова.

- Gnome, который стоит у вас в Ubuntu в качестве окружения - тормозящая и жрущая все ресурсы какашка. Если вы установите какое-то легковесное окружение или даже просто какой-то Window manager, вот тут вы заметите явный прирост в отзывчивости всего и вся.

- И, наконец, главный источник производительеости - это работа с памятью. Если вы замените Gnome на лёгкое окружение, то расход памяти значительно уменьшится. На Linux обычно нет встроенной телеметрии, рекламы и остального шпионского мусора, как в Винде. Это тоже экономит память. И вот, когда на Винде наступит момент забраться в swap, на Linux останется ещё много свободной памяти. В этот момент Винда начнёт лагать, а Linux продолжит летать.

NUT

Пока связь есть, связист не нужен. По этому дорогостоящих специалистов не любят держать много, крои... ой, то есть оптимизация. Связист нужен, когда связи нет. По этому все сетевые инженеры вокруг меня, работающие с инфраструктурой в эксплуатации (провайдеры и кампусы 5000+ хостов) встают по ночам, выходят в соседнюю комнату с застолья, или проводят выходной в парке с детьми скрючившись за ноутбуком на скамейке решая проблемы со связью.
Сетевики вокруг меня валят кто куда - техподдержка вендора, девопс, инженер майков/линьков, админ АД в банк, вахтой на газовый промысел...
Оставшимся приходится заменять сваливших. Издержки профессии.
Сложности же как раз в большом масштабе, первая в стыковке разномастного сетевого оборудования разных поколений и подбору костылей к нему; вторая в технической сложности и скорости развития технологий маршрутизации, когнитивная нагрузка как в программировании, цена ошибки выше, зарплата зачастую ниже.

Существуют, только от них больше вреда чем пользы, в каком-то минимальном уровне незнания сначала помогут, потом всё, одни проблемы

По двору прошелся жулик и попытался хакнуть эксплойтом для "майбаха" (условно) все тачки в вашем дворе. Майбахов не нашлось, этот жулик пошел дальше и забыл уже про ваш дворик.

Надо ли защищаться от атаки, не релевантной вашему сетапу? Не надо.
Надо ли делать выводы об уязвимости того или иного оборудования? Надо.
Надо ли проверять свои конфигурации на эксплойты? Надо.
Надо ли реагировать на всякую нерелевантную хрень в логах с ошибками порядка 400? Не надо.
Надо ли позаботиться об оркестрации быстрого развёртывания ваших серверов на случай взломов или проблем с железом? Конечно надо!

Вообще, если ваш сетап на виртуальных машинах в повторяемой среде и с декларативной конфигурацией вроде кубера или докера, то вы легче сможете пережить всякие такие факапы.
Схема такая.
Есть признаки взлома - бэкап логов, снапшот базы, бэкап стораджа, остановка сервисов (если позволяет продакшн), анализ атаки и последствий. Устраняем уязвимость по вектору атаки (гугление по логам и курение тредов), правим конфиги развёртывания и запускаем прод. Потом долго и тщательно разбираемся по логам, снапшотам и бэкапам что затронуто. Делаем тестовый чистый сетап по старой конфигурации и сравниваем пофайлово с атакованной системой, выясняем в какие места вмешались злодеи. Дифаем базу и смотрим на подозрительные различия. Делаем выводы, объявляем об утекших данных, если есть такие признаки (чтобы не подставлять пользователей), принимаем превентивные меры против похожих векторов атак.

Итого, залог успеха - это хранение конфигураций в гит-репозитории, своевременные бэкапы, хранение бэкапов на отдельных изолированных стораджах, оркестрация и автоматизация развертывания, подробное эшелонирование логирование с бэкапами логов, смоук тесты на нестандартную активность в БД, по сетевым интерфейсам, трафику, процессору, памяти, файловым системам, логам...

Это взгляд дилетанта по безопасности, если чего пропустил -- поправьте. Если где не прав -- расскажите.