Acronis Backup Cloud позволяет делать резервные копии как в облако, так и в локальные хранилища (будь то внешний или внутренний жесткий диск или сетевая папка). Восстановиться можно не только с помощью веб интерфейса, но и с помощью загрузочной медии.
Скачиваете .iso образ загрузочного диска, записываете на флешку или CD, храните в надёжном месте. Как только с компьютером или сервером произошла беда, можете загрузить его с этой медии и восстановить всю систему (при чём даже на другое железо) — хоть из облака, хоть с локальной сетевой папки или внешнего жесткого диска.
Для пущей надёжности можно также делать стэйджинг — настраивать бэкап план так, чтобы сначала бэкап шёл в локальное хранилище, а от туда реплицировался в облако. Таким образом у вас есть 2 копии ваших данных — локальная и облачная.
Шифруется сам архив — т.е. агент, выполняющий бэкап шифрует данные. Т.о. для получения доступа к контенту зашифрованного архива, нужно ввести свой пароль. В решении Acronis Backup Russia можно выбрать опцию шифрования в настройках резервного копирования. В других продуктах Акронис эта опция тоже присутствует.
Дело в том, что описанная система пока не решает задачи каталогизации и поиска данных (это как раз будет следующий этап в развитии данной системы, как и дедупликация, георепликация, поддержка различных протоколов доступа, тиеринг данных). И конечно, есть куча нюансов, которые в данной статье не описаны — статья рассказывает, о способе решения основных проблем первого плана (отказоустойчивость, масштабируемость, контроль, стоимость хранения). Более детальное описание нюансов работы с архивными данными — это тема для отдельной статью, которая, я уверен, вскоре появится.
Не соглашусь. Никаких «сферических коней в вакууме тут нет». Во-первых, решение в основном используется не для хранения домашних фоток (хотя и для этого тоже), а для хранения бэкапов корпоративных пользователей в нескольких датацентрах. Это петабайты информации — финансовые данные, медицинская информация, бэкапы серверов баз данных и т.д. Те, кто заботится о секьюрности своих данных, хранимых в облаке, шифрует (encrypt) свои бэкапы. Алгоритмы шифрования — AES 256 или ГОСТ 28147-89 для российских предприятий государственного значения.
Ну а насчёт того, как организовать хранилище видеоданных — всё очень просто, видео данные с точки зрения системы хранения — это всего лишь файлы (такие же как файлы бэкапов или любые другие файлы), поэтому хранение видеоданных от хранения других типов данных ничем не отличается.
По-моему, связь очевидна — в статье описан пример проблемы (причём довольно популярной), основные критерии важные для решения подобного рода проблем, и, собственно, пример решения данной проблемы, удовлетворяющий критериям.
Слово используется в обоих смыслах. В отношении олимпиады — это «исследование вопроса» (вернее даже предлагаемое решение подобного рода проблем), а в отношении длительного хранения петабайт данных в собственном облачном хранилище — это, безусловно, опыт
На самом деле, в «нормальной схеме избыточности» данные бьются на 5 фрагментов и к ним прибавляется 2 фрагмента, обеспечивающие избыточность. То, что системе необходимо не 7 серверов, а 9 — это лишь особенность текущего алгоритма, который в данный момент оптимизируется и в следующем апдейте продукта для того, чтобы иметь возможность потерять 2 сервера, понадобится всего 7 серверов хранения.
А ещё он с помощью нейронной сети (например, синхронизируясь с соц сетями в телефоне) может вычислять, что на 8 и на 16 этажах живут разнополые одинокие люди примерно одного возраста, которые спускаются утром или поднимаются вечером примерно в одно и то же время, и на базе собранной статистики будет предсказывать возможное время встречи в лифте со второй половинкой. Получится лифт знакомств. Эмиль, есть ещё время одуматься и взяться за идею лифта — заодно решишь и проблему «Близкий человек», которая у тебя в топе :))))
Сажусь я на девятом, еду на двенадцатый. Если нажал кнопку 12, лифт не должен везти меня по привычке на 1ый. Т.е. нажатая кнопка должна перекрывать сигнал с мобильника.
Да, только иногда я езжу к соседу на другой этаж, иногда я без мобильника, который помогает меня идентифицировать. Я к тому, что о Шотландцах и немых тоже стоит не забыть (но ни в коем разе не за то, чтоб на них ориентироваться) :)
Привет! Голосовое управление решает проблему занятых рук (как и, например, относительно новая фишка в автомобилях — автоматическое открытие багажника путём подноса ноги под сенсор снизу бампера).
Если бы у меня в лифте было голосовое управление, я бы обрадовался — вечно груженый поднимаюсь, а до верхней кнопки тянуться неудобно. Ы данном примере просто в требованиях не учли шотландцев и немых и глухих :)
50% успешности предприятия — реализация отобранной идеи — полнота и непротиворечивость реализованных требований, юзабилити, качество (дефекты). Вот пример решения проблемы с нажатием кнопки лифта: www.youtube.com/watch?v=5FFRoYhTJQQ :)
Скачиваете .iso образ загрузочного диска, записываете на флешку или CD, храните в надёжном месте. Как только с компьютером или сервером произошла беда, можете загрузить его с этой медии и восстановить всю систему (при чём даже на другое железо) — хоть из облака, хоть с локальной сетевой папки или внешнего жесткого диска.
Для пущей надёжности можно также делать стэйджинг — настраивать бэкап план так, чтобы сначала бэкап шёл в локальное хранилище, а от туда реплицировался в облако. Таким образом у вас есть 2 копии ваших данных — локальная и облачная.
Ну а насчёт того, как организовать хранилище видеоданных — всё очень просто, видео данные с точки зрения системы хранения — это всего лишь файлы (такие же как файлы бэкапов или любые другие файлы), поэтому хранение видеоданных от хранения других типов данных ничем не отличается.
Если бы у меня в лифте было голосовое управление, я бы обрадовался — вечно груженый поднимаюсь, а до верхней кнопки тянуться неудобно. Ы данном примере просто в требованиях не учли шотландцев и немых и глухих :)