клауд бэкап что это
Резервное копирование cloud-to-cloud: что это такое и зачем оно нужно
Входит и выходит, замечательно выходит.
Приложения, которые работают в облаке, защищены только в определенной степени. Для полной защиты данных, которые генерируются облачными приложениями, вам потребуется резервное копирование в другое облако (cloud-to-cloud backup).
По данным Forrester, расходы на услуги публичного облака вырастут к 2020 году до 236 млрд. долларов США. Это тенденция, усиливается увеличением количества приложений, размещенных в облаках.
Потреблять облачные услуги иногда настолько легко, что клиенты и ИТ-команды руководствуются принципом «работает – не трогай» и счастливы положиться в вопросах защиты данных и резервного копирования на провайдера.
Итак, почему мы видим необходимость в создании cloud-to-cloud копии?
Риски информационной безопасности в облаке
Перемещение приложений, рабочих нагрузок или ИТ-инфраструктуры в облако создает как дополнительные преимущества, так и риски. Миграция в облако означает передачу большого количества возможностей по организации хранения и защите данных третьей стороне.
Облачный сервис будет или должен иметь несколько центров обработки данных и несколько избыточных хранилищ данных для обеспечения непрерывности бизнеса и возможности восстановления данных. Он также должен обеспечивать безопасность данных на enterprise-уровне.
Но в работе облачных сервисов также возможны сбои. Они относительно редки, но ИТ-директора, которые упустили важность вопроса резервного копирования облачных данных, ставят под угрозу информационную безопасность в их организации.
Для предприятий, использующих облако, вопрос заключается не в том, не случится ли сбой в работе облачного сервиса, а в том, как и насколько успешно бизнес справится с проблемами в случае этих аварий. Хотя облачные сервисы могут обеспечить высокую степень отказоустойчивости, этого будет недостаточно для удовлетворения потребностей резервного копирования любых организаций.
Облачный vs on-premise уровень обслуживания
Облачные службы делают все возможное, чтобы поддерживать работу сервисов. Конечно, ИТ-директора должны проверить детали соглашений об уровне обслуживания (SLA). Некоторые публичные облака вовсе не гарантируют определенную доступность или время восстановления, а предлагают со своей стороны только действия «на базе наилучших усилий».
Когда дело доходит до самих данных, предприятия подвергаются еще большему риску. Провайдеры программного обеспечения как услуги (SaaS) обычно берут на себя ответственность за доступность инфраструктуры, но потеря данных является исключительно ответственностью клиента.
Это может привести к тому, что заказчики в трудную минуту останутся один на один со сложным, дорогостоящим и трудоемким восстановлением данных после сбоя.
Также провайдер облачных услуг не несет ответственности за случайное удаление данных. Человеческая ошибка — от случайной перезаписи одного поля в клиентской базе данных до очистки всего набора данных — это проблема клиента. По оценкам Backupify, провайдера резервного копирования на основе облачных технологий, одна из трех компаний теряет данные при использовании SaaS. Человеческая ошибка является наиболее распространенной причиной.
Облачные провайдеры исходя из условий договора могут также удалять данные клиентов, чья подписка на сервис закончилась. Например, Microsoft стирает все данные пользователя через 30 дней после прекращения его подписки. Если у бизнеса нет надежного плана по сбору файлов сотрудников, когда они покидают организацию, жизненно важные данные могут быть потеряны навсегда.
Опции резервного копирования в облако
В сценариях с малым масштабом пользователи могут копировать файлы, например, из Office 365 и G Suite, на локальный том или, если это разрешено правилами безопасности, на внешний диск. Но это ручной процесс, который может быть ненадежным и будет сложным для масштабирования.
Для больших файлов и более крупных приложений это редко бывает практичным. Предприятия, использующие облако по модели «инфраструктура как услуга» (IaaS) или SaaS, могут использовать процедурные интерфейсы прикладных систем (API) или стороннее программное обеспечение для резервного копирования на локальные серверы, в сетевое хранилище (NAS) или в собственный центр обработки данных.
Однако, резервное копирование данных из облачных сервисов в локальное хранилище — шаг назад. Вместо того, чтобы использовать облако, он заставляет компании сохранять или наращивать локальную инфраструктуру, увеличивая затраты и ограничивая гибкость.
Предприятия, которые создают резервные копии SaaS-приложений, будут уверены в том, что у них есть копии своих данных, но они не смогут запустить SaaS-среду внутри компании. Это ограничивает полезность локальных резервных копий. В лучшем случае бизнес столкнется с длительным восстановлением или переходом на новую платформу.
Резервное копирование данных облачных сервисов в облако может быть наилучшим вариантом.
По данным Gartner, в настоящее время только одна из 10 компаний резервирует свои данные у IaaS-провайдера. Исследователи ожидают, что этот показатель удвоится к 2020 году, так как компании осознают важность резервного копирования, и все больше провайдеров предлагают подобные облачные услуги.
Преимущества резервного копирования Cloud-to-Cloud
Резервное копирование из облака в облако обещает дать бизнесу несколько преимуществ по сравнению с локальными резервными копиями и предложениями SaaS-провайдеров, включая более низкие затраты на инфраструктуру, более быстрое резервное копирование и восстановление, а также большую гибкость.
Как и сама вычислительная мощность облачной инфраструктуры, облачные резервные копии доступны в любом месте. Организации также могут использовать резервные копии для интеллектуального анализа данных и аналитики, не подвергая исходные данные риску.
Падающие облака
К сожалению, для лиц, принимающих решения в области ИТ, рынок резервного копирования «из облака в облако» является фрагментированным и относительно незрелым. Учитывая разнообразие предлагаемых облачных вычислительных сред, службы резервного копирования значительно различаются по возможностям.
Gartner отмечает, что за последние два года поставщики услуг резервного копирования улучшили поддержку облачных сервисов, сделав проще защиту IaaS-данных и резервное копирование SaaS приложений. Наиболее развитая область в последние годы — резервное копирование ИТ-инфраструктуры как услуга – облачные копии всех виртуальных машин.
Для резервного копирования частных облаков облачный шлюз являются опцией. Частные облака используют API облачных сервисов для обеспечения резервного копирования и восстановления данных. Поставщики также предоставляют виртуализированные приложения для резервного копирования и дедупликации, которые могут выполняться в облаке.
Рынок переходит от предоставления простого «дампа базы данных» к облачному хранилищу — к более сложному, управляемому сервису, предоставляемому по модели «оплата по мере использования».
Если ваши планы проваливаются, сами планируйте возможную неудачу
Однако есть подводные камни. Резервное копирование SaaS приложений, в частности, остается сложным.
Например, резервные копии собственных данных от Salesforce.com не являются точными копиями внутренних данных приложения. Это так называемое «одностороннее» резервное копирование, которое может пропускать метаданные, а информация может быть менее «богатой», чем исходные наборы данных. Они могут быть восстановлены обратно в SaaS-приложении, но данные сначала необходимо переформатировать и перезагрузить как новые наборы данных.
В случае со многими SaaS-приложениями, если исходная услуга недоступна, у клиентов не будет возможности использовать восстановленные данные.
Резервные копии приложений, размещенных по модели IaaS, по-настоящему редко независимы от платформы. «Существует достаточно много различий между форматами данных на основных платформах, чтобы сделать восстановление весомой задачей», — предупреждает аналитик Forrester Нэвин Чхабра.
Ограничения облачных резервных копий распространяются и на персональные приложения для повышения производительности. Некоторые приложения в Office 365, в частности, трудно бэкапить. Например, Sharepoint поддерживается только несколькими поставщиками услуг резервного копирования.
Что касается резервных копий корпоративных приложений, то они должны работать как на локальной инфраструктуре, так и в публичных или частных облаках. ИТ-команды должны иметь возможность восстанавливать свои данные у любого провайдера, поддерживающего приложение, на виртуальной машине, работающей в облаке, или в локальном дата-центре. Организации должны выполнять собственную проверку бэкапов и проводить их тестирование.
На правах рекламы
Cloud4Y предоставляет несколько вариантов услуги BACKUP AS A SERVICE и Облачное хранилище. Решение Cloud4Y backup предоставляет возможность облачного резервного копирования, обеспечивающего надежность хранения любого объема данных.
Ниже перечислены три варианта реализации услуги и ко всем перечисленным вариантам предоставляется бесплатный VPN с шифрованием через Интернет:
1. Услуга Backup as a Service на базе Veeam Backup позволяет получить необходимое дисковое пространство для хранения и восстановления резервных копий из хранилища. Дополнительно к этому мы можем оказывать гарантированное восстановление по заданному времени в режимах:
1. SLA «Базовый» 10-19/5
2. SLA «Приоритетный» 9-21/7
3. SLA «Критичный» 24/7
4. SLA «VIP» 24/7
2. При использовании Veeam Endpoint Protection бэкап делается в наш Veeam, а оплата происходит согласно табличке тарифов за предоставленное дисковое пространство.
3. Используя услугу IaaS, арендуется сервер (VM) для шары (Linux или Windows – зависит от предпочтений), арендатор самостоятельно поднимает и настраивает VM и делает там шару для складирования бэкапов, затем самостоятельно соединяет сервер (VM) в облаке с сервером бэкапа. Все ресурсы можно добавлять или изменять через VMware vCloud Director в режиме реального времени.
Cloud Backup от компании Acronis. Пошаговое руководство
Cloud Backup
Облачный сервис Cloud Backup от Acronis позволяет выполнять резервное копирование и восстановление физических и виртуальных серверов, файлов и баз данных с использованием локального или облачного хранилища.
Подключиться и протестировать сервис вы можете здесь. Ограничений на объем хранимых данных нет, тестовый период – до 30 дней.
Для управления используется простой и удобный веб-интерфейс. Приведем пошаговое руководство по работе с сервисом. Остановимся подробно на каждой из возможностей интерфейса.
Выбор типа устройства для резервного копирования
Процесс копирования поддерживается для различных типов устройств:
— рабочие станции (Windows, Mac)
— серверы (Windows, Linux)
— мобильные приложения (IOS, Android)
— хосты виртуализации (VMware ESXi, Hyper-V, Virtuozzo)
— приложения (Microsoft SQL сервер, Microsoft Exchange Server, Microsoft Active Directory, Office 365)
При первоначальной настройке, на первом шаге мы имеем возможность выбрать тип устройства:
Вид консоли резервного копирования
В консоли есть два представления: простое и табличное. Для переключения между ними используется значок в правом верхнем углу.
Простое представления используется для небольшого количества серверов.
Табличное представление включается автоматически, когда количество серверов превышает определенный порог.
В обоих представлениях доступен один и тот же набор функций и операций. Отличается только интерфейс.
Задание плана копирования
План резервного копирования —это набор правил, который определяет порядок защиты данных на каждой машине. Его можно применить одной или к нескольким машинам как сразу на этапе создания плана, так и позже.
Выбор данных для резервного копирования
В качестве данных для сохранения могут быть выбраны:
Резервное копирование на уровне файлов доступно только для физических серверов.
Копию состояния системы можно создавать на серверах/рабочих станциях с операционной системой Windows (начиная с Windows Vista для рабочих станций и начиная с Windows Server 2003 для серверов).
В сохраненную копию состояния системы включаются файлы перечисленных ниже компонентов.
Выбор места хранения
В разделе Место сохранения можно выбрать один из перечисленных ниже вариантов.
Облачное хранилище
Сохраненные базы данных будут храниться в облачном центре обработки данных.
Локальные папки
Сетевая папка
Расписание резервного копирования
Параметры расписания зависят от выбранного места хранения копий.
Облачное хранилище данных
По умолчанию копирование выполняется ежедневно с понедельника по пятницу. Можно установить любое время для запуска.
Чтобы сменить частоту создания копии баз данных, перетащите ползунок и задайте нужное расписание.
Локальная или сетевая папка
Можно выбрать одну из стандартных схем или создать собственную. Схема входит в состав плана копирования и содержит расписание и методы создания копий баз данных.
В разделе Схема резервного копирования можно выбрать один из перечисленных ниже вариантов.
— [Только копии на уровне дисков] Всегда инкрементные (один файл)
Для копий используется новый формат в виде одного файла.
Каждый раз создаются полные резервные копии.
— Полное каждую неделю, инкрементное каждый день
Раз в неделю создается полная версия. Остальные копии будут инкрементными. День создания полной резервной копии зависит от параметра «Еженедельное резервное копирование» (чтобы просмотреть установленный параметр, щелкните значок шестерни и выберите пункты «Параметры резервного копирования» > «Еженедельное копирование»).
Можно задать расписания для полного, дифференциальных и инкрементных копий.
Дифференциальное копирование не выполняется для данных Microsoft SQL, Microsoft Exchange и файлов операционной системы.
Дополнительные параметры для расписания
Для каждого места назначения можно выполнить следующие действия:
Отключить расписание. Когда расписание отключено, правила хранения не применяются за исключением случая, при котором копирование запущено вручную.
Правила хранения
Доступны следующие варианты хранения:
Репликация данных
Если включить репликацию копий, то каждая из них сохраняется в дублирующее хранилище сразу же после создания. Если репликации ранее созданных баз не выполнялась (например, было утрачено сетевое подключение), то программа также выполнит репликацию всех копий, которые появились после последней успешной репликации.
Реплицированные резервные копии не зависят от оставшихся в исходном хранилище, и наоборот. Есть возможность восстановить данные из любой версии без доступа к другим хранилищам.
Поддерживаемые расположения
Можно выполнить репликацию из любого указанного ниже расположения:
Шифрование данных
Рекомендуем включать шифрование для всех резервных копий, которые хранятся в облачном хранилище данных.
Доступны следующие алгоритмы шифрования:
— AES 128 — с использованием алгоритма AES и 128-разрядного ключа.
— AES 192 — с использованием алгоритма AES и 192-разрядного ключа.
— AES 256 — с использованием алгоритма AES и 256-разрядного ключа.
Порядок шифрования
Ключ шифруется с помощью алгоритма AES-256 с использованием хэш пароля SHA-256. Сам пароль не сохраняется на диске или в копиях баз данных. В целях проверки используется хэш пароль. Такая двухуровневая схема защиты позволяет обезопасить данные от несанкционированного доступа, но восстановление утраченного пароля невозможно.
Запуск резервного копирования вручную
Предусмотрена возможность запуска вручную:
Прогресс выполнения задачи отображается в столбце «Состояние для выбранной машины».
Параметры резервного копирования
— CBT (Changed Block Tracking),
— уведомления по электронной почте,
— быстрое инкрементное или дифференциальное копирование,
— моментальные снимки на уровне файлов,
— средства безопасности на уровне файлов,
— создание моментальных снимков LVM,
— многотомный моментальный снимок,
— команды до и после процедуры,
— команды до и после захвата данных,
— копирование по секторам,
— обработка ошибок задания,
— служба теневого копирования томов (VSS),
— служба теневого копирования томов (VSS) для виртуальных машин,
— журнал событий Windows.
Хотите проверить работу сервиса Acronis Backup Cloud в действии? Заказать бесплатный тест и протестировать сервис Acronis Backup Cloud вы можете здесь.
Бэкапьтесь в облако, друзья
Сегодня мне хотелось бы еще раз пройтись по набившему оскомину резервному копированию в облако. Рассуждать на тему хорошо это или плохо, я не буду, но хочу поделиться примерами реализаций решений для этого самого облачного резервного копирования — от готового ПО до костылей на велосипедах.
Еще не бэкапитесь в облако или хотите почитать про варианты решений? Прошу под кат.
3-2-1, поехали
Считается, что история правила бэкапа «3-2-1» начинается с Питера Крога (Peter Krogh), который изложил его в книге «Управление цифровыми активами для фотографов». Вкратце напомню этот принцип:
Лично я чаще всего использую чуть другие правила в формировании резервных копий.
Классическая схема «3-2-1».
Во-первых, в качестве изначальных данных я беру резервные копии, а во-вторых, не всегда удобно и бюджетно хранить их на носителях различного типа — особенно для малого и среднего бизнеса. Моя обычная стратегия хранения резервных копий такова:
С оперативными и архивными резервными копиями обычно все достаточно просто, разве что следует придерживаться определенных рекомендаций. Один из вариантов таких рекомендаций — под спойлером.
А вот с удаленными резервными копиями вопросов много. В частности, надо выбирать, где хранить эти самые копии и чем их туда забрасывать. Сначала приведу несколько примеров «где».
Выбираем уютное облако
Одним из вариантов будет простая и незамысловатая аренда выделенного сервера или установка своего сервера в ЦОД на колокейшн.
Действительно, «облако», которое построил сам, дает больше контроля над происходящим, да и выбор решения для хранения и непосредственно резервного копирования остается на усмотрение системного администратора. Можно даже сервер включить в домен «на земле», как я описывал в статье «Как я базы 1С в Германии прятал».
С другой стороны, контроль означает и ответственность — необходимо будет мониторить состояние сервера на случай аппаратных и программных проблем, при этом недостаток облаков в виде зависимости от интернета и вопроса доверия сторонним людям никто не отменял.
А не ваш ли это арендованный сервер у недорогого хостера?
Другим вариантом будет использование специализированных сервисов, которые создавались как раз для хранения резервных копий. Самым известным примером являются сервисы Amazon Glacier. Они окутаны легендами на тему используемых технологий — начиная от ленточных кассет и заканчивая blu ray-дисками и робо-руками. Но официально это недорогие HDD.
В отличие от арендованного сервера, решение уже начинает пахнуть кровавым энтерпрайзом со многими «девятками надежности» после запятой. Правда, как и многое у веб-сервисов Amazon, он обладает непростой формулой расчета стоимости. Если грубо упрощать, то загрузка данных на сервис — бесплатна, хранение — совсем недорогое ($1 за 1 Тб в месяц), а вот за получение данных придется заплатить. Как на старых ярмарках — «вход бесплатный, выход 15 копеек».
Классические сервисы хранения данных вроде Amazon S3 и Yandex Object Storage тоже, конечно, можно использовать для резервных копий, но ценник в таком случае будет менее гуманный —
Третьим вариантом будет использование облачных хранилищ, которые не очень предназначены для хранения резервных копий компании, а больше ориентированы на простых пользователей. Приведу лишь несколько из них, которые на слуху:
Я сейчас не буду сравнивать облачные платформы, отдам это на откуп многочисленным материалам в сети. Например, статье «Облачные хранилища для физических лиц: что выбрать и почему». Лично я для своих нужд остановился на Яндекс.Диске, потому что он один из немногих, кто на бесплатных планах умеет WebDAV, API и снапшоты (историю) файлов на диске. Ну и, конечно, у меня скопилось некоторое количество бесплатных гигабайтов на нем.
Конечно, при выборе стоит обращать внимание не только на бесплатное количество и стоимость гигабайтов, но и на лицензионное соглашение, поскольку резервное копирование условных баз 1С может его нарушать. Отдельно стоит отметить пункты, по которым облачный провайдер не несет никакой ответственности, может в любой момент удалить все файлы и ничего ему за это не будет. Зато практически у всех таких сервисов есть ПО, которое позволяет загружать файлы на сервис, что подводит нас к следующему пункту сегодняшнего повествования.
Чем грузить на уютное облако
Лично мне ПО, предоставленное сервисами, не очень нравится использовать (если, конечно, речь не про специализированный сервис вроде Acronis): не всегда есть возможность настроить расписание синхронизации, да и еще жива в памяти история, когда Яндекс.Диск при обновлении устраивал патч Бармина операционной системе. По счастью, существуют специальные ПО, поддерживающие различных провайдеров. Как обычно, приведу несколько примеров в основном бесплатных и околобесплатных решений.
Handy Backup. Выдается на первой странице гугла по запросу «резервное копирование в облако». Есть платные версии различного функционала, отдельные плагины (например, для Exchange и 1C). Есть даже свое облако — HBDrive. Но самое главное, пока еще есть бесплатная версия, которая умеет бэкапить только в облако — Handy Backup Free for Cloud. К сожалению, в рамках тестирования мне не удалось заставить ее стабильно работать с Яндекс.Диском — периодически назначенное задание не срабатывало. Сложно что-то хотеть от бесплатного решения, но от использования этого ПО я отказался.
CloudBerry Backup. Всем хорош продукт, есть даже решения для восстановления отдельных объектов Exchange, есть поддержка множества разных провайдеров. От использования остановило отсутствие бесплатной версии и поддержки обычного Яндекс.Диска, только S3 совместимое хранилище Yandex Object Storage.
Список поддерживаемых провайдеров решения от CloudBerry Lab.
Duplicati 2. Уже совсем бесплатный продукт, даже для коммерческого использования. Есть под все популярные платформы от Windows до GNU\Linux, работать можно как через веб-интерфейс, так и через командную строку, также есть и шифрование бэкапов «из коробки».
Интерфейс Duplicati, поддерживаемые провайдеры.
К сожалению, «из коробки» Яндекс.Диск не поддерживается — только в режиме WebDAV. В этом режиме решение от Яндекса работает не идеально — бывают проблемы с крупными файлами. Но в списке допустимого назначения существует один, который решает эту проблему. Вот же он.
Rclone. Пожалуй, это мой бесспорный лидер среди прочего ПО. Утилита командной строки под множество платформ, на официальном сайте доступна загрузка в том числе и под редкие операционные системы вроде Plan9 и Solaris. Список поддерживаемых облачных провайдеров тоже впечатляет — в нем есть поддержка даже Cephs и OwnCloud. И да, Яндекс.Диск в списке. Конфигурация до недавнего времени производилась только через интерактивное консольное меню, но относительно недавно появилась возможность запускать веб-интерфейс и настраивать через него.
К минусам стоит отнести отсутствие каких-либо встроенных планировщиков. Утилита работает исключительно как транспорт на\с облаков, зато и не требует установки. В том числе и из-за этого я ее использую в связке с Яндекс.Диском для переноса информации с одних удаленных серверов на другие — оказалось, что крупные файлы быстрее закинуть на облако и скачать с облака, чем организовывать прямой файлообмен. Да и подгружать резервные копии одно удовольствие. Например, чтобы скопировать в облако только свежие файлы, можно использовать команду:
Где yandex — имя конфига, созданного заранее, а backups — папка с бэкапами.
Более подробно принципы работы rclone разобраны в официальной документации и в статье «Rclone: rsync для облаков».
В принципе, как уже полноценное решение для резервного копирования, rclone можно использовать вместе с Duplicati, выбрав rclonе как тип хранилища. Тогда Duplicati будет создавать резервные копии с использованием vss (снапшотов) по планировщику, а первое будет отвечать за загрузку резервных копий в нужное нам облако. Конечно, можно использовать и любое другое решение вроде Cobian или вовсе делать снапшоты vss командой diskshadow, архивировать и заливать в облако при помощи rclone. Правда, если совсем уж изобретать велосипед, то и никакой rclone не нужен.
Создаем свой велосипедо-скрипт
Конечно, если облачный провайдер предоставляет доступ по WebDAV, загрузка данных будет простой. Пример для cmd и Яндекс.Диска:
Но не все провайдеры умеют в WebDAV, и есть вопросы по скорости и стабильности работы. Поэтому можно использовать API, если, конечно, провайдер предоставляет такой доступ. Разберем пример с тем же Яндексом.
Для авторизации Яндекс использует OAuth, поэтому для нашего скрипта понадобится завести специальный токен. Сначала нужно создать приложение в разделе «Создание приложения» на сайте.
Нужно не забыть дать доступ приложению на Яндекс.Диске:
Доступ скрипта к API Яндекс.Диска.
И подставить URL для разработки в Callback URI (будет доступен после установки галочки «Веб-сервисы» на доступных платформах):
Настройка Callback URI.
После получения ID приложения следует перейти по ссылке:
Где 12345678 — полученный ID. После предоставления приложению доступа мы получим желанный OAuth-токен, который уже можно применять в скриптах. Вот, например, загрузка файла на Яндекс.Диск при помощи PowerShell:
Организовать ротацию файлов, контроль загрузки и прочий «обвес» предлагается самостоятельно, благо API Яндекса хорошо документировано. Но лично я предпочитаю не изобретать велосипед, а использовать rclone.
Ну и при резервном копировании в облако я настоятельно рекомендую шифровать архивы, чтоб не оказаться в ситуации как герой стихотворения известного в определенных кругах поэта Айклауда Фон Браузера, строкой которого и названа эта статья.
В комментариях предлагаю не разводить холивар на тему рациональности облачного резервного копирования, а поделится своим любимым инструментом бэкапа.