Облачные хранилища: обещания и реальность
Облачные технологии нынче стали настолько модными, что своё собственное облако предлагает каждый более-менее серьёзный игрок на рынке околокомпьютерных технологий. Можно было бы назвать десяток-другой таких предложений, но не хочется тратить время на вспоминание и перечисление их - вы и наверняка уже и сами в них запутались. Причём каждый провайдер представляет своё облако как нечто, что кардинально изменит Вашу жизнь к лучшему. В результате не только обычный человек, далёкий от подобных вещей, но даже и продвинутый компьютерщик вроде меня теряется: кому же отдать предпочтение, на изучение чьего предложения потратить время и деньги, которых всегда так не хватает?
В связи c этим считаю своим долгом поделиться собственным печальным опытом попыток воспользоваться обещанным раем и сделанными в процессе этого выводами.
Итак, давайте для начала разберёмся, для чего на самом деле нужно собственное облако, и каким требованиям оно должно отвечать, чтобы в итоге оно приносило пользу, а не головную боль на фоне запудренных рекламой мозгов. Излагать буду исходя из собственного видения предметной области и из собственных потребностей. Не претендую на истину в последней инстанции, поскольку у каждого свои привычки и способы использования облаков, но считаю, что эта моя статья всё же должна оказаться кому-то весьма полезной.
Облако предназначено:
Продвинутые провайдеры предлагают помимо доступа к облаку через web-интерфейс собственное приложение для компьютера, которое синхронизирует содержимое облака с заранее заданной папкой, расположенной на одном из локальных дисков компьютера. Тут возникает следующая проблема: в облаке Вам хочется сохранить много всего разнородного и расположенного на домашнем компьютере в разных местах, например документы из папки D:\Документы по работе\ и ваши семейные фотографии из папки E:\Мой фотоархив\. И как быть, ведь облачное ПО такой возможности не предоставляет?! Сваливать и то и другое в оду папку а-ля D:\Облако такое-то\ у Вас нет ни желания, ни возможности, поскольку, как минимум, ёмкости диска D: недостаточно для хранения фотографий, а рабочим документам нечего делать рядом с семейным архивом на диске E:. И уж тем более Вам не хотелось бы, чтобы семейные фотографии автоматом попытались загрузиться на маленький диск Вашего рабочего компа и за полдня съели месячный лимит интернет-трафика компании.
Тут разработчики соответствующего облачного приложения предлагают Вам отметить галочками папки, подлежащие синхронизации, и снять галочки с папок, не подлежащих таковой. Но при этом папки со снятыми галочками удаляются с локального компьютера, а выгрузка в облако ещё не успела завершиться! Упс, Вы потеряли размещённые в них файлы!
Предположим, Вы не стали убирать описанные галки дома, но твёрдо запомнили, что нужно будет убрать их на рабочем компе, приехали на следующий день на работу, включили комп, тут Вам позвонили, и пока Вы разруливаете срочные задачи, добавленная вчера дома в облако папка тем временем уже полным ходом грузится на Ваш комп без Вашего ведома. Коллеги в бешенстве, поскольку интернет у них висит, работа компании парализована, а через час взбешённый сисадмин вопрошает, какого хрена Вы загрузили на рабочий комп энное количество гигабайт личных фоток.
Хорошо, допустим, Вы не загружали фотографии в облако, а решили загрузить в него с рабочего компа только файлы, имеющие отношение к какому-то проекту, над которым непременно нужно поработать дома. Не доверяя интернету (мало ли что, Равшат с Джамшутом, делающие ремонт у соседей, кабель перерубят, или провайдер отключит доступ за неуплату, или ещё что), Вы сделали копию ещё и на флэшку. По дороге домой вспомнили, что нужно внести архиважные изменения в уже подготовленный материал, отредактировали его на флэшке, затем, приехав домой, включили компьютер. Пока раздевались и умывались, облачный диск синхронизировал новую облачную папку с локальной. Вспомнив, что Вы отредактировали файлы на флэшке, Вы синхронизируете её Total Commander-ом с содержимым той же папки на локальном диске, открываете отредактированный час назад отчёт и теряете дар речи: внесённых изменений нет! А произошло это потому, что все файлы в синхронизированной по включении Вами домашнего компьютера облачным диском папке непонятно на каком основании получили в качестве даты и времени последнего редактирования текущую дату и время, которые оказались свежее, чем у отредактированных Вами файлов на флэшке!!!
Вы скажете "Но я не собираюсь пользоваться облаком на рабочем компьютере, у меня его вообще нет! Я только хочу создать резервную копию своих фоток по указанному Вами правилу 3-2-1!" ОК, тогда разберём ситуацию сугубо личного использования.
Допустим, у Вас на домашнем компе 50 тысяч фотографий и коротких видеороликов, занимающих полтерабайта – вся Ваша жизнь. Если синхронизировать их с резервной копией на втором HDD, то только опрос локальных файловых систем этих дисков занимает полминуты. Теперь представим, что вам таки удалось выгрузить полтерабайта в облако. Кстати, какая у Вас там скорость интернета на выгрузку? Предположим, что мегабит 30 в секунду, как у меня – уже только на первоначальный upload в облако уйдёт ощутимая часть Вашей оставшейся жизни. Теперь вспомним, что для синхронизации файлов (определения, какие фото были добавлены/отредактированы) компьютеру придётся опросить список из 50 тысяч фотографий, расположенный теперь не только на локальном диске, но и в интернете. Во-первых, этот процесс выполняется в десятки раз медленнее, чем на локальных дисках, во-вторых, для того, чтобы он мог выполниться в принципе, необходимо, чтобы облачная папка была доступна для программы-синхронизатора. А для этого эта папка должна быть не web-папкой, как у говнооблаков, а локальной, соответственно, большая часть облачных предложений отпадает сама собой. Но и локальной она быть не может по причине, рассмотренной несколькими абзацами выше!
Как я уже говорил, правильный облачный диск должен обеспечивать возможность работать с ним как с буквой локального диска, причём не виртуального, а именно жёсткого, поскольку программы синхронизации (в частности, FreeFileSync) при настройке часто просто не видят буквы виртуальных дисков. Но такую возможность ещё ни один из известных мне cloud-провайдеров не предоставил!
У Яндекс.Диска есть теоретическая возможность назначать букву локального диска диску облачному посредством использования якобы современного протокола WebDAV. Однако при попытке воспользоваться заявленным функционалом мы получаем:
У Облака Mail.ru нет и того – вся работа строится на единственной локальной папке, назначенной для синхронизации с облаком – причины невозможности полноценного использования облака при таком подходе опять же описаны выше. Отсюда возникает резонный вопрос: какого хрена завлекать пользователей сногсшибательными объёмами бесплатного облака (100 ГБ или, например, 1 ТБ в ASUS WEB Storage каждому купившему ноутбук ASUS), если воспользоваться этими объёмами на самом деле нереально?
Ещё один пример попытки воспользоваться облаками. На этот раз для сохранения третьей резервной копии согласно правилу "3-2-1". Копированию подлежат резервные копии рабочих папок файлового сервера, образы настроенных серверов, образы критически важных для бизнеса компьютеров, либо – что ближе народу – многогигабайтный файл шифрованного диска TrueCrypt с личной информацией. Создаём в Яндекс.Диске новую папку с именем, к примеру, "Несинхронизируемое", снимаем с неё галку синхронизации на домашнем компе, открываем её через браузер и невыносимо долго загружаем в неё файл размером, к примеру, 8 ГБ. Когда терпение кончилось, давно уже пора спать, а комп выключить всё никак нельзя, выгрузка, наконец, заканчивается неприметным сообщением "Произошла ошибка". Вы в бешенстве по двум причинам: во-первых, потеряно время, во-вторых, теперь неясно, можно ли считать выгруженный с ошибкой файл неповреждённым. Проверить целостность файла на стороне сервера – например, подсчётом контрольной суммы – возможность не предусмотрена. Загружать 8 гигов обратно, чтобы выполнить побитовое сравнение с оригиналом? На это опять нужно время, трафик, свободное место на локальных дисках и нервы. А если к тому времени исходный локальный файл был изменён? И что же, каждый раз заниматься такой фигнёй вместо того, чтобы просто настроить автоматическое фоновое резервное копирование в облако каталога с бэкапами любого размера и забыть о его обслуживании?
Про проект "ASUS WEB Storage", подаривший мне 1 терабайт места в облаке, я уже просто не в силах писать - ASUS делает хорошее "железо", но программистов, которых эта компания нанимает для написания ПО для своих облачных технологий, нужно было убивать противозачаточными таблетками ещё до их рождения.
Проблемы мог бы решить доступ к облачному хранилищу по протоколу SFTP, современная версия которого умеет (в отличии от WebDAV и древнего FTP) сохранять при копировании дату/время последней модификации файлов, но разработчики облачных хранилищ не хотят реализовывать такой доступ – в приоритете у них другие задачи и масса проблем, которые нужно как-то решить: например, обеспечить одновременный доступ к облаку с разных устройств и разными способами (в то время как приложение Яндекс.Диск синхронизирует папки, вы зашли в облако через браузер и стали менять его содержимое).
Ещё одна проблема. Вы не можете быть уверены, что файлы, хранимые в облаке, доступны только Вам. Соответственно, хранить в нём конфиденциальную информацию нельзя. Эту проблему могла бы решить замечательная программа StableBit CloudDrive, но она не поддерживает дешёвые/бесплатные отечественные Яндекс.Диск и Облако Mail.ru.
Обращал внимание разработчиков Яндекс.Диска и Облака Mail.ru на часть вышеописанных проблем – те поблагодарили за предоставленную информацию, но дали понять, что у них и без меня огромный список потребных доработок своего программного обеспечения, а посему исправления тупиковой ситуации в сфере облачного хранения информации обещать не могут.
P. S.
16.05.17 ещё раз попытался создать в Яндекс.Диске резервную копию одной из своих папок. Подключил сетевой диск средствами Windows – в Проводнике появился диск с жутким названием. Начал копирование на него – скорость ноль целых хрен десятых Мб/с. Отключил диск, подключился к облаку через WebDAV-плагин Total Commander-а – не открываются папки с кириллическими именами. По наитию выставил в настройках подключения галку "Send/Recieve accents in URLs as UFT-8 Unicode" – стали открываться – ай да прогресс! Ну-ну. Снова запустил копирование – "скорость" (назвать ЭТО скоростью без кавычек не поворачивается язык) прыгает в пределах 0-300 Кб/с, копирование закончится после моей смерти. Остановил, сравнил то, что успело скопироваться – как и рассказывал ранее, не обнаружил ни одного одинакового файла, все скопированные в облако приобрели в качестве даты и времени последнего изменения дату и время копирования. Выругался и в очередной раз забросил попытки воспользоваться теми 50-ю гигабайтами, что мне предоставил Яндекс.
В связи c этим считаю своим долгом поделиться собственным печальным опытом попыток воспользоваться обещанным раем и сделанными в процессе этого выводами.
Итак, давайте для начала разберёмся, для чего на самом деле нужно собственное облако, и каким требованиям оно должно отвечать, чтобы в итоге оно приносило пользу, а не головную боль на фоне запудренных рекламой мозгов. Излагать буду исходя из собственного видения предметной области и из собственных потребностей. Не претендую на истину в последней инстанции, поскольку у каждого свои привычки и способы использования облаков, но считаю, что эта моя статья всё же должна оказаться кому-то весьма полезной.
Облако предназначено:
- для бесшовного доступа к информации, хранимой в подавляющем большинстве случаев в виде файлов, с устройств, использующихся в повседневной жизни дома, на работе, в дороге, в гостях, при визите к клиентам;
- для повышения безопасности хранения резервных копий невосстановимой информации - соблюдения правила 3-2-1, которое гласит, что для обеспечения надежного хранения данных необходимо иметь как минимум ТРИ резервные копии, которые должны быть сохранены в ДВУХ различных физических форматах хранения, причем ОДНА из копий должна быть передана на хранение на другую территорию.
Для этого доступ к облаку должен осуществляться такими же средствами операционной системы, как и к обычному локальному жёсткому диску. А вот как раз с этим у представленных сегодня на рынке облаков огромные проблемы.
Как выглядит нынче доступ к облакам? Разработчики помпезно заявляют о том, что если вы воспользуетесь их продуктом, то вся информация отныне будет у вас на кончиках пальцев. Но простите, о каких кончиках может идти речь, если для доступа к нужному файлу предлагается:
- Открыть браузер.
- Вставить в адресную строку хитрую ссылку на сайт с облаком - которую Вы, конечно, же не помните.
- Ввести логин и пароль - которые вы, скорее всего, не помните тоже, поскольку нынче приходится использовать сотни различных логинов и паролей, а использование одного и того же пароля в разных местах - грубейшее нарушение собственной безопасности.
- Найти и открыть нужную папку, найти и скачать куда-то на локальный диск нужный файл, а отредактировав его, не забыть выгрузить его обратно. А если Вам необходимо поработать с сотней файлов? Или если Вы не помните (и не хотите помнить!), какие именно файлы Вы редактировали? А если вам нужно срочно отбыть из офиса домой или к клиенту или из дома в офис, и времени на поиск изменённых файлов не остаётся?
Продвинутые провайдеры предлагают помимо доступа к облаку через web-интерфейс собственное приложение для компьютера, которое синхронизирует содержимое облака с заранее заданной папкой, расположенной на одном из локальных дисков компьютера. Тут возникает следующая проблема: в облаке Вам хочется сохранить много всего разнородного и расположенного на домашнем компьютере в разных местах, например документы из папки D:\Документы по работе\ и ваши семейные фотографии из папки E:\Мой фотоархив\. И как быть, ведь облачное ПО такой возможности не предоставляет?! Сваливать и то и другое в оду папку а-ля D:\Облако такое-то\ у Вас нет ни желания, ни возможности, поскольку, как минимум, ёмкости диска D: недостаточно для хранения фотографий, а рабочим документам нечего делать рядом с семейным архивом на диске E:. И уж тем более Вам не хотелось бы, чтобы семейные фотографии автоматом попытались загрузиться на маленький диск Вашего рабочего компа и за полдня съели месячный лимит интернет-трафика компании.
Тут разработчики соответствующего облачного приложения предлагают Вам отметить галочками папки, подлежащие синхронизации, и снять галочки с папок, не подлежащих таковой. Но при этом папки со снятыми галочками удаляются с локального компьютера, а выгрузка в облако ещё не успела завершиться! Упс, Вы потеряли размещённые в них файлы!
Предположим, Вы не стали убирать описанные галки дома, но твёрдо запомнили, что нужно будет убрать их на рабочем компе, приехали на следующий день на работу, включили комп, тут Вам позвонили, и пока Вы разруливаете срочные задачи, добавленная вчера дома в облако папка тем временем уже полным ходом грузится на Ваш комп без Вашего ведома. Коллеги в бешенстве, поскольку интернет у них висит, работа компании парализована, а через час взбешённый сисадмин вопрошает, какого хрена Вы загрузили на рабочий комп энное количество гигабайт личных фоток.
Хорошо, допустим, Вы не загружали фотографии в облако, а решили загрузить в него с рабочего компа только файлы, имеющие отношение к какому-то проекту, над которым непременно нужно поработать дома. Не доверяя интернету (мало ли что, Равшат с Джамшутом, делающие ремонт у соседей, кабель перерубят, или провайдер отключит доступ за неуплату, или ещё что), Вы сделали копию ещё и на флэшку. По дороге домой вспомнили, что нужно внести архиважные изменения в уже подготовленный материал, отредактировали его на флэшке, затем, приехав домой, включили компьютер. Пока раздевались и умывались, облачный диск синхронизировал новую облачную папку с локальной. Вспомнив, что Вы отредактировали файлы на флэшке, Вы синхронизируете её Total Commander-ом с содержимым той же папки на локальном диске, открываете отредактированный час назад отчёт и теряете дар речи: внесённых изменений нет! А произошло это потому, что все файлы в синхронизированной по включении Вами домашнего компьютера облачным диском папке непонятно на каком основании получили в качестве даты и времени последнего редактирования текущую дату и время, которые оказались свежее, чем у отредактированных Вами файлов на флэшке!!!
Вы скажете "Но я не собираюсь пользоваться облаком на рабочем компьютере, у меня его вообще нет! Я только хочу создать резервную копию своих фоток по указанному Вами правилу 3-2-1!" ОК, тогда разберём ситуацию сугубо личного использования.
Допустим, у Вас на домашнем компе 50 тысяч фотографий и коротких видеороликов, занимающих полтерабайта – вся Ваша жизнь. Если синхронизировать их с резервной копией на втором HDD, то только опрос локальных файловых систем этих дисков занимает полминуты. Теперь представим, что вам таки удалось выгрузить полтерабайта в облако. Кстати, какая у Вас там скорость интернета на выгрузку? Предположим, что мегабит 30 в секунду, как у меня – уже только на первоначальный upload в облако уйдёт ощутимая часть Вашей оставшейся жизни. Теперь вспомним, что для синхронизации файлов (определения, какие фото были добавлены/отредактированы) компьютеру придётся опросить список из 50 тысяч фотографий, расположенный теперь не только на локальном диске, но и в интернете. Во-первых, этот процесс выполняется в десятки раз медленнее, чем на локальных дисках, во-вторых, для того, чтобы он мог выполниться в принципе, необходимо, чтобы облачная папка была доступна для программы-синхронизатора. А для этого эта папка должна быть не web-папкой, как у говнооблаков, а локальной, соответственно, большая часть облачных предложений отпадает сама собой. Но и локальной она быть не может по причине, рассмотренной несколькими абзацами выше!
Как я уже говорил, правильный облачный диск должен обеспечивать возможность работать с ним как с буквой локального диска, причём не виртуального, а именно жёсткого, поскольку программы синхронизации (в частности, FreeFileSync) при настройке часто просто не видят буквы виртуальных дисков. Но такую возможность ещё ни один из известных мне cloud-провайдеров не предоставил!
У Яндекс.Диска есть теоретическая возможность назначать букву локального диска диску облачному посредством использования якобы современного протокола WebDAV. Однако при попытке воспользоваться заявленным функционалом мы получаем:
- запрос логина и пароля при доступе к облачному диску после каждой перезагрузки компьютера не смотря на выставленный флаг "Запомнить логин и пароль";
- крайне нестабильный доступ к сетевой WebDAV-папке - она то доступна, то нет (без объяснения причин);
- программы-синхронизаторы, которыми я пользовался, в частности FreeFileSync, не дают настроить синхронизацию с сетевым диском;
- отключить WebDAV-папку, доступ к которой отсутствует, или которая перестала существовать, невозможно – она продолжает оставаться в Проводнике, конкретно подвешивая компьютер при обращении к ней. Создал я как-то опрометчиво такое WebDAV-подключение на сервере – проклял всё на свете! Утомился потом из реестра следы такого подключения вычищать!
У Облака Mail.ru нет и того – вся работа строится на единственной локальной папке, назначенной для синхронизации с облаком – причины невозможности полноценного использования облака при таком подходе опять же описаны выше. Отсюда возникает резонный вопрос: какого хрена завлекать пользователей сногсшибательными объёмами бесплатного облака (100 ГБ или, например, 1 ТБ в ASUS WEB Storage каждому купившему ноутбук ASUS), если воспользоваться этими объёмами на самом деле нереально?
Ещё один пример попытки воспользоваться облаками. На этот раз для сохранения третьей резервной копии согласно правилу "3-2-1". Копированию подлежат резервные копии рабочих папок файлового сервера, образы настроенных серверов, образы критически важных для бизнеса компьютеров, либо – что ближе народу – многогигабайтный файл шифрованного диска TrueCrypt с личной информацией. Создаём в Яндекс.Диске новую папку с именем, к примеру, "Несинхронизируемое", снимаем с неё галку синхронизации на домашнем компе, открываем её через браузер и невыносимо долго загружаем в неё файл размером, к примеру, 8 ГБ. Когда терпение кончилось, давно уже пора спать, а комп выключить всё никак нельзя, выгрузка, наконец, заканчивается неприметным сообщением "Произошла ошибка". Вы в бешенстве по двум причинам: во-первых, потеряно время, во-вторых, теперь неясно, можно ли считать выгруженный с ошибкой файл неповреждённым. Проверить целостность файла на стороне сервера – например, подсчётом контрольной суммы – возможность не предусмотрена. Загружать 8 гигов обратно, чтобы выполнить побитовое сравнение с оригиналом? На это опять нужно время, трафик, свободное место на локальных дисках и нервы. А если к тому времени исходный локальный файл был изменён? И что же, каждый раз заниматься такой фигнёй вместо того, чтобы просто настроить автоматическое фоновое резервное копирование в облако каталога с бэкапами любого размера и забыть о его обслуживании?
Про проект "ASUS WEB Storage", подаривший мне 1 терабайт места в облаке, я уже просто не в силах писать - ASUS делает хорошее "железо", но программистов, которых эта компания нанимает для написания ПО для своих облачных технологий, нужно было убивать противозачаточными таблетками ещё до их рождения.
Проблемы мог бы решить доступ к облачному хранилищу по протоколу SFTP, современная версия которого умеет (в отличии от WebDAV и древнего FTP) сохранять при копировании дату/время последней модификации файлов, но разработчики облачных хранилищ не хотят реализовывать такой доступ – в приоритете у них другие задачи и масса проблем, которые нужно как-то решить: например, обеспечить одновременный доступ к облаку с разных устройств и разными способами (в то время как приложение Яндекс.Диск синхронизирует папки, вы зашли в облако через браузер и стали менять его содержимое).
Ещё одна проблема. Вы не можете быть уверены, что файлы, хранимые в облаке, доступны только Вам. Соответственно, хранить в нём конфиденциальную информацию нельзя. Эту проблему могла бы решить замечательная программа StableBit CloudDrive, но она не поддерживает дешёвые/бесплатные отечественные Яндекс.Диск и Облако Mail.ru.
P. S.
16.05.17 ещё раз попытался создать в Яндекс.Диске резервную копию одной из своих папок. Подключил сетевой диск средствами Windows – в Проводнике появился диск с жутким названием. Начал копирование на него – скорость ноль целых хрен десятых Мб/с. Отключил диск, подключился к облаку через WebDAV-плагин Total Commander-а – не открываются папки с кириллическими именами. По наитию выставил в настройках подключения галку "Send/Recieve accents in URLs as UFT-8 Unicode" – стали открываться – ай да прогресс! Ну-ну. Снова запустил копирование – "скорость" (назвать ЭТО скоростью без кавычек не поворачивается язык) прыгает в пределах 0-300 Кб/с, копирование закончится после моей смерти. Остановил, сравнил то, что успело скопироваться – как и рассказывал ранее, не обнаружил ни одного одинакового файла, все скопированные в облако приобрели в качестве даты и времени последнего изменения дату и время копирования. Выругался и в очередной раз забросил попытки воспользоваться теми 50-ю гигабайтами, что мне предоставил Яндекс.
Комментарии
Отправить комментарий