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

Введение

В качестве примера я рассмотрю серверы с установленными там продуктами 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 рассматривать не буду. Принципиальных отличий между ними нет. Там все то же самое.

Общие сведения о разностных резервных копиях

Разностная резервная копия фиксирует состояние любого экстента (набора из 8 физически непрерывных страниц), который изменяется с момента создания базовой копии для разностного копирования до момента создания разностной резервной копии. Это означает, что размер разностной резервной копии зависит от объема данных, которые изменились со времени создания основы. Как правило, чем старее базовая резервная копия, тем больше должна быть новая разностная резервная копия. В последовательности разностных резервных копий часто обновляемый экстент в каждой разностной копии файлов с высокой вероятностью может содержать различные данные.

На следующем рисунке показано, как работает разностное резервное копирование. В базе данных содержится 24 экстента данных, 6 из которых изменены. Разностная резервная копия содержит только эти шесть экстентов данных. Разностное резервное копирование зависит от страницы битовой карты, которая содержит один бит для каждого экстента. Для каждого экстента, обновленного с момента создания основы для разностной копии, в битовой карте биту присваивается значение 1.

Примечание

Битовая карта разностного резервного копирования не обновляется при создании резервной копии только для копирования. Поэтому резервная копия только для копирования не оказывает никакого влияния на последующие разностные резервные копии.

Разностная резервная копия, создаваемая вскоре после своей основы, занимает значительно меньше места, чем базовая копия для разностного копирования. Это позволяет сэкономить место в хранилище и уменьшить время копирования. Однако с течением времени по мере изменения базы данных различие между базой данных и базовой копией для разностного копирования увеличивается. Чем больше промежуток времени между созданием основы для разностной копии и разностной резервной копией, тем больше места, скорее всего, будет занимать разностная резервная копия. Это означает, что в конце концов разностная резервная копия приблизится по размеру к своей базовой копии для разностного копирования. Разностная резервная копия большого размера теряет все свои преимущества: быстроту работы и малый объем.

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

Прежде чем начать восстановление из разностной резервной копии, необходимо восстановить основу. Затем восстанавливается только самая последняя разностная копия, чтобы привести базу данных ко времени создания разностной резервной копии. Обычно восстанавливается последняя полная резервная копия, а затем последняя разностная резервная копия, которая на ней основана.

What is Differential Backup?

Differential backup will back up changed files based on the last full backup. This method also requires a full backup exists. All differential backups are based on the full backup, so they are relatively independent. 

During a differential backup, only marked files and folders will be backed up and the Archive Attribute will be not be cleaned, i.e. these files will not be marked as “backed up” after the differential backup. 

In terms of recovery, you just need last full backup and the latest differential backup. Here comes an example of creating differential backup with differential backup software.

Suppose that E Drive has the following data:

File name	File size
E:\file1.txt	2GB

The first job is to create a full backup of file1.txt to generate Full1.adi.

Then add file2.txt and file3.txt to E drive. Run differential backup, and you’ll get Diff1.adi that contains file2.txt and file3.txt.

Then add file4.txt and file5.txt to E drive, run differential backup, you’ll get Diff2.adi that contains file2-5.txt.

The theory is the same. It will backup changed files based on last full backup. In that case, if you lost Diff1.adi file, you can still restore all files using Full1.adi and Diff2.adi. This method requires more time on backing up yet it costs less time in recovery.

ЗАЧЕМ НУЖНО РЕЗЕРВНОЕ КОПИРОВАНИЕ

О резервном копировании в последнее время много говорят и пишут. И мы, SIM-Networks, в том числе. 🙂

Модная тема неизбежно мифологизируется. Нам свойственно заполнять пробелы в своих познаниях выдуманными фактами и субъективными оценками. Так происходит, в частности, в том, что касается услуги резервного копирования и вопроса ее организации провайдерами хостинга. Должен ли хостер предоставлять своим клиентам резервное копирование автоматически, по умолчанию? Ответ на этот вопрос можно найти в нашем материале “5 мифов о бэкапе и хостинг-провайдерах”

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

Overview

When you create a backup for data, generally, there are three types of backup images. Maybe you do not even notice, the backup type has been selected by default. To be specific, they are full backup, incremental backup, and differential backup.

In a nutshell, they are different but indivisible. Note that a full backup will be created firstly no matter which backup type you choose. Full backup is the basis of all backup types. Here is a simple understanding.

• Full backup refers to back up files completely, each backup is a complete backup and can be restored separately.

• Incremental backup means to backup files that are changed since the last backup (full or incremental). Recovery requires ALL linked incremental backups, and the full backup;

• Differential backup means to backup files that are changed since the last full backup. Recovery requires the latest differential backup and the full backup;

It can be clearly understood from above that the difference between incremental and differential backup, which needs different backup basis and recovery requirements. Then, detailed information on these backup types will be introduced below.

What is Full Backup?

Full backup refers to creating a backup of all the valid data, whether it is newly added or exists for a long time. Full backup does not depend on the file’s Archive Attribute to decide which file should be backed up. During a full backup, all existing marks will be cleaned and be marked as “backed up”, i.e. clear Archive Attribute. 

To create a full backup of selected files or applications means to create an identical duplication of these data at a particular time point. Therefore, with only one full backup, you can completely restore all data, which dramatically decrease the recovery time.

For instance, we’ll create a full system backup image using full backup software after installing an operating system. If the system is 12GB, all system files and applications will be backed up. We can easily perform a system restore using this full backup. This also applies to fully backing up a data partition, a file folder and the entire disk and so on.

How about the disadvantage? Full backup has a fatal disadvantage as well. To keep the backup up to date, it is unavoidable to create more than one full backup. In that case, many identical data will be backed up again, which is a waste of time and storage. 

Luckily, the appearance of incremental and differential backup makes it possible to figure out all these problems.

Iperius Bakcup, самый полный инструмент

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

Внутри раздела «Пуск» мы видим кнопки для создания новых резервных копий. Первая кнопка со знаком плюса (+) используется для создания новой копии. Кнопка справа используется для выполнения существующей копии. Следующие значки позволяют нам изменять предпочтения, просматривать отчеты, открывать FTP-клиент, подключаться к Iperius Online Storage и открывать справку.

Общие предпочтения

В этом разделе «Пуск» Iperius Backup на вкладке «Общие настройки» появляется новое окно «Общие настройки», откуда мы можем определить поведение программы , например, защита изменений конфигурации с помощью пароля.

На вкладке «Дополнительно» мы можем определить несколько параметров, таких как уровень ведения журнала или свойства для копирования файлов. На вкладке «Консоль» мы можем удаленно управлять программой.

Создать новую задачу резервного копирования

Если мы нажмем кнопку «Создать новую задачу резервного копирования», откроется новое окно для создания резервной копии. В нем есть несколько вкладок, таких как «Элементы», «Пункты назначения», «Планирование», «Параметры» и «Сводка». Все они будут помощь us настроить и сохранить нашу копию . С помощью первой кнопки мы можем добавлять папки, а с помощью второй мы можем добавлять файлы, которые будут составлять нашу копию, и это будут параметры, которые мы используем чаще всего, особенно если мы выберем бесплатную версию программы.

На следующем экране мы должны выбрать путь, по которому мы хотим сохранить копию. Это может быть любое хранилище, подключенное к компьютеру, или на ленте, на FTP или в облаке.

Позже во вкладке «Расписание» мы можем запустить резервное копирование. по расписанию в зависимости от сделанных нами настроек. Таким образом, мы можем делать это еженедельно, ежемесячно или время от времени. Таким же образом мы можем вставить выбранное расписание.

На последнем экране сводка всех операций будет выполняться вместе с резервным копированием , так что все, что у вас есть для этого нажмите ОК. После добавления задачи все, что вам нужно сделать, это щелкнуть по ней правой кнопкой мыши и нажать «Запустить резервное копирование».

Creating an Incremental Backup¶

To make an incremental backup, begin with a full backup as usual. The
xtrabackup binary writes a file called into
the backup’s target directory. This file contains a line showing the
, which is the database’s at the end of the backup.
with a following command:

$ xtrabackup --backup --target-dir=/data/backups/base

If you look at the file, you should see similar
content depending on your LSN nuber:

backup_type = full-backuped
from_lsn = 0
to_lsn = 1626007
last_lsn = 1626007
compact = 0
recover_binlog_info = 1

Now that you have a full backup, you can make an incremental backup based on
it. Use the following command:

$ xtrabackup --backup --target-dir=/data/backups/inc1 \
--incremental-basedir=/data/backups/base

The directory should now contain delta files, such
as and . These represent the
changes since the . If you examine the
file in this directory, you should see similar
content to the following:

backup_type = incremental
from_lsn = 1626007
to_lsn = 4124244
last_lsn = 4124244
compact = 0
recover_binlog_info = 1

is the starting LSN of the backup and for incremental it has to be
the same as (if it is the last checkpoint) of the previous/base
backup.

It’s now possible to use this directory as the base for yet another incremental
backup:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \
--incremental-basedir=/data/backups/inc1

This folder also contains the :

backup_type = incremental
from_lsn = 4124244
to_lsn = 6938371
last_lsn = 7110572
compact = 0
recover_binlog_info = 1

Общие советы

1. Чтобы проверить успешность бэкапа, можно воспользоваться опцией проверки контрольной суммы BACKUP WITH CHECKSUM. Но для больших баз данных применение опции проблематично, т.к. она способна сильно загрузить систему.
2. Бэкапы не следует выполнять на физические диски, где хранятся данные либо журнал транзакций.
3. При использовании версий MS SQL Server 2008 и выше, рекомендуется выполнять сжатие копий БД средствами SQL.
4. Копии лучше сохранять несколько дней. Если какая-нибудь окажется поврежденной, наличие старой будет как нельзя кстати. По истечении этого времени ненужные файлы с расширением bak следует удалить.
5. Перед выполнением копирования рекомендуется проверять базы, воспользовавшись DBCC CHECKDB. Это позволит своевременно получить сообщение о возникновении проблем.
6. Периодически следует обновлять статистику и реорганизацию индексов БД.

Как становится понятно, проблем с резервным копированием не должно возникать. Процесс легко настроить с помощью вышеописанных инструментов. Изучайте материал, применяйте на практике. При возникновении вопросов – обязательно задавайте. Делитесь своими мыслями и полезными советами.

Инкрементный бэкап Mysql

Основное удобство XtraBackup как раз в простых, быстрых и удобных инкрементных бэкапах для mysql. Допустим, по примеру выше, вы сделали полный бэкап. Он должен быть не сжатый. Теперь на основе этого полного бэкапа, можно сделать инкрементный, где будут только изменения со времени полного бэкапа.

# xtrabackup --backup --target-dir=/root/backupdb/inc1 --incremental-basedir=/root/backupdb/full

Можно проверить, что конкретно в себя включает полный бэкап, а что инкремент. В директории с бэкапами есть файл xtrabackup_checkpoints примерно следующего содержания.

backup_type = full-backuped
from_lsn = 0
to_lsn = 17687056
last_lsn = 17687065
compact = 0
recover_binlog_info = 1
flushed_lsn = 17687065

LSN — log sequence number. Это регистрационные номера транзакций. В данном случае полный бэкап начинается с нулевой транзакции и заканчивается 17687056. Теперь смотрим этот же файл в директории inc1.

backup_type = incremental
from_lsn = 17687056
to_lsn = 17710039
last_lsn = 17710048
compact = 0
recover_binlog_info = 1
flushed_lsn = 17710048

Инкрементный бэкап базы начался с той транзакции, на которой закончился полный. Следующий инкрементный архив может быть создан опять на базе полного, либо уже инкрементного. То есть либо так:

# xtrabackup --backup --target-dir=/root/backupdb/inc2 --incremental-basedir=/root/backupdb/full

либо так:

# xtrabackup --backup --target-dir=/root/backupdb/inc2 --incremental-basedir=/root/backupdb/inc1

Можете сами проверить, какие номера транзакций будут в этих случаях. Я обычно делаю раз в день полный бэкап и потом инкрементные на основе полного. Цепочки инкрементных бэкапов делать не люблю, так как если возникнут проблемы с одним из архивов цепочки, возникнут трудности с восстановлением.

Предлагаю вот такой скрипт для инкрементных бэкапов — mysql-inc-backup.sh.

#!/bin/bash

DATA1=`date +%Y-%m-%d`
DATA2=`date +%H-%M-%S`

xtrabackup --backup --target-dir=/root/backupdb/$DATA1/inc-$DATA2 --incremental-basedir=/root/backupdb/$DATA1/full

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

Хотя лично я делаю не так. Я сервером бэкапа сам постоянно подключаюсь к целевым серверам и забираю данные, подчищаю за собой. А на сервере уже обрабатываю их, пакую и распределяю по директориям.

Иллюстрация

Разницу между инкрементным и дифференциальным резервным копированием можно проиллюстрировать следующим образом:

Инкрементальные резервные копии:

День	Воскресенье	понедельник	вторник	Среда	Четверг	Пятница	суббота	Воскресенье
Тип резервного копирования	Полный	Инкрементальный	Инкрементальный	Инкрементальный	Инкрементальный	Инкрементальный	Инкрементальный	Полный
Эффект	Нет данных	Изменения с воскресенья	Изменения с понедельника	Изменения со вторника	Изменения со среды	Изменения с четверга	Изменения с пятницы	Нет данных

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

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

День	Воскресенье	понедельник	вторник	Среда	Четверг	Пятница	суббота	Воскресенье
Тип резервного копирования	Полный	Дифференциальный	Дифференциальный	Дифференциальный	Дифференциальный	Дифференциальный	Дифференциальный	Полный
Эффект	Нет данных	Изменения с воскресенья	Изменения с воскресенья	Изменения с воскресенья	Изменения с воскресенья	Изменения с воскресенья	Изменения с воскресенья	Нет данных

Важно помнить стандартное значение этих двух терминов, потому что, хотя приведенные выше термины очень широко используются, некоторые авторы, как известно, меняют их значение. Например, корпорация Oracle использует обратное описание дифференциальных резервных копий в своем продукте БД по состоянию на 14 мая 2015 года:. «Дифференциальное инкрементное резервное копирование — при дифференциальном резервном копировании уровня 1 RMAN выполняет резервное копирование всех блоков, которые изменились с момента последнего накопительного или дифференциального инкрементного резервного копирования, будь то на уровне 1 или уровне 0

RMAN определяет, какое резервное копирование уровня 1 было выполнено последним, и выполняет резервное копирование все блоки, измененные после этого резервного копирования. Если уровень 1 недоступен, RMAN копирует все блоки, измененные с момента резервного копирования уровня 0 «.

«Дифференциальное инкрементное резервное копирование — при дифференциальном резервном копировании уровня 1 RMAN выполняет резервное копирование всех блоков, которые изменились с момента последнего накопительного или дифференциального инкрементного резервного копирования, будь то на уровне 1 или уровне 0. RMAN определяет, какое резервное копирование уровня 1 было выполнено последним, и выполняет резервное копирование все блоки, измененные после этого резервного копирования. Если уровень 1 недоступен, RMAN копирует все блоки, измененные с момента резервного копирования уровня 0 «.

10 Клонезилла

Если вам нужно бесплатное программное обеспечение для резервного копирования Windows для клонирования системных образов и дисков, я настоятельно рекомендую инструмент с открытым исходным кодом Clonezilla. Он не предлагает вам наилучшего пользовательского интерфейса, но он очень надежен, и вы можете клонировать жесткие диски нескольких файловых систем, даже не загружаясь в систему. Да, вам нужно создать загрузочный флэш-накопитель для использования Clonezilla, но это очень быстро, когда дело доходит до клонирования файлов, папок и системных образов с нескольких жестких дисков. Что касается системы разделов Windows, она поддерживает как GPT, так и MBR, так что это здорово. Clonezilla утверждает, что она может одновременно получать данные из более чем 40 источников жесткого диска без какого-либо снижения скорости. Подводя итог, если вы переходите на новый компьютер с Windows или перемещаете файлы на новый жесткий диск или твердотельный накопитель, используйте Clonezilla в своих интересах. Однако имейте в виду, что вы не можете планировать резервное копирование с помощью Clonezilla.

Скачать (Бесплатно)

Как создать полную резервную копию файлов с помощью Exiland Backup

Рассмотрим, как сделать полный backup файлов на компьютере с помощью простой утилиты для системы Windows. Это очень простой способ.

В верхней части главного окна — кнопки управления, а под ними — список заданий. Первоначально он пуст.

Утилита позволяет создать полный бэкап

Теперь, находясь в главном окне программы, на верхней панели нажимаем кнопку «Создать» для создания нового задания. В пошаговом мастере вписываем наименование задания, например, «Мой сайт» и нажимаем «Далее». На экране появится выбор типа резервного копирования.

Выбор типа бэкапа

Выбираем соответствующее значение. Ниже, есть возможность ограничить количество копий, хранимых на диске для того, чтобы самые старые автоматически удалялись перед созданием новой. Эта настройка экономит место на диске. Также, вы можете указать, чтобы back-up создавался в любом случае, даже если исходные данные не изменились. По-умолчанию, если ни один файл в исходных папках не изменился с момента создания предыдущего бэкапа, то резервная копия не будет создана.

Остальные настройки задания (сжатие в ZIP, шифрование, папка для хранения, время запуска задания и уведомления) не вызывают трудностей. Вы можете настроить их самостоятельно или оставить пока по-умолчанию.

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

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

Программа имеет гобкие настройки, рассчитана даже не малоопытного пользователя ПК и прекрасно подойдет как для дома, так и для локальной сети организации.

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

29 апреля 2021

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

Ротация бэкапов

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

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

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

Бэкап отдельной таблицы или базы

Не всегда нужны архивные копии всего mysql сервера. Иногда достаточно отдельной базы данных или даже таблицы. Xtrabackup позволяет это сделать. Архивируем только одну базу данных sitemanager.

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

# xtrabackup --backup --databases "sitemanager" --target-dir=/root/backupdb/sitemanager

Восстановление отдельной базы mysql будет выглядеть так.

# xtrabackup --prepare --databases "sitemanager" --target-dir=/root/backupdb/sitemanager
# systemctl stop mysqld
# mkdir -p /var/lib/mysql.old/sitemanager
# mv /var/lib/mysql/sitemanager /var/lib/mysql.old
# mv /root/backupdb/sitemanager/sitemanager /var/lib/mysql
# chown -R mysql. /var/lib/mysql
# systemctl start mysql

Мы по сути просто скопировали исходные файлы базы из бэкапа в рабочий каталог, предварительно сохранив предыдущую версию базы на всякий случай.

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

Готовим бэкап к восстановлению:

# xtrabackup --prepare --export --target-dir=/root/backupdb/full

Идем в консоль mysql и выбираем там таблицу для восстановления. В моем примере это будет таблица b_user_access из базы sitemanager. Смотрим, заполнена ли таблица данными.

mysql> SELECT COUNT(*) FROM sitemanager.b_user_access;
+----------+
| COUNT(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

Делаем DISCARD этой таблицы.

mysql> ALTER TABLE sitemanager.b_user_access DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

Discard означает, что будет удален ibd файл таблицы. Теперь нам его нужно скопировать из бэкапа и назначить права для mysql.

# cp /root/backupdb/full/sitemanager/b_user_access.* /var/lib/mysql/sitemanager
# chown mysql. /var/lib/mysql/sitemanager/b_user_access.*

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

mysql> ALTER TABLE sitemanager.b_user_access IMPORT TABLESPACE;
Query OK, 0 rows affected (0.03 sec)

Смотрим, что получилось.

> SELECT COUNT(*) FROM sitemanager.b_user_access;
+----------+
| COUNT(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

Данные восстановлены. Вернулись те же 6 строк, что и были до этого.

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

1. Если у вас загрузчик RE загружается на Hyper-V виртуальной машине по сети, но не работает клавиатура в ней. Поздравляю, ваш RE образ для WinXP или древнее и не знает о существовании Hyper-V драйверов.
2. Если у вас система начинает восстанавливать бэкап, но останавливается. Удалите все разделы на жестком (на котором восстанавливается бэкап) и попробуйте заново. Только не забывайте, что бэкап может быть битый и после удаления всех разделов на жестком у вас может ничего не остаться от старой информации.
3. Если бэкап с загрузкой UEFI, а вы хотите восстановить на комп без UEFI, то не стоит тратить время. Скорее всего развернуть бэкап не получится.
4. Бэкап с загрузкой UEFI и разделами GPT можно восстанавливать на машины с другим процессором / материнкой, а вот с разделами MBR формата и с загрузкой обычного BIOS на другой машине развернуть вряд ли получится. Ну у меня точно не получалось.
5. Если бэкап пытаться развернуть на диск с меньшим объемом, то сделать это не получится. Даже если диск в бэкапе был почти пуст. В этом случае помогает восстановление на виртуальную машину с динамическим диском. Далее уменьшение этого диска и создание нового бэкапа. Но такое можно только с загрузчиком UEFI в бэкапе (почему, читаем предыдущий пункт).
6. Стоит перед восстановлением бэкапа отключить лишние диски, чтобы не затереть информацию на них.

Дельта блочное резервное копирование

Понятие «дельта» часто относят к методу дифференциального резервного копирования, но иногда его так же называют «дельта резервное копирование», «дельта блочное копирование» и «дельта стилевое резервное копирование». И в основном, все эти понятия относятся к одной и той же технологии создания резервной копии. Метод дельты корректнее всего называть дельта блочное резервное копирование, которое применяется в связке с инкрементальным и дифференциальным подходами

Важно отметить, что метод дельта блочного резервного копирования применяется только для измененных файлов, а не созданных. Добавленные файлы, конечно, так же сохраняются в копиях, но в обычном режиме

Ранее описанные методы резервного копирования создают полную копию измененного файла, даже если в нем изменился всего один символ. Конечно, такой подход не будет составлять особой проблемы, если речь идет о маленьких текстовых документах, но в случае с очень большими файлами, такими как базы данных, такой подход будет весьма проблематичным. К примеру, почтовые клиенты, такие как Outlook, чаще всего хранят всю информацию в одном большом файле (письма, контакты и прочее). В этом случае получается, что даже получив одно письмо, все предыдущие методы будут вынуждены создавать копию всего файла. А поскольку такого рода файлы могут часто меняться, то какой бы подход вы не применяли, ваши бэкапы будут разрастаться непомерными шагами и приводить к хранению огромного числа избыточной информации.

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

Примечание: Размер блока будет зависеть от программ или выбранного пользователем размера, если такое поддерживает программа. Обычно, размер блоков находится в диапазоне от 1 до 32 килобайт. 

Дельту особенно хорошо применять в технологиях, где файлы резервируются сразу после их создания или изменения. Этот подход так же известен как резервирование в режиме реального времени или непрерывной защиты данных. Дельту так же полезно применять, когда резервные копии сохраняются на удаленных ресурсах (сервера, хранилища) в условиях ограниченной пропускной способности.

Преимущества и недостатки дельта блочного резервного копирования

• Дельта резервные копии занимают очень мало места и создаются намного быстрее 
• Дельта бэкапы позволяют хранить намного меньше избыточной информации — Методы инкрементального и дифференциального резервного копирования, из-за необходимости копировать файлы, при их минимальном изменении, могут хранить значительное количество избыточной информации. Метод дельта блочного копирования позволяет снизить этот уровень.
• Так как дельта блоки создаются программами по специфическим алгоритмам, то восстановить их можно только этими же программами. В этом смысле такие бэкапы будут ограничивать тех пользователей, у которых может возникать необходимость ручного восстановления данных.
• Дельта блочное резервирование медленнее, так как необходимо восстанавливать файлы из различных частей.

Восстанавливаемся из инкрементных бэкапов

С восстановлением из дискретных бэкапов проблем нет – просто берём копию за нужную дату и разворачиваем обычным консольным tar. С инкрементными копиями немного сложнее. Чтобы восстановиться, например, на 24 июля 2018, нужно выполнить следующее:

1. Развернуть годичный бэкап, пусть в нашем случае он отсчитывается от 1 января 2018 (на практике это может быть любая дата, в зависимости от того, когда было принято решение внедрить инкрементное резервное копирование)
2. Накатить на него месячный бэкап за июль
3. Накатить декадный бэкап за 21-ое июля
4. Накатить дневной бэкап за 24 июля

При этом для выполнения 2-4 пунктов необходимо в команду tar добавить ключ -G, тем самым указав, что это инкрементный бэкап. Конечно, не самый быстрый процесс, но если учесть, что восстанавливаться из бэкапов приходиться не так уж часто и важна экономичность, такая схема получается вполне эффективной.