Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах ITSM 365 Пользователи Компании Лента заказов Курс по ITSM

10 проблем, которые могут возникнуть с планом восстановления данных

10 проблем, которые могут возникнуть с планом восстановления данных

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

1. Плохие резервные копии. Нет ничего хуже, чем обнаружить при восстановлении, что резервные копии не читаются. Когда компьютеры используются 24 часа / 7 дней в неделю, трудно сделать хорошие резервные копии. Многие приложения не работают с ПО для резервного копирования. Иногда сами резервные копии хранятся ненадлежащим образом. Возникают проблемы с чрезмерно сложными приложениями для резервного копирования, которые не работают так, как надо. Плюс аппаратные проблемы. Совокупность этих факторов и дает плохие резервные копии. Только регулярный мониторинг системы резервного копирования и тестирование копий, гарантируют вам, что они будут в рабочем состоянии, когда потребуются. Резервное копирование должно быть одним из главных приоритетов.

2. Нет системы для восстановления. Резервные копии бесполезны, если у вас нет способа запустить систему восстановления (например, с помощью live CD или каким-либо другим способом). Вы должны были столкнуться с этой проблемой на этапе пробного запуска процесса восстановления. Система восстановления всегда должна быть под рукой. Храните её вместе с резервными копиями.

3. Не осуществляется пост-тестирование. Зачем восстанавливать систему, если спустя пару дней возникают те же проблемы? Если проблема связана с системой или приложениями, её причина может крыться в резервных копиях (например, вирус). После выполнения процесса восстановления необходимо проверить общую работоспособность системы и приложений, а также выяснить устранена ли конкретная проблема, из-за которой и потребовалось восстановление. Первое тестирование должно проводиться заранее, быть четко задокументировано, а его результаты сохранены. Второе, как правило, делается на лету и определяется по ситуации.

4. Нет оборудования для восстановления. Некоторые считают (или надеются), что проблемы возникают только с программным обеспечением (вирусы, ошибки ОС и т.д.). И поэтому у них нет резервного оборудования. Однако иногда восстановление системы не требуется, вполне достаточно простой замены оборудования (если есть подходящее). Оптимальный вариант – купить партию серверов, чтобы один из них можно было использовать как резервный, который сможет заменить любой другой. Если в работе оборудования возникают проблемы, всегда можно перенести его на запасной сервер. Да, оборудование стоит дорого и порой трудно оправдать покупку дополнительного сервера. Однако его стоимость не сопоставима с потерями от простоя из-за ожидания нового оборудования или комплектующих.

5. Отсутствие комплектующих. Вот несколько основных компонентов, которые «на всякий случай» всегда должны быть под рукой:
• сетевые кабели (достаточной длины);
• кабели питания;
• жесткие диски (соответствующего объема и типа);
• оперативная память (соответствующего объема и типа);
• дата-кабели;
• контроллеры дисков (если они идут отдельно от материнских плат серверов);
• дополнительные клавиатура, мышь и монитор.

6. Не было пробного запуска восстановления. Самый известный, но наименее практикуемый совет: Заранее опробуйте свой план восстановления. Самая распространенная причина, почему никто этого не делает – недостаток времени. На самом деле для этого не требуются значительные усилия и временные затраты, особенно если запасные серверы у вас под рукой. Не пожалейте времени и проведите пробный запуск процесса восстановления.

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

8. «Неглубокие» резервные копии. Не у многих компаний достаточный бюджет, что делать все резервные копии уникальным снимком, который постоянно архивируется. Необходимо расписание, по которому будет осуществляться резервное копирование различной глубины и избыточности. Каждые три дня можно осуществлять вторичное резервное копирование, раз в неделю сохранять вторичные копии на диск, а раз в месяц один из этих дисков отправлять на удаленное хранение. Кроме того, Exchange Server осуществляет свой бэкап два раза в день, который сохраняется во вторичной системе по тому же графику. SQL Server осуществляет собственный бэкап раз в день, который также хранится во вторичной системе 14 дней. Это позволит компании быстро войти в рабочий режим: восстановить все виртуальные машины с заведомо хороших копий, а затем привести их в актуальное состояние с помощью бэкапов Exchange Server или SQL Server.

9. Слишком удаленное хранение резервных копий. Если вы используете удаленное резервное копирование, для доступа к данным требуется какое-то время. Но иногда эти данные нужно получить как можно быстрее. Резервное копирование он-лайн является удобной альтернативой записи на физические носители, но помните, для того чтобы скачать объемный бэкап и вытащить из него несколько файлов, вам потребуется хорошее соединение с Интернетом. Убедитесь что вы можете легко получить доступ к данным удаленного резервного копирования.

10. Отсутствие документации в печатном виде. Важно, чтобы процесс восстановления был задокументирован на бумаге. Если ваша система выйдет из строя, вы не сможете получить доступ к файлам! Допустим, вы храните всю документацию на сайте SharePoint. Но если SQL Server упадет, то как вы доберетесь до SharePoint? Поэтому и необходимы печатные копии документации, которая может потребоваться для восстановления, желательно вместе с физическими носителями (наряду с live CD и другими материалами). Печатные копии должны поддерживаться в актуальном состоянии. Можно разместить эти материалы в SharePoint, и тогда, подписавшись на RSS-канал списка документов, вы будете получить уведомления в случае изменения отдельных документов.

По материалам techrepublic.com

Комментарии (9)

  • Аватар

    Яковлев Андрей Михайлович [swtws], 16 декабря 2011, 22:35

    1
    1. Не существует в мало-мальски приличной системе. Крыжик "Verify"
    2. DRP все это предусматривает
    3. Почти полная ахинея
    4. Слишком дорого
    5. Так бывает около китайской лапши
    6. Входит в DRP
    7. Любая система на раз
    8. Вообще-то есть разный бэкап - полный, разностный, накопительный. Много места не надо.
    9. Никто не гонит бэкапы через WAN - дорого
    10. DRP предусматривает, но реально не все делают.

    Автору оригинала курить мануалы по бэкапу до дыр на мониторе :)
  • Аватар

    Kuznetsov Dmitry [Aksakal], 17 декабря 2011, 06:36

    1
    Все эти "проблемы"  - часто прямое следствие либо неверной методологии при составлении DRP, либо недостаточной квалификации персонала.
    Собственно сам по себе DRP обычно не существует, это часть документа более высокого уровня Business Continuity Plan - BCP.



    • Аватар

      Яковлев Андрей Михайлович [swtws], 17 декабря 2011, 08:22

      1
      Не материтесь :)

      Что такое "непрерывность бизнеса" у нас бизнес не знает почти повально.

      • Аватар

        Kuznetsov Dmitry [Aksakal], 17 декабря 2011, 11:13

        0
        Тот, кто не знает, это еще не бизнес. А так... soho.
        На самом деле знают, но готовы значительно умерить свои хотелки почти сразу-же после того, как узнают стоимость решения в соответствии с пожеланиями.
        • Аватар

          Яковлев Андрей Михайлович [swtws], 17 декабря 2011, 12:10

          0
          Согласен. Но только бизнес хоть не сильно, но должен обжечься. Правда, некоторые потеряв очень прилично в деньгах и репутации все одно не думают. Но это "свои" и C&Q, в основном.
          • Аватар

            Ланцев Андрей [Sansey], 21 декабря 2011, 11:52

            1
            Почему у нас в сообществе любой материал имеющий прямое отношение к технической или организационной части тут же опускается до уровня "бизнес козел" или "админ дурак" и никто никогда не предложит конкретных идей и примеров? Никому в голову не пришло написать сюда какое ПО лично он использует для бэкапов и по какому графику именно у него это все происходит и как контролируется?

            "Тот, кто не знает, это еще не бизнес. А так... soho." Так свысока, небрежно, опустили 80% наших предпринимателей:) Ай-яй-яй:)) а раз вы знаете так дайте формулировку того, что такое "непрерывность бизнеса" а то как-то некрасиво получается. вы знаете, а других научить не хотите:)
            • Аватар

              Яковлев Андрей Михайлович [swtws], 22 декабря 2011, 15:10

              0
              Вообще-то схем резервного копирования великое множество. Это зависит от потребностей бизнеса. В экзаменах по MS SQL бэкапы постоянно упоминаются и план надо выбрать под текущие условия. У кого база 100 МБ это одно, а у кого 100 ГБ - другое.

              "2.2 непрерывность бизнеса
              стратегическая и тактическая способность организации планировать свои действия и реагировать на инциденты и нарушения нормального хода бизнеса с целью продолжения хозяйственных операций на определенном приемлемом уровне"

              Это определение из первой части соответствующего стандарта - BS 25999
              • Аватар

                Ланцев Андрей [Sansey], 22 декабря 2011, 15:34

                0
                Ну великое множество - это сильно сказано. Я уверен, что не более 10 оптимальных планов, а все остальное уже мелкие частности. Но никто даже одним не поделился. В чем был смысл постить статью, если это прописные истины? Как не раз тут говорилось - самое интересное рождается в коментариях.

                Про непрерывность бизнеса - кто-то вообще знает о существовании BS 25999? Лично я нет и не представляю что это такое:) А тот кто знает живет по нему? Я вообще-то хотел услышать более приземленное определение.
                • Аватар

                  Яковлев Андрей Михайлович [swtws], 22 декабря 2011, 16:58

                  0
                  Нет, планов действительно много, но разнообразие - определенно для крупняка.

                  BS 25999 Стандарт Британского института стандартизации, посвященный непрерывности бизнеса. Он из двух частей.  "Практические правила" и "Стандартизация". Сертификация по подобным стандартам нужна банковскому и финансовому сектору, да страховщикам. Для большинства подобные стандарты - сборник полезных советов, как разработать, внедрить и управлять  непрерывностью бизнеса. Собственно это набор внедренных политик, которым следует компания. Просто при оценке рисков, можно выяснить, что большая часть из них просто несущественна.
                  У малого бизнеса так оно  и есть. Знание стандартов начинает играть роль, если клиент крупно-средний или крупный.