На компьютере установлен Яндекс Диск и директории были удалены в каталоге, который синхронизируется с ним.

Искренне сочувствую (действительно). Спасибо за предупреждение.

С Божьей помощью

Вот примерно так и работает официальное приложение Яндекс.Диска, когда решает, что делать с твоими данными.

Думаю, что у товарища майора с бутерброда упала шпротина аккурат на клавишу Делет, пока он твои данные щупал.

Случайно, конечно. Но это яндекс, сынок.

яндекс раздаёт по 200 гб пострадавшим от диска

https://habr.com/ru/articles/204580/

Было на оффтопике

НЕ пользоваться приложениями яндекса и твои волосы будут мягкими и шелковистыми. Если уж оно допускает подобные косяки, то доверять ему как бы странно. Ну и, конечно, нужно делать бэкапы.

1. Не пользоваться приложениями Яндекса.

2. Настраивать синхронизацию файлов с умом.

Видимо файлы синкнулись с облаком когда кто-то их переместил там в корзину.

Название ОС: Ubuntu 24.04.1 LTS

Извините, не вижу здесь используемую fs.

Теоретически может быть что угодно. Информации слишком мало.

Но. Лет 10 назад я столкнулся с багом в Linux-клиенте для Яндекс.Диск. Использовал тогда zim для хранения заметок, и заметил, что одна папка с заметками всегда пропадает.

Сам провёл расследование, и создал минимально воспроизводимый пример: если создать определённую структуру каталогов, и в ней каталог с определённым названием, то Я.Диск сразу же его удаляет.

Искал все каналы, по которым можно достучаться в поддержку, которой нет. В итоге, где-то завели issue в каком-то внутреннем трекере. За 10 лет по ней не произошло ни единой подвижки. Правда, за это время они выкатили 1 или 2 новые версии, переписанные с нуля, насколько я понимаю.

Но осадок остался, с тех пор использую Я.Диск только для резервной копии того, что может понадобиться (не единственной, конечно). Для оперативной синхронизации между своими устройствами использую syncthing.

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

ext4, стандартная

Основной вопрос что стало причиной:

1. Файловая система, другие компоненты ОС.
2. Приложение Яндекс Диска.

И как могла быть отдана команда на удаление именно 6 определённых директорий.

На компьютере установлен Яндекс Диск и директории были удалены в каталоге, который синхронизируется с ним.

Вот и причина.

Некоторым, чтобы понять, какие глупости они совершают, просто необходимо, чтобы произошло что-то такое. Простые «пугалки» на форумах с рассуждениями о том, что нехорошо, чтобы у третьих лиц был контроль над данными на твоём ПК, увы, работают не для всех.

Это как с бэкапами — некоторые понимают, что надо делать. Другие осознают только после того, как первый раз потеряют важные данные.

Надеюсь, ты извлёк из этого урок. Стоит быть, так сказать, благодарным судьбе, что такой важный урок она тебе дала малой кровью, ведь ты в итоге даже смог данные восстановить из какой-то там корзины, как я понял.

ничего не узнаешь, ибо логирование действий не было :)
а теоритически могло быть всё.

вполне возможно и по яндекс облаку пролетела какая-то дрянь, спецом аль не спецом, на удаление именно этих этих 6 директорирй, именно у тебя (у яндекса хомячков акромя тебя пруд пруди).

хочешь надежности правило 3-2-1 и желательно еще чтонить в офлайне.

С Божьей помощью

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

Поскольку файлы попали в корзину, то скорее всего произошло просто удаление их локально.

И вообще что это за приложение для яндекс диска? Последний раз когда я смотрел такие там были какие то левые и все уже давно не обновялись …

P.S. Глянул их рекомендованный, последний консольный клиент:

Source RPM  : yandex-disk-0.1.6.1080-1.fedora.src.rpm
Build Date  : Sun Mar  6 10:06:57 2022

полагаю, что следует попробовать воспроизвести проблему: удалить что-нибудь в корзину ЯД и посмотреть как оно «синхронизируется». И наоборот удалить локально и посмотреть историю событий в веб-интерфейсе Яндекс Диска.
Чтобы примерно понимать с какой стороны была инициировано удаление.

yandex-disk, версия 0.1.6.1080

а нет ли у него нет расширенных режимов логов?

Есть логи.

В push.log записи об удалении директорий:

50914-032003.583 {"root":{"tag":"diff","parameters":{"new":1757809203400837,"old":1757809188076626}},"values":[{"tag":"op","value":"","parameters":{"resource_type":"dir","key":"/disk/F/Другие проекты/Brahms Studio","fid":"e6a71f9c8542f68963d77114f76caf4efdaa88a128a374cdf1d1d7ab76e15110","type":"deleted","folder":"/disk/F/Другие проекты/"}},{"tag":"op","value":"","parameters":{"resource_type":"dir","key":"/trash/Brahms Studio_c47c2630287d004fa8294b7af809c08125b20dfc","fid":"e6a71f9c8542f68963d77114f76caf4efdaa88a128a374cdf1d1d7ab76e15110","name":"Brahms Studio","type":"new","folder":"/trash/"}}]}

По каждой директории в таком духе.

core.log

Записи такого рода (под 20 тысяч, поскольку данных много)

50914-032525.952 MONITOR delete "/home/nikolay/Yandex.Disk" / "G/Видео/2020/29.12.2020/VID_20201229_223641.mp4"

Выше указал версию yandex-disk, такая же, только deb

yandex-disk, версия 0.1.6.1080

Здравствуйте, вы написали в поддержку яндекс-диска. Ваш аккаунт очень важен для нас (нет). Мы делаем деньги на еде, рекламе и такси, а диск для нас расходная статья.

А вообще у них там дикаядичь - я однажды решил переименовать «каталог» в котором было порядка 10к подкаталогов и файлов, и оно (бакэнд яндекса) ушел в размышление на несколько часов, даже листинг не работал

Хранить критически важные данные в Яндексе - это деление на 0. Единственный правильный здесь способ - NAS + Бэкап его на внешний диск + Бэкап в S3 адекватного провайдера (BackBlaze/Amazon), чтобы следовать правилу 3-2-1.

Выглядит так, как будто ты сам удалил каталоги на компе. В любом случае надо понимать, что я.диск — это система синхронизации, а не просто хранения или (тем более) бекапа. Можно использовать в этом качестве, но это не совсем по назначению. Короче, важные данные надо куда-то бекапить и не один раз.

Что вообще могло произойти ?

перезагрузка зависла и мне пришлось воспользоваться комбинацией ALT+PrtSc REISUB

ext4

Из истории событий в веб-интерфейсе Яндекс Диска удалось установить, что 14 сентября 2025 года в 3:20 6 папок было перенесено в Корзину

Очевидно, что у тебя пропали директории при нештатном завершении работы, а после перезагрузки яндекс.диск, увидев их отсутствие, перенёс их в корзину. Достань их из корзины и радуйся, что у тебя был яндес.диск, чтобы спасти твои данные, иначе бы пришлось их выковыривать photorec-ом.

MONITOR delete "/home/nikolay/Yandex.Disk" / "G/Видео/2020/29.12.2020/VID_20201229_223641.mp4"

Вот эта запись говорит о том, что не я.диск их удалил, они пропали с ФС, я.диск только констатировал факт их пропажи.

Вот эта запись говорит о том, что не я.диск их удалил, они пропали с ФС, я.диск только констатировал факт их пропажи.

Как Вы пришли к этому выводу ?

Каким образом это могло произойти ? Я имею ввиду какой такой сбой мог целенаправленно дать команду rm -r по конкретным директориям ?

В моём понимании, если это сбой файловой системы, то он должен был устраниться при проверке во время перезагрузки или хотя бы при ручном запуска fsch.

Отдельно отмечу, что файлы хранились в домашнем каталоге с шифрованием eCryptfs.

Отдельно отмечу, что файлы хранились в домашнем каталоге с шифрованием eCryptfs.

Демон диска стартанул раньше чем примонтировался домашний раздел, например

UPD: ну по идее, он бы и конфига своего не увидел, если запускается от того же пользователя, а не рута и хранит конфиг в той же домашней директории, но я не знаю как он работает на самом деле.

Может у тебя не вся домашняя директория зашифрована, а только одна папка с данными, хотя вроде бы eCryptfs работает поверх обычной фс и создает файлы в ней, только шифрует их, но я бы копал в эту сторону