Несколько простых шагов, которые помогут избежать проблем с созданием и восстановлением бекапа
Правильно говорят, что системные администраторы делятся на тех, кто еще не делает бэкап, и тех, кто их уже делает. Конечно, это шутка, да еще и с преогромнейшей бородой, но в каждой шутке, как говорится… А проблемы с бэкапами возникают у многих компаний. Эти проблемы могут стоить сотен тысяч долларов или даже миллионов, если речь идет о крупной компании с развернутой клиентской базой.
Избежать проблем с бэкапами можно, если придерживаться нескольких простых правил. Здесь нет ничего сложного. Мы у себя стараемся их выполнять, и, надо сказать, это работает. Сразу скажу, что речь здесь пойдет не о технологических прорывах, а о рутинных мелочах, о которых многие забывают. Мы уже давно наладили процесс создания бэкапов и восстановления данных из них. И в своей работе используем несколько полезных мелочей, которые, возможно, могут оказаться полезными и для вас.
Мелочь первая. Мониторинг
Наблюдение или его отсутствие само по себе не может стать причиной сбоя создания архивной копии данных или восстановления информации из этой копии. Но за этими процессами необходимо вести мониторинг, чтобы что-то не пошло не так. А если что-то все-таки пойдет не так, это можно будет быстро исправить. Проблема состоит и в том, что бэкапятся данные в некоторых случаях на несколько серверов сразу. Большинство систем мониторинга, за исключением самых новых, просто не созданы для того, чтобы отслеживать большое число серверов единовременно.
Решением может быть автоматизированная система мониторинга, которая собирает данные и визуализирует их для пользователя. В такой системе должны быть представлены все сервера компании, включая индивидуальные и клиентские. В идеале такая система должна поддерживать создание бэкапов с использованием сервисов и оборудования различных производителей, с соответствием разных стандартов.
Стоит наладить работу системы автоматического сопоставления. Для этого можно сравнивать только контрольные суммы, поскольку сравнить полную копию с оригиналом не всегда представляется возможным.
Мелочь вторая. Пропущенные уведомления
В обычном случае уведомления отправляются администратору по электронной почте. Это относительно надежный канал связи, хотя с ним иногда возникают и проблемы. Дело в том, что все вокруг быстро меняется. Конфигурация сервера, приложения, устройства для создания резервных копий и сотрудники — все это обновляется, исчезает и появляется снова. В общем, все эти причины приводят к тому, что уведомления не доходят до нужных людей, и тогда начинаются проблемы.
В этом случае прекрасное решение — режима уведомлений реального времени. Необходимо наладить процесс доставки уведомлений по нескольким каналам. Причем особо приоритетные сообщения не должен получать один человек. В ряде случаев лучше сделать так, чтобы это было несколько человек.
Каналы связи в современном мире могут быть разными. Это e-mail, SNMP, SMSS и другие. Все это позволяет получать сообщения и быстро реагировать на них. Лучше всего внедрить в своей компании систему отправки уведомлений в режиме реального времени. В этом случае можно видеть все и сразу, а не получать сообщение через минуты, часы или дни после случившейся аварии или сбоя.
Мелочь 3. Командная строка помогает не всегда
Да, многие администраторы предпочитают консоль всему другому. Но командная строка может стать причиной того, что администратор, ошибившись при вводе, создаст большую проблему для своего дата-центра.
Что можно сделать? Лучше всего данном случае работать еще и с GUI. Можно быть админом семи пядей во лбу и сделать маленькую ошибку, которая приведет к огромным проблемам. А если будет введена в работу система с GUI-интерфейс, то в большинстве случаев фактор человеческой ошибки будет исключен.
Мелочь 4. Отчетность и планирование
Мало кто любит отчетность, еще меньшее число людей привлекает планирование. Системные администраторы не исключение. В итоге страдает эффективность работы. Кроме того, это лишь небольшая часть проблем. Есть еще одна — это анализ отчетности, поступающей из других отделов. Слишком часто администраторы не уделяют таким отчетам должного внимания.
В качестве решения можно посоветовать распределить данные по бэкапу сразу по нескольким объектам инфраструктуры. Это, в идеале не должно иметь отрицательного влияния на качество работы ДЦ, но зато поможет собирать данные из множества источников, компилируя их произвольным образом. Избыточность должна быть всегда. Результат архивирования будет надежнее, если в процессе использовать несколько серверов, а не один. Кроме того, желательно хранить копии данных на различных серверах. Если возникнет физическая угроза для одного из серверов, то данные можно будет восстановить из другого места.
Неправильная настройка
Несмотря на то, что в ИТ-отделе обычно работают профессионалы, здесь довольно часто случаются ошибки. Вот несколько их причин:
- Некорректные размеры логов. Это может привести к утере информации. В обычном случае желательно иметь в запасе свободное мест, чтобы избежать проблем;
- Проблема при записи с диска на ленту. В некоторых случаях сбоит оборудование. Скорость записи на ленту должна совпадать со считыванием данных диска. Если скорость не совпадает, то бэкап может вообще не писаться;
- Превышение числа одновременных сессий бэкапа. Превысить число процессов записи архивных данных (или считывания) очень легко. Также можно пропустить время записи бэкапа или его восстановления;
- Проблема со стеком технологий для бэкапа. Если проблемы действительно есть, что все копии архивных данных могут быть повреждены. Даже у Google случаются подобные проблемы.
Вне зависимости от типов таких ошибок, мы бы рекомендовали использовать развернутые автоматизированные системы мониторинга, которые позволят одновременно следить за всеми уголками дата-центра, включая бэкапы. Причем стоит помнить, что сами по себе они бесполезны, ценной является только информация, которая восстанавливается в процессе работы с бэкапом. Резервирование данных нужно сделать простым и понятным, аналогичным образом нужно поступить с процессом восстановления данных. Еще один важный момент — это автоматизация процессов.
Системным администраторам нужно уяснить, что сбои будут в любом случае, в любом дата-центре. Просто нужно сделать все, чтобы быть уверенным в работе своей резервной ИТ-инфраструктуры во время сбоя. Как уже говорилось выше, для этого можно использовать автоматизированные решения, которые будут работать по четкому алгоритму. В таком случае любой член команды должен усвоить, что он должен делать и в каком случае. Что-то плохое произойдет обязательно, а задачей профессионалов будет ликвидировать последствия этого чего-то за минимальное время.
Если все сделано правильно, то архивные копии данных будут создаваться без всяких проблем в автоматическом режиме. Ну, а восстановить данные тоже будет несложно. Главное — отлаженный процесс бэкапа и считывания данных из сохраненных архивных копий.
Комментарии (2)
n0wi
3 ноября 2016 в 08:43
+1↑
↓
И еще хотел бы добавить. На практике так случалось, я встречал организации, где админом настроено регулярное создание бэкапов, и в теории, в случае проблемы, все можно было откатить. Но вот никто ни разу не проводил мероприятия по восстановлению из этих бэкапов. И когда приперло — оказалось, что бэкапы делались не корректно или левым (не правильно настроенным) софтом. А у админа спокойно на душе — бэкапы делаются регулярно.
Проверяйте бэкапы! ИМХО
Archon
3 ноября 2016 в 09:21
+1↑
↓
Пропущены некоторые прописные истины.1. Бекап, с которого не проводилось восстановление, считается находящимся в состоянии суперпозиции. Если это не простая копия файла, а результат работы какого-то софта, то сразу же после создания бекап должен разворачиваться в песочнице и проверяться на валидность.
2. Quis custodet ipsos custodes? Мониторинг может молчать не потому, что всё хорошо, а потому, что он сам лёг полежать.
3. Мониторинг может орать как положено, но не мочь докричаться, т.к. каналы доставки сообщений по каким-то причинам ему недоступны (например, на площадке пропал интернет, или лёг сервер, через который он отправляет сообщения).
