Написать пост

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

Аватарка пользователя Сергей Стариков

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

Привет. Наверное, каждый может рассказать кучу историй про неудачи и катастрофы админов, потерявших данные из-за отсутствующего или неконсистентного бэкапа. «Кнопка» ведёт бухгалтерию больше 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С со всеми базами, апачами в изолированной тестовой среде.

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

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

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

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

Следите за новыми постами
Следите за новыми постами по любимым темам
1К открытий1К показов