Сергей П

Ответ.
Это может быть связано с неправильной работой с кодировками.
А именно перекодирование происходит:
- не в ту кодировку
- не из той кодировки.
Обычно неопытные программисты не хотят разбираться с тем как правильно работать с кодировками и что такое юникод, а все проблемы решают методом тыка меняя код пока проблема не исчезнет. Из-за этого у них часто присходят преобразования по умолчанию, которые ломаются при смене операционной системы, при запуске другим спообом (из терминала, от имени другого пользователя, через крон...), при смене умолчаний (локали, настроек терминала, настроек БД).
А ещё такие неопытные программисты до жути боятся сообщений об ошибках, но решать настоящие пролемы не хотят и гасят их в бесшумном режиме, отчего реальные проблемы маскируются под глобальныйми молчаливыми пустыми обработчиками ошибок. Это приводит к усложнению внутреннего поведения программы и вот таки вот случаям, как у вас.
Когда у таких программистов возникают проблемы (а за ними дело не встанет), то эти программисты не описывают проблему детально, не показывают исходный код, не обрисовывают архитектуру своей системы, а просто спрашивают в чем может быть проблема.
Исчерпывающий ответ на такой вопрос дать несложно. Вот он.

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

Если хотите максимально упростить работу всем -- делайте скрипты оркастрации (с комментариями), которые будут поднимать, опускать, развёртывать, бэкапить и поднимать бэкапы. Через пару лет, когда забудете как там всё устроено, эти скрипты и комментарии сильно сэкономят время.
Не забывайте, что помимо основной конфигурации есть еще SSL-сертификаты, которые имеют свойство "неожиданно" просрачиваться, конфигурация Nginx, которую тоже хорошо бы положить в соответствующем контейнере, и прочее. А ещё есть IP-адреса внутренних DNS и всяких шлюзов, которые могут поменяться, а тупой подъём бэкапа только усугубит ситуацию. Да и на поднятом из бэкапа сервере скорее всего давно не одновлялся сертификат и так просто ваш сайт не заработает.

Короче, нельзя просто так взять и забэкапить винт сервера, чтобы не поиметь проблем при любых обстоятельствах.

Привет всем! Я понимаю, что надо бы к врачу но где-то посеял полис и стесняюсь звонить в скорую, тем более врачи только таблетками и химией пичкать будут.
У меня есть два ножика, кухонные призщепки и четыре добротных крепких табуретки.
Хочу себе вырезать аппендицит сам.
Недавно отнялись ноги (долго сидел на унитазе, пытался вывести черепаху), но чувствительность восстанавливается, покалывает в ступнях, но жопы не чую (если это важно...).
Помогите, у кого есть время. Просто перечень действий/команд.
Если времени нет - игнорьте!

Мануалов и правда много посмотрел! Но, пузо резать больно, видимо надо ещё посидеть на точке, чтобы наркоз поднялся повыше.
Вообще, гипс, конечно, мешает, руки плохо поворачиваются,, я читал об этом, но почему вот не сказано на этапе обработки операционного поля застрял :(

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

Постойте, ведь это совершенно новая идея! Наверняка никто не додумался ещё во всём мире делать инкрементальные бэкапы rsync'ом!
Похоже, вы первый во всей галактике, кому это понадобилось.

Я пошел даже в гугл и проверил запросом "инкрементальный бэкап rsync".
И знаете что?
Оказывается там полно статей про это!

Даже не знаю... странно...

Дурацкое решение вы придумали.
Просто не давайте человеку админских прав и всё. Зачем клаву трекать? Ну сменит он пароль от своего пользователя, но вам-то что. С рутовыми правами смените обрано

Утилита dd.
Только аккуратно выясните где какой раздел и какое у него имя. Например с помощью gdisk.
Вот пример как склонировать:
https://superuser.com/questions/1050894/using-dd-t...

Не факт, что эта статья ответит на ваш вопрос в его оригинальном виде, но по крайней мере это достаточно широкий ответ про сочетания клавиш в убунту.
Сегодняшняя статья на хабре: https://habr.com/ru/post/486872/

Вообще поддержка симлинков может быть опасной в такого рода расшареных ресурсах.
У меня под рукой доступа к настройкам ftp нет, но такое ощущение, что там в конфиге была специальная опция. Могу ошибаться.

Однако общее правило такое. Симлинк нужно делать от корня ftp на папки внутри расшаренной. Нужно избегать линкования на внешние каталоги, поскольку это может вызвать уязвимость (доступ к файлам, к которым вы не планировали давать доступ).

Ещё есть вариант без симлинков:
mount --bind /source/dir /destination/dir
И в fstab:

/source/dir /destination/dir none defaults,bind 0 0

Но не во всех файловых системах.
Жесткие ссылки, по идее, должны работать в любом случае.

Мы решили вопрос доступа к API телеграма так.
Стандартный домен API телеги для ботов заблочен роскопозором, поэтому в конфиге нашего бота подменён домен для доступа к АПИ.
Наш же VDS за пределами юрисдикции роскомпозора в конфиге nginx имел такую вот запись:

server {
    listen tg.my_own_domain.ru:8079;
    server_name tg.my_own_domain.ru;
    access_log /var/log/nginx/tg.my_own_domain.ru-access.log;
    error_log /var/log/nginx/tg.my_own_domain.ru-error.log;
    location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass https://api.telegram.org/;
        client_max_body_size 100M;
    }
}