Дифференциальные и инкрементальные бэкапы MySQL
Для MySQL существует широко известный инструмент по созданию резервных копий баз данных — mysqldump, который создаёт дамп посредством записи серии SQL-инструкций для восстановления таблиц и данных целевой базы данных.
Он неплохо подходит для резервного копирования небольших баз данных, но когда база данных набирает приличный «вес» и возникает необходимость резервного копирования чаще, чем раз в сутки, скорость создания и размеры дампов могут стать проблемой. В данном случае на помощь приходят утилиты, создающие копию бинарных файлов баз данных, например, такие как Percona XtraBackup.
Percona XtraBackup поддерживает «горячее» резервное копирование для серверов MySQL, Percona, MariaDB и Drizzle (бета) всех версий.
Среди преимуществ такого подхода можно выделить следующие:
Как это работает
XtraBackup начинает копировать файлы баз данных, запоминая номер транзакции на момент начала (LSN), так как копирование файлов занимает какое-то время, данные в них могут измениться, поэтому параллельно XtraBackup запускает процесс, который отслеживает файлы с логами транзакций и копирует все изменения прошедшие с начала копирования.
После того как файлы скопированы, для получения работоспособной копии XtraBackup должен выполнить этап восстановления (crash recovery), используя сохранённый лог транзакций, на данном этапе к файлам баз данных будут применены завершённые транзакции из файла лога транзакций. Транзакции, которые изменили данные, но не были завершены, будут отменены.
После этого этапа файлы баз данных можно использовать для восстановления сервера путём его остановки и копирования файлов в их первоначальное расположение — вручную или используя XtraBackup (обычно это /var/lib/mysql, если сервер MySQL настроен по умолчанию).
Дифференциальные и инкрементальные бэкапы
Часто бывает так, что потеря данных даже за короткий промежуток времени весьма чувствительна, и возникает необходимость делать резервное копирование как можно чаще.
Создание полных бэкапов больших баз данных чаще, чем раз в день, может быть затруднительным — как правило, из-за размера дампов, тут как раз возможность копирования только выполненных изменений будет как нельзя кстати.
В зависимости от стратегии копирования могут использоваться дифференциальные и инкрементальные бэкапы, дополнительно к полным. Дифференциальный бэкап содержит изменения в данных относительно полного бэкапа, инкрементальный — содержит изменения со времени последнего частичного бэкапа – последней инкрементальной копии.
В зависимости от размера баз данных и необходимой частоты резервного копирования стратегии могут заметно отличаться, я же рассмотрю вариант с «недельным» планом, когда в конце недели создаётся полный бэкап, в начале каждого рабочего дня создаётся дифференциальный бэкап, и каждый час в течение рабочего времени — создание инкрементального бэкапа.
Такой план в самом плохом сценарии позволит сохранить данные, не потеряв более одного часа, или восстановить состояние баз на начало любого рабочего часа. А наличие дифференциального бэкапа позволит сократить количество необходимых копий, используемых при восстановлении.
Установка XtraBackup и настройка расписания
Дальнейшие действия выполнялись на CentOS 8, скачать подходящую версию XtraBackup можно с официального сайта.
По умолчанию XtraBackup ищет данные конфигурации сервера и данные подключения пользователя из файлов:
1. Установка:
Скачаем и установим XtraBackup из RPM:
Если планируется использовать компрессию, потребуется установить Qpress:
2. Проверим, что установка прошла успешно:
3. Создадим минимальную версию скрипта, который можно будет вызывать по расписанию в cron:
4. Добавим расписание в /etc/crontab:
Теперь резервное копирование будет выполняться по заданному расписанию в каталог /data/backups/db (как было задано в скрипте), но нужно учесть, что копирование не начнется, пока не будет создан полный и дифференциальный бэкап (в понедельник), поэтому, чтобы проверить работу скрипта, мы создадим их вручную:
Восстановление
Для восстановления состояния баз на требуемое время, нам нужно будет выполнить последовательно этапы:
1. Разархивирование
2. Подготовка:
Теперь, когда в каталоге /data/backups/db/20210913-FULL/ у нас готовые к использованию файлы баз данных, осталось остановить сервер, удалить или перенести старые файлы и скопировать новые файлы в оригинальное расположение и восстановить владельца файлов (mysql).
3. Применение резервной копии:
Заключение
Как известно, администраторы делятся на тех, кто не делает бэкап, и тех, кто уже делает. Последних же можно ещё поделить на тех, кто не проверяет целостность резервных копий, и тех, кто уже проверяет.
Этап с проверкой целостности выходит за пределы данной статьи, что не отменяет его важности, также стоит упомянуть, что статья не описывает всех нюансов использования Xtrabackup, но может послужить отправной точкой для администраторов, решивших делать бэкап чаще, чем раз в сутки.
Инкрементные бэкапы что это
Acronis True Image 2015 предлагает три метода резервного копирования.
Результат операции полного резервного копирования (называемый также полной версией резервной копии) содержит все данные, существовавшие на момент создания резервной копии.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию этого документа методом полного резервного копирования. Acronis True Image сохраняет весь документ при каждом выполнении резервного копирования.
1.tib, 2.tib, 3.tib, 4.tib — это полные версии резервной копии.
Полная версия резервной копии образует основу для последующих инкрементных и дифференциальных резервных копий. и его можно также использовать для создания автономной резервной копии. Создание автономной полной резервной копии может быть оптимальным решением, если вы часто возвращаете систему в исходное состояние или не хотите управлять разными версиями резервных копий.
Результат операции инкрементного резервного копирования (называемый также инкрементной версией резервной копии) содержит только те файлы, которые изменились с момента ПОСЛЕДНЕЙ ОПЕРАЦИИ РЕЗЕРВНОГО КОПИРОВАНИЯ.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию методом инкрементного резервного копирования. Acronis True Image сохраняет новую страницу при каждом выполнении резервного копирования.
Примечание. Сначала всегда создается полная версия резервной копии.
Инкрементные резервные копии наиболее полезны, если нужно часто создавать версии резервных копий и иметь возможность вернуться к состоянию на определенный момент времени. Как правило, инкрементные версии резервной копии существенно меньше полных или дифференциальных.
С другой стороны, инкрементные версии резервной копии требуют больше работы от программы при восстановлении. В приведенном выше примере, чтобы восстановить всю работу из файла 4.tib, Acronis True Image считывает данные из всех версий резервной копии. При утере или повреждении инкрементной версии резервной копии все последующие инкрементные версии резервной копии оказываются бесполезными.
Результат операции дифференциального резервного копирования (называемый также дифференциальной версией резервной копии) содержит только те файлы, которые изменились с момента СОЗДАНИЯ ПОСЛЕДНЕЙ ПОЛНОЙ РЕЗЕРВНОЙ КОПИИ.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию методом дифференциального резервного копирования. Acronis True Image сохраняет весь документ, кроме первой страницы, хранящейся в версии полной резервной копии.
Примечание. Сначала всегда создается полная версия резервной копии.
Дифференциальный метод является промежуточным между двумя предыдущими. При данном подходе требуется меньше времени и места для хранения по сравнению с полным резервным копированием, но больше по сравнению с инкрементным. Для восстановления данных из версии дифференциальной резервной копии Acronis True Image требуется только дифференциальная версия и последняя полная версия. Поэтому восстановление из дифференциальной версии будет проще и надежней, чем из инкрементной.
Инкрементная или дифференциальная резервная копия, созданная после дефрагментации диска, может иметь значительно больший размер, чем обычная. Это вызвано тем, что программа дефрагментации изменяет местоположение файлов на диске и эти изменения отражаются в резервной копии. Поэтому после дефрагментации диска рекомендуется заново создать полную резервную копию.
Чтобы выбрать метод резервного копирования, необходимо задать пользовательскую схему резервного копирования. Дополнительные сведения см. в разделе Пользовательские схемы.
Инкрементальный бэкап (incremental backup) файлов ПК, флешки или сайта
Что такое инкрементальный бэкап?
Этот тип бекапа отлично подойдет для резервного копирования больших объемов исходных данных, 50 гигабайт и более. Скорость создания backup’ов будет довольно высокой, а размер каждой добавочной копии может быть всего 100-200 мегабайт.
Как сделать инкрементный бэкап с помощью Exiland Backup
Эта универсальная программа хорошо подойдет для резервного копирования файловой 1С, сайтов на WordPress и других CMS, копируя файлы сайта с FTP-сервера на локальный ПК.
После запуска, в главном окне программы, сверху на панели нажмите кнопку создания нового задания, укажите название задания, например, «Мои документы» и нажмите «Далее». Теперь как показано на скриншоте ниже, выберите тип копирования «Добавочный (Incremental)».
Скриншот программы. Выбор типа копирования.
Ниже есть возможность ограничить количество полных копий, чтобы самые старые резервные копии автоматически удалялись перед созданием новой копии. Эта настройка экономит место на диске. Также, вы можете ограничить количество инкрементальных копий между полными. При достижении этого ограничения будет создана очередная полная копия.
При выборе шаблона наименования резервных копий, вы можете добавить строку, например, » (incremental)», для инкрементных копий, чтобы визуально их легко отличать от полных.
Инкрементально обновляемый бэкап как стратегия резервного копирования СУБД
На сегодняшний день существует множество вариантов резервного копирования СУБД Oracle, которые позволяют администраторам спать спокойно по ночам и не переживать о том, что могло бы случиться, и как можно было бы этого избежать. Также в помощь – множество программного обеспечения, позволяющего упростить ежедневные рутинные задачи.
Использование Recovery Manager (RMAN), согласно официальной документации, является рекомендованным и одним из наиболее оптимальных способов для резервного копирования и восстановления базы данных Oracle. А возможность выполнять «горячие» бэкапы, оставляя базу доступной для чтений и изменений, делает эту утилиту мощным инструментом для резервирования высокодоступных систем.
В статье я не буду говорить обо всех возможностях Recovery manager, а опишу одну из интересных стратегий резервного копирования, позволяющую по-новому взглянуть на построение системы отказоустойчивости на предприятии. Технология инкрементально обновляемого бэкапа появилась в 10-й версии Oracle. Она предоставляет те же возможности по восстановлению, что и копирование образа базы (image copy), но более быстрая и оказывает меньшую нагрузку на ресурсы системы. Также эта опция сокращает время восстановления за счет меньшего количества журналов, которые необходимо применить для актуализации данных.
Концепция
Суть сохранения данных при помощи Recovery manager в том, что мы один раз делаем полную копию базы, а затем только копируем изменения, при этом – каждый раз при выполнении инкрементального бэкапа предыдущий накатывается на образ базы, актуализируя данные. В результате наш бэкап на физическом уровне состоит всегда из копии данных и файла изменения.
Рассмотрим пример выполнения:
RUN
<
RECOVER COPY OF DATABASE
WITH TAG ‘incremental’;
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG ‘incremental’
DATABASE;
>
Эту команду мы можем поставить в расписание на ежедневное выполнение. Вот как она будет интерпретироваться:
День 0
День 1
День 2 и последующие
Рассмотрим пример команды восстановления с окном в 7 дней:
RUN
<
RECOVER COPY OF DATABASE
WITH TAG ‘incremental’
UNTIL TIME ‘SYSDATE — 7’;
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG ‘incremental’
DATABASE;
>
Оптимизация
Вместе с инкрементально обновляемым бэкапом мы можем использовать еще одну технологию – BLOCK CHANGE TRACKING. При выполнении резервного копирования recovery manager исследует каждый блок данных, отслеживая изменения. Время выполнения такой процедуры прямо пропорционально размеру файлов данных. Она может быть достаточно длительной, даже если было изменено всего лишь несколько блоков. Начиная с 10-й версии в Oracle была представлена новая технология — BLOCK CHANGE TRACKING мы можем создать специальный файл, который записывает модифицированные блоки с момента предыдущего бэкапа. Затем RMAN использует его, чтобы определить изменения. Уже не нужно полностью изучать все доступные данные. Таким образом, скорость выполнения инкрементальной копии прямо пропорциональна измененным блокам. Благодаря реализации такого функционала можно существенно уменьшить время выполнения резервирования.
Быстрое восстановление
SWITCH DATABASE TO COPY;
RECOVER DATABASE;
Acronis True Image: стратегии резервного копирования
Методы создания бэкапов
Создание схемы начинается с понимания методов резервного копирования. Таких методов три: полное, инкрементное и дифференциальное резервное копирование (full, incremental, differential backup). Зачем они нужны и в чем разница? Смотрим.
Полное резервное копирование
Тут все очень просто. В файл бэкапа записываются все данные, которые были выбраны для резервного копирования.
На рисунке: все бэкапы — полные.
Такие бэкапы самые надежные, но и самые большие. При этом для восстановления потребуется только один файл.
Инкрементное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — инкрементные бэкапы.
Инкрементные бэкапы гораздо меньше полных. Однако для восстановления потребуется предыдущий полный бэкап (на рисунке — 1.tib) и вся цепочка инкрементных бэкапов заканчивая тем бэкапом, из которого вы хотите восстановить данные.
Дифференциальное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего полного резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — дифференциальные бэкапы.
Дифференциальные бэкапы меньше полных, но больше инкрементных. Для восстановления потребуется сам дифференциальный бэкап и предыдущий полный бэкап (на рисунке — 1.tib).
Цепочки и схемы
Ну вот мы и подошли к самому интересному. Разумеется, вы уже догадались. Три метода резервного копирования дают нам массу всевозможных вариантов так называемых цепочек бэкапов. Цепочка – это один полный бэкап и все зависящие от него инкрементные и/или дифференциальные бэкапы. Схема же состоит из одной или нескольких цепочек, а также содержит правила удаления старых бэкапов.
Действительно, вариантов цепочек может быть великое множество. Но это в теории. На практике же в основу цепочки берется только один из методов: полный, инкрементный или дифференциальный.
«Тут же все ясно как белый день! Всегда создавай полные бэкапы!» – скажете вы и будете правы. Но как всегда есть одно больше «но». Полные бэкапы – самые увесистые. Вам не жалко забить ваш 2 ТБ диск бэкапами? Тогда это самое лучшее решение. Но большинству хочется максимальной надежности и вариативности при минимальных потерях дискового пространства. Поэтому, как говорится, давайте разбираться. Вот со схем на основе полных бэкапов и начнем.
Схемы на основе полных бэкапов
Схемы на основе инкрементных бэкапов
При такой схеме создается один полный бэкап и цепочка зависимых от него инкрементных. Достоинства очевидны – бэкапы создаются быстро и весят мало, т.е. можно позволить себе насоздавать их гораздо больше, чем при схеме с полными бэкапами. Как итог, вы получаете максимальную вариативность при выборе точки восстановления. Но есть один серьезный недостаток – низкая надежность. При повреждении любого из бэкапов все последующие превращаются в мусор – восстановиться из них вы не сможете. Можно ли каким-то образом повысить надежность? Да, можно. Самый простой способ – создавать новый полный бэкап после нескольких инкрементных, скажем, после четырех или пяти. Таким образом, мы получаем схему с несколькими цепочками, и повреждение одной из цепочек не повлияет на другие.
Эта схема универсальная, ее можно использовать для защиты как дисков, так и файлов.
Схемы на основе дифференциальных бэкапов
При такой схеме создается один полный бэкап и зависимые от него дифференциальные. Этот подход объединяет в себе достоинства двух предыдущих. Так как дифференциальные бэкапы меньше полных и больше инкрементных, вы получаете среднюю вариативность при выборе точки восстановления и довольно высокую надежность. Но без недостатков все равно не обойдешься. Чем дальше по времени отстоит дифференциальный бэкап от своего полного бэкапа, тем он «тяжелее», и даже может превысить размер полного бэкапа. Решение здесь то же, что и при инкрементном подходе, — разбавляйте ваши дифференциальные бэкапы полными. В зависимости от интенсивности изменения защищаемых данных новый полный бэкап рекомендуется создавать после двух-пяти дифференциальных.
Такой схемой можно защитить ваш системный раздел, если дисковое пространство не позволяет вам хранить несколько полных бэкапов.
Планирование
Здесь все просто. Вы составляете расписание, а True Image обновляет для вас бэкапы точно в назначенное вами время и в соответствии с настроенной схемой. Чем чаще меняются данные, тем чаще рекомендуется их бэкапить. К примеру, системный раздел можно бэкапить раз в месяц, а вот файлы, с которыми вы работаете каждый день, и бэкапить рекомендуется каждый день или даже чаще.
Разумеется, когда вам срочно нужно создать бэкап, не обязательно ждать запланированного времени. Вы всегда можете запустить резервное копирование вручную.
Правила очистки
Как насчет бэкапа в облачное хранилище?
Все, о чем мы до сих пор говорили, относится к бэкапам, которые вы храните у себя на внутреннем или внешнем жестком диске, на NAS-е, FTP-сервере и т.д. А как насчет бэкапа в облако? True Image сохраняет как файловые, так и дисковые бэкапы в Acronis Cloud по простой инкрементной схеме – один полный бэкап и цепочка инкрементных – и не позволяет ее менять. На резонный вопрос «почему» ответ прост – эта схема самая бережливая к дисковому пространству, а сохранность бэкапов в облаке гарантирует Acronis.
Правила очистки облачного бэкапа чуть проще, чем обычного.
Вы можете ограничить бэкап по «возрасту» и по количеству версий каждого из файлов, которые хранятся в облаке. Ограничивать бэкап по объему хранилища было бы не очень логично. Ведь в первую очередь Acronis Cloud используется именно для хранения бэкапов.