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

Доступ к резервному копированию и бэкапам недостаточно защищен

В первую очередь необходимо определить круг лиц, имеющих доступ к управлению процессами резервного копирования и содержимому резервных копий. Нередки случаи, когда ответственным за резервное копирование назначают просто наименее загруженного сотрудника ИТ-отдела компании. Чтобы минимизировать влияние человеческого фактора, рекомендуем назначать как минимум двух сотрудников, которые будут отвечать за резервное копирование и иметь полномочия на восстановление данных. Таким образом, в случае отсутствия одного сотрудника (отпуск, больничный, увольнение), его обязанности перейдут к другому.

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

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

Также в Кибер Бэкапе реализована возможность установки пароля на создаваемые резервные копии, парольная защита хранилищ и SSL-шифрование коммуникаций между компонентами системы.

Резервные копии и исходные данные располагаются в одном хранилище

Существует простая истина, проверенная поколениями администраторов на практике. Если вы храните резервные копии на том же сервере, что и исходные данные, и с сервером вдруг что-то происходит, то вы теряете всё – и исходные данные, и их копии. Поэтому бэкапы должны храниться отдельно от исходных данных, по возможности в нескольких экземплярах на носителях различного типа, часть из которых может быть отключена от локальной сети. Именно об этом правило «3-2-1» – базовый закон резервного копирования.

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

Вместо резервного копирования используются  RAID-массивы

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

Вместо резервного копирования используется программная репликация

Иногда резервное копирование подменяют программной репликацией (не следует путать с репликацией резервных копий). Программная репликация – это механизм, обеспечивающий возможность аварийного восстановления сервисов и данных компании. Репликация позволяет в реальном режиме копировать данные между основным и резервным центром обработки данных (ЦОД).

Репликация используется для обеспечения возможности быстрого переключения между ЦОД в случае аварии, для распределения нагрузки между системами и т. д. Она никак не может служить заменой резервному копированию. Рассмотрим пример. Предположим, из базы данных случайно или преднамеренно удалили какую-то информацию – эта информация будет удалена и в резервном ЦОД (возможно, не мгновенно, но это произойдет). Аналогично и при заражении вирусом – все зараженные объекты вскоре попадут и в резервный ЦОД.

Репликация – это «зеркало» всей системы или ее части на текущий момент. Бэкап – это «снимок», который отражает состояние системы в прошлом, что позволяет использовать его для восстановления утерянных данных.

В бэкап попадают файлы, зараженные вредоносным ПО

В последние годы тема кибербезопасности не сходит с первых полос печатных и интернет-изданий. Тема эта непосредственно касается резервного копирования. Представим такой сценарий: происходит заражение системы вредоносным ПО, администратор запускает восстановление данных и… в результате вы снова получаете зараженную систему, поскольку данные в резервной копии уже были заражены на момент ее создания (вирус может активироваться не сразу, а через некоторое время).

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

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

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

Расписание заданий резервного копирования составлено некорректно

Итак, мы назначили ответственных за бэкап сотрудников, позаботились о кибербезопасности, настроили создание нескольких резервных копий в соответствии с правилом «3-2-1», но это далеко не всё.

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

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

Возможность запуска и приоритет процессов резервного копирования регулируется настройками СРК. Так, в Кибер Бэкапе можно задавать уровень производительности резервного копирования (высокий, низкий или запрещено) для каждого часа недели. Также есть возможность перераспределять нагрузку в системе, перенося такие дополнительные операции, как репликация, проверка резервных копий и применение правил хранения, с защищаемого объекта на другие компоненты системы.

Не контролируется статус выполнения заданий резервного копирования

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

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

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

Не проверяется возможность восстановления из резервных копий

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

Мы рекомендуем регулярно тестировать возможность восстановления из бэкапов. Это можно делать раз в месяц или квартал – в зависимости от требований конкретной организации. Однако не следует путать две вещи: проверку (валидацию) резервной копии и проверку возможности восстановления данных из бэкапа.

В процессе валидации Кибер Бэкап проверяет сам файл резервной копии: вычисляет контрольную сумму для каждого блока данных, который можно восстановить из этой копии. Процедура полезная, но это не панацея. Тестирование восстановления подразумевает, что вы в действительности пытаетесь восстановить данные из резервной копии. Например, при резервном копировании операционной системы мы рекомендуем выполнить тестовое восстановление с загрузочного носителя на запасной жесткий диск или запустить виртуальную машину из резервной копии в среде ESXi или Hyper-V.

Отметим, что, помимо решения основной задачи, проверка возможности восстановления данных заодно позволит узнать, сколько времени займет восстановление, и рассчитать время и стоимость простоя ИТ-системы.

Не осуществляется контроль за свободным местом в хранилище

Если не контролировать заполняемость хранилища резервными копиями, оно переполнится и бэкапы  перестанут создаваться, поскольку для них просто не будет места.

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

Не настроен сетевой канал между компонентами системы резервного копирования

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

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

Заключение

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

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

Надеемся, что наша статья поможет вам избежать типичных ошибок и правильно настроить бэкап данных. Если вас заинтересовало решение для резервного копирования Кибер Бэкап, вы можете развернуть систему у себя и оценить все ее возможности в течение бесплатного 30-дневного пробного периода.