Делай бэкап, или как мы чуть не потеряли самое ценное, что у нас было
ИТ-специалисты поделились своими историями, а эксперт по облачному резервному копированию их прокомментировал.
Статья подготовлена при поддержке #CloudMTS
Бэкап против майнеров
Филипп Кулин, генеральный директор хостинга DiPHOST, Санкт-Петербург
Я занимаюсь хостингом. Был как-то случай, когда я делал и настраивал клиенту виртуальную машину на основе Linux KVM. Виртуальная машина находилась на образе с ZFS — это файловая система для работы с большим объёмом данных. Первая установка, типовых образов нет, то есть всю работу делал своими руками, подсмотреть было не у кого, никакой страховки.
Настраивал виртуальную машину я через стандартный VNC (Virtual Network Computing) — систему удалённого доступа к рабочему месту.
По умолчанию VNC была подключена к интернету без пароля.
Час я там всё причесывал, после чего пошёл кофе попить. Возвращаюсь — почему-то сессия прервалась. Сначала не обратил на это внимания. Примерно минуты через три понимаю, что кто-то на моей виртуалке майнит криптовалюту: процессор загружен, а ещё запущена программа, которая была опознана как вирус-майнер. Половина моей инсталляции стёрта. Два часа работы коту под хвост.
Вздохнул, установил пароль на систему удалённого доступа. Мне повезло — до заражения я настроил автоматическое создание снапшотов в ZFS каждые 15 минут. Поэтому я смог воспользоваться снапшотом ZFS, сделав моментальную копию файловой системы. Далее «откатил» снапшот на полчаса и продолжил настраивать виртуалку с момента создания снапшота. Благодаря этому потерял только полчаса времени, а не два с половиной, как могло бы быть.
По нашей статистике, 27% компаний, начинающих использовать сервисы резервного копирования, столкнулись с подобными проблемами. Вирусы для майнинга встречаются, но в подавляющем большинстве это всё же шифровальщики.
На рынке есть решения, которые защищают от таких вредоносных воздействий. Например, технология Acronis Active Protection. На проверяемой машине в режиме реального времени отслеживается активность. Если обнаружено нецелевое действие, например, вирус пытается поменять кодировку или зашифровать паролем документы, то это действие блокируется, а администратор получает уведомление.
Причём перед любыми изменениями делается резервная копия в кэше. Даже если данные будут повреждены, их можно максимально быстро восстановить из кэша. При этом не нужно обращаться к последний резервной копии, которая могла быть сделана задолго до атаки.
Бэкап против сбоев оборудования
Михаил Пархоменко, руководитель отдела ИТ компании «Фарм Синтез»
Каждый бизнес, который когда-либо сталкивался со сбоем в работе оборудования или ИТ-системы, понимает, насколько дорого обходится восстановление.
В нашем случае критично важной стала возможность сохранения настроек приборов для хроматографии — процесса разделения и анализа смеси веществ. Если с оборудованием что-то случится, собьются настройки, то оборудование придётся настраивать заново. А сделать это может только специалист, каждый вызов которого стоит сотни долларов. Ещё надо учитывать, к каким последствиям может привести простой в работе всего предприятия.
Мой опыт говорит о том, что зачастую к потере данных приводят не ошибки сотрудников или вредоносные программы, а технические неполадки.
Раньше мы использовали собственные мощности: покупали оборудование, настраивали серверы. Но это дорого — нужно постоянно вкладываться в мощности и поддерживать инфраструктуру. Поэтому сейчас мы перешли на системы облачного резервного копирования.
Эти услуги обходятся намного дешевле, чем работа с собственными мощностями. И точно дешевле, чем простой в работе оборудования. Если потребуется, мы сможем восстановить нужные данные в течение часа.
Второе направление для бэкапа — ноутбуки, которые используют сотрудники. У нас работают медицинские представители, которым приходится много передвигаться. У каждого есть доступ к корпоративным данным. А управляют конфигурацией устройств наши администраторы — удалённо.
На ноутбуках мы настроили политики резервного копирования. Даже если администраторы давно не проверяли технику, то мы уверены в том, что все важные данные защищены. И даже если что-то случится, то работа будет восстановлена в течение нескольких часов.
Действительно, о резервном копировании лучше подумать заранее. В любом случае понадобятся средства: на восстановление данных и компенсирование простоев в работе или на создание системы резервного копирования.
Иногда бэкап стоит примерно столько же, сколько работы по восстановлению работоспособности после аварий. Возможно, резервные копии даже никогда и не понадобятся. Но при этом бэкап — понятные и запланированные траты. Это вклад в поддержание стабильной работы бизнеса без непредвиденных ситуаций и авралов. Для менеджеров по ИТ это инвестиции в спокойствие: когда бэкапа нет, время и нервы никто не компенсирует.
Организовать и поддерживать работу системы резервного копирования можно самостоятельно: закупить лицензии на ПО, необходимое оборудование и настроить его.
Или получить готовый сервис с поддержкой. На этом специализируются облачные провайдеры, которые сотрудничают с вендорами. Они предоставляют продвинутые решения технологических лидеров, таких как Veeam, Acronis Infoprotect и CommVault.
Бэкап против ошибок сотрудников
Илья Тягунов, системный администратор, АО «ТЭК-Торг», Москва
Моим предыдущим местом работы была структура регионального масштаба — несколько городских отделов и по отделу в ряде муниципальный образований. Финансирование ИТ-инфраструктуры было небольшим, во многих отделах стояли старые компьютеры, без использования RAID. В каждом отделе была своя локальная база данных, хранящаяся на обычном компьютере. Поэтому коллегам давали инструкции — каждый день делать выгрузку базы из программы на внешние носители.
Медленно, но верно инфраструктуру модернизировали. Поставили более-менее приличные серверы, провели защищённые каналы связи. По мере появления каналов связи до отделов мы настраивали автоматические бэкапы, не отменяя при этом указаний делать ручные копии.
Бэкапы требовались регулярно. Пару раз в год происходили серьёзные поломки. Был случай, когда сломался жёсткий диск сервера в отделе в небольшом посёлке, и оказалось, что сотрудники давно игнорируют указание о создании бэкапов.
Коллеги не знали про автоматические бэкапы и подумали, что вся история за всё время существования отдела была потеряна! В итоге купили новый диск, данные восстановили довольно быстро. После этого сотрудники стали ответственнее относиться к указаниям ИТ-специалистов.
На нынешнем месте работы в Москве инфраструктура намного более мощная. Для хранения данных используется СХД (система хранения данных), в которой бэкапы имеются по умолчанию. Иногда их приходится использовать. Обычно это происходит при программных сбоях или неудачных обновлениях: например, когда по какой-то причине перестает загружаться система. В таком случае помогает откат до снапшота на СХД, создаваемого по расписанию. Выход из строя одного из дисков на СХД вообще не сказывается на работе системы, так как работает механизм резервирования данных.
Снапшоты в системах хранения данных — распространенный способ резервного копирования. Его плюсы: не нужно внедрять дополнительные решения для обеспечения большей доступности данных. Все реализовано в рамках единой системы хранения данных.
С другой стороны, снимки хранятся там же, где и сами данные. Это нивелирует саму идею резервного копирования — хранить копию исходных данных подальше от них самих. И может возникнуть ситуация «сервер упал, бэкап на сервере». Поэтому мы всё-таки рекомендуем разносить хранение данных и резервных копий.
Кроме того, хранение в одном месте невыгодно с точки зрения оптимального использования ресурсов — снэпшоты занимают место на СХД, которое можно использовать для продуктивных данных.
Также нужно учитывать, что снэпшоты не обеспечивают консистентность (согласованность данных). Делать консистентные бэкапы позволяют только некоторые СХД. Правда лицензироваться данная возможность будет отдельно.
При использовании услуг резервного копирования компания получает законченное решение, для которого не нужны апгрейды, и все возможности доступны «из коробки».
Бэкап против невнимательности
Фёдор Борщёв, учредитель, партнёрство «Федя и Самат»
В стартапах обычно некогда заморачиваться разграничением внутреннего доступа — часто программистам сразу после испытательного срока дают доступ прямо на прод, надеясь на NDA.
У меня был очень показательный случай, который убедил меня в том, что людям можно доверять. В первом стартапе, где я официально был CTO, пришло время нанять на работу второго после меня программиста. Я долго выбирал, в итоге выбрал классного чувака — крепкого мидла с хорошим опытом. В первую же неделю я дал ему ограниченный доступ на прод и простую задачу — удалить ненужную колонку из базы пользователей.
И, конечно же, новый программист из-за банальной описки взял и грохнул всю таблицу с пользователями. Причём в тот момент, когда меня на связи не оказалось. Обидно было то, что он совершил ошибку не от недостатка знаний или опыта — просто описался.
Нас спасло то, что в дополнение к прочим бэкапам у нас был простой скрипт ежечасных бэкапов прямо на сервер. Уж не знаю, как парню повезло их найти (я про них не рассказывал), но через час я узнал об инциденте уже в прошедшем времени. Он быстро развернул дамп базы на соседней машинке и вытянул оттуда нужные таблицы. Кажется, даже не все в компании заметили аварию.
Хороший специалист способен справиться с любыми сложностями. Но всё же лучше, когда сотрудник решает целевые задачи, а не пытается срочно найти выход из нештатной ситуации. Специализированные системы резервного копирования как раз помогают свести количество авралов к минимуму. Такие системы дороже, но зато всегда понятно, где находятся резервные копии. И любой сотрудник с минимальными техническими знаниями может быстро восстановить данные.
Скрипты для создания резервных копий — рабочее решение. Но в этом случае о скриптах нужно помнить, когда что-то меняется в инфраструктуре. Чтобы не получилось, например, что конфигурацию серверов изменили, а скрипт — нет. В таком случае скрипт либо пытается сделать резервную копию несуществующего раздела, либо пытается записать бэкап в несуществующую директорию. Кроме того, в хранилище резервных копий может закончиться место, и скрипт ничего не сможет записать.
Поэтому мы в #СloudMTS рекомендуем клиентам настраивать оповещения в начале использования бэкап-сервиса. Например, в рамках услуги Veeam Basic Backup оповещения осуществляются автоматически, а базовая политика резервного копирования доступна «из коробки». Да, это не столь гибко, как если бы вы производили настройку самостоятельно. Но в данном случае вы точно будете уверены, что все ваши виртуальные машины, расположенные в облаке, защищены, а ваши специалисты занимаются целевыми для бизнеса задачами.
Советы по выбору бэкап-решений
По данным ИТ-сообщества Spiceworks, компании по всему миру планируют потратить на хранение и резервное копирование данных около 10% своих ИТ-бюджетов.
Есть два основных способа сделать бэкап: организовать собственную инфраструктуру или обратиться к облачному провайдеру.
В первом случае нужно закупить лицензии на ПО для резервного копирования и необходимое ИТ-оборудование, всё это настроить. Часто такая инфраструктура избыточна — её приходится поддерживать «на всякий случай».
Второй сценарий предполагает, что компания приобретает готовый сервис с поддержкой и администрированием, а платит только за использование этого сервиса. Это помогает сократить расходы (по сравнению с созданием и настройкой собственной системы бэкапа).
По опыту наших клиентов, облачная модель обходится на 40% в месяц дешевле, чем самостоятельная поддержка системы бэкапов.
На что нужно обратить внимание при выборе провайдера:
- Стек технологий, которые предлагает провайдер. Чем больше сервисов, тем легче подобрать нужную услугу. Сегодня на рынке есть провайдеры, которые работают с 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 для этого настраивая общие директории и репликацию.
Последний случай повеселил. Кто же тестирует на проде? Хотя работал в одной компании. Именно так и было. )))