Duplicati — инкрементное резервное копирование

Введение

В качестве примера я рассмотрю серверы с установленными там продуктами bitrix, работающими в bitrixenv. Особенностью будет то, что bitrix до сих пор использует не самую свежую версию mysql от percona — Percona Server for MySQL 5.7. Тем не менее, проблем с этим нет никаких. Версия будет поддерживаться минимум до октября 2023 года.

Для полных и инкрементных бэкапов я рассмотрю утилиту Percona XtraBackup, которая позволяет делать архивы баз данных на лету без блокировок таблиц. В моей статье будет использоваться версия 2.4, так как именно она поддерживает mysql 5.7. Это максимально доступная версия в репозиториях, которые устанавливает окружение bitrixenv.

Примеры в этой статье будут актуальны практически для всех версий Mysql и XtraBackup, так как в подходах и командах отличий почти нет

Важно знать, что последняя версия XtraBackup на момент написания статьи была 8.0 и она поддерживает популярный форк mysql — MariaDB только до версии 10.2 включительно, да и то с оговорками. Для более поздних версий mariadb рекомендуется использовать mariabackup

Это форк XtraBackup, который в использовании практически ничем не отличается от оригинала.

Сегодня я рассмотрю инкрементные бэкапы mysql только с помощью XtraBackup, а так же полные бэкапы в том числе с помощью mysqldump. MariaDB и Mariabackup рассматривать не буду. Принципиальных отличий между ними нет. Там все то же самое.

Требования к системе резервного копирования

  • Надёжность хранения информации — обеспечивается применением отказоустойчивого оборудования систем хранения, дублированием информации и заменой утерянной копии другой в случае уничтожения одной из копий (в том числе как часть отказоустойчивости).
  • Многоплатформенность — полноценное функционирование системы резервного копирования в гетерогенной сети предполагает, что её серверная часть будет работать в различных операционных средах и поддерживать клиенты на самых разных аппаратно-программных платформах.
  • Простота в эксплуатации — автоматизация (по возможности минимизировать участие человека: как пользователя, так и администратора).
  • Быстрое внедрение — простая установка и настройка программ, быстрое обучение пользователей.

Ключевыми параметрами резервного копирования являются:

  • RPO — Recovery Point Objective;
  • RTO — Recovery Time Objective.

RPO определяет точку отката — момент времени в прошлом, на который будут восстановлены данные, а RTO определяет время, необходимое для восстановления из резервной копии.

Инкрементное резервное копирование

Инкрементные копии файлов делаются по следующей схеме:

В начале года собирается полный бэкап. Далее в начале каждого месяца – инкрементная месячная копия относительно годичной. Внутри месячных – инкрементные декадные относительно месячной. Внутри каждой декадной – инкрементные дневные относительно декадной.

Стоит оговориться, что пока наблюдаются некоторые проблемы при работе с директориями, которые содержат большое количество поддиректорий (десятки тысяч). В таких случаях сбор копий значительно замедляется и может протекать более суток. Мы активно занимаемся устранением этого недочета.

Восстановление из резервной копии

Восстановить локальную копию можно при помощи команды . Если резервая копия была создана командой

$ rdiff-backup /var/www/example.com/ /backup/www/example.com/

То восстановить ее можно при помощи команды

$ cp -a /backup/www/example.com/* /var/www/example.com/

При этом будет скопирован каталог со служебной информацией утилиты. Так что его надо удалить:

$ rm -r /var/www/example.com/rdiff-backup-data/

Разумеется, утилита умеет и сама восстанавливать файлы с помощью опции (или ). Например, восстановим утраченные файлы веб-сервера из последней версии архива () на backup-сервере:

$ rdiff-backup -r now evgeniy@backup.com::/backup/www/example.com/ /var/www/example.com/
$ rdiff-backup -r 10D \ # восстановить из архива, который был сделан 10 дней назад
> evgeniy@backup.com::/backup/www/example.com/ /var/www/example.com/

Посмотреть историю создания бэкапов и потом выбрать нужный можно с помощью опции (или ):

$ rdiff-backup -l evgeniy@backup.com::/backup/www/example.com/
Found 3 increments:
    increments.2020-08-21T15:55:57+03:00.dir   Fri Aug 21 15:55:57 2020
    increments.2020-08-21T16:55:57+03:00.dir   Fri Aug 21 16:55:57 2020 # версия для восстановления
    increments.2020-08-21T17:55:57+03:00.dir   Fri Aug 21 17:55:57 2020
Current mirror: Fri Aug 21 18:55:57 2020 # последняя версия архива
$ rdiff-backup -r 2B \ # восстановить из архива две версии назад
> evgeniy@backup.com::/backup/www/example.com/ /var/www/example.com/

Можно восстанавливать не весь архив, а отдельные каталоги или файлы. Смотрим существующие версии файла и восстанавливаем нужную:

$ rdiff-backup --list-increments \ # посмотреть существующие версии файла
> evgeniy@backup.com::/backup/www/example.com/index.php
Found 3 increments:
    index.php.2020-08-21T15:55:53+03:00.missing   Fri Aug 21 15:55:53 2020
    index.php.2020-08-21T16:55:53+03:00.diff.gz   Fri Aug 21 16:55:53 2020
    index.php.2020-08-21T17:55:53+03:00.diff.gz   Fri Aug 21 17:55:53 2020 # версия для восстановления
Current mirror: Fri Aug 21 18:55:53 2020 # последняя версия файла
$ rdiff-backup --force -r 1B \ # восстановить файл на одну версию назад
> evgeniy@backup.com::/backup/www/example.com/index.php /var/www/example.com/index.php

Если файл в приемнике уже существует, откажется его заменять и предложит использовать опцию для принудительной перезаписи существующего файла:

Fatal Error: Restore target /var/www/example.com/index.php already exists, specify --force to overwrite.

Differential backup

This type of backup outruns the incremental backups in terms of the data recovery time — it takes far less time since the full copies Х and Хn are compared and, hence, there is no need for a phased recovery. However, in terms of the space required in a data storage system, differential backups are comparable to full backups, which means it doesn’t help to save the storage space and the traffic.

A differential backup means that backups are created on an accrual basis: each modified file in every next backup point is copied again. It looks as follows:: Х, Х1, Х12, Х123, … +Хn, Х+Х(1+…n)

In other words, it’s very bulky and complicated to calculate the required space in the data storage.

It’s simple to realize the difference between an incremental and a differential backup. Actually, it is only one word. Just compare the following two sentences:

  • an incremental backup processes the files that have been created or modified since the time the previous backup was made;
  • a differential backup processes the files that have been created or modified since the time the previous full backup was made.

Восстановление из бэкапа

Давайте теперь восстановим данные из сделанного бэкапа. Если это тот же сервер, то все очень просто. Нам достаточно подготовить бэкап с помощью ключа prepare, как я показал ранее и заменить содержимое рабочей директории mysql на то, что хранится в архиве.

# systemctl stop mysqld && rm -rf /var/lib/mysql/*
# xtrabackup --copy-back --target-dir=/root/backupdb/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

Разбираем, что я сделал.

  1. Остановил mysql сервер и удалил все из ее рабочей директории.
  2. Восстановил данные из архивной копии xtrabackup. По факту он просто скопировал данные в рабочую директорию mysql сервера.
  3. Назначил пользователя mysql владельцем рабочей директории и всего ее содержимого.
  4. Запустил mysql сервер с восстановленными данными.

После запуска mysql сервера проверяйте лог /var/log/mysql/error.log на предмет ошибок. Если увидите там такие ошибки:

 InnoDB: Page  log sequence number 17744745 is in the future! Current system log sequence number 9160744.

Значит забыли выполнить подготовку архива перед восстановлением. Я частенько это забываю и расстраиваюсь, когда вижу ошибки. В общем случае ошибок после восстановления быть не должно.

Если будете восстанавливать базу на другой сервер, то последовательность действий будет следующая. Подключаем репозиторий percona.

# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Ставим mysql server и xtrabackup нужной версии.

# yum install Percona-Server-server-57 percona-xtrabackup-24

Копируем на новый сервер архив сервера баз данных.

# scp root@10.20.1.5:/root/backupdb/full.tar.gz ~

Распаковываем его:

# tar xzvf full.tar.gz

Восстанавливаем данные и запускаем mysql сервер.

# xtrabackup --copy-back --target-dir=~/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

Заходим в консоль mysql и проверяем список баз и пользователей.

# mysql -u root -p
mysql> show databases;
mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;

Все на месте, как и на исходном сервере.

Это я показал восстановление из полного бэкапа. Теперь показываю, как восстановиться из инкрементной копии. Для начала нам надо подготовить полную копию для накатывания на нее инкремента.

# xtrabackup --prepare --apply-log-only --target-dir=/root/backupdb/full

Теперь добавляем туда данные из инкрементного бэкапа.

# xtrabackup --prepare --apply-log-only --target-dir=/root/backupdb/full --incremental-dir=/root/backupdb/inc1

И так для всех остальных инкрементных копий, если у вас из них выстроена цепочка. Контролировать состояние полного архива и сопоставлять с инкрементами можно по содержимому файлов xtrabackup_checkpoints. После того, как восстановили все инкрементные архивы, на последнем из них не нужно использовать ключ apply-log-only. Так же он не нужен, если у вас только одна инкрементная копия. Завершающий этап подготовки полной копии должен быть без него.

После того, как восстановили всю цепочку инкрементов, с архивом можно работать как с обычным полным бэкапом.

Полное резервное копирование на уровне устройств

  1. mdraid и DRBD
    Фактически настраивается RAID1 с диском/рейдом на сервере и сетевым диском, и время от времени (по частоте выполнения бекапов) дополнительный диск синхронизируется с основным диском/рейдом на сервере.

    Самый большой плюс — скорость. Длительность выполнения синхронизации зависит только от количества внесенных за последний день изменений.
    Такая система резервного копирования используется довольно часто, но мало кто отдает себе отчет в том, что полученные с ее помощью резервные копии могут быть недееспособными, и вот почему. Когда синхронизация дисков завершена, диск с резервной копией отключается. Если у нас, например, запущена СУБД, которая пишет данные на локальный диск порциями, храня промежуточные данные в кэше, нет никакой гарантии того, что они вообще попадут на бэкапный диск. В лучшем случае мы потеряем часть изменяемых данных. Поэтому такие бэкапы вряд ли стоит считать надежными.

  2. LVM + dd
    Снапшоты — замечательный инстумент для создания консистентных бекапов. Перед созданием снапшота необходимо сбросить кеш ФС и вашего ПО на дисковую подсистему.

Например, с одним MySQL это будет выглядеть так:

$ sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
$ sudo mysql -e 'FLUSH LOGS;'
$ sudo sync
$ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s
$ sudo mysql -e 'UNLOCK TABLES;'

* Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.

Далее можно копировать снапшот в хранилище. Главное — следить за тем, чтобы во время копирования снапшот не самоуничтожился и не забывать, что при создании снапшота скорость записи упадет в разы.

Бекапы СУБД можно создать отдельно (например, используя бинарные логи), устранив тем самым простой на время сброса кеша. А можно создавать дампы в хранилище, запустив там инстанс СУБД. Резервное копирование разных СУБД — это тема для отдельных публикаций.

Копировать снапшот можно с использованием докачки (например, rsync с патчем для копирования блочных устройств https://bugzilla.redhat.com/show_bug.cgi?id=494313), можно по блокам и без шифрования (netcat, ftp). Можно передавать блоки в сжатом виде и монтировать их в хранилище при помощи AVFS, и примонтировать на сервере раздел с бекапами по SMB.

Сжатие устраняет проблемы скорости передачи, забития канала и места в хранилище. Но, однако если вы не используете AVFS в хранилище, то на восстановление только части данных у вас уйдет много времени. Если будете использовать AVFS, то столкнетесь с её «сыростью».
Альтернатива сжатию блоками — squashfs: можно подмонтировать, к примеру, по Samba раздел к серверу и выполнить mksquashfs, но эта утилита так же работает с файлами, т.е. зависит от их количества.

К тому же при создании squashfs тратится достаточно много ОЗУ, что может легко привести к вызову oom-killer.

Выполнение бэкапа

Тут все элементарно. В главном окне программы выбираем созданное задание и нажимаем Start. Система автоматически подключится к нашему серверу (или нескольким серверам), проверит доступность хранилища и зарезервирует необходимое количество дискового пространства. Затем, собственно, начнется процесс резервного копирования, и по завершении мы получим исчерпывающую информацию о процессе.

Если в процессе запуска бэкапа возникла проблема вида Failed to load module with parameters , то нужно пересобрать модуль veeamsnap в соответствии с инструкцией.

Что особенно интересно — на самом сервере мы можем посмотреть не только список всех выполненных заданий резервного копирования, но и в реальном времени наблюдать за процессом командой veeam:

Предрекая вопрос, почему консоль так странно выглядит, скажу сразу: мне очень нравится, как выглядит консоль на экране теплого лампового СRT-монитора. Делается это при помощи эмулятора терминала cool-retro-term.

Что такое дифференциальный бэкап?

Дифференциальный бэкап.Копирование только добавленных и измененных файлов по сравнению с полной копией.

Дифференциальный бэкап — это тип резервного копирования файлов, при котором копируются не все исходные файлы, а только новые и измененные с момента создания предыдущей полной копии. Он является чем-то средним между полным резервным копированием и инкрементальным. Название этого типа произошло от английского слова Differential backup и является накопительным, т.е. каждая следующая копия содержит все новые/измененные файлы с момента создания предыдущей полной резервной копии. В русском языке этот тип копирования называется Разностным или дифференцированным. Как и каждый другой, этот тип также имеет свои достоинства и недостатки.

Плюсы:

  • Относительно небольшой размер разностной резервной копии, по сравнению с полной
  • Скорость создания в разы выше, чем полного бекапа
  • Для восстановления файлов потребуется последний созданный полный бэкап и последний дифференциальный

Минусы:

Избыточность данных, так как дифф.бекап является накопительным

Вывод: Создавайте дифференциальный backup в том случае, если объем исходных данных большой, файлы в исходной папке изменяются не слишком интенсивно, а простота и скорость восстановления файлов для вас являются критичными. Создание дифференциальных копий происходит достаточно быстро, если накопленных изменений с момента создания полной немного. Оптимальная периодичность создания Differential backup — 1 раз в час, если исходные файлы изменяются часто и 1-2 раза в день, если файлы редактируются редко.

Как создать дифференциальный бэкап с помощью Exiland Backup

Рассмотрим, как создать разностный бэкап файлов вашего ПК с помощью простой утилиты Exiland Backup.

Установите Exiland Backup, запустите программу.

После запуска, на верхней панели нажмите на кнопку создания нового задания, впишите наименование задания, например, «Мои документы» и нажмите «Далее». На следующем экране мастера выберите тип копирования «Разностный (Differential)».

После выбора типа внизу окна вы можете ограничить число полных копий
(по-умолчанию 10) — тогда при достижении этого ограничения самая старая полная резервная копия будет автоматически удалена, после чего будет создана новая (эта настройка недоступна в версии Free). Кроме того, вы можете ограничить число дифференциальных копий
между полными (по-умолчанию 8). При достижении заданного ограничения будет создана очередная полная копия.

На последующих шагах мастера укажите исходную папку, дубликат которой требуется создать, и куда сохранять. Расписание запуска задания пока можете не задавать.

При указании шаблона наименования резервных копий, вы можете добавить строку, например, » (differential)», для дифференциальных, чтобы визуально можно было легко отличить их от полных.

После создания задания запустите его вручную, нажав на кнопку «Выполнить» сверху, на панели.

При первом выполнении задания создастся полная копия. Скопируйте проводником Windows любой файл в исходную папку и запустите задание повторно. Создастся разностная, в которой будет находиться только новый файл.

Михаил, разработчик Exiland Backup

Другие типы резервирования:

Многим известны различные системы создания образов дисков и резервного копирования данных, например Acronis True Image, Pagaron Drive Backup, Ghost, Time Machine для Mac-совместимых компьютеров и др. Компания Microsoft также внедрила в свои операционные системы систему резервного копирования данных, которая доступна как для обычных пользователей, так и для системных администраторов. До выпуска операционной системы Windows Vista компания Microsoft предлагала пользователям систему резервного копирования NTBackup и утилиту System Restore, которые имели массу недостатков. С выходом Windows Vista и переходом на формат хранения образов VHD появилась возможность более простого резервного копирования данных и создания образов операционной системы средствами нового комплекса утилит под названием Windows Backup and Restore. После выпуска новых операционных систем этот компонент совершенствовался и модифицировался. В данной статье мы рассмотрим, что предлагает компания Microsoft конечному пользователю для резервирования данных в недавно вышедшей операционной системе Windows 8. Но сначала вкратце расскажем об основных типах резервного копирования, которые реализованы в многочисленных продуктах различных компаний.

Как создать дифференциальный бэкап с помощью Exiland Backup

Рассмотрим, как создать разностный бэкап файлов вашего ПК с помощью простой утилиты Exiland Backup.

Для начала скачайте демо-версию.

Скачать

Установите Exiland Backup, запустите программу.

После запуска, на верхней панели нажмите на кнопку создания нового задания, впишите наименование задания, например, «Мои документы» и нажмите «Далее». На следующем экране мастера выберите тип копирования «Разностный (Differential)».

Мастер создания задания. Выбор типа «Разностный (differential)».

После выбора типа внизу окна вы можете ограничить число полных копий (по-умолчанию 10) — тогда при достижении этого ограничения самая старая полная резервная копия будет автоматически удалена, после чего будет создана новая. Кроме того, вы можете ограничить число дифференциальных копий между полными (по-умолчанию 8). При достижении заданного ограничения будет создана очередная полная копия.

На последующих шагах мастера укажите исходную папку, дубликат которой требуется создать, и куда сохранять. Расписание запуска задания пока можете не задавать.

При указании шаблона наименования резервных копий, вы можете добавить строку, например, » (differential)», для дифференциальных, чтобы визуально можно было легко отличить их от полных.

После создания задания запустите его вручную, нажав на кнопку «Выполнить» сверху, на панели.

При первом выполнении задания создастся полная копия. Скопируйте проводником Windows любой файл в исходную папку и запустите задание повторно. Создастся разностная, в которой будет находиться только новый файл.

3 марта 2020

Другие типы резервирования:

Чип кассеты

В качестве заключения

  • возможность задания порядка сорс-джоб и файлов в тейп-джобах;
  • добавлена роль Tape Operator (пользователь может делать всё, кроме восстановления с ленты – на это есть Restore Operator);
  • добавлены полноценные include/exclude-маски в файловой тейп-джобе (кроме NDMP);
  • доработано восстановление в файловой тейп-джобе (папка восстанавливается с теми файлами, которые были там на момент бэкапа, а не со всеми, которые были в ней когда-либо за всю историю её бэкапов – очень востребованная фича, кстати);
  • увеличена скорость восстановления очень большого числа файлов с кассет;
  • доработан алгоритм выбора очередной кассеты для записи, в частности, при прочих равных учитываем объём записанных/прочитанных за всю её жизнь данных, берём наиболее свежую;
  • улучшена стабильность продукта.

Полезные ссылки

  • Ссылка для скачивания бесплатной пробной версии VBR 9.5 Update 4
  • Статья на Хабре «Полезные советы по архивированию бэкапов Veeam на магнитную ленту»
  • Статья на Хабре «7 полезных советов по защите резервных копий от вирусов-шифровальщиков»
  • Раздел руководства пользователя, относящийся к тейпам (на англ.языке)
  • Ну и вернулись на прежнее место обзорные видео «Как это работает» (правда, пока на английском языке) – можно посмотреть здесь. Про тейпы рассказывается на слайдах 95 – 102.

What is data backup’s purpose?

Backups in a data security context is a very popular topic for some last years. SIM-Networks also considers the critical value of backup.

A popular theme is inevitably mythologized. We, humans, tend to fill in the gaps in our knowledge with false facts and subjective assessments. It happens with the backup and the issue of its organization by hosting providers. Should the hosting provider to set backup for its customers by default? The answer to this question can be found in our article Backups and hosters: some myths, some truth…

It’s no wonder that backup is so popular. As various malware active evolves, and its evolution is often faster than antivirus software progresses, it’s only logical to base your information security on systematically data backups. Instead of wasting your resources on preventing attacks and fighting viruses, you can save time and money by recovering the system and the data from backups.

Besides, the latest backups can neutralize the impact of force-majeure circumstances or a human factor or the consequences of hardware failure. As you may know, one of the rules for any system administrator is: whenever you set up a new server, start with backups!

Полное резервное копирование на уровне устройств

  1. mdraid и DRBD
    Фактически настраивается RAID1 с диском/рейдом на сервере и сетевым диском, и время от времени (по частоте выполнения бекапов) дополнительный диск синхронизируется с основным диском/рейдом на сервере.
    Самый большой плюс — скорость. Длительность выполнения синхронизации зависит только от количества внесенных за последний день изменений.
    Такая система резервного копирования используется довольно часто, но мало кто отдает себе отчет в том, что полученные с ее помощью резервные копии могут быть недееспособными, и вот почему. Когда синхронизация дисков завершена, диск с резервной копией отключается. Если у нас, например, запущена СУБД, которая пишет данные на локальный диск порциями, храня промежуточные данные в кэше, нет никакой гарантии того, что они вообще попадут на бэкапный диск. В лучшем случае мы потеряем часть изменяемых данных. Поэтому такие бэкапы вряд ли стоит считать надежными.
  2. LVM + dd
    Снапшоты — замечательный инстумент для создания консистентных бекапов. Перед созданием снапшота необходимо сбросить кеш ФС и вашего ПО на дисковую подсистему.
$ sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
$ sudo mysql -e 'FLUSH LOGS;'
$ sudo sync
$ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s
$ sudo mysql -e 'UNLOCK TABLES;'

bugzilla.redhat.com/show_bug.cgi?id=494313

Дифференциальное резервное копирование

Дифференциальное резервное копирование осуществляется, например, при помощи такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементальном резервном копировании.

В целом, если при поиске разницы в данных осуществляется полный перебор файлов, проблемы такого рода резервирования аналогичны проблемам с rsync.

Хотим отдельно отметить, что если в вашей схеме резервного копирования каждый файл копируется отдельно, то стоит удалять/исключать ненужные вам файлы. Например, это могут быть кеши CMS. В таких кешах обычно очень много маленьких файлов, потеря которых не скажется на корректной работе сервера.

Заключение

У каждой системы резервного копирования свои минусы и свои плюсы. В этой статье мы постарались осветить часть нюансов при выборе системы резервного копирования. Надеемся, что они помогут нашим читателям.

В итоге, при выборе системы резервного копирования под ваш проект, нужно провести тесты выбранного типа резервного копирования и обратить внимание на:

  • время резервного копирования в текущей стадии проекта;
  • время резервного копирования в случае, если данных будет в разы больше;
  • нагрузку на канал;
  • нагрузку на дисковую подсистему на сервере и в хранилище;
  • время восстановление всех данных;
  • время восстановления пары файлов;
  • необходимость в консистентности данных, особенно БД;
  • расход памяти и наличие вызовов oom-killer;

В качестве решений по резервному копированию, можно использовать supload и наше облачное хранилище.

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий