Дифференциальный бэкап (differential backup) файлов ПК, флешки или сайта
Что такое дифференциальный бэкап?
Как создать дифференциальный бэкап с помощью Exiland Backup
Рассмотрим, как создать разностный бэкап файлов вашего ПК с помощью простой утилиты Exiland Backup.
Установите Exiland Backup, запустите программу.
После запуска, на верхней панели нажмите на кнопку создания нового задания, впишите наименование задания, например, «Мои документы» и нажмите «Далее». На следующем экране мастера выберите тип копирования «Разностный (Differential)».
Мастер создания задания. Выбор типа «Разностный (differential)».
В дальнейших шагах мастера укажите исходную папку, дубликат которой требуется создать, и куда сохранять. Расписание запуска задания пока можете не задавать.
При указании шаблона наименования резервных копий, вы можете добавить строку, например, » (differential)», для дифференциальных, чтобы визуально можно было легко отличить их от полных.
После создания задания запустите его вручную, нажав на кнопку «Выполнить» сверху, на панели.
При первом выполнении задания создастся полная копия. Скопируйте проводником Windows любой файл в исходную папку и запустите задание повторно. Создастся разностная, в которой будет находиться только новый файл.
SQL Server 2008: бэкапим с умом. Часть 1: Теория
Добрый день, друзья. В этой статье я хотел бы рассказать, о чем стоит задуматься, прежде чем настраивать систему резервного копирования баз данных. Несмотря на то, что в первую очередь рассматривается использование данного подхода с MS SQL Server, принципы, изложенные здесь, легко проецируются на любую другую технологию. Ну что ж, поехали.
Первые шаги
Если так уж сложилось, что по долгу своей службы вы отвечаете за сохранность баз данных и бесперебойное функционирование SQL-сервера, то наверняка первой вещью, о которой вы задумаетесь, будут бэкапы — банально по той причине, что если вдруг с вашими базами данных случается какая-нибудь беда, а у вас нет бэкапа, вас ждет не самое приятное будущее. Но вместе со светлой мыслью о необходимости бэкапов приходит и миллион самых разнообразных вопросов: с чего начать? резервировать все базы вместе, или лучше каждую отдельно? делать полный бэкап? А может, лучше резервировать только логи? Что ж, давайте попробуем разобраться.
В первую очередь следует определиться с двумя фундаментальными вопросами:
А вот со вторым вопросом все не так гладко. Хотя бы потому, что в ответ абсолютное большинство руководителей расскажет вам о недопустимости потери данных за любой промежуток времени. Между тем, все мы прекрасно понимаем, что организация отказостойчивой инфраструктуры со сведенным к нулю шансом потери данных — дело сложное, затратное и неподходящее для небольших и средних компаний. Постарайтесь объяснить свою позицию и добиться какого-то более определенного ответа — день, час, полчаса, пять минут или любая другая цифра, с которой вы сможете работать.
Только тогда, когда у вас будут конкретные и однозначные ответы на эти вопросы, вы сможете правильно оценить плюсы и минусы различных подходов к созданию бэкапов.
Full Backup
Полный бэкап — это фундамент, на котором будет держаться вся ваша система резервирования. По большому счету, это копия базы данных, которая включает в себя вообще все — таблицы, данные, индексы, триггеры, статистику, хранимые процедуры и еще много разного добра. Более того — если вы выбираете вариант динамического резервного копирования (то есть во время резервирования данных пользователи могут полноценно работать с сохраняемой БД), то все измения, которые пользователи сделают за то время, пока создается бэкап, тоже будут сохранены. Вы можете легко вернуть базу данных к тому состоянию, в котором она была в какой-то определенный момент, если у вас есть полный бэкап, сделанный в это время.
Главный вопрос, связанный с полными бэкапами — как часто их стоит делать? Универсального ответа нет. Понятно, что полное резервирование должно выполняться по меньшей мере раз в неделю. Если у вас не слишком большие базы данных и нет особых проблем с местом под бэкапы, возможно, резервирование раз в день будет более подходящим вариантом. С другой стороны, слишком частое полное резервирование будет нагружать ваш сервер и потребует неоправданно много дискового пространства для хранения бэкапов. Точная цифра зависит от размера ваших баз данных, производительности и загруженности сервера, ответа на «фундаментальный вопрос номер два» и того, как часто вы будете делать бэкапы других типов, например, бэкап лога или дифференцированный бэкап.
Log backup
Бэкап лога отличается от полного бэкапа тем, что в него входят исключительно изменения базы данных (то есть операции INSERT, UPDATE и DELETE) с момента последнего бэкапа, будь то полный бэкап, дифференцированный или предыдущий бэкап лога. Поскольку объем сохраняемых данных крайне мал, такой тип резервирования намного быстрее, требует меньше ресурсов и занимает меньше места на диске. Недостатков, увы, тоже хватает. В первую очередь, бэкап лога бесполезен, если у вас нет хотя бы одного полного бэкапа. Объясняется это тем, что в таком логе не сохраняется никакая информация о таблицах, индексах, хранимых процедурах и так далее. Вторым существенным недостатком является то, что если с момента последнего полного бэкапа вы успели сделать сотню бэкапов лога, а потом случилась беда, то прежде, чем вы восстановите заветный сотый, вам потребуется восстановить не только полный бэкап, но и предыдущие девяносто девять бэкапов лога, да к тому же в правильном порядке. Согласитесь, приятного в такой перспективе не очень много. Еще одна немаловажная особенность заключается в том, что бэкап лога доступен только для тех баз данных, у которых указан FULL или BULK LOGGED режим восстановления.
Для того, чтобы можно было создавать бэкапы лога, ведение этого самого лога должно быть включено. Хотя данная опция работает по умолчанию и предоставляет немало замечательных возможностей, есть ситуации, когда разумнее будет отказаться от ее использования. Во-первых, лучше отключить ведение лога, если вы собираетесь добавить в базу или изменить в ней очень много данных. Такая операция может занять не один час, но с отключенным протоколированием выполнится намного быстрее. Как только данные будут добавлены, можно смело делать полный бэкап БД и включать режим ведения лога. Вторым пикантным моментом является то, что за логом нужно очень пристально следить — если память, которая доступна для записи лога, заканчивается, система останавливает все выполняющиеся транзакции до тех пор, пока память не будет освобождена. Чтобы избежать такой печальной ситуации, требуется делать бэкап лога как можно чаще — тогда как только вы делаете более свежий бэкап, система помечает сохраненную порцию лога как доступную для перезаписи, тем самым восстанавливая занятое дисковое пространство.
Как часто делать бэкапы лога? Опять же, универсального ответа нет. С одной стороны, чем чаще вы делаете бэкап лога, тем большую гибкость получаете при восстановлении и тем меньше данных теряете в случае каких-то происшествий. С другой стороны, если вы делаете полный бэкап раз в сутки, а бэкап лога раз в минуту, то при худших раскладах вам придется восстановить почти полторы тысячи бэкапов, прежде чем база вернется к тому состоянию, которое можно считать последним рабочим. Мало того, что такая перспектива сама по себе не вдохновляет на подвиги, так еще и в это время над вами будут стоять руководители, директора и все, кому не лень, спрашивая о том, когда же всё будет готово и почему так долго. Думаю, бэкап лога чаще, чем раз в пять минут, практически всегда окажется плохой идеей. Существует мнение, что бэкап лога реже, чем раз в час, тоже не имеет смысла, но это заявление кажется мне несколько спорным. В любом случае, если вы будете держаться в этих пределах, скорее всего, это станет неплохим решением.
Differential Backup
Дифференцированный бэкап — это что-то среднее между полным бэкапом и бэкапом лога. В нем сохраняются изменения, сделанные с момента последнего полного бэкапа по настоящее время. Главным его преимуществом по сравнению с бэкапом лога является то, что для полного восстановления базы данных вам достаточно восстановить только лишь полный и последний дифференцированный бэкапы. Недостатком же является то, что вы не можете восстановить промежуточное состояние базы данных на какой-то момент времени — история изменения БД в дифференцированном бэкапе не сохраняется. Как и бэкап лога, такой бэкап бесполезен, если у вас нет полной копии базы данных.
Вместо постскриптума
Напоследок я хотел бы дать вам несколько советов, которым не нашлось места в рамках основного повествования, но которые слишком важны, чтобы о них молчать.
Дифференциальные и инкрементальные бэкапы 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, но может послужить отправной точкой для администраторов, решивших делать бэкап чаще, чем раз в сутки.
Разностные резервные копии (SQL Server)
Разностная резервная копия основывается на последней предшествующей полной резервной копии. В разностной резервной копии сохраняются только те изменения, которые были произведены с момента создания последней полной резервной копии. Полная резервная копия, на которой основано разностное резервное копирование, известна также как основа разностной резервной копии. Полные резервные копии, за исключением резервных копий только для копирования, могут служить базой для последовательности разностных резервных копий, включая резервные копии баз данных, частичные резервные копии и резервные копии файлов. Базовая разностная резервная копия для файла может содержаться в полной резервной копии, в резервной копии файлов или частичной резервной копии.
Преимущества
Создание разностных резервных копий выполняется гораздо быстрее по сравнению с созданием полной резервной копии. Разностная резервная копия баз данных сохраняет только те данные, которые изменились по сравнению с полной резервной копией, которая служила основой для разностной резервной копии. Это облегчает процесс частого создания резервных копий с целью снижения риска потери данных. Однако перед восстановлением разностной резервной копии необходимо восстановить ее основу. Поэтому восстановление разностной резервной копии потребует большего количества шагов и времени по сравнению с восстановлением полной резервной копии, поскольку будут необходимы два файла резервных копий.
Разностные резервные копии базы данных особенно полезны в тех случаях, когда в базе данных имеется подмножество, которое изменяется значительно чаще всех остальных данных. В этом случае разностная резервная копия позволит чаще производить резервное копирование, одновременно снижая издержки полного резервного копирования базы данных.
В рамках модели полного восстановления использование разностных резервных копий позволяет сократить число резервных копий журналов, которые требуется восстановить.
Общие сведения о разностных резервных копиях
Разностная резервная копия фиксирует состояние любого экстента (набора из 8 физически непрерывных страниц), который изменяется с момента создания базовой копии для разностного копирования до момента создания разностной резервной копии. Это означает, что размер разностной резервной копии зависит от объема данных, которые изменились со времени создания основы. Как правило, чем старее базовая резервная копия, тем больше должна быть новая разностная резервная копия. В последовательности разностных резервных копий часто обновляемый экстент в каждой разностной копии файлов с высокой вероятностью может содержать различные данные.
На следующем рисунке показано, как работает разностное резервное копирование. В базе данных содержится 24 экстента данных, 6 из которых изменены. Разностная резервная копия содержит только эти шесть экстентов данных. Разностное резервное копирование зависит от страницы битовой карты, которая содержит один бит для каждого экстента. Для каждого экстента, обновленного с момента создания основы для разностной копии, в битовой карте биту присваивается значение 1.
Битовая карта разностного резервного копирования не обновляется при создании резервной копии только для копирования. Поэтому резервная копия только для копирования не оказывает никакого влияния на последующие разностные резервные копии.
Разностная резервная копия, создаваемая вскоре после своей основы, занимает значительно меньше места, чем базовая копия для разностного копирования. Это позволяет сэкономить место в хранилище и уменьшить время копирования. Однако с течением времени по мере изменения базы данных различие между базой данных и базовой копией для разностного копирования увеличивается. Чем больше промежуток времени между созданием основы для разностной копии и разностной резервной копией, тем больше места, скорее всего, будет занимать разностная резервная копия. Это означает, что в конце концов разностная резервная копия приблизится по размеру к своей базовой копии для разностного копирования. Разностная резервная копия большого размера теряет все свои преимущества: быстроту работы и малый объем.
Поскольку разностные резервные копии увеличиваются в размере, восстановление разностной резервной копии может значительно увеличить время, которое необходимо для восстановления базы данных. Поэтому рекомендуется через некоторое время выполнить создание новой полной резервной копии, чтобы получить новую базовую копию для разностного копирования. Например, можно выполнять полное резервное копирование всей базы данных один раз в неделю, а затем в течение недели регулярно создавать разностные резервные копии.
Прежде чем начать восстановление из разностной резервной копии, необходимо восстановить основу. Затем восстанавливается только самая последняя разностная копия, чтобы привести базу данных ко времени создания разностной резервной копии. Обычно восстанавливается последняя полная резервная копия, а затем последняя разностная резервная копия, которая на ней основана.
Разностные резервные копии баз данных с таблицами, оптимизированными для памяти
Сведения о разностных резервных копиях и базах данных с оптимизированными для памяти таблицами см. в статье Резервное копирование базы данных с оптимизированными для памяти таблицами.
Разностное резервное копирование баз данных только для чтения
Если база данных, доступная только для чтения, перестраивается, восстанавливается или отсоединяется, а затем снова присоединяется, то теряются все данные основы для разностной резервной копии. Это происходит потому, что база данных master не синхронизована с базой данных пользователя. Компонент Компонент SQL Server Database Engine не может ни обнаружить, ни предотвратить возникновение этой проблемы. Все более поздние разностные резервные копии не будут основаны на последней полной резервной копии, что может привести к непредсказуемым результатам. Чтобы установить новую базовую копию для разностного копирования, рекомендуется создать полную резервную копию базы данных.
Рекомендации по использованию разностного резервного копирования с базами данных только для чтения
Если база данных master утрачена, восстановите ее перед восстановлением любой разностной резервной копии пользовательской базы данных.
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 используется именно для хранения бэкапов.
