Pull to refresh

Comments 22

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

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

Если есть возможность — то делать бэкапы лучше не на prod-серверах, конечно, а на реплике БД или резервном сервере, куда синхронизируются файлы с production. Но об этом — в следующих частях :)
UFO just landed and posted this here
Вся конфигурация бэкапов описана в плейбуках ансибла. В текущей реализации так.
UFO just landed and posted this here
А можно не тратиться и поставить, например bacula.
А bacula мы изначально не стали внедрять, т.к. на наш взгляд это монструозная система с большим количеством лишних для нас функций, на доработку которой под наши нужды потребовалось бы значительное количество времени.
UFO just landed and posted this here
Мы поддерживаем проекты самых разных масштабов. Поэтому нам нужен был универсальный инструмент, который можно применить везде.
А что бы вы рекомендовали для серьёзного продакшена из бесплатных решений, если Bacula/Bareos не очень подходят.
UFO just landed and posted this here
UFO just landed and posted this here
Стоит понимать, что изначально своя система бэкапов началась из совсем простых скриптов — основное назначение которых было простое создание хоть каких-то бэкапов данных.

А потом они постепенно дорабатывались, исходя из новых требований. Интегрировались в наш мониторинг, в наши процессы, к ним добавлялась автоматизация — и в какой-то момент оказалось, что гораздо удобнее оставить именно их, а не пользоваться какими-то сторонними решениями. Со временем «монстр из скриптов» вырос в полноценный инструмент, который соответствует нашим нуждам и который мы можем расширять новыми модулями по необходимости.
UFO just landed and posted this here
Он будет выложен в открытый доступ :) Ближе к концу года, вероятно.
>С MongoDB всё просто, если её версия ≥ 3.2: /usr/bin/mongodump…

Да, всё просто.
Просто вы так теряете индексы.
Было и почище. ISP. Бекапы настроены, всё исправно архивируется. Кроме одного «НО».
Базы в UTF-8, а настройках указано «авто». Вот это авто писало кириллицу неизвестно в чём. В дампах — UTF-8. Но вместо кириллицы знаки вопроса. Хорошо, что проект не в боевом режиме и база относительно маленькая и данные там однотипные. Поправил руками. А иначе бы капут. Проверяю теперь все бекапы.
Да, такое часто случается. Мы все через это прошли, когда-то давно, когда еще пользовались панелями управления)
Именно поэтому мы делаем бинарные бэкапы MySQL — xtrabackup'ом, а потом при необходимости на бэкапном стенде достаём нужную базу или таблицу, проверяя, что с кодировками всё хорошо.
Более 2000 машин… СРК нужно. Единый центр управления и мониторинга будет.
Мы потихоньку идем к тому, чтобы сделать свою собственную централизованную систему управления бэкапами.
«Целый отдел» и «2000 машин и 20 терабайт ежедневно» — очень странно смотрятся друг рядом с другом. Куда тут целый отдел для таких объемов? Не хотелось бы никого ничему учить, но неужели оплата труда квалифицированных инженеров, которые будут лепить велосипеды, выходит дешевле, чем купить нормальный бекапный софт и посадить на его администрирование одного единственного инженера по совместительству?
Ввиду нашей специфики работы и количества клиентов/проектов/серверов на поддержке — задачи бэкапного отдела сводятся к решению всевозможных задач клиентов из разряда «тут всё поломалось, надо понять как восстановить, чтобы не потерять изменения, произошедшие с момента последнего бэкапа» и к развитию нашей системы создания бэкапов (дописывания новых модулей для нового ПО, новых правил проверки).
Благодаря тому, что резервные копии хранятся в удобном для нас формате — мы всегда можем достаточно оперативно достать нужную часть данных.
Ну и, опять же — применение нашего самописного решения для бэкапов уже не раз себя оправдало. Если бы оно чем-то нас не устраивало — то было бы заменено на что-то другое.
Only those users with full accounts are able to leave comments. Log in, please.