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

Первый запрос = принимаем на сервере номер телефона, генерируем токен (случайная строка длиной, предположим, 64 символа - цифры, буквы большие и маленькие), отправляем его на клиент. Генерируем код доступа, отправляем его смской на телефон. В зависимости от логики можем и не отправлять (если допустим у нас метод для логина а такого юзера еще нет (он еще не зарегистрирован)).

Второй запрос = отправляем с клиента токен (тот 64 символьный полученный от сервера) и строку с кодом из смс. Проверяем на сервере токен и код из смс, если все ок - пускаем в аккаунт.

Примечания:
1) токены и сами попытки входа должны жить определенное количество времени, предположим 5 минут.
2) попытки ввода кода (неправильные вводы) должны быть ограничены разумным числом (ну допустим 5 попыток)
3) если можно то лучше код сделать длиннее - хотя бы 6 цифр, а лучше 8 и более.
4) попытки входа в аккаунт можно ограничить, но тогда будет можно абузить эту "фичу" и блокировать вход чувакам, тут выбираем меньшее из зол исходя из бизнес требований
5) можно экономить на смсках и доставлять код в последних цифрах номера / голосовой озвучкой, отправлять в вк, ватсап, телеграм, вайбер

500 айкью примечания для кое какой защиты от слива бюджета:
1) можно юзать капчу (можно не всегда а когда начинается аномалия по отправке кодов - всплеск количества отправок)
2) как уже и говорил разделение входа и регистрации
3) ставим бот защиту от какого нибудь сервиса по защите от ддос/бот атак
4) иногда можно не отправить код а отправить клиенту респонс что код отправлен, если клиент вводит код - скорее всего это атака. человек же запросит код повторно (потому что он тупо ему не пришел)
5) иногда можно отправить код не сразу а через предположим, 30 секунд - если ввели код раньше - значит что-то не так

Почитать "Запуск cron внутри Docker-контейнера" и разочароваться.

Почитать про "supercronic" воодушевиться и добавить supercronic в образ с backend, затем из образа backend запустить контейнер, собственно, с backend и из этого же образа запустить supercronic в соседнем контейнере, в котором и будет выполняться целевая команда по расписанию заданному в crontab

Можно ли из под Windows перенести

Не надо из под Windows. Надо из самого Debian.
1.1. через sfdisk выгрузить дамп таблицы разделов HDD в текстовый файл;
1.2. поправить размеры разделов (если несколько разделов ext4, то с учетом их заполненности), чтобы суммарно влезло на 120 ГБ (на самом деле нужно через fdisk -l проверить точный размер SSD в мегабайтах; возможно, там чуть меньше, чем 120 ГБ);
1.3. через sfdisk залить исправленную таблицу разделов на SSD;
2. сделать обычное пофайловое копирование ext4-разделов с HDD на SSD, а лучше потоковое копирование через tar (dd не годится, потому что размеры разделов уменьшились);
3. скопировать через dd первый сектор диска, в который обычно ставится grub;
4. если есть раздел EFI, то его целиком скопировать через dd;
5. PROFIT
Когда у вас Linux, то для такого переноса даже не требуется cпециальное ПО, всё можно сделать стандартными средствами Linux.

P.S. Не помешает перед копированием файлов перемонтировать файловые системы на HDD в режиме read-only.

vreitech pfg21 Adamos Всем спасибо. Проблема оказалось в том, что докер не удалил остановленные контейнеры

Магическая команда (из под рута), чистящая все логи всех контейнеров docker

truncate -s 0 /var/lib/docker/containers/*/*-json.log

А после этого изучать, как ограничить объем логов docker в /etc/docker/daemon.json, который по умолчанию не лимитирован.

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

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

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

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

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

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

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

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

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