Глубоко ТЕОРЕТИЧЕСКИ - да, может. Но надо понимать, что все домены НА САМОМ ДЕЛЕ на уровне DNS имеют точку в конце имени. И имя 123.123.123.123. (с точкой на конце) - не то же самое, что IP-адрес 123.123.123.123 (без точки).
Но главная беда в том, что софт будет понимать такие домены крайне ужасно. Например, без конечной точки сразу воспринимать их как IP. А с точкой на конце домены софт часто не понимает или удаляет эту точку - как и привыкли пользователи.
Мне кажется, имеет смысл рассмотреть предположение, что предыдущие неудачные выгрузки файлов задним числом всё же выполняется, но получаемый файл получается нулевой длины и затирает успещно загруженный... Правда, всё равно непонятно как...
Алексей Поваров, есть rsnapshot, который на базе rsync умеет делать дифференциальные и инкрементальные бэкапы. Но в реальности я бы смотрел в сторону чего-нить более серьёзного, типа borg.
Если просто делать наивно rsync, то да, в копии будет испорчено при очередной синхронизации.
Вообще, есть и такая стратегия, когда используется lsyncd, который держит почти моментальную копию дерева файлов в каталоге на втором сервере. Тогда даже промежуток времени между регулярными бэкапами будет закрыт - всегда будет актуальная или практически актуальная копия сайта.
Вариант - под систему или под раздел с данными подсунуть drbd с онлайн-репликацией - но это уже намного сложнее и чаще всего используется для виртуальных машин, причём лучше на "короткой" дистанции - типа два соседних сервера (можно даже подключить их по 10 Гбит/с или FibreChannel). И это умеют всякие proxmox из коробки. Но для виртуалки, купленной у хостера, это не особо годится.
Тынай Бакасов, если бот отправит двум разным пользователям или пользователь быстро отправит два разных сообщения - то вся нумерация легко поедет и удалиться может не то, что надо (в том числе у другого пользователя!). Я уж не говорю о том, что способ выдачи id может изменить телеграм на своей стороне, например, начать выдавать их с другим инкрементом или вообще без какой-либо монотонности. Если изначально соблюдать API как надо, то бот это без проблем переживёт и будет работать, а если нет...
Я могу пример привести из своей практики. Есть интеграция, в которой id выдают блоками по 1000 штук два независимых сервиса, один выдаёт нечётные, другой - чётные (чтобы не пересекались). Некоторые клиенты ошибочно думали, что id монотонны и всегда возрастают, но это не так: когда очередной блок берётся с другого генератора, чем в предыдущий раз, очередные id могут измениться в сторону снижения. Причём чем дольше длится интеграция, тем больше расхождение может накопиться (хотя в нормальной ситуации должно быть приблизительно поровну).
Причём это когда-то много лет назад было переделано из простых sequence в базе в рамках повышения отказоустойчивости. И это там реально работает. Так, при тормозах, кратковременной или полной недоступности базы основной функционал сервиса сохраняется. Причём он может так работать не один час, и такие аварии там несколько раз бывали.
Правильнее хранить предысторию, включающую все нужные id сообщений в рамках текущего активного диалога. В общем, если у бота не будет большой аудитории и нет высоких требований к его надёжности, то можно оставить и так, а чинить в случае если совсем припрёт. Ну и обязательно проверять вызов удаления на ошибки, чтобы бот не упал, если пользователь успеет сам своё сообщение и что-то пойдёт не так (тм)
PS: Я кстати был реально уверен что удалять бот чужие сообщения из личного чата не может. Но вероятно перепутал с редактированием - тут был кто-то, кто очень хотел ботом редактировать текст сообщения пользователя.
Можно поднять свой сервер LiberTranslate, можно осваивать всякие почти готовые решения типа EasyNMT, скачивать готовые обученные модели... Да, не супер качественно и не особо быстро без хорошей видеокарты, но зато очень недорого.
Также можно обратить внимание на то, что тексты на сайтах, вообще говоря, показываются далеко не один раз. И каждый раз их переводить не нужно, достаточно перевести один раз всё заранее или переводить конкретный текст в нужный язык при первом обращении. В зависимости от объёма сайта, это может очень существенно снизить общие затраты на перевод.
Вы о чём? Пользователь быстро поймёт, что у него shadow ban (а он это понять может легко, например, зайдя анонимно или с проверочного мульта). И как только он узнал, что так на сайте можно сделать, эта тактика против него перестанет работать окончательно.
Борьба с нежелательными регистрациями пользователей - это всегда компромисс между надёжностью защиты и неудобствами для пользователя.
Самое простое решение - перенести проблему множественной регистрации на тех, кто умеет с этим бороться лучше: на сотовых операторов (авторизация требует телефона и кода из SMS) или соцсети. Конечно, это не суперзащита, но заводить новый номер телефона или аккаунт в соцсети после каждого бана заметно сложнее, чем новую почту.
Можно заранее банить сети TOR и даже просто сети известных датацентров. Некоторые сайты так и делают. Да, это тоже не суперзащита, но опять же - сузит манёвренность нарушителя.
Можно сделать ограничения на начальном этапе. Например, первые три дня или первые 15 сообщений пользователь видит лишь часть разделов авторизованной области сайта, лимитирован в числе отправляемых сообщений в сутки итд. Усложнит регистрацию мультов - их придётся "прогревать", а за это время их можно будет обнаруживать и банить.
Ну а вообще если это вопрос общетеоретического характера, то можно давать общие советы, а если борьба с конкретным пользователем, то советы могут быть более целенаправленны. И, конечно, зависит от специфики сайта. То, что годится для форума, может не очень пригодиться для доски объявлений или сайта онлайн-курсов.
AshBlade, в таком случае будет дешевле взять виртуалку и на ней поднять свой докер, чем переплачивать за managed cloud и ещё тратить кучу времени на разбирательства как он работает.
LAG_LAGbI4, например, Thunderbird. Но там тоже, разумеется, бывают сложности, Например, если закончилось место на диске, можно получить повторную синхронизацию всех гигабайт ящика, что не очень быстро. А большие письма с приличной html-разметкой могут вызвать жуткое вытекание памяти, правда, это обычно экзотика и вряд ли случится на парактике (из моего опыта: таблица на ~1000 строк привела вытеканию более 6 Гб памяти, после чего пришёл OOM killer и убил thunderbird; аутлук при этом не очень быстро, но всё же успешно это рендерит и показывает).
С разработкой Thunderbird сейчас есть сложности, так как Mozilla от его финансирования отказалась. Будем надеяться, что он будет жить, тем более что протоколы и стандарты в почте довольно стабильны и не очень часто меняются.
