Комментарии 80
Очередное доказательство, что хранить все важные данные в одном месте - не лучшая идея.
Сожалею, что автор потерял свои файлы. Пусть его история будет предсотережением для тех, кто не делает бэкапы и доверяет всё облакам.
Бэкап должен быть
Бэкап и оригинальные данные никогда не хранятся в одном месте
Бэкапы должны делаться регулярно.
Бэкапы должны валидироваться.
Должно быть настроено уведомление о бэкапе и о его валидации.
Кроме того, время от времени нужно производить ручную проверку бэкапов.
RAID - это не бэкап. Даже RAID6. Но лучше RAID чем не RAID.
Нужно разделение на холодный и горячий бэкап. Холодный бэкап хранится на физически отключенном носителе, в безопасном месте, вдали от горячего бэкапа и места хранения бэкапируемых данных.
Старый бэкап удаляется только после валидации нового.
У вас должно быть как минимум три точки восстановления(т.е. три полных бэкапа за разную дату)
Бэкап-сервер должен сам забирать файлы для резервного копирования с удалённого сервера, а не наоборот
Шифрование бэкапов так же имеет смысл.
Ну и стандартное параноидальное брюзжание об опенсорсе, о недопустимости использования проприетарного софта и облачных решений.
Если это не планомерное вторжение в сеть, а просто случайное попадание шифровальщика - то и 11-ый пункт будет кстати. Вообще, чеклист у @ramiilочень полезный.
У меня "холодные бэкапы" хранятся на обычных серверах, на двух разных площадках, без сейфов и отключения от сети, но удалённо на них можно подключиться только по сертификату, и да - они сами забирают бэкапы. Так как с шифровальщиком я уже как-то сталкивался, и да, бэкапы тогда сливались "в сетевую папку"...
3-2-1
> Бэкап-сервер должен сам забирать файлы для резервного копирования с удалённого сервера, а не наоборот
Можете пояснить почему такое правило?
Потому что у клиента не должен быть прямой доступ к бэкапу, во избежание его повреждения/изменения со стороны клиента.
Причин несколько. Основная - что-бы шифровальщик не пошифровал бэкапы.
Зачастую бэкапирование "на коленке" делается примерно таким скриптом в кроне:
tar -czvf /nfs-share-mountpoint/backup-date +%s).tar.gz /data-to-backupШифровальщик найдёт смонтированныю шару и радостно всё пошифрует.
Чуть более хитрых способ:
mount -t nfs backup-server:/share /nfs-share-mountpoint
tar -czvf /nfs-share-mountpoint/backup-date +%s).tar.gz /data-to-backup
umount /nfs-share-mountpointНо во время бэкапа всё равно можно пошифровать.
Самый плохой случай:
backupname=$($date +%s)
tar -czvf /temporary/backup-$backupname.tar.gz /data-to-backup
sshpass -p "password" scp /temporary/backup-$backupname.tar.gz backupuser@backup-server:/shareВ таком случае можно ещё и пароль от ssh украсть, хотя тупой скрипт этого не сделает.
В дополнение - вообще сам факт наличия бэкап-сервера должен быть хорошо замаскирован, по крайней мере - никаких открытых шар, портов, и др.. И на основной сервер он должен лазить под ничем не примечательной учёткой.
горячий и холодный бекапы имеют совершенно иное значение. у специалистов. в правильно посторенную систему резервного копирования шифровальцик попасть не может даже если это не lan-free. то что Вы назавали "холодным бекапом" обычно называют "удаленным хранением" или off-site backup и обычно это носители с копиями которые просто куда-то унесли или увезли.
в 7й пп еще бы добавить что снапшот - тоже не бекап.
А в чём баг состоит? В том что иконка не поменялась? Так это видимо кеш на конкретном устройстве, на другом поменяется.
Насколько я понимаю в любой ФС если скопировать файл в директорию где есть такой же файл он тупо перезапишется.
В FAT было ещё смешнее - если скопировать папку саму в себя получится рекурсия и место на диске быстро закончится.
Бага никакого нет, автор не знает, как работают ФС. Причем здесь ЯД вообще, если он перезаписал данные самостоятельно и жалуется..
Да, где-то внутри нашей системы была ошибка и каким-то образом 3 файла получили имена как у папок и переместились в корень. Но вот Яндекс диск взял и заменил папки файлами.
Вот не знаю, баг это или фича Яндекса
Это не баг и не фича, а работа ФС и Яндекс тут вообще н е п р и ч е м.
Hidden text
Это не баг и не фича, а работа ФС
Убунта в такой ситуации просто сообщает о невозможности записи "поверх", Windows пишет что папка с таким именем уже существует, и предлагает переименовать, то что Яндекс позволяет в этой ситуации замену, это все же особенность Яндекса. С учетом того, что это сервис для обычного пользователя, особенность так себе.
Не знаю правильно ли я понял, но WebDAV это вроде возможность работать через api, а при работе через есть свойство overwrite которое позволит избежать таких ситуаций, и либо разраб который делал либу для работы либо поставил это свойство в true либо это сделал пользователь. Т.к. яндекс диск возвращает ошибку при попытке записи файла с таким же именем, в целом наверное это не лучшее решение из возможных, но если используешь api, то наверное стоит знать об этом и почитать документацию, т.к. об этом в ней написано, хотя в целом непонятно кто конкретно виноват.
Фича - это особенность работы файловой системы. Да, автор не знал как работают файловые системы. Да, я прямо признаю, что была ошибка в скрипте перемещения и он неправильно обозвал файлы и эти названия совпали с названиями папок. Предупреждаю тех, кто может ещё не знает. Прошу у вас прощения, что не знал. В браузере можно случайно лишиться всех файлов, если ты вдруг стал так переписывать и не гений в ФС.
А ведь там вовсе не файл "123"
И вообще в браузере я просто пробовал воспроизвести ошибку. По факту проблема произошла при работе через API. Так что не было никаких окошечек и никто ничего не подтверждал. Жалуюсь на Яндекс, что не идут навстречу, ведь файлы скорее всего живы.
и не гений в ФС
Во времена DOS и книг Фигурнова объяснялось, что папка (directory тогда еще) — это файл особого вида, и каждое имя в ФС должно быть уникально в пределах того же уровня иерархии, потому что конфликт имен приведет к замещению. Не знали этого только двоечники.
А гении разрабатывали ФС.
Теперь же, оказывается, для этого надо быть гением.
Я ж написал, что я пользователь. Ладно, сдаюсь. Пошёл читать Фигурнова. И жене дам почитать на всякий. Считаю, что без короткого теста по Фигурнову нельзя давать пользователям залогиниться в систему))) Яндекс.диск не для двоечников)
В скрипте нет обработки исключительных ситуаций, а она должна была возникнуть и по хорошему не должно было произойти ничего.
Overwrite: F в запросе MOVE, по умолчанию файл/папка перезаписывается, и это поведение задокументировано у Яндекс.Диска и прописано в стандарте WebDAV.
В те времена, если я правильно помню, у них ещё и расширение .DIR было, только на уровне интерфейса оно скрывалось. Поэтому файл "123" и папка "123" (на деле 123.DIR) тоже бы существовали без проблем - так что столкнуться с ситуацией было сложновато.
С другой стороны, в более новых ФС папки дополнительно обозначены признаком в файловой таблице, так что перепутать их системе должно быть сложно, и ничто не мешает разрешить одинаковые названия.
Хм. Помнится, FAT12 в первой редакции не имела иерархии вообще, а .dir — это Macromedia Director…
Одинаковые названия разрешить нельзя: имя и атрибуты — разные сущности. И в работе с файлами они учитываются отдельно от имени.
маленько не так помните - там у каждой записи каталога есть байт атрибутов, в котором выставляются необходимые биты ("только для чтения", "архивный", "скрытый" и "каталог")))
Так а если попробовать теперь поверх этого файла скопировать папку созданную в другой папке, ну чтобы в таблице файловой системы этот "особый файл" с видом "файл" перезаписался "особым файлом" с видом "папка". вдруг всё что хранилось внутри папки осталось
… если переименовать *.txt в *.mp3, то можно будет послушать, а если в *.avi — то даже и посмотреть!
Содержимое папки же заменится.
Вариантов тут не так уж и много: или в саппорт и (если у них есть снепшоты) надеяться на удачу, или восстанавливать из бэкапа.
содержимое папки не равно содержимое файла. содержимое папки - это записи в таблице файлов с привязкой, к какой папке файлы привязаны. Есть ненулевая вероятность что файлы на диске сохранились, как и записи о них в таблице. Если точнее, то папка - файл нулевой длины. И внутри этого файла соответственно ничего не лежит. Но зато имя этого файла упоминается в таблице файловой системы как указатель - где лежат вложенные файлы и папки. Получается, можно надеяться, что создатели той файловой системы не предусмотрели удаление вложенных файлов физически с диска и удаление записей о них. При перезаписи папки - файлом с тем же именем. Ведь не было же Команды именно Удалить. Намекает на таковую вероятность особенности отображения этого файла, указывающие что это как бы папка. Иконка папки же у него неспроста.
Вы укапываетесь в подробности реализации знакомой вам ФС, не зная, что у яндекса не-NTFS.
При этом не понимаете, что если, как вы предложили выше, перезаписать файл перезаписавший папку,другой папкой, то по этому же имени станет доступна эта другая папка, а не та, которую удалили.
можно надеяться, что создатели той файловой системы не предусмотрели удаление вложенных файлов физически с диска и удаление записей о них
если в системе SSD, почти наверняка ФС просто отправит trim и всё, после этого там может быть что угодно
Итак. Не даёт Папкой перезаписать файл при попытке переместить интерактивно. Т.е. Файл Папкой заменить удалось. А вот Папкой файл не удаётся. Изначально во всплывающем окне он предлагает сразу папку переименовать с постфиксом - текущей датой. Но после удаления постфикса. Записать таки не даёт. Не реагирует на нажатие кнопки записи. т.к. защита, по крайней мере в интерактивном режиме есть. По API я не пробовал. Пусть автор заметки пробует.\
И пожалуйста, khajiit не считайте всех собеседников идиотами. Некоторые упомянутые вами книжки не только читали. Но и писали.
Это я к вашему:
"… если переименовать *.txt в *.mp3, то можно будет послушать, а если в *.avi — то даже и посмотреть! "
Слишком толсто.
А ведь исходя из Интерактивного! поведения Яндекс-диска - это даже не косяк. Это Залёт. Ибо Даже если подтвердив перезапись папки файлом можно потерять доступ к содержимому папки (я специально опустил формулировку "похерить файлы", ибо ещё неизвестно что с ними), то обратная операция, потенциально более безобидная, т.к. в результате её мы можем потерять данные лишь одного файла, который превращается в папку.
Впрочем, замечу, что при перезаписи Папки файлом. Изображение всё же меняется после обновления страницы (я просто закрыл, и через некоторое время открыл заново яндекс-диск, Обновить страницу я не жал, но уверен что и простое обновление страницы тоже подгрузит уже изменённое изображение для этого файла/папки.
Слишком толсто
Это ирония и отсылка к одному вошедшему в баш случаю.
Простите, если обидел.
Некоторые упомянутые вами книжки не только читали. Но и писали.
Тогда становится еще более загадочно, чем вы руководствовались, предлагая примерно такое же по толстоте осмысленности действие…
Потому как если бы это могло сработать, то, во-первых, это был бы большой такой баг с восстановлением "удаленных" файлов, а во-вторых, правильная реализация потребовала бы огромного количества ресурсов, целенапраленно потраченых для именно такого поведения, в том числе проверки а не совпадет ли перемещенная папка с одной из ранее удаленных*, что само по себе иррационально.
Но давайте таки не будем ссориться на ровном месте.
Поведение, конечно, хоть ожидаемое, но потерпевшему легче от этого не становится.
Del
У меня уже два года тикет висит по поводу ошибки на яндекс услугах))) до сих пор исправить не могут, периодически пишут
На мой взгляд, это такая прекрасная дыра в безопасности. В принципе, я бы апеллировал тех. поддержке, что проблема не только в том, что пользователь потерял свои файлы, а в том, что не исправление этого прекрасного механизма может привести к лавине не приятных последствий для сервиса, не буду описывать алгоритм он и так очевиден.
На мой взгляд, это такая прекрасная дыра в безопасности.
Дыра состоит в стандартном и очевидном поведении файловых систем? Если бы их скрипт бэкапил не под WebDav а на другой физический диск, то было бы абсолютно так же.
не буду описывать алгоритм он и так очевиден.
Мне не очевиден. Расскажите?
Не очень понял, чем поведение очевидно? Если в Линукс (любой юникс-подобной на самом деле, но не важно) перенести (mv) файл в другой файл, то он заменится, тут ясно, но если пункт назначения (destination) папка, то файл не перезапишет папку, а поместит файл в эту папку. Вы про какую ФС конкретно говорите?
Т.е. я.диск предупреждает при перемещении файла о дубликате? И при подтверждении удаляет одноимённую папку?
Или удаляет и при переименовании тоже?
Не понимаю что хочет автор, описывая данный кейс как проблему. У вас есть путь /123. По одному и тому же пути в операционных системах не может быть одновременно и папки /123 и файла /123. Вам выдается предупреждение что будет замена по этому пути папки на файл. После замены (еще раз повторюсь замены) автор почему то ожидает что останутся и папка и файл.
Автор за свои 40 годиков первый раз столкнулся с этим и хочет предупредить таких же неумёх. Оказывается даже Windows так не умеет делать. В предупреждении было написано, что такой файл существует без намёков на папку. Опять же это был эксперимент. По API, думаю, просто выполняется перемещение. А ожидаю я, что останутся файлы, потому что наверное физически они не перезаписались и не перетёрлись, и писал в поддержку именно с этой надеждой.
Ну да, в RSX-11, такой проблемы не было, там уже было версионирование файлов.
Да и в Вандрайве две корзины.
А яндекс похоже наличие расширения вообще никак не учитывает.
Возможные грабли, это то что тебя забанят без объяснения причин и диск удалят. Благо что там ерунда хранилась, стучался в ТП - без результата
Не рекомендую использовать Яндекс.Диск для работы и/или через WebDAV. Несколько лет назад они практически отключили его для существующих клиентов искусственным ограничением скорости.
А бэкапы принципиально решили не делать?
Уникальности много не бывает. Надо делать префикс в имени: file_ для файлов и folder_ для папок
Понятно, что ответ тут один — бэкапы. Мало ли что вообще может случиться с файловой системой.
Но я никогда даже не задумывался что произойдёт при совпадении имён файла и папки.
Могу сказать больше, раньше (да и сейчас тоже) иногда проворачивали фокус чтобы автоматически не ставились левые программы: создаешь файл с именем каталога в место куда программа автоматически устанавливается.
Было такое давно на одной из первых работ. Собственно: на компьютерах пользователей был установлен клиент radmin'а, чтобы админы могли удалённо подключаться. Причём делать это они могли без уведомлений. Мне это не понравилось, поэтому удаляю radmin.exe... и нет, не даёт удалить. Далее стандартный виндовый способ: переименовываю этот файл и создаю папку с названием radmin.exe. Далее перезагрузка и никаких radmin'ов.
Ага, папка autorun.inf в корне диска, например
Понятно, что ответ тут один — бэкапыОтвет тут один — учить матчасть
То есть, программист намеренно использовал что-то типа: «rm -rf», а потом удивляется «Как это так? Зачем директорию то удалять?». Потому что я не представляю, зачем специально ставить эту опцию и не понимаю — как ее можно поставить случайно.
Хотя вариант есть. «Программист» копипастил код непойми откуда, не понимая что там и зачем
Главное, чтобы это в бэкапе тоже не случилось
Лет 5 назад, кажется, можно было заварить отличную "кашу" из данных, если включить дедупликацию на машине с установленным Яндекс Диском. Данные были консистентными только на машине где была включена дедупликацию, а на других уже синхронизированная Яндексом каша =))
удивительно, что Яндекс. еще не ответил тут) Репостни на vc)) А лучше на Дзен)
хотя по сути, вам все ответили - вы. правда считаете, что из вредности или пренебрежения к ламерам не хотят восстановить?)
"Ваши папки удалены и если они удалены через WebDAV, то они не появляются в корзине. Их не вернуть. "
Тоже не понимаю, чего хочет автор. У него там какой-то скрипт с непонятным поведением. Этот скрипт мог и просто rm -rf / сделать.
Дальше автор пошёл в ТП Яндекса просить, по сути, услугу бекапа данных, которую ему никто не обещал. Сам же никаких бекапов, судя по всему, не делал. Хотя, откуда такая вера в сохранность данных в Яндекс.Диске? Ну вот забанят они аккаунт, и всё, кранты. Данных нет.
Ув.автор, не нужно обвинять компанию, если Вы, или Ваши разработчики не смогли/захотели качественно разобраться в документации API.
Несмотря на то, что сейчас яндекс диск наши конкуренты, ничего плохого об их реализация протокола WebDAV я сказать не могу. Все работает согласно спецификации протокола, и описанное поведение может управляться посредством API.
Что касается Ваших данных: естественно физическое удаление не производится ежесекундно и, с максимальной вероятностью, сами файлы на диске были лишь помечены на удаление и физически сотрутся позже. Но из дерева каталогов пользователя запись должна удаляться сразу, что логично. Иначе вы лишились бы возможности быстро менять один файл на другой и всегда ожидали бы его физического удаления. А это может происходить в течение длительного срока.
Но если бы, сотрудник яндекса смог вам их восстаровить - это означало бы, что сотрудники ТП могут спокойно просмотреть содержимое чужого облака. А это было бы грубейшим нарушением приватности и по сути делало бы облако публичным.
Обращение было с просьбой попытаться восстановить. А ответ формальный - сами дураки. То что сами дураки я не отрицаю.
Да и возможность восстановления файлов можно сделать без возможности их просмотра.
Когда Вы монтируете сетевой диск и удаляете из него файл/папку - он(а) удаляется безвозвратно. Именно такоп поведение и реализуется посредством WebDAV.
Все вопросы и предупреждения "вы уверены..." при этом отображает клиент в виде файлового менеджера.
Вы сами выбрали работу именно через API и не стали подробно с ним разбираться. Если продукт не оправдывает Ваших ожиданий, очень часто дело именно в ожиданиях, а не в продукте.
Я понимаю Ваши эмоции, но в данном конкретном случае проблема находитс на стороне вашей ИС, а Вы обвиняете яндекс, что они не подстраховались на случай Вашей ошибки.
Если я к компьютеру подключаюсь по Anydesk, то файлы всё равно удаляются в корзину.
Это понятно и логично.
Разница такая, что вы, ничтоже сумняшеся, сравнили удаленную ФС с удаленным рабочим столом.
Подсказка: когда винда в цикле ребутов пишет "Компьютер загружен неправильно", или когда на домашнем пингвине ломаются иксы (Wayland? не, не слышал) — то файловая система у вас есть, а рабочего стола — нет.
Корзина это вообще абстракция уровня файлового менеджера, на уровне ФС ее попросту не существует.
На уровне ФС могут существовать версии, если сама ФС их поддерживает. Но они совершенно не обязаны поддерживаться софтом, реализующим WebDAV — и могут отображаться как угодно или не отображаться вообще.
Абсолютно верный комментарий от khajiit.
Прежде чем формировать свои ожидания от системы, пожалуйста, ознакомьтесь с предлагаемой документацией. А когда выбираете метод интеграции, не поленитесь, почитайте спецификации. В них часто все подробно описано, может быть несколько многословно, за то однозначно. Едва ли не половина всех обращений в ТП любого продукта - это просто несоответствие ожиданиям клиента. Люди не читают ни пользовательские соглашения (я тоже ленюсь, каюсь))), ни спецификации протоколов - а результат один: сервис плохой, ТП формально отписываются и вообще мир не справедлив.
Подойдем с обратной стороны: что мотивировало выбирать интеграцию именно посредством WebDAV? Это далеко не самый "удобный" протокол. Есть более "попсовый" REST, там и команд больше, описание русское, и список проверок от случайностей побольше.
Яндекс ДИСК — возможные грабли