Сергей Стариков
технолог инструментов сервиса аутсорсинга бухгалтерии «Кнопка»
Привет. Наверное, каждый может рассказать кучу историй про неудачи и катастрофы админов, потерявших данные из-за отсутствующего или неконсистентного бэкапа. «Кнопка» ведёт бухгалтерию больше 1500 предпринимателей, и мы не можем позволить себе потерять их данные. Рассказываем, как мы подходим к резервированию данных.Файловая хранилка
Как правило, файловое хранилище — это сетевые папки на сервере с доступом по SMB, в лучшем случае располагающееся на RAID-массиве. Какие основные опасности подстерегают:- пользователь с правом записи случайно удалил/фатально изменил файл;
- атака робота-шифровальщика;
- сбой или выход из строя железа.
Система состоит из:
- Директора — управляющий демон, который запускает задания и следит за их выполнением.
- Демонов хранения (Storage Daemon) — служба, предоставляющая устройства хранения (это может быть лента, папка на диске).
- Файловых демонов — служб на бэкапируемых машинах, которые выполняют команды директора. Они существуют для различных ОС, поэтому решение годится не только для инфраструктуры *nix.
- первого числа каждого месяца создаём полную копию — её храним 3 месяца;
- еженедельно создаём дифференциальные копии — их храним месяц;
- ежедневно создаём инкрементальные копии — их храним неделю.
Файловые базы 1С
Для файловых баз подходит Bareos — он отлично работает с теневыми копиями, поэтому может копировать и заблокированные файлы. Если баз не так уж много, подойдёт инструмент «Обновлятор 1С». Мы резервируем файловые базы 1С так же, как и файловые ресурсы.Базы данных
В «Кнопке» мы используем PostgreSQL, поэтому примеры будут для неё, хотя в общем смысле они подходят и для других СУБД.В самом начале мы использовали Bareos, но в настройках клиента указывали плагин, который запускал pg_dump для базы. Полученный файл забирался на сервер архивации, ротация обеспечивалась настройкой архива, схожей с настройками для файловых ресурсов. Но базы росли, pg_dump был всё медленнее, а однажды тестовое восстановление показало неконсистентность архива: некоторые таблицы в базе стали слишком большого размера для pg_dump. К этому времени размер баз 1С у нас перевалил за 500 Гб и намекал, что будет расти и дальше.
https://tproger.ru/events/intensiv-...esql-praktika-primenenija/?utm_source=in_text
А ещё жизнь нам подсказывала, что «помнить» только одно состояние в день недостаточно.
Мы стали использовать pg_basebackup и архивацию wal. Логи хранили неделю. Этот подход позволял нам восстанавливать состояние на любой момент времени. Однако были и минусы. За возможность восстанавливаться на произвольный момент времени потребовалось огромное количество места на сервере с бэкапами.
Нашу проблему решила утилита pg_probackup. Она даёт возможность делать дифференциальные и инкрементальные бэкапы, гибко управлять планом бэкапа, проверять консистентности бэкапа без его восстановления.
Какие копии баз 1С у нас имеются на текущий момент:
- копия на начало года;
- копия на первое число каждого квартала (последние четыре квартала);
- копия на начало каждого месяца;
- полная копия на каждый день за последнюю неделю;
- архив WAL за последнюю неделю.
Настройки сетевых устройств
Даже в небольшой сети, где есть хотя бы три управляемых коммутатора и маршрутизатор, вопрос внезапного восстановления настроек может оказаться очень болезненным. А если этих устройств десятки или больше? Некоторые вендоры делают функционал архивирования конфигов, но единой системы управления всё равно нет.В «Кнопке» мы используем RANCID. Эта утилита работает с различными сетевыми устройствами, собирает с них конфиги по расписанию, её можно подружить с SVN и видеть историю изменений в конфигах.
Бэкап судного дня
Всё вышеперечисленные меры в большой степени защищают нас от потери данных, однако они бессильны, например, перед полным выходом из строя сервера бэкапов, пожара в ЦОД, блэкаута и атаки внеземной цивилизации.Большинство из этих рисков можно решить бэкапом, размещённым в совершенно другой локации и по своим правилам. Для этого подходят хранилища S3. К такому бэкапу странно предъявлять повышенные требования по глубине хранения, он используется для других целей.
По каждому серверу мы определили критичные данные и критичный период резервирования данных, выбрали место, где будем хранить бэкапы, и написали набор скриптов, которые периодически скидывают архивы в это хранилище.
Проверка бэкапов
Даже настроив крутые системы резервного копирования, можно столкнуться с невозможностью восстановить данные. По закону подлости это случится в самый неподходящий момент. Чтобы избежать этого, мы проводим различные упражнения и сделали несложных роботов. Бэкапы PostgreSQL проверяем через pg_probackup, регулярно упражняемся в восстановлении критичной инфраструктуры из бэкапа судного дня. Роботы ежедневно разворачивают полную вчерашнюю копию продуктивной среды 1С со всеми базами, апачами в изолированной тестовой среде.О чём важно не забыть при резервировании данных
- организуйте мониторинг успешности бэкапов;
- периодически проверяйте развёртывание критичных данных;
- следите за схематичной документацией о резервном копировании.
Будет здорово, если эта статья поможет улучшить работу с резервными копиями. А если вы не согласны с нашим выбором, то пишите в комментариях о наших ошибках
Источник статьи: https://tproger.ru/articles/kak-my-v-knopke-podhodim-k-rezervirovaniju-dannyh/