Организация надежного резервного копирования веб-проекта Антон Баранов
Кто я? Антон Баранов начальник отдела по работе с клиентами в компании ITSumma В прошлом - системный администратор Linux. Более 7 лет опыта работы с Linux-системами и web-проектами различной сложности. Последние два года тружусь над обеспечением стабильной работы highload-проектов для посетителей со всего мира.
О нашей компании: Работаем с 2008 года. Офисы в Иркутске, Санкт-Петербурге и Москве. 150+ клиентов на круглосуточной поддержке. 90 ТБ резервных копий. 5 оповещений о «сломавшихся» бэкапах в сутки.
Мы поддерживаем:
Содержание доклада: • Что бэкапить? • Когда? • Чем? • Откуда? • Как проверить бэкапы?
Внимание! Говорим про LA(N)MP
Бэкап ломается раз в 29 дней
Люди делают бэкапы один раз в … Никогда 25% Год 39% Месяц 19% Неделю 9% День 8% 0 10 20 * по статистике Back. Blaze за 2015 -й год 30 40 50
Общая информация • Что именно нужно бэкапить? • Типы бэкапов. Плюсы и минусы. • Периодичность создания. • Выбор хранилища.
Что бэкапим? • Файлы сайтов • Базы данных • Конфигурационные файлы • Список установленного ПО • Директории с самосборными сервисами
Типы бэкапов • Полный • Инкрементальный
Полные бэкапы Плюсы: • Самодостаточен • Прост в восстановлении • Легко проверить
Полные бэкапы Минусы: • Большой объем • Длительное время создания • Большая нагрузка по сравнению с инкрементальным бэкапом
Инкрементальные бэкапы Плюсы: • Меньше нагрузка на систему • Для передачи нужно меньше трафика • Занимают меньше места
Инкрементальные бэкапы Минусы: • Сложно проверить валидность • Сложно восстанавливать
Периодичность создания Один раз в сутки ночью
Периодичность создания Основные факторы: • Важность данных • Объем
Периодичность создания • Важные данные бэкапим чаще • Объемные - реже
Период хранения • Минимально - 1 неделя • Идеально - бесконечно
Выбор хранилища Не нужно хранить все яйца в одной корзине
Выбор хранилища Плохое внешнее хранилище: • ftp от хостера в этом же ДЦ • сервер в офисе • Dropbox/Яндекс. Диск
Выбор хранилища Хорошее внешнее хранилище: • выделенный сервер с объемными дисками • Amazon S 3 или аналоги (может быть низкая скорость аплоада)
Выбор хранилища Идеальный вариант: • Локальное: отдельный диск • Внешнее: сервер в другом ДЦ
Создание бэкапов • Источники данных для бэкапа • Файлы • БД • Конфигурационные файлы • Особенности создания/восстановления
Источники данных • production-сервер • резерв
Бэкапы с production • аффектят производительность ресурса • проблемы с местом на дисках • можно создавать только в определенное время
Бэкапы с резерва Плюсы: • не аффектят работу ресурса • нет ограничений по времени и способам создания
Бэкапы с резерва Минусы: • нужно поддерживать резерв в актуальном состоянии
Синхронизация на резерв • Файлы: lsyncd (без delete) • БД: штатные средства репликации (реплика не является бэкапом)
Бэкапы файлов • Небольшой объем и количество файлов архивация и копирование • Большой объем данных - rsync на бэкапный сервер (без delete, либо в /backup/YY-MM-DD)
Бэкапы файлов • Данных много, места мало: стриминг tar czhf - /home/bitrix/www/ -exclude=bitrix/managed_cache -exclude=bitrix/stack_cache -exclude=bitrix/cache | ssh $SSH "cat -> ${RPATH}/${FN}" ; » $LOG 2>&1 || die_if_tar_failed files_tar
Бэкапы файлов Не нужно бэкапить: • кэши • внутренние бэкапы CMS • логи приложения
Бэкапы БД Инструменты: • Mysqldump • Percona xtrabackup • pg_dump
Бэкапы БД Трюки: • отложенная репликация pt-slave-delay или CHANGE MASTER TO MASTER_DELAY • репликация и резервирование бинлогов
Бэкапы конфигов • Настройки, кроны, список установленных пакетов, иногда - самосборное ПО • Git в /etc + autocommit • Системы управления конфигурациями
Неочевидные особенности бэкапов • Процесс бэкапа БД не запускается • Бэкапим не ту БД • Бэкап с неактуального резерва • Период бэкапа БД не выверен • Процедура восстановления БД не отлажена
Неочевидные особенности бэкапов • Восстанавливаем не той версией xtrabackup • Нет места для распаковки • ETA восстановления внезапно велико • Апдейт ПО на сервере привел к неработоспособности бэкапов
Неочевидные особенности бэкапов • Архив битый • Бэкап без статики • Архив с картинками сжимается • Бэкапы на том же сервере • Конфиги сервера не бэкапятся
Верификация бэкапов • Тестовый стенд • Мониторинг процесса • Ручные проверки
Верификация бэкапов Непроверенный бэкап - не бэкап
Тестовый стенд • Пять виртуалок для проверки My. SQL: 5. 1, 5. 5, 5. 6, 5. 7, Maria. DB 10 • Скрипты для распаковки, apply-log • Возможность создать виртуалку для проверки всех бэкапов проекта (БД, файлы, конфиги)
Мониторинг процесса • Сервер во время создания (место на диске, нагрузка, доступность проекта) • Вывод логов бэкапных скриптов (innobackupex: completed OK!) • Размер созданных бэкапов
Мониторинг процесса • Изменение размера заливаемых бэкапов • Дату последнего бэкапа
Ручные проверки • Возможность распаковки бэкапа • Проверка времени распаковки • Проверка содержимого бэкапа
Ручные проверки На стенде: • Восстанавливаем БД • Распаковываем файлы сайта • Восстанавливаем конфиги • Проверяем сайт в браузере
Надежный бэкап • Содержит все необходимое для восстановления с нуля • Известны сроки восстановления и они приемлемы • Бэкап актуален • Бэкап проверен • Создается
Антон Баранов https: //www. facebook. com/anton. s. baranov abaranov@itsumma. ru https: //anton-baranov. me
http: //www. itsumma. ru/blog/1/ https: //www. percona. com/blog/2012/01/18/b acking-up-binary-log-files-with-mysqlbinlog/ https: //www. itsumma. ru/blog/5/
Скачать презентацию Организация надежного резервного копирования веб-проекта Антон Баранов
2016 Highload Junior - Организация надежного резервного копирования веб-проекта. Практика и подводные камни.pptx