Архив инкрементный: Инкрементальный бэкап (incremental Backup) файлов. Как сделать?

Инкрементальный бэкап (incremental Backup) файлов. Как сделать?


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

Инкрементальный бэкап.
Копирование только новых и измененных файлов.

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

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

Этот тип бекапа отлично подойдет для резервного копирования больших объемов исходных данных, 50 гигабайт и более. Скорость создания backup’ов будет довольно высокой, а размер каждой добавочной копии может быть всего 100-200 мегабайт.

Плюсы:

  • Быстрое создание резервной копии
  • Малый объем, занимаемый резервной копией (экономия места на диске)

Минусы:

  • Сложность настройки (по сравнению с полной копией Full Backup)
  • Сложность восстановления файлов (по сравнению с полной копией)

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

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

Exiland Backup — простая утилита для резервного копирования и синхронизации папок по сети, FTP, между ПК и серверами. Поддерживает все типы бэкапов файлов.

Эта универсальная программа хорошо подойдет для резервного копирования файловой 1С, сайтов на WordPress и других CMS, копируя файлы сайта с FTP-сервера на локальный ПК.

Для начала скачайте демо-версию backup-программы

Скачать

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

Скриншот программы. Выбор типа копирования.

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

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

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

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

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

Полный бэкап (full backup)

Дифференциальный бэкап (differential backup)

Инкрементное копирование — что это такое. Определение Incremental Backup

30.07.2018

Инкрементное копирование (Incremental Backup) — это метод сохранения информации, при котором архивируются только измененные с момента последнего бэкапа данные.

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

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

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

Алгоритм в этом случае прост: восстанавливается крайняя копия Full Backup, а затем на нее накладывается копия Incremental за последнюю дату резервного копирования. Когда обоснованна данная схема копирования?

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

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

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

+7 965 022 73 40

Перезвонить Вам?

Заявка
в HelpDesk

Часто подаете заявки в Helpdesk через форму на сайте?
Попробуйте более удобный способ — мобильное приложение ITBOX!

Заявка
на услугу / проект

Мы гарантируем конфиденциальность и целевое использование
сообщаемой Вами информации!

Запрос на покупку Битрикс24

1С-Битрикс24: Корпоративный портал 50

Для оформиления покупки сообщите, пожалуйста, свои контактные данные:

Запрос на консультацию по Битрикс24

Сообщите, пожалуйста, свои контактные данные и удобное время для проведения консультации:

Запрос на отправку образца отчета

Сообщите, пожалуйста, свои контактные данные для отправки документа:

Обратный звонок

Сообщите, пожалуйста, свои контактные данные:

Выполнение добавочного резервного копирования с использованием tar

Это гостевой пост, написанный Аруном Кумаром Сори .

Об авторе:

Арун Кумар Сори — энтузиаст открытого исходного кода, любитель C++ и инженер-разработчик. Люблю учиться и делиться.

Выполнение инкрементного резервного копирования с помощью tar

Все мы хорошо знакомы с командой «tar» в Linux. В основном мы используем его для архивации некоторых файлов или получения файлов из уже созданных архивов.

Для тех, кто не знает «tar» означает ленточный архив, который системные администраторы используют для резервного копирования. Команда tar используется для копирования набора файлов и каталогов в сильно сжатый архивный файл, обычно называемый tarball или tar, gzip и bzip в Linux. Команда tar наиболее широко используется для создания сжатых архивных файлов, которые можно легко перемещать с одного диска на другой или с одной машины на другую.

В этом уроке я покажу вам, как использовать редко используемую функцию команды tar, известную как 9. 0003 Инкрементальные дампы .

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

1. Создание архивов из tar

tar -cvf archive.tar /path/to/dir/

В этом примере создается архив archive.tar для файлов в каталог /путь/к/каталогу .

Детали аргументов:

  • c – создание архива
  • v – подробный режим
  • f – тип имени файла для архива

Обратите внимание, что эта команда создает обычный архив, а не сжатый. Для сжатия используйте «z» для tar.gz и «j» для tar.bz2 .

Например:

 tar -cvzf archive.tar.gz /path/to/dir 

Это создает архив tar.gz .

 tar -cvjf archive.tar.bz2 /path/to/dir 

Это создает архив tar. bz2 .

2. Распаковка архивов
tar -xvf archive.tar

То же самое можно использовать и для архивов .tar.gz и .tar.bz2 .

Теперь давайте перейдем к более продвинутым функциям tar, которые обсуждаются в этом руководстве.

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

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

Эта функция предоставляется «tar» путем простого предоставления аргумента «-listed-incremental=snapshot-file» , где snapshot-file — это специальный файл, поддерживаемый командой tar для определения добавляемых файлов.

, изменены или удалены.

Итак, давайте рассмотрим пример:

 tar --listed-incremental=snapshot.file -cvzf backup.tar.gz /path/to/dir 
 tar: .: Каталог новый
./
./1
./бар
./фу
./snapshot.file 

Давайте разберемся, что происходит с приведенной выше командой.

В обычную команду создания архива добавляется только аргумент –listed-incremental .

В приведенной выше команде, если snapshot.file не существует, tar делает полную резервную копию (уровень-0) и создает файл моментального снимка с дополнительными метаданными.

В противном случае будет создан увеличенный архив backup.tar.gz , содержащий только измененные файлы путем проверки snapshot.file. Это будет называться «уровень-1» резервная копия.

 tar --listed-incremental=snapshot.file -cvzf backup.1.tar.gz /path/to/dir 
 . /
./backup.tar.gz
./foo 

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

Итак, если мы хотим сделать больше резервных копий уровня 1 , мы можем скопировать файл моментального снимка, а затем предоставить его tar. Если нам это не нужно, нам не нужно ничего делать, он просто создаст еще один увеличенный архив.

 cp snapshot.file snapshot.file.1 
 tar --listed-incremental=snapshot.file.1 -cvzf backup.1.tar.gz /path/to/dir 

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

Конечно, мы можем заставить tar сделать резервную копию

«уровень-0» , либо удалив файл моментального снимка, либо передав аргумент «-level=0» для tar.

 tar --listed-incremental=snapshot.file --level=0 -cvzf backup.2.tar. gz /path/to/dir 
 tar: .: Новый каталог
./
./1
./бар
./фу
./snapshot.file 

Обратите внимание, что инкрементальные дампы имеют решающее значение на временных метках. Любое вмешательство в них может вызвать проблемы.

Таким же образом мы можем извлечь инкрементные резервные копии.

Для извлечения из инкрементных архивов нам необходимо предоставить аргумент –listed-incremental .

В этом случае tar не нуждается в доступе к файлу моментального снимка, так как все данные, необходимые для извлечения, хранятся в самом архиве. Итак, при извлечении мы можем передать любой аргумент ‘–listed-incremental’ , обычной практикой является использование ‘–listed-incremental=/dev/null’ .

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

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

Сначала выполните level-0 извлечение:

 tar --listed-incremental=/dev/null -xvf backup.tar.gz 

а затем level-1 извлечение:

 tar -- list-incremental=/dev/null -xvf backup.1.tar.gz 

Для получения более подробной информации перейдите по ссылке: http://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html

Обратите внимание, что приведенное выше относится к версии tar GNU.

Кроме того, здесь я сделал сценарий оболочки для создания инкрементных резервных копий и их хранения в удаленных местах (с использованием ssh).

Пояснения даются в файле. Любые комментарии и улучшения приветствуются.

Ура!

Создание добавочных резервных копий с помощью Tar из командной строки Linux

Ранее в этой серии мы рассмотрели добавление и объединение архивов. В этом руководстве мы рассмотрим создание инкрементных резервных копий с помощью tar.

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

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

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

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

Метаданные хранятся в файле, на который мы ссылаемся с опцией –listed-incremental или -g. Если файл не существует, мы выполняем полное резервное копирование или резервное копирование уровня 0, как его называет tar. Это будет резервная копия в понедельник в нашем предыдущем примере. Каждую неделю вам нужно будет перемещать или удалять файл метаданных, чтобы мы начинали каждую неделю с полной резервной копии. Во вторник мы ссылаемся на тот же файл, и поскольку он существует, он становится резервной копией уровня 1. Резервное копирование в среду будет уровня 2 и так далее.

Чтобы увидеть эту работу, давайте создадим новый каталог или домашнюю папку с парой файлов:

 $ cd
 $ mkdir данные
 $ echo "Данные файла1" > данные/файл1
 $ echo "File2 Data" > data/file2 

Имея наши драгоценные данные, мы создадим полную резервную копию, полная резервная копия определяется, когда метафайл не существует. На метафайл ссылаются с параметром -g или –listed-incremental.

 $ tar --create --listed-incremental=data.snar --verbose --verbose --file=data.tar данные
   tar: data: Каталог новый
   drwxrwxr-x ubuntu/ubuntu     0 03.04.2018 14:00 данные/
   -rw-rw-r-- ubuntu/ubuntu     5 03.04.2018 14:00 данные/файл1
   -rw-rw-r-- ubuntu/ubuntu     5 03.04.2018 14:00 data/file2 

Общепринято именовать метафайлы с расширением .snar, думайте об этом как об объединении моментального снимка и tar. Мы также дважды включаем подробный параметр, чтобы увидеть более подробную информацию о том, что резервируется.

Вы, наверное, заметили, что здесь длинные опции становятся громоздкими. Параметр list-incremental может быть сокращен до -g. Полную команду можно переписать так:

 $ tar -cvvg data.snap -f data.tar data
  tar: data: Каталог новый
  drwxrwxr-x ubuntu/ubuntu     0 03.04.2018 14:00 данные/
  -rw-rw-r-- ubuntu/ubuntu     5 03.04.2018 14:00 данные/файл1
  -rw-rw-r-- ubuntu/ubuntu     5 03.04.2018 14:00 data/file2 

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

Теперь мы добавим в каталог новый файл. Когда мы делаем резервную копию после этого добавления, изменяется только новый файл, поэтому копируется ТОЛЬКО этот файл. В этом заключается преимущество инкрементных резервных копий, поскольку файлы хранилища становятся меньше и создаются быстрее. Убедитесь, что мы используем тот же метафайл, но ДРУГОЙ архив.

 $ echo "Данные файла3" > данные/файл3
 $ tar --create --listed-incremental=data.snar --verbose --verbose --file=data1.tar данные
   drwxrwxr-x ubuntu/ubuntu     0 03.04.2018 14:41 данные/
   -rw-rw-r-- ubuntu/ubuntu     11 2018-04-03 14:41 data/file3 

Из подробного вывода видно, что копируются только измененные данные, в данном случае file3. Продолжая неделю, мы редактируем еще несколько файлов. Теперь мы отредактируем файл2 и создадим следующую инкрементную резервную копию. Мы добавляем дополнительную строку в файл2, чтобы имитировать редактирование, обратите внимание на использование >> для добавления; один шеврон перезаписывает файл.

 $ echo "больше данных" >> данные/файл2
 $ tar --create --listed-incremental=data.snar --verbose --verbose --file=data2.tar данные
   drwxrwxr-x ubuntu/ubuntu     0 03. 04.2018 14:41 данные/
   -rw-rw-r-- ubuntu/ubuntu     15 2018-04-03 14:47 data/file2 

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

 $ rm данные/файл1
 $ tar --create --listed-incremental=data.snar --verbose --verbose --file=data3.tar данные
   drwxrwxr-x ubuntu/ubuntu     0 03.04.2018 14:55 данные/ 

Мы видим, что даже с установленной детализацией мы не видим копируемого файла. Файла нет в резервной копии, но удаление сохраняется в метафайле. До некоторой степени мы можем это увидеть, если перечислим только что созданный архив:

 $ tar --list --verbose --verbose --listed-incremental=data.snar --file=data3.tar
  drwxrwxr-x ubuntu/ubuntu     15 03.04.2018 14:55 данные/
  N файл2
  N файл3 

Вывод показывает, что файл2 и файл3 не включены в резервную копию. Это говорит нам о том, что файл file1 включен в резервную копию.

Мы создадим собственную мини-катастрофу, удалив каталог данных из нашего домашнего каталога. После этой катастрофы мы начнем процесс восстановления. Нам не нужен метафайл в восстановлении, поэтому мы отправляем в файл /dev/null:

 $ tar --extract --verbose --verbose --listed-incremental=/dev/null --file=data. смола
  drwxrwxr-x ubuntu/ubuntu     15 03.04.2018 14:00 данные/
  -rw-rw-r-- ubuntu/ubuntu     5 03.04.2018 14:00 данные/файл1
  -rw-rw-r-- ubuntu/ubuntu     5 03.04.2018 14:00 данные/файл2
 $ cat данные/файл1 данные/файл2
  Данные файла 1
  Файл2 Данные 

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

 $ tar --extract --verbose --verbose --listed-incremental=/dev/null --file=data1.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *