Алексей Поваров, есть 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 от его финансирования отказалась. Будем надеяться, что он будет жить, тем более что протоколы и стандарты в почте довольно стабильны и не очень часто меняются.
Зачем так сложно? Есть функция os.system, которая делает как раз то, что нужно.
Изначальная попытка была неудачной, потому что исполняемого программного файла с именем "net start MySQL80" (да-да, именно так, с пробелами) не сущетвует.
Однажды ехали мы по улице, пересекающий проспект. И там что-то повредилось в светофоре, две его секции, смотрящие в два разных направления, вывернулись так, что показывали противоположные показания нашему направлению. Но естественно это не вызвало проблем, ибо водители прекрсно понимали, какой из светофоров показывает правильное. А что бы сделал автопилот?
Я тогда задумался о том, что если введут реальное автопилотирование автомобилей, то оно не будет полагаться на обычные светофоры, знаки и разметку в силу их машинно-распознаваемого несовершенства. Ну как в той картинке с Mapilary, который распознал знак стоянке в букве P синего знака населённого пункта. Вместо этого будут какие-то другие средства: NFC-метки, специальные QR-коды, радиодатчики, глобальные идентификаторы улиц и направлений, криптография с доверительными отношениями правильным ключа для авторизованного сообщения верной инфы. Ну, погромисты поймуть, я думаю.
А все эти приколы, когда дорожный знак распознаётся с рекламного щита или светофор с рисунка на детской площадке - это ж хрень какая-то.
Что касается упомянутого отбойника, если автопилот его "видит", то может оперативно принять решение о необходимости остановки безальтернативно "нейросетевому" мнению о дорожной ситуации. Как это бы сделал и настоящий водитель. Собственно, в нейросети должны быть отработаны и такие ситуации и она должна уметь их избегать. Хотя тут же возникла мысль: а нет ли у автопилота слепых пятен, в которые можно завести "невидимое" препятствие? Типа отбойника на правильной высоте, например.
У меня был Samsung A6 2018 года. В принципе, производитель выпустил на него два обновления мажорной версии Android, и он бы меня вполне устраивал. Но не нравилось две вещи. Во-первыйх, очень мало по нынешним временам встроенной памяти - сейчас очень много приложений и игрушек считает, что занять на телефоне гигабайты это норм. Во-вторых, через 2 года использования что-то случилось с камерой и она начала половину кадра снимать очень размыто. Поэтому купил примерно такой же модели, но свежего года. Тот проработал 4 года (и в принципе ещё работает), а этот я рассчитываю проживёт не меньше.
Также у меня есть старый планшет Galaxy Tab 2014 года со стилусом. У него сломано гнездо для сим-карты, поэтому он вынужденно превратился в Wi-Fi only. Я недавно достал его, прошил сборкой LineageOS с Android 10 и он вполне себе работает. Не очень быстро грузится и по отзывам у сборки бывают проблемы с внезапной перезагрузкой устройства, но в целом вполне работоспособный, и даже стилус работает нормально.
Тынай Бакасов, потому что при нажатии inline-кнопки никакого сообщения от лица пользователя не отправляется. А при обычной кнопке - отправляется (и в истории сообщений это видно).
Если просто делать наивно rsync, то да, в копии будет испорчено при очередной синхронизации.
Вообще, есть и такая стратегия, когда используется lsyncd, который держит почти моментальную копию дерева файлов в каталоге на втором сервере. Тогда даже промежуток времени между регулярными бэкапами будет закрыт - всегда будет актуальная или практически актуальная копия сайта.
Вариант - под систему или под раздел с данными подсунуть drbd с онлайн-репликацией - но это уже намного сложнее и чаще всего используется для виртуальных машин, причём лучше на "короткой" дистанции - типа два соседних сервера (можно даже подключить их по 10 Гбит/с или FibreChannel). И это умеют всякие proxmox из коробки. Но для виртуалки, купленной у хостера, это не особо годится.