 |
|
|
|
Делайте бэкап бэкапа!
Делайте бэкап бэкапа!
Говорят, что Международный день резервного копирования был недаром назначен накануне 1 апреля, чтобы подстраховаться от злых шуток и первоапрельских вирусов. Так это или нет, но чувство ужаса от исчезнувшей на глазах цифровой информации, наверное, испытывает каждый ИТ-профессионал хотя бы однажды в жизни. И тут уж не до смеха! Сбой в работе системы или потеря данных каждый раз, грубо и зримо, напоминают о важности бэкапа. Давайте же обменяемся опытом хранения данных. Вопросы для экспертов:
Вопрос 1. Как производить резервное копирование (не снепшот и не репликацию, а полноценную реализацию) в условиях постоянно растущих объемов данных?
Резервное копирование можно осуществлять с помощью любого удобного ПО. Оно должно отвечать потребностям компании в бэкапе, аварийном восстановлении и в эргономике. Учитывая постоянно растущие объемы данных, я бы рекомендовал рассматривать ПО, способное работать с облачными хранилищами. Отдельно хотелось бы упомянуть бэкап на магнитную ленту. Это емкий и не требующий дополнительного электропитания носитель: записали и убрали в сейф или увезли в другой офис. Данный вид бэкапа помогает соблюдать «Правило 3-2-1», которое предполагает создание как минимум трех резервных копий. Они должны быть сохранены в двух различных физических форматах, причем одна из этих копий должна храниться в другой локации.
Для резервного копирования в условиях постоянно растущих объемов данных нужно всего две вещи: ПО и оборудование, предназначенное для хранения резервных копий, то есть ленточные библиотеки и/или система хранения данных. Важно, чтобы и программное, и аппаратное обеспечение позволяло легко и относительно недорого масштабировать систему в соответствии с задачами компании. Также окажутся полезными и средства экономии дискового пространства, такие как дедупликация и компрессия.
Сейчас для этого существуют все возможности. Прежде всего, необходимо тщательно проработать регламент резервного копирования. Конечно, желательно использовать модель 3-2-1, когда два набора резервных копий данных располагаются на разных типах носителей, при этом один набор хранится на удаленной площадке или в облачном хранилище. Необходимо также применять различные методы уменьшения окна резервного копирования, выполнять его инкрементально, использовать сжатие и дедупликацию. Использование консистентного резервного копирования на уровне приложений позволяет быстрее восстанавливать отдельные объекты с высокой гранулярностью. Кроме того, система резервного копирования должна хорошо масштабироваться. На рынке есть достаточно широкий выбор разнообразного ПО, который поможет этого добиться. Кстати, правильно настроенная репликация с возможностью возврата к нескольким точкам восстановления также является эффективным и современным способом резервного копирования.
В условиях постоянно растущих объемов данных, по возможности, стараются организовать горизонтальное масштабирование системы. С точки зрения бэкапа, каждый дополнительный компонент такой системы может рассматриваться как отдельный модуль и бэкап может настраиваться для него независимо от остальных. Например, при добавлении нового сервера в систему на нем может быть бэкапный диск, на который периодически резервируется вся важная информация, хранящаяся на данном сервере.
В первую очередь следует определиться, насколько часто нужны резервные копии. Здесь всё индивидуально. Надо понять, как часто меняется информация на сервере, есть ли возможность восстановления информации без восстановления из резервной копии и т. п. Важно также разделить информацию на сервере на три типа – информация, которая не меняется долгое время; информация, которая меняется постоянно (базы данных); информация, утрата которой не критична (журнальные файлы, файлы операционной системы, конфиги). Исходя из класса информации, можно настроить разные политики резервного копирования. Например, конфигурационные файлы, изменения которых крайне редки, можно хранить на отдельном носителе и не копировать постоянно. Файлы операционной системы легко восстановить, их тоже нет смысла копировать. Таким образом, осталось только два типа данных, которые нужно защищать. Эти два типа можно зарезервировать с теми же базами данных – настроить репликации для информации, которая редко меняется. Обычно это статические файлы, их тоже можно зарезервировать и делать копии уже в процессе. Основная задача – разбить большой объем данных для копирования на более мелкие сегменты. Так копировать проще, быстрее и дешевле.
Резервное копирование стоит разделить на несколько подпунктов: а) разделить информацию на типы данных и создать политики (транзакции могут храниться 10 лет, а история изменения профиля – 1 день и т. д.); б) в зависимости от типа данных настроить разные методы резервирования, к примеру: медиа и прочие файлы (которые постоянно растут, причем возможно довольно быстро) можно хранить в так называемых инкрементных бэкапах (от англ. Incremental backups), когда вместо полного снепшота делается бэкап лишь той порции данных, которой не было в прошлом бэкапе (дельта) – базы данных идеально реплицируются и реплик может быть много, распределенных по гео. Делать бэкапы серверов в целом, наверное, уже исторический вариант, современные инструменты позволяют относиться к конфигурациям сервера и исходному коду вместе с приложениями довольно утилитарно и разворачивать их из заранее созданных образов, поэтому его предлагаю даже не рассматривать; в) настроить шифрование данных при передаче и при хранении и обезопасить доступ.
Человечество ежегодно генерирует колоссальные объёмы информации. Даже если не принимать в расчёт те данные, которым не требуется сохранение в резервных копиях, то задача по резервированию все равно требует больших ресурсов. Для ежедневной обработки растущих объемов необходимо применять профессиональные системы резервного копирования. Они используют различные технологии, методики и алгоритмы, призванные сократить количество передаваемой и хранимой информации, снизить нагрузку на сети и оборудование, обеспечить восстанавливаемость данных из резервных копий. Выбор правильного способа создания резервных копий зависит от многих факторов, например от ценности данных или частоты их изменения. На основе этих характеристик определяются требования к RPO/RTO и создается план резервного копирования. Есть известная концепция 3-2-1 от профессионального фотографа Петера Крога – три резервные копии на двух разных типах носителей и одна копия вне основной площадки размещения информации. И, конечно, обязательное регулярное тестирование резервных копий на возможность восстановления.
Правильный ответ зависит от целей и задач, которые стоят перед конкретной организацией. Объемы растут, но одновременно снижается стоимость хранения данных и длительность самого сохранения. Кроме того, объем уникальных данных растет незначительно. В зависимости от типа данных определяются периодичность копирования и сроки хранения, а вместе с ними – способ и тип резервного копирования. Различают полный, инкрементальный (добавочный) и дифференциальный бэкапы. Например, рабочие файлы требуют создания регулярных копий, при этом важно соблюдать версионность, что даст возможность вернуться к промежуточным версиям одного и того же файла. Иными словами, нужно предусмотреть возможность отката версий. Такой бэкап называется дифференциальным – т. е. новые версии вновь скопированных файлов не замещают более старые версии. Очевидно, что для такого копирования требуется автоматизированная система. Существует достаточно много утилит разной степени функциональности, поддерживающих разные типы накопителей для сохранения информации, включая облачные сервисы, сетевые хранилища и FTP-ресурсы. Если же мы говорим об огромных базах данных, то там процесс резервирования осуществляется средствами самой СУБД. Также следует помнить, что сами средства хранения резервных копий должны быть защищены от сбоев, возможных атак шифровальщиков, случайного или злонамеренного уничтожения. Поэтому важная информация всегда должна иметь несколько параллельных копий.
По нашему мнению, здесь существуют две проблемы. Первая, как сохранять растущие объемы фронтенд данных. Здесь могут быть применены специальные технологии, например, такие как резервное копирование на основе блоков для файловых серверов или СХД или Change Bock Tracking для виртуальной инфраструктуры, также специализированные протоколы, такие как DDBoost, которые помогут записывать только измененные блоки без необходимости передавать весь объем фронтенд данных по Ethernet или SAN/WAN. Вторая, как хранить быстро растущие объемы резервных копий. Здесь поможет технология дедупликации. Сейчас есть реализации как на аппаратном, так и на программном уровнях. Реализация этой технологии в линейке Data Domain была одна из первых на рынке и до сих пор остается наиболее эффективной с точки зрения сокращения объемов хранимых данных. Могу привести пример одного из наших заказчиков в России, который смог достичь коэффициента дедупликации 110:1, т. е. хранить в 110 раз меньше информации, чем если бы он использовал традиционные подходы для хранения данных.
Полагаем, что в условиях постоянно растущих объемов данных для осуществления полноценного резервного копирования компаниям необходимо: Продумать эффективную стратегию резервного копирования, которая позволит минимизировать потерю данных при их восстановлении. Закупить и внедрить необходимую инфраструктуру (ПО и «железо») для реализации этой стратегии. На данный момент рынок располагает широким спектром таких решений. Закупленная и внедренная инфраструктура под эффективное резервное копирование должна быть масштабируемой с учетом возможного роста объемов данных. Для того чтобы правильно спрогнозировать рост данных, в компании должен быть внедрен процесс Capacity Management. Данный процесс поможет вовремя заметить растущий объем данных и принять решение о закупке необходимого оборудования, чтобы не оказаться в ситуации, когда в информационных системах не хватает места как для новых данных, так и для бэкапов. В компании должен быть внедрен процесс тестирования бэкапов. Это нужно для того, чтобы быть уверенными в том, что из созданных бэкапов возможно выполнить успешное восстановление системы. Поэтому нужны не только специалисты по резервному копированию, но и специалисты по восстановлению данных, которые способны вовремя восстановить и проверить эти данные.
Нет никакого смысла в постоянном создании полных копий данных. Для того чтобы поддерживать актуальность бэкапа, можно воспользоваться одним из двух принципов резервного копирования. Инкрементальный подход подразумевает, что после создания первоначальной копии изменения в нее вносятся только при изменениях в структуре файлов. Дифференциальное резервное копирование отличается тем, что после создания первой копии все последующие содержат не все данные, а только произошедшие изменения. Таким образом, создав один раз полную копию, в нее вносятся только актуальные изменения. Это экономит и время, которое тратится на копирование, и место, необходимое для хранения копий. Например, можно один раз в месяц делать полную копию, а в ежедневном режиме копировать только те файлы, в которые вносились изменения.
Да, объемы всегда будут расти, этого не избежать. Но можно избежать резервного копирования неактуальных данных или даже серверов. Часто из-за большого количества виртуальных машин уже и не помнишь, нужна та или иная. Она вовсе может оказаться год как выключенной. Нужно время от времени следить за этим. Кроме того, сервисы бэкапирования предлагают быстро сжимать данные для хранения. Но есть некоторые проблемы с зашифрованными дисками linux. Их сжимать тяжеловато. И не стоит забывать, что пространство HDD стоит небольших денег. Потому, мне кажется, что эти факторы пока компенсируют рост объема данных.
Не так важно есть ли у тебя бэкапы. Важно – есть ли у тебя ресторы! Много лет назад наблюдал смерть популярного интернет-проекта. Сам проект – коллекция работ учеников и студентов (курсовые, рефераты и т. д). Хороший, крупный проект. Как обычно это и бывает, сервер «накрылся». Но это не было проблемой – бэкапы делались ежедневно, велся четкий контроль списка файлов к сохранению. Оно и понятно: сами файлы материалов – основной актив сайта. Поэтому аппаратная часть сервера была заменена, файлы восстановлены из бэкапа, но… сайт «не завёлся». Не буду описывать процесс поиска проблемы, суть была в том, что файлы на машине с бэкапами были нулевого размера. Только имена. Восстановление произошло, но только формально. Сами материалы были безвозвратно утеряны. Здесь опять опущу описание многодневных поисков решения проблемы, но проект восстановиться не смог. Почувствуйте себя на минутку владельцем коллекции, которую вы собирали годами и которая вся была потеряна за несколько минут из-за простого недосмотра. Я уже много лет сам не настраиваю бэкапы. Но я очень хорошо запомнил одно: неважно, есть ли у тебя бэкап, важно – сможешь ли ты сделать рестор. Конечно, нельзя сравнивать техническую реализацию системы бэкапирования многолетней давности и современные программные комплексы. Конечно, сейчас «защита от дурака» находится на высоком уровне. Но даже сегодня регулярно случаются проблемы. Например, «скопировал файлы бэкапа, попытался выполнить восстановление, оказалось, что это только файлы инкремента»… Ну и привет. Есть только один действительно надежный способ предотвращения подобных ситуаций: выполнять полный цикл DR-процедур. То есть регулярно пробовать полностью восстановить работу системы из бэкапов. Этот принцип с годами не меняется. Вы не можете знать, насколько успешно работает ваша система, если не попробовали полностью восстановить ее работу из резервной копии или не пытались переключиться на резервные мощности. Эти тренировки должны проходить регулярно. Конкретный срок определяется требованиями к актуальности для каждого отдельного проекта: неделя, месяц, полгода, год. Чем реже – тем больше вероятности забыть процедуру и в критической ситуации потерять драгоценное время. Да, это дополнительные затраты – как минимум на «железо», на которое надо выполнить восстановление. Да, всё-таки на «боевую» машину попытаться восстановить из бэкапов ваш сервис – плохая идея. Что-то может пойти не так, и вы собственными руками похороните свои данные. Так плохо. Хорошо восстанавливаться куда-то еще. Но эти затраты могут быть существенно меньше, чем потеря данных. Как ни странно, в России почему-то не особо принято разрабатывать DR-планы. Да, бэкапы делают почти все. Но выполнение DR-процедур – отключить основной сервис, восстановиться из бэкапов, переключиться на резервные мощности, описать, что надо делать, если всё-таки не удалось восстановить сервис, – почему-то до сих пор редкость, даже в весьма крупных компаниях. Также довольно часто можно слышать «мы не делаем, потому что это делает наш поставщик облачных ресурсов». А вы видели? А вы проверяли? А по вашему запросу уже восстанавливали? Я бы не рискнул доверять этим словам даже лучшего друга. Ну просто потому, что все люди ошибаются. Делайте ресторы. Спите спокойно.
Объемы хранения данных увеличиваются с каждым годом. Если в 2020- м году во всем мире хранилось порядка 50 Зеттабайт информации, то за ближайшие 10 лет объемы данных вырастут на порядок и превысят 500 Зеттабайт, что еще недавно казалось немыслимым объёмом информации. Значимая часть этой информации важна и не может быть утеряна, поэтому должна храниться в резервных копиях - и тут встает вопрос, как справляться с все более возрастающими объемами данных. Современные системы резервного копирования используют различные способы как для снижения нагрузки на систему резервного копирования, чтобы не гонять одни и те же данные раз за разом по сети, так и при хранении. Для контроля размеров копий используются классические подходы инкрементального или дифференциального резервного копирования. Сначала выполняется первое полное резервное копирование, такая копия обладает автономностью, но ее создание требует много времени, ресурсов сети и особенно хранилища. Создавать все время полную копию очень накладно, поэтому делают дифференциальные копии, где сохраняются только различия между текущим состоянием системы и ее последней полной копией. Для восстановления из дифференциальной копии нужно, чтобы последняя по времени полная копия также была рабочей. Такие копии создаются быстро, но размер все равно может быть большим и необходимо для восстановления обработать две копии – полную и дифференциальную. Еще один подход - создание инкрементной резервной копии, в которой сохраняются различия между текущим состоянием системы и любой последней по времени резервной копией. Последняя копия может быть полной, дифференциальной или тоже инкрементной – для инкрементного копирования это не важно. Восстановление из инкрементной копии самое долгое, ведь необходима обработка последней полной копии и каждой последующей инкрементной вплоть до директивной точки восстановления. В результате восстановление системы из резервных копий этого типа может занять очень много времени. Большинство современных программ для резервного копирования позволяет объединять инкрементные копии в автономном режиме. Это значительно повышает надежность копирования и ускоряет процесс восстановления. Резервное копирование с автоматической консолидацией при создании копий называется обратно-инкрементным. Для экономии хранилища используются ряд походов. Прежде всего, различные методы сжатия, которые подразумевают уменьшение размера файлов и выполняются с помощью различных алгоритмов, заменяющих повторяющуюся информацию сокращениями. Этот метод эффективен, когда данные содержат большое число предсказуемых элементов. Например, если компания называется Акронис Инфозащита, то это словосочетание будет часто появляться в документах. Программа зарегистрирует этот факт и создаст для него сокращение. Сжатие часто используется для локальных резервных копий и работы хранилищ. Для сжатия есть несколько ограничений – ряд данных, например, видео-файлы ужимаются очень плохо, т.к. они уже сжаты, и дополнительно уменьшить их в резервной копии не получится. Зашифрованные данные по сути своей непредсказуемы, поэтому их тоже нельзя сжать. Более того, если вы можете сжать зашифрованные данные, это повод задуматься о замене системы шифрования. Дедупликация (или устранение дублирования) работает аналогично сжатию. Например, вам необходимо создать сто резервных копий образа системы стандартных корпоративных компьютеров. В этих копиях все время будут повторяться одни и те же файлы ОС, и большое число дубликатов займет много лишнего места. С помощью дедупликации можно сохранить одну копию общих данных, на которую в каждой резервной копии будет сделан специальный указатель. Можно использовать несколько методов дедупликации. Сначала применяется дедупликация на лету: она сокращает объем данных, записываемых в архив резервных копий. Затем можно выполнить постобработку для дедупликации готовых архивов. Таким образом, для обеспечения эффективного резервного копирования необходимо использовать решения, в которых уже реализована поддержка корпоративных процедур бэкапа для современных размеров файловых хранилищ и баз данных.
Существует несколько законов и нормативных документов, которые исчерпывающе покрывают собой затронутую в вопросе тему. Основными можно назвать: Закон «Об информации, информационных технологиях и о защите информации», Закон 152-ФЗ «О персональных данных», приказы ФСТЭК и ФСБ России, постановления Правительства РФ и стандарты Банка РФ. Требований множество, всё зависит от вида данных, ситуаций их использования на практике.
К хранению данных предъявляется огромное количество требований регуляторов, и в каждой отрасли они будут кардинально отличаться. В частности, это могут быть требования к срокам хранения или к его особенностям относительно специальных видов документов. Например, банковские документы нужно хранить пять лет.
В разных отраслях свои требования, однако в целом они отличаются характеристиками RPO и RTO – насколько часто нужно выполнять резервное копирование данных и насколько быстро иметь возможность восстановиться в случае их потери. Часто требования регуляторов довольно консервативны и не вполне соответствуют последним тенденциям и возможностям индустрии. Компаниям я бы посоветовал, разумеется, соответствовать всем требованиям, но и продолжать следить за новинками.
Требования регуляторов, вполне возможно, отличаются от отрасли к отрасли, однако можно выделить общий тренд – локализация хранения на территории РФ и передача сведений о хранении и обработки данных Роскомнадзору, более детально могут ответить юристы и профессионалы из отраслевых предприятий.
Если организация обрабатывает информацию ограниченного доступа, например, персональные данные, то в этом случае должны выполняться требования российского законодательства к средствам резервного копирования. Средства резервного копирования и восстановлениях данных могут быть сертифицированы по требования регуляторов, и использование таких средств позволяет компании не проводить оценку соответствия своей системы копирования. Операторы ПД должны руководствоваться в первую очередь 152-ФЗ «О персональных данных». Кроме того, существует ряд других законодательных требований к информационной безопасности процесса резервного копирования информации, например, законы «Об информации, информационных технологиях и о защите информации», «О банках и банковской деятельности», а также различные приказы ФСТЭК и ФСБ.
Существуют несколько законодательных требований регуляторов, специфических для различных областей. К примеру, свои требования действуют для защиты персональных данных, коммерческой тайны, индустрии платежных карт и т. д. Приняты и международные стандарты по информационной безопасности, которые тоже нужно соблюдать. Отметим, что все требования по информационной безопасности должны действовать по отношению к резервным копиям на том же уровне, что и по отношению к работающим сервисам. Нельзя отгружать бэкапы или размещать системы резервного копирования в менее защищенные локации.
Самым интересным требованием было шифрование данных резервных копий, лежащих на зашифрованных дисках. А также шифрование передаваемых данных во время бэкапа. В общем, шифрование в шифрование с шифрованной передачей. Очень спорное решение. Самое страшное я предполагал, что после перезагрузки NAS и расшифрования дисков файлы бэкапов не расшифруются. Но всё работает.
У регуляторов требования к хранению и предоставлению определенных данных о пользователях. Фирма должна сама озаботиться сохранностью данных в случае сбоя. Бэкапы делаются, прежде всего, для нормального функционирования бизнеса, чтобы не получилось так, что после вышедшего из строя диска фирму можно закрывать.
Понятно, что вне зависимости от отрасли данные должны быть надежно защищены от потери. Для этого используются системы резервного копирования. В ряде случаев регуляторы предъявляют определенные требования к надежности и безопасности хранения данных, особенно это проявляется в так называемых объектах критической информационной инфраструктуры. Такие объекты должны соответствовать требованиям приказов ФСТЭК в части обеспечения безопасности. Практически все отрасли имеют собственные объекты КИИ, и резервное копирование помимо прочих мер защиты является обязательным для таких организаций.
Из личного опыта могу выделить следующие ошибки:
Самая типичная и распространенная ошибка при организации резервного копирования – вы будете смеяться – отсутствие резервного копирования. Очень часто резервных копий нет – и всё, с этим ничего нельзя сделать. Только организовать процесс, чтобы в следующий раз не столкнуться с такой же проблемой снова. Вторая частая ошибка – отсутствие регулярных проверок восстанавливаемости резервных копий. Это приводит к тому, что когда срочно требуется восстановить данные из резервных копий, внезапно оказывается, что сделать это невозможно. Причин может быть много: изначально неверная организация процесса резервного копирования, недостаток ресурсов для восстановления или другие технические ограничения. Чтобы избежать таких проблем, нужно проводить постоянные тренинги в области восстановления данных: записывать и обновлять процедуры, всё тщательно проверять.
Наиболее типичной ошибкой является отсутствие самого бэкапа – полного или для части систем. Ошибкой можно считать и отсутствие регулярных проверок целостности резервных копий и процедур восстановления данных. Также сюда можно отнести отсутствие полноценного регламента и хранение резервных копий рядом с исходными данными, т. е. на том же хранилище. Исправить это можно всегда (если данные еще не потеряны), доверившись профессионалам, например, «ЛАНИТ-Интеграции».
Существует 3 типовых заблуждения.
Отсутствие шифрования и низкий КПД, думаю, это основные проблемы бэкапа. Если с первым всё понятно, то со вторым я бы выделил целый кластер проблем, стоимость за хранения 1 ГБ данных может отличаться в десятки раз, если выбрать верную технологию и оператора хранения данных: скажем, магнитные диски у AWS стоят от 1.01 USD/мес за 1 ТБ данных (однако тут стоит иметь в виду, что не все данные могут покидать границы РФ).
Основная ошибка – это не делать резервные копии и полагаться на надежность систем хранения. Есть и другие, может быть, не столь очевидные. Например, делать резервную копию на ту же систему хранения или не хранить дополнительную копию за пределами своего центра обработки данных. Делать резервную копию слишком редко. Не следить за результатами работы системы резервного копирования и не проверять резервные копии на регулярной основе. Любые из этих ошибок можно с легкостью исправить до момента потери данных, после – уже будет сложнее.
Самыми распространенными я бы назвал следующие ошибки. Создание бэкапов вручную – это чаще всего приводит к низкой надежности. Сохранение бэкапов без их проверки, так как не все админы готовы тратить на это время. Удаление предыдущей копии бэкапа, когда еще не создана новая. Есть риск, что админ случайно удалит новый вместо старого и сотрет частичные бэкапы, что нарушит схему копирования. Хранение бэкапа на том же сервере в том же дата-центре. Ошибки бэкапа не всегда можно исправить, поэтому я рекомендую, во-первых, изолировать его или перенести данные на offline-носитель, без подключения к инфраструктуре. Также можно использовать иммутабельные (неизменяемые) хранилища. Во-вторых, необходимо регулярно проверять целостность резервных копий, так как в процессе создания копий может произойти сбой, и на выходе часть данных окажется битой. И в-третьих, дедуплицировать – сжатие или устранение избыточных копий данных помогает не превратить бэкап в свалку.
Типичная ошибка – это не тестировать бэкапы. Часто у разработчиков и администраторов много бизнес-задач и до тестирования бэкапов просто не доходят руки. С точки зрения бизнеса, тестирование бэкапов никакой прибыли не дает. И часто понимание зачем это нужно приходит уже после сбоя, когда понимаешь, что бэкап был не в полном объеме. Тут бороться нужно с собственной ленью путем самоорганизации и дисциплины.
Первая и главная ошибка бэкапа – игнорирование возможности резервного копирования данных. Конечно, если говорить о бизнесе, то сейчас всё меньше и меньше компаний пренебрегают этой процедурой. Однако это не значит, что резервное копирование стали делать абсолютно все. Случаев необратимой потери данных всё еще очень много. Вторая ошибка – неправильная настройка резервного копирования или же неверный выбор типа копирования. То, что вполне годится для домашнего пользователя, – не годится для компании. Выше мы уже говорили о том, что рабочие файлы и базы данных требуют создания регулярных копий для обеспечения версионности. Еще одна ошибка – сохранение только одной резервной копии на одном физическом носителе. Исправить ошибку можно до тех пор, пока данные не потеряны безвозвратно. Прежде чем это случилось, следует сделать ревизию системы резервного копирования и плавно перенастроить ее в соответствии с потребностями пользователей и организации в целом.
Самые типичные ошибки резервного копирования – это, в первую очередь, отказ от тестовых восстановлений. Некоторые из компаний недооценивают их важность. Они надеются, что все данные хранятся в порядке и при восстановлении проблем не будет. Но, как известно, надежда бывает обманчива. Далее можно выделить отсутствие регламентов выполнения резервного копирования – какие данные и когда нужно резервировать, сколько нужно хранить резервные копии данных; в какой последовательно нужно восстанавливать данные информационных систем при возникновении инцидентов. Зачастую заказчики хранят всё, что есть, пока не закончится место, или же стирают копии критичных данных, чтобы записать копии менее важных. Чаще всего это приводит к тому, что нужную копию уже не найти. Отдельно можно отметить, что часто проектируют систему резервного копирования не удовлетворяющую требованиям к производительности и надежности. И тогда при инциденте в дата-центре, страдает и система резервного копирования или же заказчик просто не успевает записать все данные и так же рассчитывает на авось. Не все ошибки можно исправить. Если изначально система резервного копирования построена неправильно, то в худшем случае при возникновении потери или порчи данных организации не сможет эти данные восстановить. А это означает большие убытки для бизнеса, а в некоторых ситуациях может послужить причиной закрытии компании.
Основная ошибка специалистов состоит в том, что они выполняют только резервное копирование, но не тестируют возможность восстановления данных. Чаще всего отсутствует план восстановления – disaster recovery plan. А работы по проверке плана восстановления – редкость. Пока не будет успешного тестирования восстановления системы, можно считать, что средств резервирования нет. Если система резервного копирования длительное время не выполняла консистентные бэкапы, то вряд ли можно будет исправить такую ошибку, если потребуется реальное восстановление из копии. Скорее всего, много важных данных будет утеряно и восстановить систему можно будет только на момент последнего консистентного бэкапа.
Типичная ошибка при организации резервного копирования – выбор ненадежного места хранения. Классический принцип хранения резервных копий 3-2-1 предусматривает выполнение трех правил: три копии данных, две копии на разных носителях и хранение как минимум одной копии в иной локации. В противном случае существует риск утраты данных. Также можно выделить невнимательность к актуальности резервных копий. Простого создания копии системы или файловой системы недостаточно. Современные решения позволяют настроить периодичность копирования – и это необходимо сделать сразу же после развертывания бэкап-системы. В облаке MCS поддержание копии в актуальном состоянии можно автоматизировать, для этого есть решения как самого провайдера, так и его технологических партнеров. Третья ошибка – несоответствие объема резервного копирования потребностям компании. Случается, что администраторы стремятся создать полные копии систем, тогда как достаточно организовать хранение актуальных копий баз данных или файлов, используя при этом инкрементный или дифференциальный принципы. Постоянный полный бэкап системы невыгоден экономически, потому что требует расходов на хранение больших массивов информации. Не оправдан он и технологически – для этого может потребоваться выделение «технологических окон» для работы бэкап-решения, что может привести к временной недоступности информационных систем. Для тех компаний, кто уже работает в облаке, этой проблемы не существует: они могут наращивать и сокращать объемы хранилища в зависимости от текущих потребностей.
Есть несколько ошибок. Первая – не делать систематическую проверку бэкапов. Нужно раз в единицу времени восстанавливать тестовый стенд из бэкапов. Вторая – надеяться только на один вид бэкапов, сделанный одним сервисом. Нужно всегда делать дополнительный бэкап, возможно, не такой частый как основной, но другими средствами. Да хоть простым экспортом ВМ. Третья – расположение бэкапов в одной географической точке. Нужно всегда иметь бэкап хотя бы критических ресурсов в отдельном от основного «здания». Четвертая – траты на хранение и процесс резервного копирования должны быть соизмеримы стоимости бэкапируемых данных. То есть нужно понимать рентабельность.
После того, как система резервного копирования установлена, и планы резервного копирования заработают, необходимо постоянно проверять работу на наличие ошибок. Проверка позволит убедиться, что все резервные копии созданы успешно, или, если это не так, поможет найти причину сбоев. Самая распространенная причина – нехватка места в хранилище резервных копий, на втором месте идут проблемы с сетевым подключением. В больших системах, где постоянно добавляется новое оборудование, зачастую забывают назначить план резервного копирования на новый сервер или рабочую станцию, а в результате данные там остаются без защиты. Подобные ошибки создают брешь в процессе резервного копирования/аварийного восстановления, их нужно устранять как можно быстрее. То есть, без устранения проблем с резервной копией, при возникновении ошибки на продуктивной системе вы не сможете восстановить самые актуальные версии данных или вообще не сможете вернуться к работе без дополнительных действий. Современные угрозы для резервных копий представляют, как ни странно, вирусы-вымогатели, для защиты от которых резервное копирование должно хорошо помогать, но проблема состоит в том, что большинство современных вирусов-вымогателей первым делом изучают систему на предмет наличия резервных копий и уничтожают или портят их так, что восстановить данные будет невозможно. Интеллектуальные технологии, такие как Acronis Active Protection, помогают предотвращать атаки на архивы с резервными копиями и не дают вредоносному ПО зашифровать или удалить данные. Самым удобным для пользователя является комплексное решение, которое совмещает в себе возможности резервного копирования, защиты от вредоносного ПО и управления параметрами системы. Подобные системы позволяют автоматически устранять большую часть проблем, приводящих к потерям данных.
Думаю, что акцент здесь должен быть на различные варианты синхронизации между площадками, а также наличие копии инфраструктуры в облаке. То есть в случае отказа сервиса, он просто переключается на ресурсы, которые заранее подготовлены, максимально быстро, чтобы избежать простоя.
Самому быстрому восстановлению с нуля уже никак не обойтись без использования облачных технологий. Не всегда всю инфраструктуру компания может развернуть в облаках. В основном это происходит по финансовым причинам. Но именно DRP (Disaster Recovery Plan), как мне кажется, уже подразумевает развертывание инфраструктуры в облаке. Например, синхронизация Active Directory баз данных в облако. А также хорошей практикой будет использование инструментов по типу Ansible c описанием тасков с ролями для экстренного поднятия инфраструктуры. Время от времени нужно проверять DRP в тестовом режиме, чтобы и команду обучить и проверить план.
Давайте определимся, что означают два этим модных слова. Disaster Recovery – аварийное восстановление. То есть если у вас произошла авария (пожар, затопление или другие форс-мажорные обстоятельства), то у вас должен быть рабочий инструмент восстановления штатной работы ИТ-инфраструктуры и ее данных. Любому ли бизнесу это нужно? Чтобы ответить на этот вопрос нужно определить: приведет ли потеря данных и/или остановка штатной работы ИТ-инфраструктуры к неприемлемому ущербу для бизнеса? Если ответ «нет», то заниматься этим не следует или следует, но в низкоприоритетном порядке. Тратить средства на такие процедуры, если потенциальная авария не приведет к серьезным неприятностям, абсолютно бессмысленно. А вот если ответ «да», то это вопрос, который откладывать не стоит. Авария подразумевает потерю площадки, где расположена ИТ-инфраструктура, – будь это серверная в офисе, стойки в ЦОДе или инфраструктура облачного провайдера. И авария может произойти везде. Распространено мнение, что если сервер расположен в облаке, то ему ничего не грозит, – но это ошибка. Инциденты касаются и крупных, и мелких облаков. Поэтому главное правило, если вам необходимы инструменты аварийного восстановления, – у вас должна быть альтернативная площадка для хранения данных, физически отличная от первой. Дальше следуют уже технические нюансы восстановления. Есть еще одно обязательное правило – наличие плана резервного копирования. При этом он будет работать, только если компания проводит регулярные тренировки, также как в случае восстановления резервных копий. Важно, что не всё восстановление с нуля является аварийным. Поэтому эти понятия нужно разделять.
Сегодня DR – это совокупность сложных процессов, объединяющая сеть, резервное копирование, различные виды программной и аппаратной репликации. Правильно разработанный DR-сценарий позволяет осуществлять переход на резервную площадку и обратно с минимальными потерями и гарантией целостности данных. Особую популярность приобретает DRaaS (Disaster Recovery as a Service), т. е. DR в облако. Всё больше отечественных облачных провайдеров поддерживают эту услугу. Она может стать интересным вариантом, благодаря минимизации затрат на содержание резервной площадки.
Для начала вся инфраструктура должна быть описана, это могут быть графические схемы, описание в Ansible и т. д. У всех «железных» компонентов должны быть аналоги на складе для экстренной замены, вплоть до сервера целиком. Это могут позволить себе только крупные провайдеры, зачастую их парк серверов гомогенен и они могут хранить большие складские запасы. Также нужно понимать угрозы, для чего создается план по Disaster Recovery. Это могут быть: - полный выход из строя дата-центра (пожар, наводнение); - поломка одного из серверов в кластере; - поломка сервера, на котором размещался проект. Сегодня всё больше систем строится на системе виртуализации, которая позволяет зарезервировать аппаратные ресурсы. Таким образом, сам по себе план экстренного восстановления закладывается в систему еще на этапе проектирования ее архитектуры: логическое разнесение на площадки разных ДЦ, выделение отдельных узлов для работы сервера баз данных, фронтенда и бэкенда и т. д. Инструкция по восстановлению должна быть максимально подробной и напоминать чек-лист. В критической ситуации нет времени на раздумья, все действия должны быть описаны.
На мой взгляд, при верном подходе Disaster Recovery будет простым, понятным и не потребует вмешательства человека. При использовании подхода, когда есть мастер-мастер сервера БД и распределенные файловые системы, кэширующие серверы, распределенные load balancer-ы и прочие современные методы, возможность избежать потерь в операционном плане, даже при выводе из строя значительной части инфраструктуры, вполне себе доступна. Если же не использовать ничего из вышеперечисленного, восстановление с нуля тоже вариант, почти всегда для быстрого восстановления мало иметь бэкапы данных, стоит еще обратить внимание на образы серверов с уже сконфигурированными параметрами, которые можно «развернуть» в минуты.
Облачные операторы уже сейчас предлагают своим клиентам сервисы аварийного восстановления в облаке, а современные системы резервного копирования умеют отправлять резервные копии в защищенные хранилища облачных провайдеров. В случае серьезного сбоя можно восстановиться из резервной копии сразу в облако оператора. Или, вставив в домашний ноутбук заранее подготовленную флешку, восстановить его утерянные данные по сети.
По прогнозу компании Grand View Research, к 2025 году объем мирового рынка решений для аварийного восстановления достигнет огромной суммы – 26,23 млрд долларов США. Это происходит потому, что ИТ-системы становятся сложнее, спрос на такие решения растет, а число случаев отказа от инфраструктуры из-за угроз увеличивается. Как выглядит восстановление с нуля? Резервирование основных систем хранения и обработки данных происходит на удаленной площадке, например, через облачных провайдеров или на физическом оборудовании. Бывает, что ЦОД компании может быть распределен по нескольким площадкам, в этом случае важно организовать каналы между ними и составить планы резервного копирования и восстановления данных. В плане аварийного восстановления должны быть роли и обязанности всех членов команды, ответственных за аварийное восстановление, а также условия для запуска плана в действие. План должен подробно описывать действия по реагированию на инциденты. План аварийного восстановления может варьироваться по степени сложности ситуации от базового до всеобъемлющего.
Disaster Recovery в современных условиях обязателен для любой организации, которая хочет обеспечить должный уровень надежности и устойчивости своей ИТ-инфраструктуры к различным техническим неисправностям или даже катастрофам. Реализация DR-решения обязательно должна включать не только технической решение, но разработанные регламенты, описывающие выполнение определенных мероприятий и последовательности выполнения этих мероприятий для восстановления ИТ-инфраструктуры в случае возникновения инцидентов. В последнее время мы видим тенденцию развития решений DR из физических ЦОДов в облачную и инфраструктуру провайдеров, ИТ-мощности которых могут быть расположены на большом расстоянии от ЦОДа заказчика. Такие варианты решений позволяют даже компаниям с небольшим ИТ-бюджетом обеспечить возможность восстановления работы критичных ИТ-сервисов без необходимости больших инвестиций в построении полноценных DR ЦОДов. Восстановление ИТ-сервисов с нуля будет отличаться для каждой компании. Мероприятия по восстановлению могут включать в себя как простой перезапуск некоторых ИТ-сервисов на DR-сайте, так и целый ряд действий по восстановлению сначала сопутствующих ИТ-сервисов, например, таких как AD, эл. почты или виртуальной инфраструктуры. Комплекс мер по восстановлению зависит от сложности восстанавливаемой ИТ-инфраструктуры заказчика, количества ИТ-систем, объемов данных. В любом восстановлении ключевую роль играет – насколько детально можно автоматизировать процедуры DR.
Всё зависит от того, какой период простоя некритичен для бизнеса. Если простой даже в минуты недопустим, то, скорее всего, будет горячий резерв, на который сразу произойдет переключение. Если можно полдня подождать, пока произойдет восстановление данных, то, скорее всего, будет обычное восстановление базы без особой спешки.
DR должен повторять инфраструктуру основной площадки, но при этом должен располагаться на резервной площадке (например, в другом ЦОДе). Данные и бэкапы с основной площадки должны перманентно реплицироваться в DR. Далее, при утере основной площадки (например, пожар) инфраструктура в DR переводится в режим основной площадки, и ИТ-системы продолжают функционировать уже с площадки в DR. Компании должны регулярно, хотя бы раз в год, проводить учения по тестовому переходу на DR, чтобы быть уверенными в том, что в случае реального пожара на основной площадке бизнес компании продолжится. Поэтому это не восстановление с нуля, а, скорее, его предупреждение. А примером решения по восстановлению с нуля на «голое железо» может послужить Symantec Bare Metal Restore. Но это не отменяет потребности держать в резерве свободные мощности с предустановленным ПО на случай необходимости восстановления.
Сегодня Disaster Recovery из облака – это отраслевой стандарт, наиболее целесообразный вариант организации аварийного восстановления в подавляющем большинстве случаев. Компания может арендовать в облаке инфраструктуру для создания резервной копии, самостоятельно развернув в ней DR-систему или воспользовавшись дополнительными услугами провайдера. Кроме того, как и любое программное решение, DR можно получить как сервис, услугу DRaaS «под ключ». Такой выбор будет оправдан как с технической, так и с экономической точек зрения. Во-первых, часть ответственности компания перенесет на провайдера, который будет обеспечивать доступность в соответствии с требованиями SLA. Это освободит заказчика и от расходов на узкоспециализированных сотрудников, и от неоправданных затрат на вычислительные ресурсы. Во-вторых, провайдеры предоставляют сложные услуги по организации DR постоянно, для многих своих клиентов, прекрасно знают все технические детали, вероятность ошибок в их работе стремится к нулю. Более того, все необходимые операции провайдер в силу опыта и наличия квалифицированной команды выполнит быстрее, чем ИТ-служба компании. Принцип Pay-as-you-go (платишь столько, сколько потребляешь), который используется при оплате облачных услуг, позволит добиться значительной экономии – организация DR остается весьма затратным мероприятием. А для небольших и средних компаний использование облака является в большинстве случаев и вовсе единственным способом получить услуги DR промышленного уровня.
Основной проблемой восстановления в случае катастроф является время, которое необходимо, чтобы перенести данные на новое оборудование взамен утраченного в результате катастрофических сценариев, а также наладка, восстановление, тестирование. Это может занимать и недели, и месяцы и никакое предприятие не сможет работать без своих данных и ИТ-систем такое время. Не все организации могут позволить себе дублирующий ЦОД, поэтому решения, где используется облачный ЦОД сервис-провайдера для облачного резервного копирования, все чаще находит свое применения. Следующим логическим шагом будет создание сервиса по восстановлению в случае катастроф прямо из тех данных, которые уже хранятся в облаке у сервис-провайдера – там есть образы ВМ и базы данных – все. что нужно для того, чтобы запустить виртуальный ЦОД, пока свой ЦОД будет восстанавливаться.
Есть, они доступны на различных ресурсах онлайн-обучения – например, https://www.specialist.ru/course/rezkop. Также можно идти учиться к производителю вашего ПО для бэкапа. У Veeam очень неплохие курсы по данному направлению, с хорошей теоретический и практической частью, а также с опцией обмена опытом с другими учащимися.
Самая первая книга по резервному копированию, которую я целенаправленно прочитал не по нужде, а для развития, – «Сохранение данных: теория и практика» Алексея Бережного. Остальную информацию брал из документации продуктов, которыми пользовался для резервного копирования. Как выбирали продукт? В зависимости от условий, какие технологии используются.
Теорию резервного копирования преподают еще в школах на уроках информатики. В целом существует много общетеоретических курсов. На практике любая программа известного производителя систем резервного копирования уже включает в себя общую теорию предмета. Также курсы предлагают разные организации из коммерческого сегмента образования и профессиональной переподготовки.
Я бы посоветовал обучение или другие вводные материалы от ведущих производителей ПО резервного копирования. Обычно они раскрывают общую теорию и позволяют понять последние тенденции. Принципы работы у всех схожи, отличаются только нюансы. Желающим для начала будет достаточно посетить хотя бы одно такое обучение или несколько вебинаров.
Определенных стандартов подобных знаний нет. Есть библиотеки типа ITIL или COBIT – это подборка лучших практик по организации того или иного процесса в ИТ-компании.
Большинство производителей систем резервного копирования проводят курсы и вебинары, в том числе и бесплатные, по работе со своими системами, в рамках которых обучают в том числе и азам.
Бывают курсы при технических университетах, где рассматривается общая теория, даются распространенные схемы и методы, разбирается различное оборудование и типы носителей информации для резервного копирования. По поводу книг и учебников по данной теме могу порекомендовать «Компьютерную безопасность» Александра Заики, где целиком раскрываются вопросы компьютерной безопасности и, в том числе, по организации резервного копирования. А также интересная книга к прочтению – «Сохранение данных: теория и практика» от автора Алексея Бережного. Здесь рассказано о том, как создать Disaster Recovery Plan (план полного восстановления) и как создать эффективную систему резервного копирования.
Как правило, общие принципы и методы резервного копирования изучаются в рамках обучающих материалов для системных администраторов и рассматриваются в соответствующих пособиях. При этом компании-производители программных решений для резервного копирования зачастую проводят курсы и семинары, посвященные своим продуктам и резервному копированию в целом. Некоторые компании также распространяют бесплатные брошюры и другие печатные материалы в рекламно-образовательных целях. Даже если абстрагироваться от конкретного продукта, в таких пособиях можно найти множество ценной информации, касающейся резервного копирования данных.
В основном, все предлагаемые курсы именно по продуктам. На просторах Интернета можно легко найти их, в том числе на сайтах технических вузов.
Все курсы и книги, что встречались на практике, имеют привязку к конечному продукту. Что в принципе правильно. Изучив теорию по какому-то конкретному продукту, можно составить мнение о теоретическом подходе к данному вопросу в целом. Книги по DR тоже есть – например, «Disaster Recovery Testing. Exercising Your Contingency Plan», автор – Philip Jan Rothstein
Тут, скорее, должен быть курс по самоорганизации и самодисциплине. Главное не полениться и выделить время на создание и ТЕСТИРОВАНИЕ бэкапа. Причем этап тестирования не менее важен. Во-первых, позволяет понять, насколько полно сделан бэкап, во-вторых – отработать последовательность действий в случае сбоя.
Курсы по резервному копированию:
Книги по резервному копированию:
Сейчас нет проблем с обучением специалистов в данной отрасли, можно найти как профессиональную литературу, так и подходящие образовательные курсы. На наш взгляд, острее вопрос стоит с более массовым понятием – культуры защиты данных. К сожалению, она формируется гораздо медленнее, чем окружающая нас цифровая среда. Причем речь идет как о защите коммерческих данных, так и персональных. Мы считаем, что защита данных – это актуальная в наши дни базовая потребность человека, и что информационная гигиена должна плотно войти в нашу жизнь и жизнь наших детей. Именно поэтому мы сейчас готовим практический курс по информационной безопасности для школьников и учителей, чтобы внести свой вклад в повышение уровня цифровой грамотности.
К счастью, у меня лично ужасных уроков не было. Но доводилось видеть/слышать, что потерян единственный бэкап или потерян пароль от зашифрованного бэкапа. Второе, действительно, ужасно, потому что бэкап есть, а воспользоваться им нельзя.
У меня в практике был интересный случай. Около десяти лет назад один известный банк хранил данные на дорогом серверном оборудовании на двух площадках. В один момент система резервного копирования, основанная на ленточных накопителях, вышла из строя и не подлежала гарантийному ремонту. А руководство банка ответило отказом на запрос ИТ-службы оплатить негарантийный ремонт ленточной библиотеки или купить новую, решив так сэкономить средства. То есть банк стал жить без резервных копий. Через некоторое время на одном из серверов произошел сбой. Сервер не был задублирован на другой площадке. И банк потерял всю свою электронную почту. История завершилась благополучно: ночью весь ИТ-департамент в спешке ездил по городу и искал экспертов в области восстановления данных с разрушенных RAID-массивов. Эксперта нашли: информацию за несколько часов восстановили, и ближе к утру банку вернули почту. После этого случая руководство банка всё-таки пошло на «уступки» своим ИТ-шникам и в аппаратную составляющую резервного копирования решили вложиться.
Во времена студенчества я сохранял написанные программы, скрипты, важные данные на внешний диск, полагая, что, не храня данные на своем ПК, получится их защитить. Однако в один прекрасный день внешний диск вышел из строя и все данные были утеряны. Самое страшное – на нем была моя курсовая работа. После этого вопрос с резервным копированием для меня был решен.
Самый ужасный урок был не с рабочими, а личными данными, на заре цифровизации все фотографии из личного архива хранились на жестком диске без копий, много фотографий было безвозвратно утеряно, больше такого не допускаю. Был случай, когда у компании вышел из строя первый из трех дисков, затем второй, пока пытались сообразить, что происходит, вышел и третий, увы, у компании не было на тот момент зеркального сервера и операции остановились, как позже выяснилось, все диски были куплены одновременно и их серийные номера отличались лишь по последней цифре, благодаря наличию бэкапа, операции удалось восстановить в считанные часы.
Двадцать лет назад я начал работать в одном маленьком городском интернет-провайдере, который предоставлял доступ в Интернет по телефону. И в компании был единственный сервер, который отвечал за всё, и в нем стоял единственный диск из печально известной серии одного из крупнейших мировых производителей. Когда пришло время этого диска, то выяснилось, что у администратора есть только копия биллинга трехмесячной давности и всё. Тогда спасли ситуацию «корешки» от квитанций, которые хранились в архиве, сплоченность коллектива и бесплатный Интернет для всего города. С тех пор для меня вопрос резервного копирования – один из важнейших.
Любой опытный администратор с ходу назовет десятки случаев, когда клиенты готовы были отдать любые деньги, чтобы вернуть потерянную информацию. Соответственно, таких ужасных уроков очень много, и все они – разной степени трагичности. Следует помнить, что успешное восстановление данных после сбоя – скорее исключение, чем правило, и предотвратить проблемы гораздо проще, чем исправлять последствия.
Самые ужасные уроки и самые яркие воспоминания всегда личные. У меня дома был развернут автоматизированный бэкап для ноутбука, и обычно он выполнялся автоматически, и я уже привык, что у меня есть резервная копия и всё в порядке. Кстати, это самый правильный вариант, потому что если оставлять что-то для выполнения вручную, всегда присутствует риск человеческого фактора. А затем произошла смена учетной записи, и бэкап перестал работать. Каждый день я думал, надо всё настроить и запустить, и откладывал настройку из-за нехватки времени. И вот в один из дней на моем ноутбуке, который никогда не ломался, вылетает жесткий диск. И, конечно, в полном соответствии с законом Мерфи, это произошло ровно тогда, когда у меня уже пару недель не было бэкапа. Этот урок я запомнил надолго, потому что потом собирал всю информацию по крохам из различных источников и очень переживал, что, возможно, потерял коллекцию исторических фотографий, которые были оцифрованы и хранились на жестком диске. Урок пошел впрок, и сейчас у меня две копии данных на двух домашних NAS с репликацией и отдельно копия в облаке. Другой интересный пример успешного восстановления был у одного из наших заказчиков, который подвергся атаке вируса шифровальщика. И этот вирус зашифровал не только системы хранения данных, но и сервера резервного копирования (РК) и даже сервера доступа в помещение. Поэтому, когда приехали наши специалисты помогать с восстановлением данных, то им пришлось не только взять свои рабочие станции, которые использовались как серверы РК, но и обсуждать с заказчиком, что правильнее сломать, стеклянную дверь или окно, для доступа в помещение. В итоге всё закончилось хорошо, потому что сами резервные копии хранились на системах Data Domain и вирус не смог туда добраться из-за использования специализированных протоколов. Однако восстановление в таком авральном режиме было хоть и успешным, но очень затратным, и заказчик решил построить у себя систему Кибервосстановление для гарантированного хранения и восстановления данных, защищенных от кибератаки.
Говорят, что самый лучший опыт – это опыт, построенный на ошибках. Не знаю, хорошо это или плохо, но у меня ни разу не возникало ситуации, когда я забыл сделать бэкап или бэкап был сделан неправильно. Не могу сказать, что мне часто нужны бэкапы по назначению, но когда они вдруг нужны, я рад, что они есть.
Классический пример – это когда студент пишет дипломную работу и вечером перед сдачей у него сгорает жесткий диск. Я когда писал свой диплом, то использовал Dropbox…
Самый ужасный случай это "rm -rf" по каталогу с БД. Случай произошел из-за путаницы в рабочих терминальных окнах. БД была восстановлена перезаливкой всех данных. К счастью, специфика источников данных позволяла это сделать достаточно оперативно без потери данных. Основные выводы:
В далекие нулевые был такой случай. Скорость терминального соединения выдавала паузу в три секунды между нажатием клавиш и отображением символов. С помощью putty, ctrl+c, crtl+v и благодаря протоколам резервного копирования удалось получить файловые идентификаторы при записи на ленту. Далее – восстановление контрольного файла и всего каталога резервных копий. Финальным шагом удалось осуществить восстановление БД и последних журналов транзакций. Но уже на следующий день БД снова потеряли в буквальном смысле. При перемонтировании файловых систем файлы БД загадочно пропали. Но велся протокол в терминальных окнах, и благодаря этому оказалось возможным обнаружить прежнее местоположение файлов. К счастью, файлы не были удалены. БД была запущена в кратчайшие сроки без потребности в восстановлении. Вывод – всегда обязательно вести протоколы терминальных окон и записывать видео рабочих столов. Эти логи могут хорошо выручить в случае необоснованных обвинений в ваш адрес. Протоколы резервного копирования и их регулярное чтение по почте и есть тот самый «бэкап бэкапа"!
С информационным здоровьем действуют те же правила, что и с физическим:
По оценкам ИТ-специалистов другого нашего заказчика – «Северстали», внедрение комплексной системы резервного копирования позволит им в 7-10 раз (с недель до суток) сократить время восстановления работоспособности объектов инфраструктуры в случае полного прекращения работоспособности в результате киберинцидентов. А это позволит избежать производственных простоев и значительно снизить издержки.
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
