О Чем Стоит Задуматься, Сохраняя Свои Данные в Облаке. Часть 2

[@maxvodo]

Получается, результатом развития данной идеи должен явиться облачный провайдер, узлами облачного хранилища данных которого должны явиться аккаунты (хранилища данных) текущих облачных провайдеров. И чем больше уровней — тем надежнее получается, но… Салат: огурцы, помидоры, Салат:… ну вы понимаете.

[@mechanical_mind]

Речь идет о программе кототорая работает на стороне клиента

[@rPman]

Это должен быть не облачный сервис, а клиентское приложение… и самое сложное в нем — модули унифицированной работы с облачными сервисами хранения данных… и еще, далеко не все из них предоставляют API.

[@silvansky]

Как раз в соседней ветке про Я.Диск заходила речь о создании программы-аггрегатора для облачных хранилищ данных. Если её объединить с идеями из данного топика, то вышло бы ещё и более безопасное хранилище.

[@mechanical_mind]

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

[@igudym]

Напомнило разговоры 15-летней давности «зеркало vs райд»
Очередной виток спирали.

[@mechanical_mind]

Да, есть такое) Старые подходы хорошо использовать в новом контексте

[@sova]

Я сознательно использую английский термин erasure codes в статье – я не нашла этого термина на русском языке. Это не коды корректирующие ошибки никоем образом.

почему?

[@sova]

При восстановлении в любом из случаев – используется ли репликация или erasure codes, размер данных, которые требуется передать будет равен размеру изначального файла, те L.

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