Слишком долгий период между полным резервным копированием
Суть ошибки такова. В целях экономии полное резервное копирование выполняется один раз в течение длительного периода, допустим, раз в месяц. А для поддержания актуальности сохраняемых данных служит множество инкрементных или дифференциальных копий. Обычно такую странную схему создают из-за экономии средств на носители или для сокращения времени использования окна бэкапа. Все бы ничего, но при восстановлении приходится задействовать большое число инкрементных копий, что само по себе может значительно увеличить время «реанимации», а. следовательно, удлиняется пауза в работе бизнес-процессов.
Некоторые системы резервного копирования, например, Acronis True Image, при повреждении одной из инкрементных копий перестают «видеть» и все последующие, созданные уже после поврежденной. Но самое страшное в этом случае - утрата единственной полной копии за требуемый период. Случись это с еженедельным бэкапом - бизнес потеряет информацию за семь дней, кроме того, возможно, удастся восстановить какие-то данные из инкрементных копий. Но в приведенном случае теряется вся работа за очень долгий период. Поэтому пользы от такого резервного копирования практически никакой.
Слишком много полных копий
Это другая крайность по сравнению с предыдущей ситуацией. Допустим, у администратора хватает и места на диске или ленте, и временного промежутка, чтобы выполнять полное резервное копирование. Он с удовольствием этот факт использует. Все бы ничего, но объем данных со временем обычно увеличивается. Растет и бизнес, появляются новые серверы в инфраструктуре, уплотняется рабочий график, все это неизменно ведет к тому, что для выполнения постоянного полного резервного копирования не хватает ни места, ни временного отрезка в «окне бэкапа». Я уже упоминал выше о необходимости постоянного мониторинга объемов информации, подлежащей сохранению. В описываемом случае объем исходных данных может быть не очень большим, но забивать носители для хранения резервных копий множеством мало отличающихся друг от друга версий вряд ли оправдано. Гораздо разумнее организовать инкрементное или дифференциальное резервное копирование, а еще лучше сделать это сразу, чтобы не изменять уже настроенную и работающую систему на ходу.
Много копий на одном носителе
Эта ошибка характерна для небольших компаний, где объем копируемых данных весьма незначительный. Возникает соблазн вместо ротации нескольких сравнительно дорогих носителей все записывать на меньшее число кассет. Проблема заключается в том. что при утрате одного, ставшего уже драгоценным носителя (например, при размагничивании, механическом повреждении, ошибках файловой системы на дисковом томе и т.д.) теряются резервные копии за весьма длительный период.
***
О резервном копировании можно говорить и писать очень долго. Нет сомнения, что эта сфера крайне важна для бизнеса. В то же время это такая область ИТ - технологий, в которой для достижения сходных целей можно использовать различные методы. Мы рассмотрели теоретические и практические основы резервного копирования, познакомились с технологическими аспектами, выработали примерный план внедрения, разобрали некоторые ошибки. Надеюсь, что этот материал поможет читателям создавать эффективные и надежные системы сохранения данных.
- << Назад
- Вперёд
