Акция

Миграция с других систем

Скидка на систему «ДЕЛО» при миграции с других решений.

Получите бесплатную демоверсию и консультацию

+7(495) 221-24-31

Вернуться к списку

Десять самых распространенных ошибок архивации

Даже при самых благих намерениях IT-специалисты порой оказываются не в состоянии реализовать надежный механизм резервного копирования данных. Возможно, с некоторыми из описанных проблем приходилось сталкиваться и вам.

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

1. Недостаточно регулярная архивация состояния системы

Срок годности резервных копий состояния системы в среде Windows ограничен. Для контроллеров домена он равен максимальному возрасту захоронения и по умолчанию составляет составляет 60 дней. По истечении этого периода резервная копия становится недействительной. Это актуально и для других типов систем.

Все компьютеры в локальной сети Windows имеют учетные записи в Active Directory. Как и в случае с пользовательскими учетными записями, каждому компьютеру присвоен пароль, который присваивается системе автоматически и периодически изменяется. При попытке восстановить систему из устаревшей резервной копии с давно не актуальным паролем учетной записи в Active Directory, компьютер лишится возможности участвовать в домене. Эту проблему, разумеется, можно решить, но куда проще осуществлять резервное копирование состояния сервера на регулярной основе.

2. Сохранение резервных копий без проверки их работоспособности

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

3. Резервное копирование без учета специфики приложений

Для некоторых приложений резервного копирования на файловом уровне недостаточно. Классический пример – резервное копирование Microsoft Exchange, который требует специализированного подхода к архивации. Если такого подхода не обеспечить, резервная копия будет неполной и может даже оказаться совершенно бесполезной при восстановлении данных. С этой точки зрения очень важно знать, какие приложения установлены на серверах, и учитывать их специфические требования.

4. Преждевременная отправка резервных копий на склад

Одна из компаний, в которых мне доводилось работать, практиковала отправку резервных копий с курьером на удаленный склад. Каждое утро в 8:00 записанные ночью пленки с резервными копиями увозили из офиса. Однажды наш сервер дал сбой в 9:30 утра, но сразу же приступить к восстановлению данных мы не смогли, потому что архивную копию уже отправили на склад. Вернулась в офис она только к четырем часам дня, и все это время сервер был в простое. Без сомнения, хранить резервные копии в безопасном месте – хорошая идея, но увозить их на склад стоит хотя бы в конце рабочего дня, а никак не утром.

5. Наличие единой точки отказа

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

6. Неумение планировать на будущее

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

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

7. Необдуманное использование механизмов обеспечения безопасности при архивации

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

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

8. Архивация одних только файлов данных

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

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

9. Хранение архивных копий исключительно на резервном сервере

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

10. Слишком быстрая перезапись пленок

В одной из организаций, где мне доводилось работать, было принято записывать новые резервные копии поверх старых двухнедельной давности. В целом подход был неплох, но двухнедельный интервал оказался слишком маленьким. Как-то раз у нас рухнул сервер Exchange из-за повреждений информационного хранилища. Когда мы попытались восстановить его из резервной копии, оказалось, что повреждения присутствуют и в ней. Проблема, как выясняется, возникла еще давно и со временем все прогрессировала. Повреждения сохранились во всех наших резервных копиях за последние две недели, так что восстановить сервер мы не смогли. Это прекрасный аргумент не только в пользу периодической проверки архивных копий на работоспособность, но и в пользу того, чтобы сделать больше интервал между перезаписью магнитной пленки или сохранять хотя бы некоторые из них для долгосрочного архивирования.

Автор: Brien Posey
Источник: www.winblog.ru


Возврат к списку


Ольга Савко

Начальник группы телемаркетинга

Получите качественную бесплатную консультацию

Акция

Переход на отечественную АИС МФЦ

Скидка на право использования АИС МФЦ «ДЕЛО» при миграции с других решений по автоматизации МФЦ

Акция

«Амнистия» по техподдержке

Акция для клиентов, у которых есть просроченная техподдержка до 01.01.2015

Календарь мероприятий

28ноября

На конференции в Ереване ЭОС представил ECM-решение e-gorts, локализация EOS for SharePoint для Армении

Узнать больше

15ноября

ЭОС - участник форума «Искусственный интеллект, большие данные, отечественный софт: национальная стратегия»

Узнать больше

26октября

Важнейшее IT-событие октября - конференция «Осенний документооборот»

Узнать больше

Наши клиенты

7 000 компаний

Наши партнеры

250

во всех городах России
и странах СНГ