Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Спасибо за обзор. Акутально к 2тб от Mail.ru
Как я понял, может возникнуть проблема с .encfs6.xml, если его клиент облака тоже синхронизирует. (Конечно, можно ему запретить, но кто знает, будет ли реально действовать запрет?)
А по мейлру какие могут быть рекомендации?
Из обзора больше всего приглянулся CarotDav.
Но, учитывая проблемы с webdav у Майл.ру-шного облака, не глючит ли данный клиент при работе с ним?
Но, учитывая проблемы с webdav у Майл.ру-шного облака, не глючит ли данный клиент при работе с ним?
2 дня назад при снятой галочке «Don't update property» c mail.ru работал нормально. Сейчас, похоже, webdav они отключили: с webdav.cloud.mail.ru идет 301 Redirect на cloud.mail.ru.
Поэтому из предложенных решений можно использовать первые 3 пункта, скармливая официальному клиенту mail.ru зашифрованные папку или диск.
Поэтому из предложенных решений можно использовать первые 3 пункта, скармливая официальному клиенту mail.ru зашифрованные папку или диск.
Есть продвинутый вариант encfs4win — boxcryptor. Имеется бесплатная версия, которой хватает на все. Есть версия под андройд. Пользуюсь, доволен.
Отсутствие доступа с мобильных устройств сильно снижает комфорт использования. А на больших устройствах можно бесплатно воспользоваться всяким разным типа WebDAV, который с помощью некоторых в свою очередь бесплатных программ тоже подцепят его как папочку или диск. Или с некоторых пор даже Bittorrent Sync. Всё бесплатно и объёмы все ваши.
Если вы не хотите делиться информацией о себе (я тоже не хочу), то имеет смысл ничего в облако не лить из личного. Я лью немножечко личного — фотки с телефона автоматом сами туда прыгают. Но тоже можно отключить. Базы с паролями тоже там храню, чтобы если что, в отъезде можно было работать, если приспичит. Но они зашифрованы.
В общем, я за битсинк. Время синхронизации в среднем секунд 30, не считая времени пересылки.
Если вы не хотите делиться информацией о себе (я тоже не хочу), то имеет смысл ничего в облако не лить из личного. Я лью немножечко личного — фотки с телефона автоматом сами туда прыгают. Но тоже можно отключить. Базы с паролями тоже там храню, чтобы если что, в отъезде можно было работать, если приспичит. Но они зашифрованы.
В общем, я за битсинк. Время синхронизации в среднем секунд 30, не считая времени пересылки.
> локальные данные остаются нетронутыми, а шифруется только их отображение на виртуальном диске
Не понял этот пункт. Получается, на жестком диске храниться две копии данных: локальная рабочая не зашифрованная копия, и пофайлово зашифрованные данные?
Не понял этот пункт. Получается, на жестком диске храниться две копии данных: локальная рабочая не зашифрованная копия, и пофайлово зашифрованные данные?
При размерах места в mail.ru прямо просится возможность делать к ним копию чуть не всего жесткого диска, с возможностью восстановить потом диск на голом железе.
Тут либо возиться пофайлово (и отслеживать особенности ФС и разметки, такие, как файловые потоки, например, или где и как лежит загрузчик), либо поблочно (в идеале — только занятые блоки, конечно), и тогда ОСь, в принципе, уже не важна.
Так вот эту копию без шифрования копировать — занятие либо для неслабонервных, либо для очень беспечных. А шифровать, получается, и нечем: нужна программа, подобная Ghost, но умеющая WebDav (что универчальнее в смысле выбора облака для хранения; впрочем, непонятно, WebDav уже в mail.ru умер, или это просто его колбасит из-за бета-статуса) и/или «родные» протоколы каждого из облаков (это, по идее, обещает более четкое общение с облаком, но универсальность теряем). При таком раскладе, конечно, хранить несколько копий бекапа смысла нет (ну, только если сохранять целый образ: представил, как выглядит череда томов «мой ПК на 21.12.13», «мой ПК на 28.12.13» и т.д. — но 1 Тб на такое не хватит).
Пока вариант один: грузиться в LiveCD, сооружать велосипед из 1) виртуальной ФС с шифрованием на WebDav и 2) бекапера целого диска, и указания пункту второму делать копию диска на ФС пункта первого. Копирование времени сожрет — жуть, но как вариант… По крайней мере, подобных готовых решений я не встречал.
Тут либо возиться пофайлово (и отслеживать особенности ФС и разметки, такие, как файловые потоки, например, или где и как лежит загрузчик), либо поблочно (в идеале — только занятые блоки, конечно), и тогда ОСь, в принципе, уже не важна.
Так вот эту копию без шифрования копировать — занятие либо для неслабонервных, либо для очень беспечных. А шифровать, получается, и нечем: нужна программа, подобная Ghost, но умеющая WebDav (что универчальнее в смысле выбора облака для хранения; впрочем, непонятно, WebDav уже в mail.ru умер, или это просто его колбасит из-за бета-статуса) и/или «родные» протоколы каждого из облаков (это, по идее, обещает более четкое общение с облаком, но универсальность теряем). При таком раскладе, конечно, хранить несколько копий бекапа смысла нет (ну, только если сохранять целый образ: представил, как выглядит череда томов «мой ПК на 21.12.13», «мой ПК на 28.12.13» и т.д. — но 1 Тб на такое не хватит).
Пока вариант один: грузиться в LiveCD, сооружать велосипед из 1) виртуальной ФС с шифрованием на WebDav и 2) бекапера целого диска, и указания пункту второму делать копию диска на ФС пункта первого. Копирование времени сожрет — жуть, но как вариант… По крайней мере, подобных готовых решений я не встречал.
Посмотрите Acronis. Насчет стойкости шифрования там не знаю, а вот закрыть паролем образ он позволяет.
Он, кстати, движется в сторону облачного хранения. Пока правда только свое облако использует, но если разработчики добавят вариант выбора любого облака в качестве места хранения, то это будет киллер фича.
Он, кстати, движется в сторону облачного хранения. Пока правда только свое облако использует, но если разработчики добавят вариант выбора любого облака в качестве места хранения, то это будет киллер фича.
Киллер-фича будет, если кто-то (Акронис тот же) даст 1 Тб в своем облаке навечно и бесплатно.
Потому что я верю техникам mail.ru, но не верю менеджменту. Выпилят они облако через годик, и пофиг, что обещали «навечно» — и плакали бекапы :( А платить по тарифам dropbox за 1 Тб что-то не очень радует, я уж проще в www.backblaze.com/ пойду. Давно бы уже их использовал, но все же гнать данные через океан — как-то идеологически неверно, да и скорость при проверке была маловата.
Потому что я верю техникам mail.ru, но не верю менеджменту. Выпилят они облако через годик, и пофиг, что обещали «навечно» — и плакали бекапы :( А платить по тарифам dropbox за 1 Тб что-то не очень радует, я уж проще в www.backblaze.com/ пойду. Давно бы уже их использовал, но все же гнать данные через океан — как-то идеологически неверно, да и скорость при проверке была маловата.
Такое ещё просится у SkyDriv'а, также, как это сделал Apple.
Насколько я понял, что в данном варианте все-равно используется клиент майл ру, а кто даст гарантию, что он в определенный момент не начнет внезапно синхронизировать «иные» папочки на компьютере, а не только явно указанные.
Если уж параноить, то по полной, например отдельная за-tor-енная тачка, с доверенным софтом и os, с шифрование всего и вся без исключения.
Если уж параноить, то по полной, например отдельная за-tor-енная тачка, с доверенным софтом и os, с шифрование всего и вся без исключения.
Объясните пожалуйста, а зачем вам --reverse с encfs и почему бы просто не монтировать зашифрованный каталог из «облака» напрямую? Плюс на windows можно использовать Boxcryptor Classic как более удобный клиент encfs, — бесплатная версия поддерживает ограниченное подмножество возможностей encfs (нет поддержки шифрования имен, и только 1 «контейнер» за раз можно замонтировать), платная версия — 100% совместима с encfs, так что можно использовать как замену консольному encfs.
Сам подобным образом шифрую данные в dropbox-е, отлично работает. На винде — BoxCryptor Classic, на Linux-е — encfs к тому-же каталогу, на андроиде — cryptonite как реализация encfs, либо BoxCryptor Classic опять-же, когда нужно быстро просто один файл посмотреть, и не нужно монтировать на долговременное использование.
Сам подобным образом шифрую данные в dropbox-е, отлично работает. На винде — BoxCryptor Classic, на Linux-е — encfs к тому-же каталогу, на андроиде — cryptonite как реализация encfs, либо BoxCryptor Classic опять-же, когда нужно быстро просто один файл посмотреть, и не нужно монтировать на долговременное использование.
Разница в скорости. В случае --reverse вы будите работать с файлами напрямую, а не через прокладку. Думаю, это может быть полезно для работы с видео и прочими тяжёлыми файлами. А уж клиент синхронизации будет работать с зашифрованным файлом и ему потери в скорости доступа менее существенны.
Сейчас попробовал смонитровать непосредственно из облака.
Ничего хорошего не получилось, копирование зависло, а потом encfs закрэшилась. Думаю, из-за сетевых таймаутов или кривой реализации webdav клиента Windows.
" --reverse" мне нужен, т.к. я не хочу шифровать локальные данные. Для этого есть средства лучше и быстрее, тот же TrueCrypt.
Boxcryptor — вариант неплохой, только я не уверен, что он полностью совместим с encfs. Нашел на их сайте такое — This version brings some “invisible” changes, most notably the replacement of EncFS with our own BoxCryptorFS.
net use X: \\webdav.yandex.ru@SSL\DavWWWRoot /USER:xxxx@yandex.ru *
encfs.exe X:\Crypted\ Y:Ничего хорошего не получилось, копирование зависло, а потом encfs закрэшилась. Думаю, из-за сетевых таймаутов или кривой реализации webdav клиента Windows.
" --reverse" мне нужен, т.к. я не хочу шифровать локальные данные. Для этого есть средства лучше и быстрее, тот же TrueCrypt.
Boxcryptor — вариант неплохой, только я не уверен, что он полностью совместим с encfs. Нашел на их сайте такое — This version brings some “invisible” changes, most notably the replacement of EncFS with our own BoxCryptorFS.
Про BoxCryptor — там два разных продукта, на самом деле, а не один. BoxCryptor и BoxCryptor Classic. Между собой они не совместимы, первый использует свой формат, второй (classic) — совместим с encfs. Я говорил именно о classic. Его чуть сложнее найти у них на сайте, но он все так же поддерживатся и в том числе продается, если нужна полная версия. Разработчики вроде обещали, что classic никогда не забросят в плане поддержки.
Увы, так и не получилось подружить опцию reverse с Яндекс-диском.
Для начала попробовал совместить шифруемые и нешифруемые данные — в синхронизируемой папке сделал две разных подпапки, в одну кидаю Junction на папки, которые не надо шифровать (работает отлично), во вторую собрался подключать полученный виртуальный диск.
Вот только не нашёл, как узнать GUID этого виртуального тома, чтобы скормить его команде MOUNTVOL.
Пошёл кривым окольным путём. Создал в шифруемой папке служебную папку, в которую и перенес Junction'ы. А на ту, что получилась в корне X:, сделал Junction в синхронизируемой папке. Клиент Я.Д, подумав, ругнулся на все подпапки «ошибка чтения» (проверил — даже если вместо создания Junction просто скопировать папку — всё равно не осиливает).
Ладно, думаю, без нешифрованных файлов можно и обойтись (хотя лишаешься функции файлообменника).
Задал в качестве синхронизируемой папки корень зашифрованного диска (X:/) — клиент заклинило в стадии «Обработка данных».
Я подумал — а ведь он должен в указанную папку свои служебные файлы положить. Смотрю — никаких следов.
Попробовал вручную скопировать файл на этот диск — фигвам. Что фар, что эксплорер сообщают «Параметр задан неверно».
Это ж что получается — если даже на этой машине таки залить в облако зашифрованные файлы, то при попытке их вытащить на другой машине клиент не сможет их записать на виртуальный диск?
Для начала попробовал совместить шифруемые и нешифруемые данные — в синхронизируемой папке сделал две разных подпапки, в одну кидаю Junction на папки, которые не надо шифровать (работает отлично), во вторую собрался подключать полученный виртуальный диск.
Вот только не нашёл, как узнать GUID этого виртуального тома, чтобы скормить его команде MOUNTVOL.
Пошёл кривым окольным путём. Создал в шифруемой папке служебную папку, в которую и перенес Junction'ы. А на ту, что получилась в корне X:, сделал Junction в синхронизируемой папке. Клиент Я.Д, подумав, ругнулся на все подпапки «ошибка чтения» (проверил — даже если вместо создания Junction просто скопировать папку — всё равно не осиливает).
Ладно, думаю, без нешифрованных файлов можно и обойтись (хотя лишаешься функции файлообменника).
Задал в качестве синхронизируемой папки корень зашифрованного диска (X:/) — клиент заклинило в стадии «Обработка данных».
Я подумал — а ведь он должен в указанную папку свои служебные файлы положить. Смотрю — никаких следов.
Попробовал вручную скопировать файл на этот диск — фигвам. Что фар, что эксплорер сообщают «Параметр задан неверно».
Это ж что получается — если даже на этой машине таки залить в облако зашифрованные файлы, то при попытке их вытащить на другой машине клиент не сможет их записать на виртуальный диск?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор вариантов шифрования данных в облаках для Windows