Как правильно делать бэкапы и следить за ними

Написать данную заметку меня побудила ситуация вокруг хостера ihor.ru, с которым я сотрудничаю уже лет 5. Еще летом у них начались какие-то проблемы, а сейчас они вылились в открытое противостояние собственников. В чем там конкретно проблемы, я не знаю. Есть 2 противоборствующие стороны, у каждой из которых свой канал в телеграме — @ihor_hosting и @marosnet. Там есть подробности. Они делят между собой компанию. А на пользователях это сказывается тем, что постоянно что-то не работает. То связи нет, то сервера выключаются, тех. поддержка не работает вообще, платежи не принимают. В общем, жуть.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужно пройти .

Введение

За столько лет я оброс всевозможными сервисами и услугами этого провайдера. Многим его советовал. Я туда десятки (может сотни) клиентов привел, в том числе через этот сайт. Долгое время у меня висела его реклама, так как я сам пользовался его услугами.

Последние дни торопливо переносил оттуда все критично важное (в основном в selectel). Оставил только то, что было оплачено заранее сильно вперед (например, дедики с оплатой на год). В связи с этой ситуацией, хотел еще раз обратить внимание на важность бэкапов и мои подходы к их созданию и обслуживанию.

Бэкапы нужно обязательно разворачивать и проверять

Мало просто настраивать мониторинг бэкапов и оповещения. Я регулярно вручную проверяю все бэкапы. Да, это очень хлопотно, но другого выхода я не вижу. Если я этого не делаю, то перестаю спокойно спать.

Вот свежий пример, когда большая продуктовая база бэкапилась, но бэкап не проверялся. Автору повезло, что потерял только несколько записей. А мог и всю таблицу. Там, где можно, я автоматизирую разворачивание на запасном сервере с помощью простых bash скриптов. У меня бывали всякие ситуации, когда бэкапы по каким-то причинам переставали делаться. Если они физически отсутствуют, я получаю уведомление от zabbix. Но этого мало.

Особенно важно проверять дампы баз. Физическое наличие файла с дампом не означает, что вы без проблем его развернете. Надо проверять данные, заливая дамп в базу. Это единственный способ убедиться, что данные реально есть и они актуальны.

Backup должен быть в другом дата центре у другого юр. лица

В описываемом выше случае, из-за проблем у конкретного юридического лица есть шанс потерять разом все — и прод и бэкапы от него. Я очень часто сталкиваюсь с ситуацией, когда заказчики предлагают купить сервис для бэкапов у того же хостера, где работает прод. Всегда от этого отговариваю, так как проблемы бывают разные.

Вас могут банально заблокировать за неуплату, из-за ошибки. Хостер может разорвать отношения в одностороннем порядке. Все это я видел и встречал подобные истории от других. Вот пример из одного чата.

Как правильно делать бэкапы и следить за ними

С самого сервера с данными не должно быть доступа к бэкапам

Очень важное правило — бэкап сервер сам подключается к целевым машинам и забирает информацию. Это добавляет сложности к сервисам, с помощью которых вы будете делать бэкап. Не получится просто купить где-то место в s3, nfs, smb и класть туда бэкапы с серверов. Нужен активный агент, который будет ходить по целевым серверам и собирать данные сам. Зачем такие сложности?

Представьте ситуацию, что на целевой сервер попадает злоумышленник или вирус. Он шифрует не только ваши данные, но и бэкапы, к которым есть доступ с машины. Иногда я делаю 2 разных бэкапа — в первое хранилище целевой сервер кладет данные самостоятельно. А с этого хранилища второй бэкап-сервер сам забирает данные. К нему нет доступа ни у кого. Для большей безопасности можно затирать в логах следы подключения, чтобы нельзя было получить информацию не только о местоположении второго сервера, но и в целом информации о том, что он существует.

Для подобного рода бэкапов хорошо подходят бюджетные vps с большими дисками. Такая услуга, к примеру, есть у ruvds. В списке услуг выбирайте большой диск. Доступен не на всех тарифах и датацентрах.

Как правильно делать бэкапы и следить за ними

Бэкапы должны быть максимально полные и подробные

Что я имею ввиду? Зачастую бэкапы делаются с расчетом на то, что что-то изменится на проде и нам надо будет развернуть бэкап и посмотреть на него. Бэкапятся, к примеру, исходники сайта и база к нему. Когда все в порядке и ты просто проверяешь бэкап, сложностей не возникает, потому что если ты даже что-то забыл, то залез на prod и посмотрел.

Например, у сайта может быть сложный и насыщенный конфиг nginx с кучей location и редиректов. В процессе эксплуатации вы могли тюнить и вносить много изменений в настройки mysql сервера. Если конфиги не забэкапить вместе с сайтом, то разворачивать и запускать его в работу может быть очень трудозатратно и хлопотно, особенно если оптимизация и настройки выполнялись давно и все уже забыто.

Отсюда правило — бэкапьте не только данные, но и все окружение из расчета на то, что вы разом можете потерять prod навсегда. Я много раз об это спотыкался и по второму разу настраивал все то, что у же было настроено ранее. Сейчас все конфиги проектов храню в своем gitlab. Из того, что часто забывают — ssl/tls сертификаты. А потом их приходится торопливо искать.

Backup виртуальных машин

Я знаю, что многие бэкапят целиком виртуалки. Я редко делаю такие бэкапы, так как с ними трудно работать. Получаются файлы огромных размеров. Если гоняете их через интернет, то они могут биться по дороге, либо в момент создания. У меня были ситуации, когда нужно было развернуть бэкап виртуальной машины на 200 Гб. Я несколько часов его заливал через интернет, а потом он не разворачивался из-за ошибки чтения. Пробовал несколько раз и каждый раз неудачно. Очень повезло, что заметил это в момент тестового разворачивания, а не тогда, когда была бы реальная авария. Это был бы полный провал, так как это был единственный экземпляр архивной копии.

Если нужно делать бэкап виртуальной машины, то я делаю небольшой системный диск (30-50 Гб) и бэкаплю только его. Данные кладу на отдельный виртуальный диск и забираю их в сыром в виде с помощью rsync или аналогов. С его помощью легко и быстро делать инкрементные бэкапы, а потом их разворачивать. Нет проблем с докачкой и битыми файлами. Даже если что-то и повреждено, то 1 файл из десятков тысяч погоды не сделает. Можно пережить.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Это мои основные правила создания бэкапов. А как вы делаете бэкапы? Поделитесь своим опытом. Возможно, я что-то забываю или упускаю.

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Что даст вам этот курс:

  • Знание архитектуры Linux.
  • Освоение современных методов и инструментов анализа и обработки данных.
  • Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
  • Владение основными рабочими инструментами системного администратора.
  • Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
  • Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Источник

Просмотров:

Добавить комментарий