Довольный Айтишникъ

Написать простенький API, запросы на который будет слать клиентское приложение, ну и соответственно обрабатывать все запросы на защищенном сервере, с него же и делать sql запросы, но уж никак не хранить данные для аутентификации БД прям в коде...

Не используйте естественные ключи в качестве первичных. Используйте только суррогатные. Избежите многих проблем.

Основных проблем с естественными ПК две.

1. Проходит время, и возникает необходимость поменять естественный ключ. Например, его внесли с ошибкой (человеческий фактор). В вашем случае, допустим ISO решила, что существующий код оказывается не политкорректный, и его нужно поменять. И вам нужно поменять либо одну строку в одной таблице, либо все строки во всех таблицах, которые на нее ссылаются. Чувствуете разницу? А часть данных может быть уже в архиве, read-only и т.д.
   
2. Проходит время, и "уникальный" естественный ключ оказывается не уникальным. Например, вам понадобился тот же доллар, но с особым курсом и т.п. Если это ПК, то нормального решения нет, пусть даже сложного, как в п. 1. Вам придется превратить естественный ключ в суррогатный, а для естественного добавить отдельный столбец. Так лучше сделать это с самого начала. :)
   

Очень теоретически можно организовать бэкап БД "одним запросом". И это будет запрос
CALL stored_procedure(@datatbase_name);
А вот в хранимой процедуре будет дофига запросов. Нужно будет из INFORMATION_SCHEMA получить список всех имеющихся в БД объектов и организовать копирование информации во внешний файл (причём для каждой таблицы придётся делать два файла - один со структурой, второй с данными). А ещё надо не забыть про процедуры, функции, триггеры... в общем, задачка весьма нетривиальная. Лучше даже не начинать.

Не может ли так быть, что файл будет битым при этом.

Почти наверняка будет битым.
И тормозить СУБД может быть даже недостаточно. Гарантировать "небитость" можно только при размонтировании.

• остановили СУБД
  
• отмонтировали контейнер
  
• сделали бэкап
  
• примонтировали контейнер
  
• подняли СУБД
  

В остальных случаях получится бэкап Шрёдингера. :)

Ну или правильный метод: делать бэкап средствами СУБД, без остановки. Можно бэкапить в другой примонтированный криптоконтейнер.

return в функции настройте нормально, чтоб оно что-то возвращало кроме None(ничего), как пример:

return '\n'.join([descriptions[v]['name'] for v in descriptions])

$out = mb_strlen($in) > 150 ? mb_substr($in, 0, 150)."..." : $in;

Потому что в C# нумерация с 0

И массив длины Length имеет элементы с индексами 0..Length-1
Индекс Length будет уже за пределами массива.

В вашем примере производится запись в последний элемент массива

system settings -> startup & shutdown -> session management -> restore previous session

в русском интерфейсе не уверен как точно написано будет, но перевести не сложно

В России есть Россвязь, которая распределяет номерную ёмкость по операторам. Эта информация публична, можно скачать машиночитаемые выгрузки у них на сайте: https://rossvyaz.gov.ru/deyatelnost/resurs-numerac...

Далее, в России есть MNP, позволяющий переносить мобильный номер от оператора к оператору. Но только в пределах региона. Поэтому если задача по номеру определять только регион, то она надёжно решается указанными выше выгрузками. Оператора по ним определять ненадёжно, так как ежедневно много номеров меняют оператора, и любые данные быстро устаревают.

Оператором базы данных перенесённых номеров (БДПН) является ЦНИИС, на его сайте можно получить текущего оператора только по конкретному номеру: https://zniis.ru/bdpn/check/ а обновляемый доступ ко всей базе простым смертным не получить.

Чтобы понимать масштаб проблемы, сейчас в России ~14.7 млн. перенесённых номеров, за вчерашние сутки ~9.5 тыс. номеров поменяли оператора и ~1.5 тыс. вернулись из списка перенесённых к своему родному оператору.

Таким образом, никакого смысла в подобном сайте без обновляемого доступа к БДПН (а она обновляется каждые 2 часа) нет.

Что касается технической реализации, то тут всё достаточно просто, если у тебя есть доступ к БДПН. ЦНИИС публикует раз в сутки Numbering_Plan, аналогичный выгрузке DEF-9xx.csv Россвязи (формат отличается, но смысл тот же - диапазоны, каждый назначен оператору+региону), также публикует раз в сутки Port_All с полным списком MNP. Если не нужно поддерживать (для простоты) частые (каждые 2 часа) обновления, то этого достаточно. Любой номер сначала проверяем на наличие в Port_All, если не нашёлся - ищем подходящий диапазон в Numbering_Plan.

BGP оперирует не IP-адресами, а автономными системами, которые должны быть не менее чем /24 (256 адресов). Судя по всему, у вас нет своей AS, а адреса принадлежат провайдерам.

Я вижу только один способ сохранить прям те же самые адреса: сервер поместить в датацентр, а на старом месте оставить недорогой сервер для проброса нужных портов в целевой сервер в датацентр. Лучше подобное воспринимать как временное решение, всё переносить на новый IP сервера, переводить туда клиентов и всё такое, чтобы в дальнейшем когда-нибудь от лишних провайдеров отказаться.

Если у оператора есть точка присутствия в датацентре, а текущий договор на юрлицо, то можно попробовать официально договориться с ним о том, чтобы подключиться к нему в датацентре и перености IP, но у оператора моугт быть (и скорее всего будут) свои нюансы устройства сети, которые это не позволят.

скопируйте сертификат (файлы которые в соответствующих директивах конфига nginx прописаны) с рабочего сервера перед переносом и пропишите в директивы nginx на новом сервере

уже после переноса и смены А-записей поставьте нормально certbot с автообновлением сертификата

не городите велосипед и грабли

Это будет самый быстрый способ для разового переноса одного сервера.

UPD: чтобы не было конфликтов, размещайте файлы с рабочего сервера с ключем и сертификатом на новый не в /etc/letsencrypt, а, например, в /etc/nginx/ssl, а то потом certbot офигеет, че ему подсунули