Назад | Перейти на главную страницу

Резервное копирование с диска на диск в тот же массив хранения?

Мы ищем новую SAN, поэтому мы повторно изучаем наши проблемы с хранением данных, сетью и резервным копированием. Мы планируем приобрести EMC VNXe 3100 с дисками SAS для производственных данных, а затем купить полку расширения и заполнить половину ее дисками SATA (6 ТБ необработанных данных). Наше программное обеспечение для резервного копирования затем будет использовать SATA в качестве цели.

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

На мой взгляд, цель резервного копирования диска на SATA - предоставить нам 1.) меньшее окно резервного копирования и 2.) удобное безленточное восстановление. Мы по-прежнему будем использовать ленту для аварийного восстановления и использовать программу резервного копирования для переноса резервной копии диска на ленту. У нас только один сайт, поэтому репликация - не лучший вариант. Поскольку для нас важен бюджет, это кажется разумным, в отличие от покупки специального устройства.

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

Итак, я с ума сошел? Кто-нибудь еще делает что-то подобное?

Пока ваше предлагаемое решение бы работа, как упоминал Chopper3, не идеальна. Мы используем и нам очень повезло с Nexsan SATAboys для резервного копирования с диска на диск. SATAboy не собирается предоставлять вам все расширенные функции, которые предоставляет EMC, но, честно говоря, вам это не нужно для промежуточного резервного копирования. Для этого вам просто понадобится bucket-o-disk, который вам даст SATAboy. Они также по очень разумной цене - много дешевле, чем специализированное устройство резервного копирования. Если вы выбрали SATAboy, вы бы просто подключили его к существующему серверу резервного копирования через Fibre Channel или iSCSI.

Одна из причин, по которой вы не решаетесь позволить своим производственным данным и резервным копиям сосуществовать в одной и той же сети SAN, заключается в следующем: как получить резервные копии, если вся SAN выходит из строя. Это действительно хороший повод для разделения, но есть еще один - IOps. С обеими рабочими нагрузками в одной и той же SAN (даже если не в одном массиве дисков) вы будете перекачивать через SAN вдвое больше операций ввода-вывода, как если бы промежуточное резервное копирование находилось в другом месте. Это может быть или не быть проблемой в зависимости от того, насколько загружена сеть SAN.

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

Резервное копирование с диска на диск может дать вам некоторые преимущества:

  1. Защита от ошибки пользователя / удаления файла / повреждения файла / повреждения файловой системы.
  2. Защита от сбоя жесткого диска.

Однако он не сможет защитить вас от

  1. Огонь уничтожает ваш сервер.
  2. Воровство.
  3. Другой аппаратный сбой (например, не HDD) на вашем сервере.

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

Если эти риски приемлемы для вас, то переход с диска на диск может быть для вас жизнеспособным решением. Однако, если ваши данные достаточно важны, чтобы они могли пережить любую из этих катастроф, резервное копирование за пределами объекта является обязательным.

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

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

Конечно, если у вас есть бюджет, вам следует делать краткосрочные резервные копии на отдельном массиве, но лучше иметь некоторые резервное копирование, даже если один и тот же массив, чем ни одного.