Делай бэкап, или как мы чуть не потеряли самое ценное, что у нас было
ИТ-специалисты поделились своими историями, а эксперт по облачному резервному копированию их прокомментировал.
Статья подготовлена при поддержке #CloudMTS
Бэкап против майнеров
Филипп Кулин, генеральный директор хостинга DiPHOST, Санкт-Петербург
Я занимаюсь хостингом. Был как-то случай, когда я делал и настраивал клиенту виртуальную машину на основе Linux KVM. Виртуальная машина находилась на образе с ZFS — это файловая система для работы с большим объёмом данных. Первая установка, типовых образов нет, то есть всю работу делал своими руками, подсмотреть было не у кого, никакой страховки.
Настраивал виртуальную машину я через стандартный VNC (Virtual Network Computing) — систему удалённого доступа к рабочему месту.
Час я там всё причесывал, после чего пошёл кофе попить. Возвращаюсь — почему-то сессия прервалась. Сначала не обратил на это внимания. Примерно минуты через три понимаю, что кто-то на моей виртуалке майнит криптовалюту: процессор загружен, а ещё запущена программа, которая была опознана как вирус-майнер. Половина моей инсталляции стёрта. Два часа работы коту под хвост.
Вздохнул, установил пароль на систему удалённого доступа. Мне повезло — до заражения я настроил автоматическое создание снапшотов в ZFS каждые 15 минут. Поэтому я смог воспользоваться снапшотом ZFS, сделав моментальную копию файловой системы. Далее «откатил» снапшот на полчаса и продолжил настраивать виртуалку с момента создания снапшота. Благодаря этому потерял только полчаса времени, а не два с половиной, как могло бы быть.
Бэкап против сбоев оборудования
Михаил Пархоменко, руководитель отдела ИТ компании «Фарм Синтез»
Каждый бизнес, который когда-либо сталкивался со сбоем в работе оборудования или ИТ-системы, понимает, насколько дорого обходится восстановление.
В нашем случае критично важной стала возможность сохранения настроек приборов для хроматографии — процесса разделения и анализа смеси веществ. Если с оборудованием что-то случится, собьются настройки, то оборудование придётся настраивать заново. А сделать это может только специалист, каждый вызов которого стоит сотни долларов. Ещё надо учитывать, к каким последствиям может привести простой в работе всего предприятия.
Мой опыт говорит о том, что зачастую к потере данных приводят не ошибки сотрудников или вредоносные программы, а технические неполадки.
Эти услуги обходятся намного дешевле, чем работа с собственными мощностями. И точно дешевле, чем простой в работе оборудования. Если потребуется, мы сможем восстановить нужные данные в течение часа.
Второе направление для бэкапа — ноутбуки, которые используют сотрудники. У нас работают медицинские представители, которым приходится много передвигаться. У каждого есть доступ к корпоративным данным. А управляют конфигурацией устройств наши администраторы — удалённо.
На ноутбуках мы настроили политики резервного копирования. Даже если администраторы давно не проверяли технику, то мы уверены в том, что все важные данные защищены. И даже если что-то случится, то работа будет восстановлена в течение нескольких часов.
Бэкап против ошибок сотрудников
Илья Тягунов, системный администратор, АО «ТЭК-Торг», Москва
Моим предыдущим местом работы была структура регионального масштаба — несколько городских отделов и по отделу в ряде муниципальный образований. Финансирование ИТ-инфраструктуры было небольшим, во многих отделах стояли старые компьютеры, без использования RAID. В каждом отделе была своя локальная база данных, хранящаяся на обычном компьютере. Поэтому коллегам давали инструкции — каждый день делать выгрузку базы из программы на внешние носители.
Медленно, но верно инфраструктуру модернизировали. Поставили более-менее приличные серверы, провели защищённые каналы связи. По мере появления каналов связи до отделов мы настраивали автоматические бэкапы, не отменяя при этом указаний делать ручные копии.
Коллеги не знали про автоматические бэкапы и подумали, что вся история за всё время существования отдела была потеряна! В итоге купили новый диск, данные восстановили довольно быстро. После этого сотрудники стали ответственнее относиться к указаниям ИТ-специалистов.
На нынешнем месте работы в Москве инфраструктура намного более мощная. Для хранения данных используется СХД (система хранения данных), в которой бэкапы имеются по умолчанию. Иногда их приходится использовать. Обычно это происходит при программных сбоях или неудачных обновлениях: например, когда по какой-то причине перестает загружаться система. В таком случае помогает откат до снапшота на СХД, создаваемого по расписанию. Выход из строя одного из дисков на СХД вообще не сказывается на работе системы, так как работает механизм резервирования данных.
Бэкап против невнимательности
Фёдор Борщёв, учредитель, партнёрство «Федя и Самат»
В стартапах обычно некогда заморачиваться разграничением внутреннего доступа — часто программистам сразу после испытательного срока дают доступ прямо на прод, надеясь на NDA.
У меня был очень показательный случай, который убедил меня в том, что людям можно доверять. В первом стартапе, где я официально был CTO, пришло время нанять на работу второго после меня программиста. Я долго выбирал, в итоге выбрал классного чувака — крепкого мидла с хорошим опытом. В первую же неделю я дал ему ограниченный доступ на прод и простую задачу — удалить ненужную колонку из базы пользователей.
Нас спасло то, что в дополнение к прочим бэкапам у нас был простой скрипт ежечасных бэкапов прямо на сервер. Уж не знаю, как парню повезло их найти (я про них не рассказывал), но через час я узнал об инциденте уже в прошедшем времени. Он быстро развернул дамп базы на соседней машинке и вытянул оттуда нужные таблицы. Кажется, даже не все в компании заметили аварию.
Советы по выбору бэкап-решений
По данным ИТ-сообщества Spiceworks, компании по всему миру планируют потратить на хранение и резервное копирование данных около 10% своих ИТ-бюджетов.
Есть два основных способа сделать бэкап: организовать собственную инфраструктуру или обратиться к облачному провайдеру.
В первом случае нужно закупить лицензии на ПО для резервного копирования и необходимое ИТ-оборудование, всё это настроить. Часто такая инфраструктура избыточна — её приходится поддерживать «на всякий случай».
Второй сценарий предполагает, что компания приобретает готовый сервис с поддержкой и администрированием, а платит только за использование этого сервиса. Это помогает сократить расходы (по сравнению с созданием и настройкой собственной системы бэкапа).
На что нужно обратить внимание при выборе провайдера:
- Стек технологий, которые предлагает провайдер. Чем больше сервисов, тем легче подобрать нужную услугу. Сегодня на рынке есть провайдеры, которые работают с Veeam, Acronis Infoprotect и CommVault.
- Возможность мониторинга и блокировки всех изменений на устройствах пользователей. Например, при попытке изменить буквы на символы, зашифровать информацию или запустить расчёты для майнинга. Кроме того, решение должно уметь восстанавливать последние чистые версии из кэша, на случай, если вирусам всё-таки удастся зашифровать часть данных.
- Соответствие требованиям 152-ФЗ по работе с персональными данными, если компания с ними работает. #CloudMTS предлагает отдельную инсталляцию с использованием решений Veeam, к которой клиент может получить доступ по защищенному каналу через криптографический шлюз.
Жизненная история, пожалуй поддержу автора текста, поскольку сам в этом году столкнулся с такой же проблемой. Только в моем случае все было куда плачевней, ведь бэкапы я как раз таки не делал и в какой-то момент просто увидел черный экран смерти, а вместе с ним и потерю всех данных на компьютере. Как оказалось позже, вышел из строя жесткий диск в силу возраста и появления кучи битых секторов... Повезло, что поверхность самого хдд не была испорчена и отнеся жесткий диск в сервис - https://datalabs.ru/pages/vosstanovlenie_dannyh_s_zhestkogo_diska смог всё же получить всё назад. Правда вылилось всё это в круглую копеечку, но хотя бы восстановили 4 террабайта информации. Теперь же научился и стараюсь каждый день делать резервы...
В современных "персональных" виндовсах есть технология Storage Spaces. Можно самому соломку подстелить.
Почитал. Безумный Фил повеселил безалаберностью и выставлением голого VNC в DMZ, если как написано здесь верно.
Снэпшоты - не обязательно храняться в том месте, где запущена VM. Консистентности данных может не быть, но за свою практику не могу припомнить случая, когда эта консистентность потребовалась бы. У нас не HA/HL был, да и там лучше смотреть в сторону Kubernates для этого настраивая общие директории и репликацию.
Последний случай повеселил. Кто же тестирует на проде? Хотя работал в одной компании. Именно так и было. )))