Файлы с экранированными частями (с использованием обозначения \xAA) — это нормально и ожидаемо (при кодировании task ID/UPID мы экранируем всё, кроме '_', '.', цифр и букв a-z, при этом всё, кроме '/', экранируется именно таким образом ('/' заменяется на '-')). Я всё ещё не понимаю, как в наших файлах с (неэкранированным) '/' в имени могли появиться такие символы, ведь ядро операционной системы просто не позволит это сделать.

Остаётся несколько вариантов:

- к диску имела доступ какая-то другая ОС, которая неправильно обработала эти пути;  
- произошла системная порча данных файловой системы на диске, которая заменила какой-то символ на '/';  
- символ на самом деле не обычный '/' , а какой-то похожий юникодный символ (маловероятно, учитывая правила экранирования, описанные выше).

Ты упоминал NextCloud — может, именно он виноват и как-то портит имена файлов с обратными слешами?

В твоём изначальном сообщении файл был скопирован из вывода «ls» или чего-то похожего на стороне Linux, либо это был лог/ошибка NextCloud?

Если такие пути ещё остались, попробуй получить статус задачи или лог через PBS UI/API и скажи, получится ли это.

Это "UPID:redacted:000289CB:3BEF2DE3:000003B1:64B24022:backup:Redacted/x3act-182:root@pam:" — это (искажённый из-за наличия '/') "UPID", то есть идентификатор выполнения задачи. У такой задачи должен быть соответствующий экземпляр. Интересно, существует ли соответствующий корректный путь (с '/' заменённым на '\'), и можно ли получить статус задачи и её лог через GUI/API/CLI (например, проверить с помощью "proxmox-backup-manager task list --all" и "proxmox-backup-manager task log 'ЗНАЧЕНИЕ UPID'"). В вашем исходном сообщении говорится, что вы заметили проблему при попытке синхронизировать указанный путь с NextCloud.

Если я правильно понял, то порядок событий был такой:
- scp PBS -> "локальный компьютер"
- затем попытка синхронизировать папку на локальном компьютере с NextCloud не удалась.

Какая ОС работает на локальном компьютере? Команды "stat PATH" или "ls -lh PATH" (а ещё лучше что-то вроде find PATH -print -exec sh -c 'echo -n "{}" | xxd -pu' \; — это выведет имя файла и его байты в шестнадцатеричном формате) помогли бы прояснить ситуацию. Пока вы только утверждаете, что проблема есть, но не показываете это на практике. Это также помогло бы понять, не выглядит ли имя файла так, словно в нём есть слэш из-за какого-то юникод-символа, похожего на слэш.

Я всё ещё почти уверен, что с этими именами файлов что-то сделал кто-то другой, а не PBS — обычные приложения не могут создавать файлы с символом слэша в имени в Linux вообще, и в BTRFS в частности. PBS сам не позволяет и никогда не позволял использовать слэш в строковом представлении UPID.

К примеру, создаётся файл командой "touch foo∕bar" (здесь используется знак деления U+2215), а вот "touch foo/bar" (обычный слэш) не сработает.

Код: root@REDACTED:/var/log/proxmox-backup/tasks/E3# stat 'UPID:REDACTED:000289CB:3BEF2DE3:000003B1:64B24022:backup:REDACTED\x3act-182:root@pam:'  
 Файл: UPID:REDACTED:000289CB:3BEF2DE3:000003B1:64B24022:backup:REDACTED\x3act-182:root@pam:  
 Размер: 455331          Блоки: 896        Размер блока ввода-вывода: 4096   обычный файл  
Устройство: fd00h/64768d    Inode: 6428481     Ссылки: 1  
Доступ: (0644/-rw-r--r--)  Uid: (   34/  backup)   Gid: (   34/  backup)  
Доступ: 2024-03-05 14:34:17.376729619 -0700  
Изменён: 2023-07-15 00:44:52.509272617 -0600  
Изменение статуса: 2023-07-15 00:44:52.509272617 -0600  
Создан: 2023-07-15 00:43:46.220776104 -0600  
Эээ, надеюсь, что форматирование для форума получится нормальным. В общем, вот такой результат REDACTED.