Инкрементное копирование. Резервирование данных средствами ОС Windows

Сегодня мы рассмотрим принципы организации инкрементального и дифференциального резервного копирования с использованием программы .

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

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

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

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

Итак, для определенности, допустим нам необходимо организовать резервное копирование папки C:\work\ в архив D:\backup\ . Мы будем делать полный бэкап по воскресеньям (например, выходной, когда никто не работает с сервером) а инкрементальные копии каждый вечер остальных дней недели.

Режим копирования может быть ЛЮБОЙ, программа будет работать одинаково в любом режиме: Архивирование (возможно с использованием внешнего архиватора), копирование, копирование на FTP. В нашем примере это будет архивирование с использованием внутреннего архиватора.

Итак, для начала создадим задание для организации полного копирования.

Назовем задание TEST_FULL, режим копирования: «Архивировать» , Вид резервного копирования: «Сохранять все файлы»

Расписание: еженедельно по воскресеньям .

Источник: «C:\WORK»

Для сохранения полного архива используем папку «d:\backup\» , архив имеет префикс «FULL_» + формат даты . Глубина = 1, т.е. будет сохранен только 1 последний полный архив.

В принципе, для надежности можно копирование полного архива в дополнительные директории на другом сервере и даже на FTP сервер в этом же задании.

Теперь, когда задание для полного резервного копирования готово, можно создать его копию для настройки инкрементального резервного копирования. Копию задания можно сделать, находясь в основном окне программы через меню «Задание»-> «Создать копию (F5)»

После создания копии будет открыто окно конфигурации нового задания. Нам необходимо внести следующие изменения в новом задании:

Описание: «TEST_INC», Вид резервного копирования: «Только новые и измененные файлы (с последнего архива)» . Это как раз инкрементальный режим резервного копирования. Для выбора дифференциального режима необходимо выбрать режим копирования: «Только новые и измененные файлы (с последнего полного архива)»

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

На закладке «Сохранение архива» необходимо изменить префикс архива на другой чем у полной копии, изменим на «INC_». А так же изменим глубину архива на 7 ДНЕЙ. Т.к. для восстановления нам понадобятся ВСЕ инкрементальные копии с момента полного архива т.е. все копии за последние 7 дней. В случае дифференциального копирования глубину можно задавать 1 день, т.к. нам необходимо будет только последний архив.

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

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

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


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

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

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

Как настроить бэкап

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

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

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

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

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

Основные критерии выбора программы для бэкапов

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

  • эффективность расхода ресурсов: программа должна работать в максимально автономном режиме (не отвлекая вас и не тратя ресурс вашего времени, то есть автоматизирована насколько возможно), с минимально возможной загрузкой ресурсов системы и выполняться за минимально возможное время;
  • скорость восстановления: ПО должно восстанавливать ваши данные из резервной копии максимально быстро, чтобы не страдали бизнес-процессы; идеальной будет функция работы напрямую с копиями данных;
  • защита данных и безопасность: программа для резервного копирования обязательно должна обеспечивать вам достаточный уровень безопасности - как криптографическими, так и аппаратными средствами (защита каналов передачи данных в СХД, защита данных во время операции резервного копирования, возможность восстановления прерванной сессии);
  • гибкость: ПО должно быть одинаково пригодно для всех типов данных (поскольку невозможно прогнозировать, какие из них вы посчитаете критически важными и выберете для копирования в резервное СХД), а также давать вам возможность выбора методов бэкапа и одинаково полноценно функционировать при любом из них.

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

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

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

Тут все понятно из названия: каждый раз, согласно заданию на бэкап, создается полная копия всей системы, точнее, всех тех данных, которые вы определили для резервного копирования при постановке задачи. Для уменьшения итогового объема резервной копии все данные сжимаются в архив. Таким образом, в вашем хранилище при полном резервном копировании с заданной периодичностью появляются архивы, где данные в основной своей массе дублируются (поскольку на протяжении долгого времени не изменяются). Это серьезный недостаток, ведь расходуется огромный объем ресурсов (см.п.1 в списке критериев бэкапа): место в хранилище, время создания и процессорное время, вычислительные мощности, наконец, ресурсы трафика при транспортировке архивов в удаленную СХД. И хотя метод полного копирования ранее был очень распространенным из-за высокой надежности, в чистом виде на сегодняшний день он признан малоэффективным. Например, для резервного копирования невысокой глубиной (менее двух недель) или с высокой частотой (раз в сутки, раз в несколько часов) полный бэкап чрезмерно расходует ресурсы.

Немного спасет ситуацию механизм дедупликации - выявление и удаление дублирующихся данных в полных копиях. Он также задается специальными программными средствами как на уровне СХД или сервера, так и на клиенте непосредственно. Статистика в некоторых источниках приводит впечатляющие результаты степени дедупликации - от 90% до 98%.

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

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

Инкрементальный, или инкрементный, бэкап (incremental backup)

По сравнению с full backup гораздо экономичнее и быстрее, поскольку в этом процессе копируются только те файлы, которые изменились со времени предыдущего резервного копирования. Исходные данные, записанные изначально, не перезаписываются. Механизм инкрементального копирования прост: в качестве начальной точки бэкапа Х 0 выбирается время (например, полночь с воскресенья на понедельник), в которое делается полный бэкап; в точке Х 1 (полночь с понедельника на вторник) делается копирование файлов, измененных и/или появившихся с момента Х 0 ; в точке Х 2 (полночь со вторника на среду) копируются файлы, измененные/появившиеся с момента выполнения Х 1 ; … в точке Х n происходит завершение цикла и делается следующий полный бэкап.

Этот метод гораздо более экономично расходует ресурсы и места в хранилище, и времени, и трафика передачи данных, по сравнению с другими. Однако при восстановлении данных в случае необходимости из резервной копии происходит поэтапное восстановление из точек Х n-1… Х 2, Х 1, Х 0 - до последнего полного бэкапа включительно, и этот процесс может занять много времени.

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

Выигрывает перед инкрементальным в случае восстановления данных - время на эту операцию у него меньше, поскольку сравниваются полные копии Х 0 и Х n и не требуется поэтапного восстановления. Однако в части объема пространства для размещения в СХД дифференциальное резервное копирование сопоставимо с полным, поэтому экономии места в хранилище и трафика практически не достигается.

При дифференциальном бэкапе происходит копирование «нарастающим итогом»: каждый измененный файл в каждой последующей точке бэкапа копируется заново. То есть выглядит это как: Х 0 , Х 1 , Х 1 +Х 2 , Х 1 +Х 2 +Х 3 , … +Х n , Х 0 +Х (1+… n)

Словом, очень громоздко и сложно при расчете места в СХД.

Понять разницу между инкрементальным и дифференциальным бэкапом достаточно просто. Фактически - она в одном слове. Просто сравните:

  • инкрементальный обрабатывает файлы, измененные или созданные с момента выполнения предыдущего бэкапа;
  • дифференциальный обрабатывает файлы, измененные или созданные с момента выполнения предыдущего полного бэкапа.

Другие виды резервного копирования

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

Его отличает высокая скорость создания, крайняя экономия места и значительно меньшее (в сравнении с инкрементальным и дифференциальным бэкапами) количество избыточных данных. Казалось бы, применять дельту должны все, но этого не происходит, поскольку создание бэкапов таким способом и восстановление информации происходит средствами специального ПО. Кроме того, восстановление из дельта-бэкапа происходит очень долго: данные приходится собирать из мозаики измененных кусочков. Тем не менее, этим методом удобно пользоваться для обеспечения непрерывной защиты данных (когда бэкап файла делается непосредственно после его создания или внесения в него изменений - механизм, который отдаленно напоминает автосохранение в файлах Word’а))) или в случаях пониженной пропускной способности при сохранении резервных копий в удаленном СХД.

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

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

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

За последние 12-15 лет в технологиях резервного копирования произошло много критических изменений, заставивших пересмотреть эффективность подходов и открыть новые способы. Например, внедрение технологии снэпшотов (snapshots ) - моментальных «снимков» файловой системы, из которых можно «склеить» резервную копию, - позволяют в облачных системах делать резервное копирование быстро и безболезненно, не останавливая виртуальной машины. Кроме того, применяясь в облаке, снэпшоты позволяют серьезно экономить ресурс СХД, поскольку на диске клиента они места не занимают.

Клиенты SIM-Networks выбирают бэкап!

Конечно, если вы любите все делать самостоятельно, для вас не составит проблемы настроить резервное копирование вручную - на своем домашнем компьютере. Правда, даже в этом случае есть частичный риск, ведь что-то может пойти не так, и ценные фотографии, книги, видеозаписи или расчеты ракетной ступени случайно могут не сохраниться или сохраниться с дефектом, который сделает невозможным их восстановление из резервной копии. А если речь идет об офисных машинах? Как быть, если необходимо обеспечить бэкап данных, которые хранит корпоративная инфраструктура? Мы рекомендуем все-таки полагаться не на собственные силы, а на профессионализм хостинг-провайдера. Заказать настройку резервного копирования и пространство для удаленного хранения резервных копий в Германии - это очень просто.


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

Если вы арендуете мощности в нашей облачной инфраструктуре , заказать услугу резервного копирования SIM-Cloud BaaS , проще простого, в пару кликов. Всё уже настроено и будет подключено автоматически, как только вы дадите команду. Кстати, когда наши инженеры разрабатывали SIM-Cloud BaaS, они проанализировали эффективность разных типов бэкапа и остановили свой выбор на методе инкрементального копирования. Наше резервное копирование в облаке оптимизировано таким образом, что показатель RTO (время восстановления данных из копии) составляет в среднем от 15 до 30 минут в зависимости от объема данных. Облачный BaaS от SIM-Networks соответствует всем заявленным выше критериям высококачественного резервного копирования.

Вы можете самостоятельно выбрать, в каком дата-центре организовать хранилище для бэкапов. Первый вариант - локальное хранение: ваши резервные копии хранятся в том же ДЦ, где развернута ваша основная инфраструктура. Это дает возможность ускорить RTO и RPO. Второй вариант - бэкапы отправляются на хранение в дата-центр, удаленный от того, в котором развернута основная инфраструктура. Восстановление данных в этом случае будет происходить немного медленнее, но фактор безопасности выше. Если вы сомневаетесь, какой вариант выбрать, обратитесь в нашу службу Customer Care - вам помогут подобрать оптимальное решение.

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

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

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

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

Другие методы и техники резервного копирования

1. Полная резервная копия

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

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

Преимущества и недостатки создания полных резервных копий

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

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

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

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

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

Преимущества и недостатки инкрементных резервных копий

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

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

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

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

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

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

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

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

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

Примечание : Примером применения такого метода резервного копирования является FastBittm, который используют крупные компании, такие как Microsoft, IBM и Compaq.

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

Преимущества и недостатки бинарных патчей резервных копий

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

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

6. Зеркальные резервные копии

Большинство программ резервного копирования поддерживают зеркальное резервное копирование в качестве альтернативы полному копированию, дифференциальному и прочим. Некоторые программы используют альтернативную терминологию для понятия зеркала, как например, "простое копирование". Отчасти это происходит от того, что зеркальные копии в основном представляют собой простой тип создания бэкапа. В данном методе не применяется каких-либо специальных резервных технологий, только простая операция копирования. Как пример, если вы копируете и вставляете каталог с одного диска на другой, то можете считать, что вы создали зеркальную резервную копию этой папки. Файлы в зеркальных копиях обычно представляют собой те же файлы, что и в источнике. Они не сжимаются в архивы, как при полном резервном копировании (хотя некоторые программы поддерживают сжатие отдельных файлов и шифрование).

Когда используются зеркальные резервные копии

Зеркальные копии без сжатия хорошо подходят в тех случаях, когда большинство копируемых файлов уже сжато в архивы. Например, музыкальные файлы в формате mp3 или wma, изображения в формате jpg или png, видео в DivX, mov или flv формате. Кроме того, большинство инсталляторов так же сжаты. Если включить эти файлы в обычную процедуру полного резервного копирования, которая применяет сжатие, то вы заметите, что кроме того, что такое копирование будет выполняться долго, итоговый архив будет мало отличаться в размере (очень мало данных будет сжато). В этом смысле, лучше всего создавать отдельные задания для резервного копирования для сжатых и не сжатых файлов. Если ваши программы резервного копирования поддерживают фильтры, то вы можете их использовать для автоматического выбора подходящих файлов для каждого из заданий.

Преимущества и недостатки зеркальных резервных копий

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

7. Синтетические полные резервные копии

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

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

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

8. Резервное копирование с использованием жестких ссылок

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

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

При использовании программ резервного копирования, которые поддерживают жесткие ссылки для создания нескольких копий одинаковых файлов, программа будет создавать жесткие ссылки для всех файлов, которые не изменились. Например, если вы создаете две копии каталога, который содержит 100 Мб данных, то, в обычных условиях, эти копии занимали бы 200 Мб на жестком диске. С помощью жестких ссылок такие копии будут занимать все те же 100 Мб дискового пространства. Изменение любого из файлов в таких каталогах будет в действительности изменять только одни физические данные, при этом эти данные будут доступны в обоих каталогах. К примеру, если после создания каталогов с жесткими ссылками, вы в первом каталоге увеличите файл на 2 Мб, то их общий размер будет 102 Мб, и при этом в обоих каталогах данные в файле будут одни и те же.

Следует отметить, что если вы захотите удалить одну из резервных копий, содержащих жесткие ссылки, то это не будет проблемой, та как при этом не затрагиваются остальные ссылки. Физические данные файла на диске удаляются только тогда, когда все жесткие ссылки на него были удалены. Так же необходимо понимать, что жесткие ссылки можно создавать только в приделах одного тома (логического диска). Например, между разными разделами или дисками нельзя создавать жесткие ссылки. В Windows файловых системах, NTFS поддерживает жесткие ссылки, в то время как FAT не поддерживает.

Примечание : Проводник Windows, при подсчете размера, не учитывает использование жестких ссылок. Это означает, что если файл занимает 100 Мб и имеет две жесткие ссылки, то в реальности будет потребляться всего 100 Мб диска, в то время как проводник Windows будет показывать использование 200 Мб диска. Этот момент необходимо учитывать, при использовании резервного копирования с использованием жестких ссылок.

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

Заключительные слова о резервировании

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

Теперь, вы знаете некоторые термины резервного копирования, а так же понимаете, что обозначают методы в теории и на практике.

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

Принцип дифференциального резервного копирования

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

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

Дифференциальная копия обычно занимает намного меньше места, чем полная. Так, если из 2000 файлов в наборе данных со времени полного копирования изменились только 10, то дифференциальное копирование сохранит новые версии только этих 10 файлов.

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

Снижение расходов и затрат при восстановлении данных

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

Рекомендуемое решение для дифференциального резервного копирования

Скачать

Купить!

Версия 8.1.2 от 21 февраля 2020 . 106 MB
Программа резервного копирования Handy Backup. 1200 RUB за лицензию

Все решения Handy Backup, начиная с популярного решения Standard, обладают инструментами для дифференциального резервного копирования доступных данных.

Handy Backup как программа дифференциального резервного копирования

В Handy Backup дифференциальное резервное копирование реализовано для любых типов данных. Особенно рекомендуется использовать эту технологию при регулярном копировании больших, часто изменяемых массивов данных, например, баз данных SQL.

Как применить дифференциальное копирование в Handy Backup?

Создайте новую задачу резервного копирования, выберите продвинутый режим, укажите источники данных и хранилище для резервных копий. На Шаге 4 выберите тип копирования – "Дифференциальное".

Совет: дифференциальное копирование показывает наибольшую эффективность в сочетании с выполнением задачи бэкапа по расписанию . Укажите на Шаге 6 расписание – Handy Backup будет выполнять автоматическое дифференциальное резервное копирование в заданное время.

Восстановление данных из дифференциальной копии

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

Для сравнения: при восстановлении данных из инкрементальной копии вам потребуются все инкрементальные копии данных за восстанавливаемый период времени.

Дополнительные возможности создания дифференциальной копии в Handy Backup

  • Смешанный тип бэкапа . При этом типе резервного копирования также создаётся полная копия, вслед за которой по расписанию делаются заданное число дифференциальных резервных копий. Затем весь цикл повторяется.
  • Временные метки . В Handy Backup вы можете выбрать режим, при котором каждая копия будет содержать в названии каталога дату и время выполнения копирования, что очень удобно при поиске и сортировке данных.
  • Хранение копий в исходном формате . Файлы, скопированные Handy Backup, по умолчанию сохраняются в исходном формат, что позволяет открывать и редактировать эти файлы в резервной копии, без их восстановления.
  • Дифференциальная копия баз . Мы всегда рекомендуем выбирать дифференциальное, а не инкрементальное копирование БД , особенно часто изменяемых, так как при этом достигается большая экономия места и времени.

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

В отличие от полного резервного копирования в этом случае копируются не все данные (файлы, сектора и т.д.), а только те, что были изменены с момента последнего копирования. Для выяснения времени копирования могут применяться различные методы, например, в системах под управлением операционных систем семейства Windows используется соответствующий атрибут файла (архивный бит), который устанавливается, когда файл был изменен, и сбрасывается программой резервного копирования. В других системах может использоваться дата изменения файла. Понятно, что схема с применением данного вида резервного копирования будет неполноценной, если время от времени не проводить полное резервное копирование. При полном восстановлении системы нужно провести восстановление из последней копии, созданной Full backup, а потом поочередно восстановить данные из инкрементных копий в порядке их создания. Данный вид используется для того, чтобы в случае создания архивных копий сократить расходуемые объемы на устройствах хранения информации (например, сократить число используемых ленточных носителей). Также это позволит минимизировать время выполнения заданий резервного копирования, что может быть крайне важно в условиях, когда машина работает постоянно, или прокачивать большие объемы информации. У инкрементного копирования есть один нюанс: поэтапное восстановление возвращает и нужные удаленные файлы за период восстановления. Например: допустим, по выходным дням выполняется полное копирование, а по будням инкрементное. Пользователь в понедельник создал файл, во вторник его изменил, в среду переименовал, в четверг удалил. Так вот при последовательном поэтапном восстановлении данных за недельный период мы получим два файла: со старым именем за вторник до переименования, и с новым именем, созданным в среду. Это произошло потому, что в разных инкрементных копиях хранились разные версии одного и того же файла, и в итоге будут восстановлены все варианты. Поэтому при последовательном восстановлении данных из архива «как есть» имеет смысл резервировать больше дискового пространства, чтобы смогли поместиться в том числе и удаленные файлы.

Достоинства метода:

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

Меньшее время резервного копирования и восстановления - Инкрементальное резервное копирование занимает меньше времени, чем полное и дифференциальное резервное копирование.

Недостаток метода:

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

Похожие публикации