Архив метки: snapshots

Являются ли снэпшоты бэкапами?

Когда-то я довольно часто переводил статьи тогда сотрудника NetApp Димитриса Крекоукиаса, он умный блоггер, с широким кругозором, и, что важно, одновременно с этим (а это встречается нечасто), умеет развернуто и интересно выражать свои мысли.

С тех пор прошло много времени, Димитрис перешел из NetApp в Nimble, а теперь с ним, кажется, и в HPE, и, как и я, подзабросил блог. Но всякий раз, когда у него в нем появляются посты, они интересные и заставляют задуматься.

В рамках рубрики «запоговорить» этого блога (в ней не так много, увы, публикаций), я решил перевести одну из недавних его статей, посвященной проблеме защиты данных. Надеюсь, прочтение ее заставит моих читателей задуматься над поднятыми проблемами, и, возможно, немного лучше защитить их от возможных потерь с катастрофическими последствиями. Комментарии со своими соображениями, как всегда, приветствуются.

July 24, 2018 by Dimitris

Снэпшоты — это бэкапы? И что вам нужно предпринять для защиты ваших данных?

Идея этого поста родилась из дискуссии в Твиттере. Я уж думал, что подобные темы давно в прошлом, но скоро стало ясно, что это не так. Поэтому я решил пролить некоторый свет на вопросы защиты данных, в прежней моей жизни мне приходилось заниматься резервным копированием в по настоящему безумных масштабах.

Итак, моя позиция: Неважно, как фича называется — вы можете, используя ее, восстановить ваши данные? И, если ответ «да», то как быстро и по какому сценарию? И какие возможные минусы решения?

Начните с составления списка возможных ситуаций!

Перед тем, как засесть за разработку вашего решения для бэкапа/DR/BR, начните с того, что обдумайте ВСЕ от чего вы хотите предусмотреть защиту ваших данных. Например вот две очевидных ситуации:

      • Случайное удаление данных
      • Потеря сайта целиком

Но подумайте также и о ситуациях не совсем обычных, но которые тоже приведут к потерям данных.

      • Акт корпоративного саботажа, или злонамеренный админ, который удаляет ВСЕ ваши данные на сторадже, и ВСЕ ваши бэкапы, на ВСЕХ сайтах (это займет время, но это потенциально возможно, поэтому может случиться).
      • Хакер завладевает админской учеткой и удаляет ВСЕ ваше облако, когда вы только закончили миграцию в облако. (Такое уже тоже было).
      • Вирус-шифровальщик закончил шифрование всех ваших данных, и теперь просит денег.

То есть, задача состоит в том, чтобы создать список возможных отказов в работе бизнеса, и начать думать над тем, что вы готовы сделать в случае перечисленных событий, чтобы обеспечить защиту. И уже после этого начинать разрабатывать решение.

Почему «стратегия 3-2-1» — недостаточна.

Главное правило, которое рекомендуют при разработке стратегии бэкапа принято называть «стратегией», или «правилом 3-2-1». Это означает:

      • 3 полных копии данных
      • На 2 разных носителях
      • И одна из этих копий — на удаленном сайте

Звучит здорово, и легко запомнить, но подумайте о том, что ваш админ имеет доступ ко всем этим копиям, и потенциально может удалить их ВСЕ.

Снэпшоты — это бэкапы. Но просто этот вариант не покрывает ВСЕ возможные случаи защиты данных.

Вопрос не столько в том, являются ли снэпшоты резервными копиями. Они ими являются. Но более важно то, от чего именно они защищают ваши данные.

Например, довольно просто сделать систему, соответствующую «правилу 3-2-1» просто с помощью снэпшотов:

      • Множественные (виртуальные) копии, хранящиеся локально и удаленно, не просто «три копии»… (обычный профиль использования снэпшотов)
      • Репликация некоторых снэпшотов на другую систему (и убедитесь, что используемая вами технология создания снапшотов позволяет вам иметь полностью раздельные политики retention для источника и получателя репликации)
      • И одна из используемых систем расположена на удаленном сайте (идеально — в сотне километров от основного).

Некоторые люди думают, что если снэпшоты реплицируются на сходную систему, то если одна такая система имеет катастрофический баг, то и вторая будет его иметь. Ну, это словно бы две ленты одного типа обе обнаружат проблему в один и тот же ммоент времени. Нет, это так не работает, системы хранения так не выходят из строя (или, по крайней мере, нормальные системы хранения).

Главная проблема со снапшотами состоит в том, что админ системы хранения может просто, легко и быстро уничтожить все снэпшоты, как на источнике репликации, так и на удаленной системе-получателе репликации.

Поэтому основная тема спора состоит не в том, что «бэкапом является», а что — «нет». Основная тема обсуждения тут — кто и как контролирует процесс создания резервных копий, неважно, как именно эти копии созданы и где хранятся.

Что вы можете сделать против злонамеренного вмешательства

Здесь вы уже должны согласиться со мной, что именно пресловутый «человеческий фактор» является наиболее опасным фактором проблемы резервного копирования, а не какая-либо технология как таковая.

Большинство людей вообще не задумываются о данной проблеме.

Осознайте факт того, что роль backup admin — это САМАЯ опасная роль в IT!

Задумайтесь над этим фактом. ПО бэкапа, по своему определению:

      1. Управляет созданием резервных копий (включая создание снэпшотов и репликации, в некоторых решениях)
      2. Имеет агентов на хостах, которые, обычно, имеют полный неограниченный доступ ко всем пользовательским данным, включая права на перезапись всех данных. Или, как вы думаете, работает процесс восстановления?

То есть backup admin может легко сделать следующее:

      1. Удалить все снэпшоты на массиве хранения (если бэкапный софт управляет процессом создания этих снэпшотов) – даже если он не является админом хранилища!
      2. Сделать так, чтобы все ленты (если вы используете ленты) за прошедшие месяцы были отозваны из хранилища и стерты (а вы думали, что достаточно записать бэкапы на другой носитель, чтобы их обезопасить).
      3. Воспользоваться агентами бэкапа, чтобы полностью стереть все серверы.
      4. Стереть базу бэкап-сервера и все копии данных.
      5. [Бонус] Сделать копию данных для себя, чтобы оставить возможность шантажа – вы же не забыли, эта роль имеет доступ ко ВСЕМ серверам. Ему не нужны пароли глобального админа (доменные админы, вы правда считаете, что права вашей учетки абсолютно необходимы для запуска агента резервного копирования?)

И вот результат – все данные, и все бэкапы на лентах за последний месяц, и все снэпшоты — все уничтожено.

А теперь представьте, что это случилось с вами, и ВАМ надо восстановить данные в получившейся ситуации. И что такая потеря данных будет означать для вашей компании? 

Определенные ключевые сотрудники должны проходить особую углубленную проверку

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

Держите по крайней мере одну копию данных полностью недоступной для админов

Мы живем во времена программ-вымогателей, а то и еще чего похуже. Обдумайте некоторые из перечисленных идей:

      • Если вы используете ленты для оффсайт-хранения, используйте ДВЕ разных компании, предоставляющие вам услуги хранения лент, причем админы должны иметь доступ к хранилищу только ОДНОЙ. Только глава компании (например CEO, или исполнительный директор), должен иметь права доступа к хранилищу другой.
      • Используйте 3 локации хранения, а не обычных 2. Одна из трех должна располагаться очень далеко от других, идеально — другой континент (а в будущем может быть и геостационарная орбита?).
      • Если вы не используете ленты, у вас должна быть одна полностью независимая команда админов, отвечающая за третью копию ваших данных в отдельном датацентре. Массив хрнения в этом датацентре должен быть полностью недоступен для любого из админов остальных двух сайтов хранения. Сама копия должна создаваться полностью иным методом, то есть НЕ вашим обычным бэкапным софтом, ни штатным механизмом репликации дискового массива. Обычные админы НЕ должны иметь доступа к этому дополнительному механизму репликации и создания резервной копии, идеально — он должен быть от них полностью скрыт. Кстати, это не так просто сделать.
      • Подумайте о использовании лент как дополнение к всем прочим вариантам хранения, если вы их еще не используете. Да, все сегодня ненавидят ленты, но в данном случае это как раз задача для них.
      • Подумайте о возможности использовать настоящее WORM решение (такое, запись на которое никак нельзя изменить).

Я могу продолжать, но в целом вы уже поняли ход рассуждения.

Может быть пришла пора нового стандарта, «правила 4-3-3-3-1»?

      • 4 копии данных
      • В 3 локациях
      • Управляемых 3 разными системами создания копий
      • Администрируемых 3 разными командами, без пересечений в правах между ними.
      • И 1 копия, остающаяся полностью недоступной для почти любого в компании.

 

А для фанатов «облаков», это означает использование AWS, Azure и Google cloud вместе, одновременно (вот вам, например, ваши необходимые «три локации»).

И в заключение: остерегайтесь стать «слишком параноиком»

Чтобы уберечься от этого, задайте себе несколько вопросов:

      • Вы правда готовы заплатить за придуманное решение?
      • Во что паранойя обойдется вам и вашей компании, учтите и денежные затраты, и потерю оперативности бизнес-управления, а также темпов развития?
      • Рассматриваете ли вы ситуации отказов в порядке вероятности их появления, или сразу смотрите на самые экстремальные?
      • Доверяете ли вы людям, достойным вашего доверия?

Источник <http://recoverymonkey.org/2018/07/24/are-snapshots-backups-and-what-do-you-need-to-protect-against/>

NearSync replication — ограничения

В версии 5.5 у нас, в дополнение к нашей обычной асинхронной реликации с минимальным циклом «раз в час», добавилась еще и новая, которую мы назвали NearSync. Ее минимальный цикл — раз в минуту, и это может быть хорошим вариантом для тех, кому раз в час — редко, а синхронная репликация или не подходит, или слишком тормозит (например из-за расстояний между датацентрами).
Однако, как у любых фич, у NearSync есть ряд ограничений, которые хорошо знать, прежде чем вы начнете ей заниматься, планировать использование и использовать в работе.
Вот какие действующие ограничения есть в последней, на момент написания этого текста, версии AOS 5.8:

  • Поддерживается только репликация один-к-одному. С асинхронной можно разные конфигурации, например один-ко-многим.

  • Минимальное число нодов в кластере — 3, как для источника, так и для получателя. Соответственно, не работает на single-node и dual-node ROBO clusters.

  • В расписании для NearSync возможно указать только диапазон от 1 до 15 минут. Нельзя указать интервал от 16 до 59 минут. Начиная с 60 минут будет использоваться обычная Async.

  • Каждый SSD в кластере, участвующем в репликации, должен быть размером не менее 1.2TB. Оптимальный размер SSD для hybrid system — 2 x 1.9TB, для AllFlash ограничений нет. Не рекомендуется добавлять SSD размером меньше 1.2TB в кластер, который использует NearSync при его расширении.

  • Убедитесь, что в каждом Protection Domain, участвующем в NearSync репликации не более 10 объектов (VM или Volume Groups).

  • Система-получатель репликации должна иметь перед включением репликации свободного места столько же, сколько занимает защищаемый workset на системе-источнике.

  • Не включайте NearSync Replication в кластере, где есть узлы с более чем 40TB емкости хранения (SSD+HDD).

  • Поддерживаются гипервизоры ESXi и AHV на x86, не поддерживается AHV на IBM Power.

  • Поддерживается только гомогенный кластер. Не поддерживаются кластеры с разными гипервизорами (пример: ESXi и AHV на capacity nodes).

  • Linked Clones для VM, участвующих в NearSync replication не поддерживаются.

  • Не поддерживается CBT (Change Block Tracking), его пока нет в Lightweight Snapshots, используемых в NearSync.

  • Контейнеры, участвующие в Metro-репликации и в SRM — не поддерживаются.

  • Self-service Restore для реплицируемых с NearSync виртуальных машин не поддерживается (он есть только для full, а не для LWS снэпшотов). По той же причине не поддерживается интеграция для данных защищаемых NearSync VMs с Commvault, HYCU, Rubrick. Им всем нужны full snapshots, а не LWS.

  • Также для NearSync-protected VMs не поддерживаются AppConsistent Snapshots, они также используют full snapshots, а не LWS.

  • Не поддерживается NearSync репликация для AFS (Acropolis File Services).

  • Не поддерживается кросс-гипервизорная репликация.

Так что, как видите, NearSync подойдет не всем, и не является чем-то, заменяющим обычный Async, «тока быстрее». Для задач, которые требуют минимального RPO/RTO, например какая-то ответственная база данных, или аналогичная система, которой в самом деле надо иметь цикл репликации раз в минуту/в пять минут это должно неплохо подойти и ограничения легко обходятся. Для остального — по прежнем лучше использовать обычный Async.