Чем сильнее бизнес зависит от IT-систем, тем большие убытки он понесет в случае потери данных и простоев из-за восстановления работоспособности. Поэтому важно настроить регулярное резервное копирование систем и данных.
Но какое решение для этого выбрать? И если Veeam, то что использовать — Backup & Replication, Agent или Сloud Connect? В тексте постарались объяснить, в чем разница между сервисами Veeam для резервного копирования.
Используйте навигацию, если не хотите читать текст полностью:
→ Правила хорошего бэкапа
→ Veeam Backup & Replication
→ Veeam Cloud Connect
→ Veeam Agent
→ Заключение
Правила хорошего бэкапа
Раньше единственной страховкой от потери информации было самостоятельное использование систем хранения данных, СХД. Сегодня ответственность за сохранность данных и их бэкапов можно передать провайдеру. А чтобы они были своевременными и не напрасными, достаточно следовать всего нескольким рекомендациям.
- Автоматическое резервное копирование
Бэкап должен выполняться автоматически, согласно установленному расписанию. Обязательно делайте резервное копирование перед установкой нового ПО, модернизацией аппаратного обеспечения и при переносе данных.
- Тестовое восстановление данных
Каким бы надежным ни было ПО для резервного копирования, всегда есть вероятность ошибки, из-за которой восстановиться не получится. Поэтому лучше регулярно проводить тестовое восстановление данных.
- Избавление от дублей
Устранение дубликатов позволяет копировать только уникальные данные и оптимизирует использование дискового пространства в СХД.
- Правило 3-2-1
Желательно хранить по меньшей мере три копии данных. Пару копий — на двух разных носителях, еще одну — на удаленной площадке.
Для того, чтобы настроить бэкапы «по правилам» и не изобретать велосипед, можно воспользоваться готовыми решениями — например, от Veeam. Мы в Selectel предоставляем три сервиса для резервного копирования на базе этой платформы. Рассмотрим их особенности и разберемся, в каких задачах можно использовать.
Дисклеймер: ниже мы показываем, как устроена работа с сервисами Veeam в нашей «экосистеме». Реализация может отличаться от провайдера к провайдеру.
Veeam Backup & Replication
Самый типовой случай — есть виртуальная машина, которую нужно забэкапить. Если вы пользуетесь облаком на базе VMware, для настройки бэкапов можно воспользоваться услугой резервного копирования в облаке, которая построена на основе Veeam Backup & Replication и Enterprise Manager.
Veeam Backup & Replication — это клиент-серверное программное обеспечение для централизованного резервного копирования виртуальных машин. Решение поддерживает виртуальные среды VMware vSphere и Microsoft Hyper-V.
Как работает
Схема работы проста. Пользователь подключается к консоли Veeam Enterprise Manager и настраивает резервное копирование для виртуальных машин, доступных в Cloud Director.
Схема работы резервного копирования облака на базе VMware.
После подключения к Veeam Backup & Replication с помощью Enterprise Manager можно настроить восстановление файлов и отдельных дисков, объектов приложений SQL Server и Oracle. А также полное резервное и инкрементное копирование на уровне образа виртуальной машины и vApp.
Сценарии использования
Гранулярное восстановление данных
Один из сотрудников бухгалтерской фирмы случайно удалил важный документ. Но компания ежедневно делает резервное копирование в облако. Чтобы вернуть утерянные данные, не нужно восстанавливать всю систему: Veeam Backup & Replication поддерживает гранулярные бэкапы.
Минимизация RTO и RPO
Из-за конфликтов записей в базе данных компании N удалилась часть информации. Но благодаря высокой частоте бэкапов и скорости восстановления данных в Veeam Backup & Replication сервису удалось свести издержки к минимуму.
Подробнее о резервном копировании в облаке на базе VMware и Veeam Backup & Replication рассказали в документации →
Veeam Cloud Connect
Если вы используете Veeam на on-premise площадке и у вас нет удаленных серверов для хранения резервных копий, можно воспользоваться облачным репозиторием на базе Veeam Cloud Connect.
Veeam Cloud Connect — это инструмент для создания дополнительных резервных копий систем и данных в облаке. С помощью него можно сохранять бэкапы в удаленном репозитории, а также «подтягивать» их при необходимости.
В облачном репозитории можно безопасно и надежно хранить резервные копии систем и данных. Репозиторий хранит зашифрованные на стороне клиента данные, забэкапированные по правилу 3-2-1.
Как работает
На стороне пользователя должно быть установлено ПО Veeam — например, Backup & Replication 10+ или Veeam Agent 5+. Именно с помощью него можно забэкапить системы и данные. Veeam Cloud Connect отвечает только за безопасное соединение и загрузку резервных копий в облачный репозиторий Selectel.
Схема работы с облачным репозиторием на базе Veeam Cloud Connect.
WAN-акселерация позволяет снизить нагрузку на сеть: в облачный репозиторий передаются только измененные данные. При необходимости их можно зашифровать.
Сценарии использования
Надежное хранение данных
Веб-платформа N хранит много чувствительных данных в рамках одного пула — бухгалтерские отчеты компаний-клиентов, конфигурации для работы внутренних и внешних сервисов. Чтобы обеспечить максимальную сохранность данных, разработчики связали СХД с облачным репозиторием с помощью Veeam Cloud Connect. Теперь бэкапы хранятся на удаленной площадке.
Организация Disaster Recovery
Для финансовой компании N репутационные и финансовые потери из-за простоев в работе сервисов недопустимы. Поэтому разработчики запустили резервную площадку для аварийного восстановления, Disaster Recovery. Так, если инфраструктура в основном пуле упадет, запустится ее «клон». С помощью Veeam Cloud Connect он быстро загрузит резервные копии из облачного репозитория и продолжит работу. Итог — простои и издержки минимальные, компания сохранила репутацию и бюджет.
Если вам интересно узнать подробнее о способах реализации Disaster Recovery, читайте нашу статью →
Veeam Agent
Backup & Replication подходит для резервного копирования облака на базе VMware. Но для пользователей облачной платформы и выделенных серверов также есть решение — резервное копирование агентами на базе Veeam Agent.
Veeam Agent — это утилита, с помощью которой можно делать бэкапы физических и виртуальных машин под управлением основных операционных систем — Windows, Linux и MacOS. При этом серверы могут располагаться в любом дата-центре, у любого провайдера или даже на on-premise площадке.
Как работает
Для создания бэкапа на сервер устанавливается Veeam Backup Agent — именно он выполняет резервное копирование данных. А также Management Agent, который позволяет управлять параметрами бэкапов с помощью портала самообслуживания.
Схема работы с Veeam Agent.
Портал самообслуживания — это веб-интерфейс, с помощью которого можно устанавливать и обновлять агенты, настраивать политики бэкапов и другое. Так, например, можно установить периодичность, с которой Backup Agent будет загружать резервные копии в облачный репозиторий.
Подробнее о работе, настройке агентов и бэкапов читайте в нашей документации →
Сценарии использования
Сценарии использования Veeam Agent и Backup & Replication идентичны. Выделим те, которые не упоминали ранее.
Инкрементальное копирование
Компания N каждый час делает резервное копирования файлов пользователей своего облака. Чтобы оптимизировать этот процесс и не сохранять каждый раз всю систему, компания настроила инкрементальные бэкапы в Veeam Agent.
Теперь резервное копирование происходит по принципу «замещение блоков со старыми данными на новые». Сперва выполняется бэкап всей информации, потом создаются копии файлов, которые изменились со времени последнего резервного копирования. Такой подход значительно ускоряет процесс создания копий и уменьшает их размеры.
Безопасное резервное копирование
Веб-платформа W хранит конфиденциальную информацию — статистику о продажах, контракты и другие документы. Для бэкапов данных разработчики настроили резервное копирование агентами. Теперь все данные шифруются на стороне веб-платформы
Заключение
Есть разные способы, как настроить резервное копирование. Например, можно комбинировать резервное копирование агентами и в облаке, объединив их с помощью облачного репозитория для хранения бэкапов.
А какие решения для резервного копирования используете вы? Поделитесь своим опытом в комментариях!
Возможно, эти тексты тоже вас заинтересуют:
→ Как тестировать Android-приложения без использования эмуляторов? Знакомство с фермами мобильных устройств
→ IP-фабрики — что это такое и как мы к ним пришли. Устройство сетей в облачной платформе
→ OpenStack vs VMware: что лучше — open source или проприетарная платформа
Комментарии (13)
Lazhu
21.06.2023 10:49+2ответственность за сохранность данных и их бэкапов можно передать провайдеру
А у провайдера случился пожар/потоп/налетсаранчи, и он такой: "все ваши данные потеряны, вот вам 30 дней бесплатного облака в виде компенсации"
Doctor_IT Автор
21.06.2023 10:49Конечно, какой бы надежной ни была инфраструктура, всегда есть вероятность возникновения нештатных ситуаций, способных негативно повлиять на работу компании в целом. Но дата-центры как раз и служат решением, которое закрывает потребность в отказоустойчивости и надежности.
Например, для защиты серверных и технологических помещений в своих дата-центрах мы используем самые проверенные средства пожарной защиты, не экономя на надежности инфраструктуры и качества ОТВ. Высокий уровень защиты достигается за счет использования автономных центральных станций газового пожаротушения с веществом Хладон 125. И это только про системы пожаротушения.
А что касаемо сохранности бэкапов — мы также предлагаем инструменты, которые позволяют делать резервное копирование по правилу 3-2-1.
mixsture
21.06.2023 10:49Но дата-центры как раз и служат решением, которое закрывает потребность в отказоустойчивости и надежности.
ДЦ как и любой бизнес служит извлечению прибыли. А все остальное это скорее проблемы клиента. Который проверить актуальность всех описанных мер безопасности не в состоянии. Что вполне логично, эти меры, будучи исключительно затратами для ДЦ — деградируют.
На выходе мы получаем
https://www.gazeta.ru/tech/2021/03/11/13507844/tsod.shtml
где здание выгорает полностью, система пожаротушения что-то ничего не потушила, персонал с пожаром бороться не умеет, а приехавшие пожарные длительное время даже не могут обесточить здание.Но при этом до последнего верим, что там-то все надежно и продуманно. Я бы сказал, что там черный ящик. И цели у этого черного ящика сильно расходятся с целями клиента.
gbdfc
21.06.2023 10:49можно настроить восстановление файлов и отдельных дисков, объектов приложений SQL Server и Oracle
А восстановление на уровне БД точно будет работать из EM сервис провайдера? Если я правильно помню, виму нужен прямой сетевой доступ для такого манёвра. Есть настолько смелые провайдеры?
Doctor_IT Автор
21.06.2023 10:49Добрый день! Да, всем данная возможность из коробки не доступна, но мы делаем схему под запрос клиента. Она разработана для организации восстановления отдельных БД MSSQL на уровне приложения из image based резервных копий, созданных в рамках резервного копирования облака на базе VMware. Ставим специализированные guest interaction proxy (GIP), через который возможен доступ по сети к инфраструктуре.
remendado
Помню, как зашел на позицию CIO на некое предприятие.
- бэкапы делаете?
- а как же.
- где они у вас?
- вот они, тут.
- а восстанавливаться с них пробовали?
- а зачем, пока, слава богу, ничего не падало.
- ....
Пришлось объявлять в выходной учения по восстановлению данных из бэкапов. Выяснилось много интересного, технологию резервного копирования пришлось существенно менять.
Через 15 лет призвали поднимать из руин драматически рухнувший интернет проект. Один админ сбежал еще до меня, второй за один день показал мне дым пожарищ и сбежал тоже. Техдир, который все это допустил, дорабатывал последние дни и нужен был только для инвентаризации железа. Так вот, там бэкапы делали в Bacula. В основе оной была MySQL-база. Она рухнула одной из первых. То, чем потом пришлось заниматься, чтобы выгрызть хоть какие-то куски проектов из разрозненных останков Бакулы, напоминало чистку септика на даче с выгребанием говна своими руками при помощи ведра.
Так что совет один - бэкапить надо тем, из чего потом точно сможете поднять. Для данных в идеале это rsync. Загрузочные диски желательно зеркалировать, профит может оказаться несоизмеримым с расходами. То, что может жить в контейнерах типа jail или lxc, надо там и держать, регулярно снимая снапшоты. СУБД - дампы, дампы и еще раз дампы. Если сподобились поднять репликацию на резервный сервер, то обязательно учения по переключению на резервный сервер и возврату на основной.
Понятное дело, для серьезных корпоративных проектов с мегабюджетами, где техдиры, девопсы и тимлиды с утра до вечера пишут планы и отчеты рабочих групп, есть соответствующие инструменты, учитывающие в полной мере требования корпоративной бюрократии и позволяющие не ударить носом в грязь перед аудиторами. Но мы же не о них? )))
Redduck119
Да, бекапом можно считать то что можно восстановить. И я не часто, раз в полгода провожу, тестовое восстановление на виртуальную машину разные сервера. Только у меня бекапы без подписи, что тоже не гуд совсем. Так злодей может подменить архив.
Zeroxzed
Рисковый вы человек. Восстанавливаете раз в полгода. Я каждый бэкап через некоторое время проверяю на восстановление. Что вы будете делать, если в очередную проверку окажется, что восстановиться может только бэкап пятимесячной давности? Если он вообще будет существовать.
Redduck119
У каждого своя ситуация. Например сервер Elastix, или OpenVPN меняются крайне редко и имея все данные по изменением (телефонные номера, SIP аккаунты) можно восстановить и старую версию. Есть важный файловый сервер, с ним проще - очень часто просят восстановить тот или иной файл. Получается неполная проверка файлового архива. AD - тут три домен контролера, мало вероятно что все три одновременно накроются по естественным причинам. Важный сервер 1С - тут всё хуже, база всегда есть в архиве с большой глубиной. Только восстановление займет очень много времени так как восстанавливать не на что, нужен сервер такой же по характеристикам или лучше. И так далее. Риск конечно есть, еще конечно я запускаю тестирование архива программой которая делает архив, но и тут риск есть.
remendado
На файловом сервере часто просят восстановить старую версию того или иного файла, так что версии за разумное время хранить крайне желательно. Тоже самое с 1С, бухгалтерам часто приходит на ум менять что-то задним числом, что вроде как нельзя, но если очень хочется, то деваться некуда. AD - отдельная песня. Не знаю, как в последних версиях, но во времена W2K3 адэшка могла просто развалиться, Primary отцеплялся от Secondary, и в некоторых случаях помогал только синхронный откат всех DC, хотя иногда удавалось связать домен-контроллеры при помощи шаманства в командной строке.
Doctor_IT Автор
Спасибо за такую интересную историю, сравнение с чисткой септика очень жизненное)) Вы правы, проверять работоспособность резервных копий — крайне важная итерация. Напомнило историю отсюда :)
FlashHaos
Просто надо использовать нормальные инструменты. Бакура к таким не относится.