Backup – дань традиции или необходимость?

В умных СХД и приложениях есть мощное средство защиты и восстановления данных – репликация. Оно позволяет восстанавливать данные как после логического сбоя, так и после катастрофы. Иногда между лагерями сторонников СХД и приложений бывают дебаты — где лучше защищать данные? Мне, конечно, больше нравится, когда для защиты данных используются средства СХД, но я не могу разделить точку зрения радикалов с обеих сторон, заявляющих, что встроенная репликация это панацея, а резервные копии при хорошей репликации вообще не нужны.
Недавно я встречался с представителем одного банка, который совершенно серьезно мне заявил, что при наличии хорошей репликации бэкап не нужен.

Я, честно говоря, рояль из кустов не достал, но пообещал прислать развернутую аргументацию за бэкап.
Так что с удовольствием делюсь здесь с вами своими аргументами за резервное копирование.

1.       Резервная копия более независима

1.1 Физически и логически отдельное хранение резервной копии гарантирует большую степень защиты.

Объяснение: В итоге, даже глобальный сбой в системе хранения или приложении не повредит данные и не нарушит их доступность. Естественно, надо помнить, что хранить резервную копию надо на другой системе хранения (лента или диск – не принципиально, главное отдельно).

1.2  Из РК восстановление данных всегда возможно на любую СХД любого производителя.

Объяснение: Если основная система вдруг скончалась – восстановление свежей резервной копии на новую СХД любого производителя – сущий пустяк, в отличие от восстановления реплики, которая может быть недоступна из за 1.1, или несовместима с новой СХД по протоколу репликации. В любой случае, восстановление из реплики займет больше времени, в течение которого продуктивные приложения будут недоступны, и предприятие будет стоять.

1.3      РК не зависит от продуктивных СХД и является горизонтальным решением по защите данных для предприятия.

Объяснение: Вы можете менять основные СХД, но резервные копии сохранят свою топологию и логику работы. Старые архивы резервных копий останутся доступны даже если вы полностью спишете старые СХД.

1.4 РК не зависит от целевой СХД, и может быть развернуто в гетерогенном окружении, для преемственности, либо для диверсификации.

Объяснение: Даже если у вас для продуктивных приложений используются разные СХД разных архитектур и производителей, у вас все равно будет единый инструментарий для резервного копирования и восстановления. Что, согласитесь, как то спокойней и надежней.

2.       Резервная копия экономичней

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

Объяснение: Достаточно очевидно, что ленточные накопители недорого стоят по сравнению с хранением данных на основной продуктивной СХД. Но сейчас уже есть и дисковые системы резервного копирования, которые при помощи снэпшотов и дедупликации успешно соревнуются по экономической эффективности с лентами. В ряде случаев, резервное копирование экономичней, чем репликация.

3.       Надежность и гибкость восстановления из резервной копии выше

3.1 Резервная копия может  использоваться для восстановления на данный момент времени многократно (в случае неудачи и повторной порчи данных).

Объяснение: Восстановление из реплики во многих случаях «подменяет» этой репликой продуктивные данные. Так или иначе, при помощи снимка, или клона, или восстанавливаясь при помощи журнала изменений на предыдущий момент времени, мы можем оказаться в ситуации с отрезанными путями к отступлению. Т.е. в случае повторного сбоя восстановиться по прежнему сценарию уже нет возможности, а есть только более старые реплики. Чтобы не выбирать между большим и меньшим злом – восстанавливайтесь всегда с целостной резервной копии. Она может быть использована для восстановления многократно и без труда.

3.2 Резервная копия исторически глубже интегрируется с приложениями, и поэтому целостность РК гораздо легче обеспечить.

Объяснение: Бывает, что упускают это из виду на этапе внедрения, но резервные копии надо проверять на целостность после их создания. Только резервная копия прошедшая тест на целостность считается сделанной на 100%. Стоит ли говорить, что реплики создаваемые средствами СХД или приложения почти никогда тест на целостность не проходят из на отсутствия самой возможности проверить реплики на лету в процессе их постоянного создания. В итоге «съедается» много места и ресурсов, но риск наступить на грабли с неконсистентной резервной копией значительно выше, если у вас нет полноценного резервного копирования. А резервное копирование по своему дизайну создавалось для того чтобы данную консистентность обеспечить гарантированно.

4.       Резервная копия это удобней

4.1 Более богатые метаданные, для мониторинга, отчетов, поиска нужных для восстановления данных, итп

Объяснение:  Легко ли в «сырой» реплике найти порцию данных, которую вы хотите восстановить? Файл, почтовый ящик, письмо или табличное пространство? В целом, я бы сказал что это скорее трудно. А если вы используете полноценное резервное копирование – то вся информация со структорой каталогов, метаданные СУБД, почты и прочего, позволят вам быстро не только найти, но и восстановить ценную информацию сразу до уровня приложения.

4.2 Резервное копирование обеспечивает мониторинг качества защиты приложений, трендов, итп

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

5.       Резервная копия соответствует нормативам защиты данных

5.1 РК имеет встроенную совместимость с отчуждаемыми носителями (лентами)

Объяснение: Для ряда организаций, например, банков, есть нормативы Гос. Регулятора заставляющие их хранить данные резервных копий на отчуждаемых носителях. Этот норматив придуман не просто так, а для портируемости данных на случай катастрофы или проведения расследования. За этим можно разглядеть рациональное зерно:

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

 В общем, товарищи, я считаю, что репликация репликацией, а резервное копирование это обязательно.

Справедливости ради, надо привести полную аргументацию в пользу репликации. Но это уже тема для следующего поста 🙂

Денис Серов

Backup – дань традиции или необходимость?: 2 комментария

  1. Уведомление: Подводные камни резервного копирования новых СХД. Ч. 2. Восстановление гибридных систем | Блог Дениса Серова

  2. Уведомление: Подводные камни резервного копирования новых СХД. Ч. 3. Дедупликации и катастрофы | Блог Дениса Серова

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s