«Бэкап Шрёдингера». Кое-что важное про успешность аварийного восстановления данных

Оставить комментарий
«Бэкап Шрёдингера». Кое-что важное про успешность аварийного восстановления данных

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

Бэкап по расписанию

Существует три основных метода резервного копирования.

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

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

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

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

Только реализуемый по расписанию автоматизированный бэкап позволяет рассчитывать на восстановление актуальных данных. Точная схема бэкапа формируется исходя из требований проекта к скорости восстановления.

Не все бэкапы одинаково полезны

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

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

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

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

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

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

Также данным угрожает неправильный выбор средства резервного копирования. Например, когда администратор использует бэкап для виртуальной машины, на которой  работает база данных, без поддержки целостности приложения (application aware backup).

Однако БД активно использует кэш в оперативной памяти, где и находится часть данных. СУБД записывает данные на диск, и они всегда согласованы между собой. При этом система бэкапа не учитывает синхронизацию кэша с файловой системой и записывает данные не мгновенно. Это приводит к тому, что при резервировании часть данных может быть записана в неправильном порядке, и когда ВМ восстановится — база будет повреждена. 

Бэкап как сервис

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

Существует два вида проверки резервных копий: когда проверяется целостность самой копии (то есть, идёт сверка контрольных сумм блоков её данных), и когда происходит проверка в песочнице корректности восстановления системы из резервной копии.

Однако на практике большинство компаний не проверяют резервные копии ни одним из этих методов. Более того, даже в необходимости бэкапа ещё не все убеждены. В далёком 2015 году в компании Backblaze провели опрос пользователей и выяснили, что только 8% опрошенных резервируют данные каждый день, 39% — раз в год, а 25% — никогда.

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

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

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

Большинство крупных Managed IT провайдеров предлагают бизнесу бэкап как сервис. Тестирование восстановления из резервных копий надёжные провайдеры проводят по умолчанию, что особенно важно, если в стратегии используется дифференциальный или инкрементальный метод резервного копирования, при которых выше риск проблем с резервными копиями.

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

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

Северный Рейн-Вестфалия на пути к цифровизации – шансы для белорусского бизнеса
Северный Рейн-Вестфалия на пути к цифровизации – шансы для белорусского бизнеса
Северный Рейн-Вестфалия на пути к цифровизации – шансы для белорусского бизнеса
Северный Рейн-Вестфалия на протяжении многих лет является излюбленным местом локализации иностранных компаний в Европе. Удачное местоположение региона стало настоящим залогом успеха: Северный Рейн-Вестфалия — это инновационная и открытая земля с большим потенциалом для развития бизнеса в сфере цифровой трансформации. 
3 комментария
«Если бы все бизнесы были венчурными, это был бы караул!» Бизнес-ангел Angels Band — о грамотном делегировании, пределах влияния на стартап и идее ИТ-квартала
«Если бы все бизнесы были венчурными, это был бы караул!» Бизнес-ангел Angels Band — о грамотном делегировании, пределах влияния на стартап и идее ИТ-квартала
«Если бы все бизнесы были венчурными, это был бы караул!» Бизнес-ангел Angels Band — о грамотном делегировании, пределах влияния на стартап и идее ИТ-квартала
3 комментария
«Мы знаем, чего хотят айтишники». Владелец сдающегося в аренду офиса на 200+ мест в центре Минска — о «крутых опциях» и «приятном соседстве»
«Мы знаем, чего хотят айтишники». Владелец сдающегося в аренду офиса на 200+ мест в центре Минска — о «крутых опциях» и «приятном соседстве»
«Мы знаем, чего хотят айтишники». Владелец сдающегося в аренду офиса на 200+ мест в центре Минска — о «крутых опциях» и «приятном соседстве»
8 комментариев
«Мы понимаем боль пользователей, вынужденных решать сложные задачи на компьютерах и мониторах, собранных в 2000-х». Продолжение истории про выброшенный из окна монитор
«Мы понимаем боль пользователей, вынужденных решать сложные задачи на компьютерах и мониторах, собранных в 2000-х». Продолжение истории про выброшенный из окна монитор
«Мы понимаем боль пользователей, вынужденных решать сложные задачи на компьютерах и мониторах, собранных в 2000-х». Продолжение истории про выброшенный из окна монитор
1 комментарий

Обсуждение

Комментариев пока нет.
Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже