Комментарии 22
как вы отслеживаете ситуацию, что ваш бекап укладывает продакшн?
Все основные параметры сервера (использование CPU, нагрузка на диски) нами мониторятся, и если во время бэкапа нагрузка чрезмерна — бэкап сразу же останавливается. После этого добавляем nice/ionice в запуск бэкапных скриптов. У некоторых утилит — например, у xtrabackup'a — есть встроенные параметры для регулирования нагрузки во время создания бэкапа. Ну и плюс при настройке бэкапов делаем соответствующие правки в скриптах, исходя из опыта.
Создавать бэкапы нужно в самое наименее нагруженное время суток — в этом случае аффект работы проекта минимален.
Если есть возможность — то делать бэкапы лучше не на prod-серверах, конечно, а на реплике БД или резервном сервере, куда синхронизируются файлы с production. Но об этом — в следующих частях :)
Создавать бэкапы нужно в самое наименее нагруженное время суток — в этом случае аффект работы проекта минимален.
Если есть возможность — то делать бэкапы лучше не на prod-серверах, конечно, а на реплике БД или резервном сервере, куда синхронизируются файлы с production. Но об этом — в следующих частях :)
НЛО прилетело и опубликовало эту надпись здесь
А можно не тратиться и поставить, например bacula.
А bacula мы изначально не стали внедрять, т.к. на наш взгляд это монструозная система с большим количеством лишних для нас функций, на доработку которой под наши нужды потребовалось бы значительное количество времени.
НЛО прилетело и опубликовало эту надпись здесь
Стоит понимать, что изначально своя система бэкапов началась из совсем простых скриптов — основное назначение которых было простое создание хоть каких-то бэкапов данных.
А потом они постепенно дорабатывались, исходя из новых требований. Интегрировались в наш мониторинг, в наши процессы, к ним добавлялась автоматизация — и в какой-то момент оказалось, что гораздо удобнее оставить именно их, а не пользоваться какими-то сторонними решениями. Со временем «монстр из скриптов» вырос в полноценный инструмент, который соответствует нашим нуждам и который мы можем расширять новыми модулями по необходимости.
А потом они постепенно дорабатывались, исходя из новых требований. Интегрировались в наш мониторинг, в наши процессы, к ним добавлялась автоматизация — и в какой-то момент оказалось, что гораздо удобнее оставить именно их, а не пользоваться какими-то сторонними решениями. Со временем «монстр из скриптов» вырос в полноценный инструмент, который соответствует нашим нуждам и который мы можем расширять новыми модулями по необходимости.
>С MongoDB всё просто, если её версия ≥ 3.2: /usr/bin/mongodump…
Да, всё просто.
Просто вы так теряете индексы.
Да, всё просто.
Просто вы так теряете индексы.
Было и почище. ISP. Бекапы настроены, всё исправно архивируется. Кроме одного «НО».
Базы в UTF-8, а настройках указано «авто». Вот это авто писало кириллицу неизвестно в чём. В дампах — UTF-8. Но вместо кириллицы знаки вопроса. Хорошо, что проект не в боевом режиме и база относительно маленькая и данные там однотипные. Поправил руками. А иначе бы капут. Проверяю теперь все бекапы.
Базы в UTF-8, а настройках указано «авто». Вот это авто писало кириллицу неизвестно в чём. В дампах — UTF-8. Но вместо кириллицы знаки вопроса. Хорошо, что проект не в боевом режиме и база относительно маленькая и данные там однотипные. Поправил руками. А иначе бы капут. Проверяю теперь все бекапы.
Более 2000 машин… СРК нужно. Единый центр управления и мониторинга будет.
«Целый отдел» и «2000 машин и 20 терабайт ежедневно» — очень странно смотрятся друг рядом с другом. Куда тут целый отдел для таких объемов? Не хотелось бы никого ничему учить, но неужели оплата труда квалифицированных инженеров, которые будут лепить велосипеды, выходит дешевле, чем купить нормальный бекапный софт и посадить на его администрирование одного единственного инженера по совместительству?
Ввиду нашей специфики работы и количества клиентов/проектов/серверов на поддержке — задачи бэкапного отдела сводятся к решению всевозможных задач клиентов из разряда «тут всё поломалось, надо понять как восстановить, чтобы не потерять изменения, произошедшие с момента последнего бэкапа» и к развитию нашей системы создания бэкапов (дописывания новых модулей для нового ПО, новых правил проверки).
Благодаря тому, что резервные копии хранятся в удобном для нас формате — мы всегда можем достаточно оперативно достать нужную часть данных.
Ну и, опять же — применение нашего самописного решения для бэкапов уже не раз себя оправдало. Если бы оно чем-то нас не устраивало — то было бы заменено на что-то другое.
Благодаря тому, что резервные копии хранятся в удобном для нас формате — мы всегда можем достаточно оперативно достать нужную часть данных.
Ну и, опять же — применение нашего самописного решения для бэкапов уже не раз себя оправдало. Если бы оно чем-то нас не устраивало — то было бы заменено на что-то другое.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резервное копирование не «для галочки». Часть первая: мониторинг, бэкапы баз данных и реплики