Организация надежного резервного копирования...

Организация надежного резервного копирования

веб-проекта

Антон Баранов

Кто я?

Антон Барановначальник отдела по работе с клиентами в компании ITSumma

В прошлом - системный администратор Linux.

Более 7 лет опыта работы с Linux-системами и web-проектами различной сложности.

Последние два года тружусь над обеспечением стабильной работы highload-проектов для посетителей со всего мира.

О нашей компании:

Работаем с 2008 года.

Офисы в Иркутске, Санкт-Петербурге и Москве.

150+ клиентов на круглосуточной поддержке.

90ТБ резервных копий.

5 оповещений о «сломавшихся» бэкапах в сутки.

Мы поддерживаем:

Содержание доклада:

•Что бэкапить?•Когда?•Чем?•Откуда?•Как проверить бэкапы?

Внимание!

Говорим про LA(N)MP

Бэкап ломается раз в 29 дней

Series1

0 10 20 30 40 50

Люди делают бэкапы один раз в …

День 8%

Неделю 9%

Месяц 19%

Год 39%

Никогда 25%

* по статистике BackBlaze за 2015-й год

Общая информация

•Что именно нужно бэкапить? •Типы бэкапов. Плюсы и минусы.•Периодичность создания. •Выбор хранилища.

Что бэкапим?

•Файлы сайтов•Базы данных•Конфигурационные файлы•Список установленного ПО•Директории с самосборными сервисами

Типы бэкапов

•Полный•Инкрементальный

Полные бэкапы

Плюсы:• Самодостаточен• Прост в восстановлении• Легко проверить

Полные бэкапы

Минусы:• Большой объем• Длительное время создания• Большая нагрузка по сравнению с

инкрементальным бэкапом

Инкрементальные бэкапы

Плюсы:• Меньше нагрузка на систему• Для передачи нужно меньше трафика• Занимают меньше места

Инкрементальные бэкапы

Минусы:• Сложно проверить валидность• Сложно восстанавливать

Периодичность создания

Один раз в сутки ночью

Периодичность создания

Основные факторы:• Важность данных• Объем

Периодичность создания

• Важные данные бэкапим чаще• Объемные - реже

Период хранения

• Минимально - 1 неделя• Идеально - бесконечно

Выбор хранилища

Не нужно хранить все яйца в одной корзине

Выбор хранилища

Плохое внешнее хранилище:• ftp от хостера в этом же ДЦ• сервер в офисе• Dropbox/Яндекс.Диск

Выбор хранилища

Хорошее внешнее хранилище:• выделенный сервер с объемными дисками• Amazon S3 или аналоги (может быть низкая

скорость аплоада)

Выбор хранилища

Идеальный вариант:• Локальное: отдельный диск• Внешнее: сервер в другом ДЦ

Создание бэкапов

• Источники данных для бэкапа• Файлы• БД• Конфигурационные файлы• Особенности создания/восстановления

Источники данных

• 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 восстановления внезапно велико• Апдейт ПО на сервере привел к

неработоспособности бэкапов

Неочевидные особенности бэкапов

• Архив битый• Бэкап без статики• Архив с картинками сжимается• Бэкапы на том же сервере• Конфиги сервера не бэкапятся

Верификация бэкапов

• Тестовый стенд• Мониторинг процесса• Ручные проверки

Верификация бэкапов

Непроверенный бэкап - не бэкап

Тестовый стенд

• Пять виртуалок для проверки MySQL: 5.1, 5.5, 5.6, 5.7, MariaDB 10• Скрипты для распаковки, apply-log• Возможность создать виртуалку для

проверки всех бэкапов проекта (БД, файлы, конфиги)

Мониторинг процесса

• Сервер во время создания (место на диске, нагрузка, доступность проекта)• Вывод логов бэкапных скриптов

(innobackupex: completed OK!)• Размер созданных бэкапов

Мониторинг процесса

• Изменение размера заливаемых бэкапов• Дату последнего бэкапа

Ручные проверки

• Возможность распаковки бэкапа• Проверка времени распаковки• Проверка содержимого бэкапа

Ручные проверки

На стенде:• Восстанавливаем БД• Распаковываем файлы сайта• Восстанавливаем конфиги• Проверяем сайт в браузере

Надежный бэкап

• Содержит все необходимое для восстановления с нуля• Известны сроки восстановления и они

приемлемы• Бэкап актуален• Бэкап проверен• Создается

Антон Баранов

https://www.facebook.com/anton.s.baranovabaranov@itsumma.ru

https://anton-baranov.me

http://www.itsumma.ru/blog/1/https://www.percona.com/blog/2012/01/18/backing-up-binary-log-files-with-mysqlbinlog/https://www.itsumma.ru/blog/5/