Резервное копирование не «для галочки». Часть первая: мониторинг, бэкапы баз данных и реплики

[erlyvideo]

как вы отслеживаете ситуацию, что ваш бекап укладывает продакшн?

[antosha]

Все основные параметры сервера (использование CPU, нагрузка на диски) нами мониторятся, и если во время бэкапа нагрузка чрезмерна — бэкап сразу же останавливается. После этого добавляем nice/ionice в запуск бэкапных скриптов. У некоторых утилит — например, у xtrabackup'a — есть встроенные параметры для регулирования нагрузки во время создания бэкапа. Ну и плюс при настройке бэкапов делаем соответствующие правки в скриптах, исходя из опыта.

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

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

[antosha]

Вся конфигурация бэкапов описана в плейбуках ансибла. В текущей реализации так.

[dbax]

А можно не тратиться и поставить, например bacula.

[antosha]

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

[antosha]

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

[sohmstyle]

А что бы вы рекомендовали для серьёзного продакшена из бесплатных решений, если Bacula/Bareos не очень подходят.

[antosha]

Стоит понимать, что изначально своя система бэкапов началась из совсем простых скриптов — основное назначение которых было простое создание хоть каких-то бэкапов данных.

А потом они постепенно дорабатывались, исходя из новых требований. Интегрировались в наш мониторинг, в наши процессы, к ним добавлялась автоматизация — и в какой-то момент оказалось, что гораздо удобнее оставить именно их, а не пользоваться какими-то сторонними решениями. Со временем «монстр из скриптов» вырос в полноценный инструмент, который соответствует нашим нуждам и который мы можем расширять новыми модулями по необходимости.

[antosha]

Он будет выложен в открытый доступ :) Ближе к концу года, вероятно.

[pansa]

>С MongoDB всё просто, если её версия ≥ 3.2: /usr/bin/mongodump…

Да, всё просто.
Просто вы так теряете индексы.

[timelle]

Было и почище. ISP. Бекапы настроены, всё исправно архивируется. Кроме одного «НО».
Базы в UTF-8, а настройках указано «авто». Вот это авто писало кириллицу неизвестно в чём. В дампах — UTF-8. Но вместо кириллицы знаки вопроса. Хорошо, что проект не в боевом режиме и база относительно маленькая и данные там однотипные. Поправил руками. А иначе бы капут. Проверяю теперь все бекапы.

[antosha]

Да, такое часто случается. Мы все через это прошли, когда-то давно, когда еще пользовались панелями управления)
Именно поэтому мы делаем бинарные бэкапы MySQL — xtrabackup'ом, а потом при необходимости на бэкапном стенде достаём нужную базу или таблицу, проверяя, что с кодировками всё хорошо.

[DesertFoxAst]

Более 2000 машин… СРК нужно. Единый центр управления и мониторинга будет.

[antosha]

Мы потихоньку идем к тому, чтобы сделать свою собственную централизованную систему управления бэкапами.

[FlashHaos]

«Целый отдел» и «2000 машин и 20 терабайт ежедневно» — очень странно смотрятся друг рядом с другом. Куда тут целый отдел для таких объемов? Не хотелось бы никого ничему учить, но неужели оплата труда квалифицированных инженеров, которые будут лепить велосипеды, выходит дешевле, чем купить нормальный бекапный софт и посадить на его администрирование одного единственного инженера по совместительству?

[antosha]

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