Есть такая полушутливая фраза - "люди делятся на тех, кто уже делает резервные копии данных, и на тех, кто еще пока не делает, но скоро поймет, что делать их нужно было". Тема резервного копирования - одна из суперважных.
В каком-то объеме мы говорили о ней на нашем мероприятии "Информационная безопасность" . Но, как показывает практика, актуальность темы не просто остается. Проблема обостряется, и чем дальше, тем сильнее.
Вот несколько реальных кейсов и общих практик из нашего опыта, иллюстрирующих наиболее важные вопросы, на которые стоит находить ответы заранее, а не по факту того, как случилось что-то непоправимое.
- Про взаимопонимание.
Системный администратор приходит к руководителю компании и говорит, что ему надо купить новые диски, потому что количество данных выросло, и резервные копии складывать некуда. Руководитель компании, задав несколько значимых на его взгляд вопросов, и получив на них ответы, принимает решение, что ситуация не требует немедленного решения и отказывает в покупке дисков.
Через пару месяцев наступает тот самый момент, когда надо воспользоваться резервной копией. Выясняется, что принципиальной для нормального существования компании информации нет. Она не вошла на имеющиеся диски.
Вопрос - кто должен принимать решение, о том, какие данные важны, что нужно помещать в резервные копии? Как должен быть построен процесс с организационной точки зрения?
- Про скорость восстановления информации.
В компании так много данных, что начинают они помещаться в резервную копию в 8 часов вечера, и заканчивают только к 8-9 часам утра. Т.е. процесс копирования растянут на 12-13 часов.
Однажды ночью происходит ЧП, после которого приходится восстанавливать данные из резервной копии. Информация о ЧП стала известна в 9 утра. К 11 последствия ЧП были устранены, началось восстановление. Данные восстанавливались до вечера. В результате компания теряет минимум 1 рабочий день.
Вопрос - сколько стоит простой компании в течение 1 рабочего дня?
- Про длительность хранения копий.
Данные с течением времени изменяются. Иногда они изменяются сильно. Но регулярно возникает вопрос, какие были данные 2 недели назад? А месяц назад? А квартал?
Регулярно возникает вопрос о состоянии базы 1С, какой-то папки или файла на большой промежуток времени назад. Часто эти вопросы имеют принципиальное значение для определенных бизнес-вопросов. И, как правило, бизнес имеет довольно серьезные проблемы, не получая тех или иных слепков за отдаленное время.
Вопрос - кто определяет, на сколько глубоко в прошлое надо сохранять данные?
- Про уничтожение данных.
Люди увольняются. Или их увольняют. Довольно часто бывает, что расставание с сотрудником сопровождается тем, что сотрудник пытается уничтожить все, что может.
И вот тут есть очень хорошо замаскированные грабли. Дело в том, что далеко не всегда пользователи хранят файлы, с которыми работают, на сервере, с которого спокойно можно сделать резервную копию.
Регулярно бывает так, что пользователь хранит данные на локальном диске своего рабочего компьютера. Перед уходом он спокойно удаляет файлы, чистит корзину. Также удаляет файлы из своей папки на сервере. После этого компьютер перенастраивается для работы другого пользователя. И примерно через пару недель, а то и месяц, приходит осознание того, что чего-то не хватает в данных, которые оставил пользователь.
Вопрос - каковы корпоративные правила и требования к месту хранения информации?
- Про безопасность резервных копий.
Мы несколько раз сталкивались с такими случаями, как уничтожение резервных копий. Один раз серверная сгорела вместе со всем, что в ней находилось. Другой раз система резервирования находилась на том же сервере, что и рабочая система. Сервер так удачно вышел из строя, что и рабочая система, и ее резервная копия погибли разом. Третий раз проникший в корпоративную систему вирус-шифровальщик зашифровал и данные, и резервную копию этих данных.
Вопрос, как от этого защищаться?
Используя несколько инструментов: логику, системный анализ и опыт, можем поделиться рабочим сценарием, который поможет избежать наиболее частых ошибок, которые приводят к вышеописанным проблемам. Весь процесс создания резервных копий данных стоит делить на 2 части. Организационную и техническую.
Организационная часть процесса
- Определение рисков, от чего страхуемся, делая резервные копии;
- Процесс определения и согласования содержимого резервных копий;
- Процесс изменения состава резервных копий;
- Определение, как долго нужно хранить данные? Нужно ли хранить только последние 2 недели? Или нужно копировать 2 недели и еще в течение последних трех лет данные на начало каждого месяца?
Вопросы понятны, а кто все это будет делать? Ответ простой - делать будет техническая служба - или штатный айтишник, или приходящий, или аутсорсер.
А вот решения должно принимать руководство. Опираясь на вопросы и слова технического специалиста, или на свои знания и ощущения. Совет руководителям - не отмахивайтесь от системного администратора, если он пришел поговорить про резервные копии, поверьте, 10-15 минут вашего времени на разговор стоят того. И ни в коем случае не говорите "ну ты же сам знаешь, с какими данными мы работаем, их и копируй".
Совет айтишникам - добивайтесь внимания руководства для решения этих вопросов. Задавайте максимально конкретные вопросы, например, "у нас на сервере лежит 15 баз 1С, мне копировать их все? Мне оставлять копии на начало каждого месяца, или копировать только последние 2 недели? Мне сохранять весь архив фотографий, которые есть на сервере?". "Вас устроит, если база будет восстанавливаться 1,5 дня?". Чем больше конкретных вопросов, тем точнее итоговая схема. Ну и еще один совет - зафиксируйте схему резервного копирования в виде регламента и согласуйте ее с руководством и с руководителями отделов. В 95% случаев это оказывается очень полезным.
Техническая часть
- Выбор оборудования и программного обеспечения под систему резервного копирования;
- Настройка системы резервного копирования;
- Мониторинг системы резервного копирования.
Последнее - суперважно. Основное предназначение резервной копии - возможность восстановить систему на какую-то дату и время и продолжить работу. Никогда не сталкивались с ситуацией, что по каким-то причинам резервная копия повреждена и из нее невозможно восстановить данные? Чтобы этого не произошло, продумайте и реализуйте механизм проверки резервных копий - как их наличия, так и их состава.
Конечно же, техническая часть, т.е. непосредственно реализация системы резервного копирования - область ответственности айтишника.
GLOS IT
20.12.2017
