Как мы в «Кнопке» подходим к резервированию данных

Сергей Стариков

технолог инструментов сервиса аутсорсинга бухгалтерии «Кнопка»

Привет. Наверное, каждый может рассказать кучу историй про неудачи и катастрофы админов, потерявших данные из-за отсутствующего или неконсистентного бэкапа. «Кнопка» ведёт бухгалтерию больше 1500 предпринимателей, и мы не можем позволить себе потерять их данные. Рассказываем, как мы подходим к резервированию данных.

Файловая хранилка

Как правило, файловое хранилище — это сетевые папки на сервере с доступом по SMB, в лучшем случае располагающееся на RAID-массиве. Какие основные опасности подстерегают:

• пользователь с правом записи случайно удалил/фатально изменил файл;
• атака робота-шифровальщика;
• сбой или выход из строя железа.

Это самый простой случай и вариантов резервирования данных здесь масса. Например, скрипты, утилиты (в том числе и бесплатные) бэкапирования папок на другой носитель, снапшоты и так далее. Когда количество таких папок измеряется сотнями, а объём данных — терабайтами, остро встаёт вопрос, как этим управлять, узнавать о неудачных бэкапах и быстро их восстанавливать. Мы в «Кнопке» уже много лет пользуемся Open Source решением Bareos. Это решение для централизованных бэкапов корпоративного класса. Система работает с файлами, хотя есть возможность научить её работать, например, с базами данных.

Система состоит из:

1. Директора — управляющий демон, который запускает задания и следит за их выполнением.
2. Демонов хранения (Storage Daemon) — служба, предоставляющая устройства хранения (это может быть лента, папка на диске).
3. Файловых демонов — служб на бэкапируемых машинах, которые выполняют команды директора. Они существуют для различных ОС, поэтому решение годится не только для инфраструктуры *nix.

Хранение и управление развёрнуто на специально выделенном сервере с большим количеством дисков, объединённых в RAID-массив. Наличия инструмента для резервирования недостаточно, не менее важен план резервного копирования. Мы очень дорожим своими данными, поэтому поступаем так:

• первого числа каждого месяца создаём полную копию — её храним 3 месяца;
• еженедельно создаём дифференциальные копии — их храним месяц;
• ежедневно создаём инкрементальные копии — их храним неделю.

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

Файловые базы 1С

Для файловых баз подходит Bareos — он отлично работает с теневыми копиями, поэтому может копировать и заблокированные файлы. Если баз не так уж много, подойдёт инструмент «Обновлятор 1С». Мы резервируем файловые базы 1С так же, как и файловые ресурсы.

Базы данных

В «Кнопке» мы используем PostgreSQL, поэтому примеры будут для неё, хотя в общем смысле они подходят и для других СУБД.

В самом начале мы использовали Bareos, но в настройках клиента указывали плагин, который запускал pg_dump для базы. Полученный файл забирался на сервер архивации, ротация обеспечивалась настройкой архива, схожей с настройками для файловых ресурсов. Но базы росли, pg_dump был всё медленнее, а однажды тестовое восстановление показало неконсистентность архива: некоторые таблицы в базе стали слишком большого размера для pg_dump. К этому времени размер баз 1С у нас перевалил за 500 Гб и намекал, что будет расти и дальше.

А ещё жизнь нам подсказывала, что «помнить» только одно состояние в день недостаточно.

Мы стали использовать pg_basebackup и архивацию wal. Логи хранили неделю. Этот подход позволял нам восстанавливать состояние на любой момент времени. Однако были и минусы. За возможность восстанавливаться на произвольный момент времени потребовалось огромное количество места на сервере с бэкапами.

Нашу проблему решила утилита pg_probackup. Она даёт возможность делать дифференциальные и инкрементальные бэкапы, гибко управлять планом бэкапа, проверять консистентности бэкапа без его восстановления.

Какие копии баз 1С у нас имеются на текущий момент:

• копия на начало года;
• копия на первое число каждого квартала (последние четыре квартала);
• копия на начало каждого месяца;
• полная копия на каждый день за последнюю неделю;
• архив WAL за последнюю неделю.

Настройки сетевых устройств

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

В «Кнопке» мы используем RANCID. Эта утилита работает с различными сетевыми устройствами, собирает с них конфиги по расписанию, её можно подружить с SVN и видеть историю изменений в конфигах.

Бэкап судного дня

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

Большинство из этих рисков можно решить бэкапом, размещённым в совершенно другой локации и по своим правилам. Для этого подходят хранилища S3. К такому бэкапу странно предъявлять повышенные требования по глубине хранения, он используется для других целей.

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

Проверка бэкапов

Даже настроив крутые системы резервного копирования, можно столкнуться с невозможностью восстановить данные. По закону подлости это случится в самый неподходящий момент. Чтобы избежать этого, мы проводим различные упражнения и сделали несложных роботов. Бэкапы PostgreSQL проверяем через pg_probackup, регулярно упражняемся в восстановлении критичной инфраструктуры из бэкапа судного дня. Роботы ежедневно разворачивают полную вчерашнюю копию продуктивной среды 1С со всеми базами, апачами в изолированной тестовой среде.

О чём важно не забыть при резервировании данных

• организуйте мониторинг успешности бэкапов;
• периодически проверяйте развёртывание критичных данных;
• следите за схематичной документацией о резервном копировании.

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

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