После 22:00 у меня случилась проблема с диском U: ёмкостью 2 Тб — на нем частично исчезли файлы и папки, изначально мне показалось, что из-за аппаратного сбоя HDD, но потом я выяснил истинную ужасную причину, о которой нужно знать. Рассказываю, как я с этим боролся.
Папки с картинками и видео большей частью остались, а вот с документами пропали. Осталось примерно столько:
Восстановление данных на Яндекс-диске
Для самых ценных файлов (рабочие и личные проекты) была включена автоматическое постоянное сохранение папок на Яндекс-диск, но там они тоже удалились, потому что сработала синхронизация. Но, счастью, они удалились в корзину.
Я вышел из приложения, потому что даже если отключить синхронизацию, сохранение папок с компьютера все равно работает и файлы переносятся в корзину.
Зашел в корзину Яндекса, выделил все файлы и папки в ней и нажал на них восстановить.
Данные на Яндекс-диске начали восстанавливаться:
Через некоторое время восстановились, корзина показывается как пустая:
Попытки восстановить с HDD специальными программами
Параллельно я скачал и запустил Recuva, хотя она и не хотела скачиваться из РФ.
Recuva искала удаленные файлы:
Но к сожалению, программа показала файлы, которые может восстановить, без каталогов, это мало что давало мне. К тому же файлы, измененные 8 августа, в день падения, восстановлению не подлежали:
Попробовал похожую программу EaseUS Data Recovery, но она точно так же не восстанавливала папки:
Восстановление из локальных архивов
Заглянул в свой бэкап-план на Гугл-диске. Там увидел куда сохраняется бэкап:
Сделал несколько копий последнего архива:
На всякий случай отключил создание последнего архива:
Полные архивы на диске я делал не часто. Каждый архив делался на три диска. В данном случае последний 5 месяцев назад, в марте 2025:
Нашел пустой диск на 2 Тб, он у меня был для архивов в будущем, решил на нем собрать образ нужного мне диска. В это же время заказал на озоне диск HDD на 4 Тб.
Подключил его вместо сбойнувшего диска U.
Поставил копирование всего архива диска U на новый диск. Total Commander при этом благополучно вылетел, потому что был на этом диске. Поставил копирование через проводник. Прогноз не особо радовал, но я надеялся что скопируется быстрее:
Копировалось чуть быстрее, но случайно задел ногой HDD, копирование прекратилось:
Перезапустил уже для удобства в Total Commander. Он пропустил уже скопированное и продолжил копирование:
Копирование данных с Яндекс-диска
Чтобы скачать данные с Яндекс-диска, пришлось запустить его на ноутбуке, чтобы он не пытался синхронизировать локальные данные. При этом я сначала пытался скачать Яндекс-360 4.0, который начинал синхронизировать данные, не давая никакого интерфейса. Пришлось удалять это приложение. Потом я из веб-браузера в Яндекс-диске нажал «Скачать Яндекс-диск» и загрузилось то приложение, что мне было нужно (3.0), оно позволило загружать файлы в нужные папки.
Поставил скачивание на компьютер по локальной сети, думаю, можно было бы и на компьютере такой же трюк провернуть, хотя как знать, может быть Яндекс-диск опять начал бы сохранять папки.
Скачивание запускал дважды — сначала хотел напрямую с ноутбука на расшаренную папку, но так Яндекс-диск зависал. Поэтому сначала локально на ноутбук, оттуда на компьютер в расшаренную папку.
Сбор итоговых данных из разных источников
У меня была копия данных от марта.
В нее я скопировал в режиме «заменить более старые» файлы из ежедневного архива, а потом скачанное с Яндекс-диска.
Также на ноутбуке у меня синхронизировались в поездках фотографии и видео, я еще раз синхронизировал их с телефоном и скопировал в папку на диске. Это закрыло те файлы фото-видео, которые могли пропасть.
Обошлось практически без потерь.
Перенос модели на рабочий диск
Как раз к 15 часам дня приехал новый диск из Озона на 4 Тб:
По странному стечению обстоятельств, он тоже был Seagate Baracuda — преступника тянет на место совершения преступления.
Вставил в крэдл диск с моделью и поставил через Проводник копирование на новый диск:
Выявление причины удаления файлов
Но счастье длилось недолго. Через некоторое время файлы на диске U: опять начали удаляться.
Кроме того, удалились файлы и с диска Y:, под которым я подключил через WebDav свой Яндекс-диск.
Чтобы понять, что именно удаляет файлы, я запустил старый добрый Process Monitor и истинная причина удаления открылась мне во всей своей зловещей простоте:
То есть файлы удалялись при подключении к удаленному рабочему столу, потому что я подключался с доступными для записи локальными дисками!
Финальное восстановление
Remote Desktop Manager в бесплатной версии не позволяет массово назначать доступ, так что я прошелся по всем записям и настроил доступ только к виртуальному диску Z:, который я создал специально для целей обмена данными.
Ранее я жалел, что нельзя было скопировать сразу на новый диск, но сейчас диск с моделью пригодился, я просто скопировал с него на новый диск.
Выводы
Техника подводит, это бывает. Но не всегда стоит пенять на технику.
Полные архивы надо делать хотя бы раз в месяц. Раз в полгода — это слишком редко. Повезло, что удалось восстановить все данные благодаря нескольким средства бэкапа.
От шифровальщика моя схема не защищает, надо продумать варианты. Но от случайного или аппаратного удаления данных защищает.
Яндекс-диск через приложение — очень неудобный инструмент, надо пробовать варианты вроде WebDAV. Но даже при подключении диска нужно быть аккуратным с доступом, чтобы данные на Яндекс-диске не очистились.
Такие учения заставляют нас задуматься о сохранности наших данных, еще раз напоминают о материальной природе хранения информации.
Решил выделить время и упорядочить данные. Старые данные вынести в read-only архивы по годам, чтобы не тратить время на их восстановление.
Как закончу с восстановлением данных, сделаю их полный бэкап. Также буду следить, чтобы полный бэкап делался не реже, чем раз в месяц.
Нужно поискать, как сделать, чтобы по-умолчанию при подключении по RDP без настроек был доступен только диск Z:
Комментарии (72)
Lev3250
28.09.2025 14:23Очень сумбурно. Подключение по рдп было с этого компа на другой, или с другого на этот? Как подключение влияет на удаление файлов? Там было пересечение по именам дисков, или антивирус, или что-то другое?
HomeMan
28.09.2025 14:23Не RDP, а RDM это "немного" разные вещи. И самую мякотку расследования про РДМ нам не рассказали.
fixin Автор
28.09.2025 14:23я по роду профессии (программист 1с) работаю с множеством удаленных рабочих столов клиентов (порядка 10). Какой именно из них занимается порчей файлов и почему непонятно - может это вирус, может сбой скрипта. Почему он удаляет только на дисках U, Y, а не трогает C:, D:, Q:, тоже неясно. Но вывод такой - не используйте расшаривание локальных дисков. Даже если файлы не удалят, их могут скопировать.
HardWrMan
28.09.2025 14:23То есть файлы удалялись при подключении к удаленному рабочему столу, потому что я подключался с доступными для записи локальными дисками!
Непонятно, почему RDP в принципе решил массово удалять файлы. Кто его надоумил это делать? Ведь надо решать проблему в корне а не лечить симптомы ограничением доступов в R/O.
HomeMan
28.09.2025 14:23Потому что человек не использует РДП, а использует РДМ. Море подробностей про диски, тоталкомандеры и прочее. И ноль информации про РДМ. А проблема пришла оттуда. Ждем сериал "Как я спасал данные".
fixin Автор
28.09.2025 14:23не суть. я думаю на каком-то из серверов что-то удаляло данные на подключенных дисках. Думаю при доступе через RDP, а не RDM было бы тоже самое. Бойтесь подключаться с локальными дисками!
ifap
28.09.2025 14:23Полные архивы надо делать хотя бы раз в месяц
Раз в месяц? Рисковать месячным объемом работы, который в иной месяц стоит пары лет? Мсье еще не слышал про синхронизацию, которую стоит выполнять раз в день, а то и чаще?
fixin Автор
28.09.2025 14:23я имел ввиду полные архивы. Ежедневные архивы у меня тоже были, включая синхронизацию на яндекс. Тут они мне помогли. Против шифровальщиков бы не помогли. В поисках инструмента для надежного бэкапа сейчас.
ifap
28.09.2025 14:23Синхронизация - это и есть полный архив по состоянию на время синхронизации.
fixin Автор
28.09.2025 14:23да, но это ненадежно. если шифровальщик зашфирует файлы, они окажутся на Яндекс-диске аккурат зашифрованными. Яндекс-диск версии поддерживать не умеет.
Нужна какая-то сторонняя утилита.ifap
28.09.2025 14:23Шифровальщик - отдельно, синхронизация отдельно. Но если и совместить их, то поврежденными окажутся лишь файлы тех времен, когда завелся зловред, а не весь месячный архив.
fixin Автор
28.09.2025 14:23это да. но если полный архив я делаю раз в месяц, а синхронизацию ежедневно, можно потерять месячную работу.
MkIV007
28.09.2025 14:23поставь duplicati и синхронизируй хоть каждый час, он будет передавать в облако только изменения и очень быстро.
fixin Автор
28.09.2025 14:23В Обновляторе неплохо сделано. Только я думаю, для каждого файла должна быть ежедневная, еженедельная, ежемесячная версия.
MkIV007
28.09.2025 14:23duplicati - это подход непрерывного бэкапа. Ставите сколько времени хранить файлы и в этом промежутке у вас будут все версии. Я ставлю 1 месяц на обычные и 3 месяца на критичные. 1-2-3 - это старомодный подход которому уже лет 50 :).
ed77777
28.09.2025 14:23В бесплатной версии 30 дней у YD. И в приложении и в веб интерфейсе. В платной 90 дней.
MkIV007
28.09.2025 14:23Я много лет использую вот это. https://duplicati.com/download - полет нормальный. Я кидаю на onedrive - просто потому что 5 Тб ни у кого больше за такие деньги не купишь, но он понимает кучу облаков и серверов для хранения бэкапов. Восстанавливается без проблем, проверял в деле :)
fixin Автор
28.09.2025 14:23а принцип какой?
MkIV007
28.09.2025 14:23В каком смысле "какой принцип"? Запускаешь агента, он складывает шифрованные архивы выбранных папок в облако с заданными интервалами, понимает windows shadow copy чтобы открытые файлы забэкапить, делает инкрементальный архив, чтобы место использовать экономно. Агентом же восстанавливаешь из бэкапа, когда надо. Хранит версии, сколько укажешь.
fixin Автор
28.09.2025 14:23т.е. если я шифровальщиком раз в 10 минут буду перезаписывать файл, этим я надорву возможности этой схемы?
aik
28.09.2025 14:23Шифровальщик не переписывает раз в десять минут файл. Он отработал и удалился - чтобы вы его не поймали и не вытрясли из него ключ шифрования.
А если вы укажете хранить копию год - она будет храниться год. И даже если вы каждые десять минут меняете файл и загружаете его в хранилище, у вас будет просто очень много копий этого файла.
fixin Автор
28.09.2025 14:23особо зловредный шифровальщик после себя создаст версию, которая не содержит ключа, но будет перезаписывать файлы раз в минуту, чтобы исчерпать хранилище.
aik
28.09.2025 14:23Шифровальщик так не делает. Так может сделать человек, который хочет вам напакостить. Шифровальщик же просто зашифрует всё, до чего дотянется и самоуничтожится, оставив вам записку с координатами кошелька. Всё остальное ему не нужно. Ибо он работает на потоке - потому должен быть простым, быстрым и надёжным.
fixin Автор
28.09.2025 14:23ну мы же не можем списывать со счетов вирусы-дестройеры?
aik
28.09.2025 14:23Можем. Да, всегда можно придумать подход, который положит вашу систему бэкапа. Но надо ещё думать, как он с массовостью сочетается. Нахрена "дестроеру" каждые 10 минут что-то шифровать? Это бесполезно для его целей. Просто забил диск нулями и всё на этом. Большинство людей бэкапы не используется, а беспокоиться о самых хитрых смысла нет, слишком малый выхлоп относительно затраченных усилий.
Вот направленная атака - это другая история.
aik
28.09.2025 14:23Так какова же Ужасная Причина удаления файлов? RDM сам файлы не удаляется, вообще-то.
Яндекс.диски и т.п. - это не бэкап, это синхронизация. Что у вас файлы остались в корзине - это повезло. Могла переполнится, могла очистится сама и т.п. А бэкап - это однонаправленное действия, из источника к цели. Обычно с поддержкой истории. Так что изменения в цели вам не сломают источник, а проблемы в источнике не приведут к уничтожению цели. Именно на это бэкап и нужен.
Вебдав на яндексе кривой, лучше синхронизацию через rclone настройте. Ну или подключение диска через него же, если вам именно "сетевой диск" интересен.
Не надо вертикально диски ставить. Ненадёжно это. Даже если не зацепите, он сам упасть может.
fixin Автор
28.09.2025 14:23Причина удаления файлов - то что какая-то программа на сервере случайно или намеренно очищала диски U:, Y: и т.п., Q: не тронула, например. Может это сбой скрипта, может злонамеренная программа.
Т.к. диски в RDP были доступны, то она могла их чистить.aik
28.09.2025 14:23Программа работала именно в вашем сеансе, а не просто "на сервере". Так что смотрите, что у вас там в автозагрузке и логонскриптах.
fixin Автор
28.09.2025 14:23нет, она работала на сервере, а не локально. Выполнялась в процессе Free Desktop Manager.
aik
28.09.2025 14:23Она работала на сервере в вашем сеансе. Потому что пользовательские диски подключаются только в вашем сеансе, а не всем процессам на сервере.
fixin Автор
28.09.2025 14:23Верно, она работала в моем сеансе на сервере RDP, там была какая-то штука, которая чистила подключенный диск. Т.е. не на моем компьютере, а именно на RDP
aik
28.09.2025 14:23Я именно это и пишу. Это был процесс в вашем сеансе, а не системная служба. То есть вы можете его там отловить в своей автозагрузке или логонскрипте и посмотреть, что это такое.
fixin Автор
28.09.2025 14:23проблема в том, что не повторяется. Я сделал один диск Z: для обмена
много там не хранил, типа как буфер.
И один раз, да. У меня этот диск очистился.
Причем так что аж сам пропал, потому что был сделан через Subs
Но потом я его подключил заново и больше удаление на диске Z не ловил.
Полет нормальный. Не знаю, что там чистило подключаемые диски и почему перестало.Но выводы сделал - подключаю только диск Z:
RoasterToaster
28.09.2025 14:23Вот поэтому то я ВЕЗДЕ отказался от маппинга сетевых дисков по буквам. Только ссылка на ресурс. И пока, насколько я вижу, шифровальщики не парсят ярлыки на рабочем столе в поисках сетевых ресурсов.
dag_tech
28.09.2025 14:23WebDAV у Яндекса - организован своеобразно. Повторные эксперименты провожу один-два раза в год, то с одним, до с другим WebDAV-клиентом, на разных ПК. Последние 5-7 лет результат один и тот же: отправка на Яндекс Диск по этому протоколу работает очень медленно - десятки килобайт в секунду, практическое применение невозможно. А вот загрузка из Яндекс Диск - вполне терпимо - несколько мегабайт в секунду. В последнее время использую Good Sync - можно настроить несколько WebDAV-подключений чтобы выкачивать данные из отдельных "левых" папок в разных ЯД (разных аккаунтов), записывать можно в любые "правые" папки, сопоставленные по отдельности под каждую "левую" папку. "Правые" папки могут располагаться где угодно - на подключенных носителях или на сетевых ресурсах.
Можно запустить одновременное выкачивание по нескольким таким подключениям. Скорость снижается, но не критично. Всё это - односторонняя синхронизация, поэтому потом выполняется бекап на локальных ресурсах.fixin Автор
28.09.2025 14:23да, давно известно что Яндекс диск не дает нормального веб-дав, чтобы его не использовали в коммерческих целях.
dimsoft
28.09.2025 14:23Програмист 1С - этим всё сказано. Когда Вы научитесь нормальным решениям backup ? 3-2-1, rto rpo, что мешало бекапить например в тот же яндекс в s3 ? Где комплексный подход к хранению ? Информация может "пропасть" и со смертью дисков и с шифровальщиками. Нужен комплексный подход.
fixin Автор
28.09.2025 14:23у S3 есть недостатки в виде накопления потерянных очередей. Я об этом тоже писал на хабре, поищите.
Dupych
28.09.2025 14:23Ubuntu 22
При установке ставлю галрчку Nextcloud.
Личное облако 2 ТБ.
VeeamBackup делает бэкап.
Доступ из интернета и домашнего пк.
0 проблем.
ramil_trinion
28.09.2025 14:23Очень интересно. Опишите подробнее пожалуйста.
torigetz
Поправьте пожалуйста в самом начале статьи 2 ГБ)
fixin Автор
а что не так?
K0styan
У вас там Гб - гигабит, вместо гигабайта, ГБ)
Efrem3112
Я, так понял, там вообще ТБ должно быть.
fixin Автор
да, верно. 2 Тб. ;-)