Как делать бэкапы, чтобы не стать грустным админом

Сегодня международный день резервного копирования. Повод вспомнить, какие промахи в настройке и хранении бэкапов зацементировали ваши нервные клетки и остались навсегда в виде неуловимой тяжести опыта в глазах.

Предлагаем в честь праздника сыграть в игру «Было/ не было». С помощью клиентов Selectel, которые подключили автоматические бэкапы по расписанию, мы описали лучшие практики и косяки при работе с бэкапами. С какими из них вы встретились в карьере? Поучительные байки в комментариях приветствуются!

Составлял подробную документацию по бэкапам

Достойный подход, одобренный сотнями крепко спящих по ночам админов. Многие согласятся, что первый шаг в работе с бэкапами — это составление документа, в котором описывается, что и как часто нужно делать, где хранить, как восстанавливать. Нередко такой документ является частью Disaster Recovery Plan компании.

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

Вот что рассказывает о своем опыте клиент Selectel, который занимается инфраструктурой страховой компании:

«По разным системам у нас есть разные регламенты бэкапирования. Их формулируют владельцы сервиса / приложения исходя из собственных аргументированных потребностей и требований государственных регуляторов, если они есть.

Некоторые системы бэкапятся каждый день или каждую неделю. Если есть активная на запись база данных и потери критичны, бэкап снимается с логов каждый час. Если база большая, то в будни ночью делается дифференциальный бэкап, а полный — в выходные. Для некоторых данных нужно еще организовать долгосрочное хранение на ленточных кассетах до 5-10 лет.

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

Ошибся с выбором окна снятия бэкапов

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

Разработчики знают, что, когда бэкапится база данных, индексы лучше не обновлять, иначе задачи накладываются друг на друга. Как минимум обе операции будут идти дольше и часть ресурсов будет «выедаться» текущей нагрузкой, как максимум — наткнешься на более диковинные конфликты, известные лишь DBA.

Клиент, который развивает площадку для автоматизации рекламных кампаний, обезопасил себя от подобной ошибки с помощью GitHub:

«Все расписания бэкапов у нас лежат в репозитории. На их основании можно найти свободное окно для резервирования нового сервиса.

Окно определяется в зависимости от порядка взаимодействия с сервисом. Где-то пользователи работают с 9:00 до 18:00 — например, бухгалтеры в 1С. После окончания рабочего дня они не задерживаются, так что бэкапиться можно с 6 вечера.

С какими-то системами люди могут взаимодействовать постоянно. Тогда мы снимаем бэкапы с реплики в момент минимальной нагрузки. Потому что, когда реплика бэкапится, входящие записи копятся и занимают место. И нужно рассчитать так, чтобы места хватило как на сам рост базы, так и для wal»
.

Использовал непроверенное решение для бэкапов

Обычно резервное копирование — не место для экспериментов. С другой стороны, непроверенное решение можно тестировать в дополнение к зарекомендовавшему себя способу снятия бэкапов. Если пройдет проверку, его можно использовать на постоянной основе.

Один из клиентов рассказал такую поучительную историю из прошлого:

«Однажды использовал бесплатную программу, которая делала что-то наподобие zip-архивов данных. Впоследствии оказалось, что zip нечитаемые — все архивы побиты. К сожалению, понял я это только тогда, когда нужно было восстановить данные. Сделать это, разумеется, не удалось. Зато с тех пор я всегда проверяю работоспособность копий».

Не проверял работоспособность резервных копий

Говорят, все системные администраторы делятся на три группы: те, кто не делает бэкапы, те, кто делает бэкапы, и те, кто проверяет их консистентность и работоспособность.

Действительно, далеко не всегда бэкапы — это «сделал и забыл». Работа по проверке целостности и периодические восстановления из бэкапа не менее важны. Это даст гарантии, что в экстренном случае резервные копии восстановятся штатно. То есть вы найдете их там, куда положили, они будут консистентными, и вы вернете последнюю версию системы за известное количество времени.

Способов проверки немало. Так, один из опрошенных нами специалистов пробовал и ручные проверки, и решения из «коробки»:

«Сейчас у меня нет регламентов проверки. Просто проверяю работоспособность копий время от времени. Делаю это нерегулярно, но, если настраиваю что-то новое, обязательно чекаю архив.

У ряда компаний этот процесс задокументирован. Так, мой коллега раз в полгода обязательно восстанавливал бэкап production-базы данных и передавал разработчикам на проверку. Некоторые команды хотят, например, видеть базу, развернутую из бэкапа только на чтение, чтобы убедиться, что все данные записаны корректно».

Другой сисадмин с десятилетним стажем уверен, что формирование механизмов проверки бэкапов требует много ресурсов, но, если они есть, нужно делать:

«При первом запуске системы и бэкапов проверяем работоспособность бэкапов и развертку из них. Если бюджет позволяет, проводим искусственные тесты возникновения внештатных ситуаций — так называемые Monkey testing. В рамках теста начинаем отключать инфраструктуру по частям и, руководствуясь регламентом, тренируем необходимые действия в каждом случае. Такие тесты нужны в сложных системах, где есть распределенность не только за счет репликаций, но и функционала (если у вас микросервисы, например)».

Масштабные тесты нужны не всегда. Иногда для проверки достаточно развернуть пустой проект, наполнить его данными, сделать бэкап и восстановиться из него. Также есть практика закрывать риски для систем несколькими способами резервирования: одна копия из 3-4 будет целостной с большей вероятностью.

Использовал несколько способов резервного копирования

Кто-то называет это оверхедом, а кто-то — лучшими практиками. Тем не менее, как показывает опыт сисадминов, чем богаче панель инструментов для бэкапов, тем надежнее. В некоторых компаниях реализовывать бэкапы несколькими способами — корпоративная норма. Главное, чтобы было место для их хранения. Часть клиентов бэкапов по расписанию Selectel подключили решение как раз в добавку к существующим способам бэкапирования — чаще всего кастомным скриптам.

DevOps-специалист, с которым нам удалось поговорить, отметил, что несколько видов бэкапов полезны там, где нужно закрыть и риск падения инфраструктуры, и риск потери данных. Для критических сервисов стоит поднять реплику, чтобы быстро переключиться на нее при отказе «железа». Исключительно на RAID и SMART-мониторинг дисков полагаться не стоит.

Защита данных тоже может быть в двух вариациях. Вот, так, например, решал эту задачу один наш клиент:

«В нашей компании есть правило: резервируем всю инфраструктуру и всегда двумя способами. Так, база данных бэкапится и в режиме plain text — это чистый SQL, который описывает всю структуру базы данных, и в формате бинарных файлов. В экстренном случае это позволит нам более гибко подойти к восстановлению базы».

Не ставил алерты

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

Один из опрошенных клиентов Selectel предлагает не мелочиться и ставить алерты на все:

  • факт снятия копии;
  • копия больше или меньше, чем должна быть;
  • остаточный объем места на сервере, куда отправляются бэкапы (чтобы место не кончилось);
  • статус для команды бэкапа (может завершиться ошибкой) и др.

Конечно, можно работать без алертов, но зачем отказываться от возможности дать инфраструктуре самой сообщить об ошибках. Так, у системного администратора, который поделился с нами опытом, потенциальные проблемы автоматически формируются в тикеты:

«У нас есть проверка на размер бэкапа: он должен расти. То есть текущая резервная копия должна быть больше или равна предыдущей. Если бэкап меньше, сразу формируется тикет — мы расследуем причины. Иногда это связано не с ошибками в копировании, а, например, с чисткой базы. Проверки проводятся в среднем раз в неделю, в зависимости от объема базы данных. Скрипт запускается автоматически по планировщику в GitLab».

Хранил резервные копии на одном сервере с бэкапируемыми данными

Иногда это объясняется тем, что другого места нет и так экономнее (плохой сценарий). Или же так админ решает хранение горячей копии данных, чтобы восстановление конкретного утерянного файла происходило быстрее (хороший сценарий). В таком случае правильность решения определяется наличием холодной копии на стороннем сервере.

Не всегда проблема с системой может затронуть весь сервер. Например, если работник компании нечаянно удалит несколько важных файлов, самой инфраструктуре ничего не грозит. Но, если проблема более сложная, под раздачу попадет весь сервер вместе с бэкапами. Подобных случаев в практике немало. Вот, например, рассказ инженера, который администрировал серверы 1C:

«Ситуация: в пятницу вечером взломали сервер. В субботу бухгалтер захотел поработать, а у него ничего не открывалось. На самом сервере все файлы были зашифрованы. Хорошо, что резервные копии хранились отдельно и нам удалось все восстановить».

Проблема с сервером может произойти как в ПО, так и в «железной» части. Поэтому резервирование серверов часто идет рука об руку с бэкапами данных. Есть такая неприятная история:

«У сервера с базой данных сгорел блок питания — машина перестала работать. Блок питания заменили, но система не загружалась. Вчерашний бэкап “умер” вместе с сервером. Пришлось брать более старую холодную копию. Разницу между репликами восстанавливали вручную всем отделом: вспоминали, что делали последние два дня, какие документы выписывали и меняли».

Забывал делать бэкапы

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

Проблему забывчивости, нехватки времени и добрую половину ранее озвученных вызовов решит сервис бэкапов сетевых дисков по расписанию. Бэкапы создаются автоматически по плану, который достаточно настроить один раз и применить ко всем дискам. Для переноса резервных копий в хранилище используются выделенные сети провайдера (не нужно нужно думать о торможении систем из-за ограничений собственных каналов). А для объема хранимых бэкапов нет ограничений — можно забыть о страхе, что однажды бэкап не сделается из-за отсутствия свободного места на диске.

Автоматические бэкапы в облачной платформе

Настройте расписание резервного копирования и спите спокойно.
Рассчитать цену за бэкапы

Что еще почитать по теме

Кирилл Филипенко 14 сентября 2022

Увеличиваем FPS в аниме с помощью нейросети и GPU Tesla T4

Рассказываем про технологию интерполяции и ее практическое применение с помощью облачных серверов с GPU.
Кирилл Филипенко 14 сентября 2022
Ульяна Малышева 25 августа 2022

CDN против DDoS-атак: в каких случаях это действительно работает

Рассказываем про неочевидное преимущество CDN — услуга повышает безопасность инфраструктуры за счет защиты от DDoS-атак.
Ульяна Малышева 25 августа 2022
T-Rex 24 августа 2022

IT-инфраструктура организации: понятие, типы и функции

Рассказываем об IT-инфраструктуре предприятия и ее компонентах для малого, среднего и крупного бизнеса.
T-Rex 24 августа 2022

Новое в блоге

Михаил Фомин 24 июня 2022

Docker Swarm VS Kubernetes — как бизнес выбирает оркестраторы

Рассказываем, для каких задач бизнесу больше подойдет Docker Swarm, а когда следует выбрать Kubernetes.
Михаил Фомин 24 июня 2022
Ульяна Малышева 30 сентября 2022

«Нулевой» локальный диск. Как мы запустили облако только с сетевыми дисками и приручили Ceph

Чем хороши сетевые диски и почему именно Ceph, рассказал директор по развитию ядра облачной платформы Иван Романько.
Ульяна Малышева 30 сентября 2022
Валентин Тимофеев 30 сентября 2022

Как проходит онбординг сотрудников ИТО? Что нужно, чтобы выйти на смену в дата-центр

Рассказываем, как обучаем новых сотрудников, какие задачи и испытания проходят инженеры прежде, чем выйти на свою первую смену.
Валентин Тимофеев 30 сентября 2022
T-Rex 28 сентября 2022

Книги по SQL: что почитать новичкам и специалистам

Собрали 6 книг, которые помогут на старте изучения SQL и при углублении в тему.
T-Rex 28 сентября 2022