синтетический бэкап что это
Синтетическое резервное копирование
Синтетическое резервное копирование Arcserve Backup
Современные программы бэкапа используют синтетическое резервное копирование. Давайте познакомимся с ним ближе
Это давало существенное сокращение времени и места хранения резервных копий, но приводило к большому проигрышу при восстановлении данных.
А как раз время восстановления и является критически важным. Как говорится, когда «земля горит под ногами. «.
Этот недостаток традиционных систем резервного копирования был преодолен с разработкой алгоритмов синтетического резервного копирования.
Этот алгоритм несет свои преимущества как при выполнении резервного копирования, так и при выполнении восстановления информации.
Синтетическая резервная копия при копировании
При выполнении резервного копирования синтетический бэкап выглядит аналогично традиционному копированию. Но это только внешне. По факту, вы можете делать только одну, первую полную резервную копию. Далее достаточно выполнять только резервное копирование изменений. Программа бэкапа самостоятельно будет синтезировать полные резервные копии.
Как это работает
F – полная резервная копия, созданная при первом запуске задания.
I4 – это традиционные инкрементные резервные копии.
I5 – это тоже инкрементная резервная копия, в которую выродилась идущая по графику полная. Эта сессия создаст полный каталог – каталог измененных файлов и неизмененных файлов..
Задание SFB соберет данные из сессий F, I1
I5 и синтезирует полную сессию F’.
Активирование синтетического резервного копирования
Активировать синтетическое резервное копирование в программе Arcserve Backup можно на этапе создания задания.
Далее определяются политики синтетического резервного копирования
Вы можете определить два очень важных параметра:
Подробная информация о программе для резервного копирования Arcserve Backup может быть найдена в статье » Arcserve Backup для Windows, Linux, UNIX, MacOS и FreeBSD » на этом сайте.
Синтетический бэкап что это
Синтетическое резервное копирование исключает необходимость регулярного полного резервного копирования поддерживаемых удаленных ресурсов. Стратегия, созданная для этой функции, позволяет собирать из полной (базовой) резервной копии и последующих инкрементальных резервных копий, также содержащихся в политике, синтетическую резервную копию.
В результате этого процесса синтетическая резервная копия становится базовой, и пока не будет создана следующая синтетическая копия, достаточно будет выполнять только инкрементальное резервное копирование. «Возраст» синтетической резервной копии будет равен возрасту последней содержащейся в ней инкрементальной копии.
Политика синтетического резервного копирования состоит из следующих компонентов:
Базовое резервное копирование. Первое резервное копирование, результат которого связывается с синтетическим резервным копированием. Базовая резервная копия создается только один раз и включает в себя все файлы выбранных ресурсов.
Регулярное инкрементальное резервное копирование. Последующие операции резервного копирования, при которых копируются только файлы, изменившиеся с момента базового резервного копирования.
Регулярное синтетическое резервное копирование. Процесс, который объединяет данные базовой копии и инкрементальных, в результате чего формируется полная синтетическая резервная копия выбранных ресурсов. Эта полная копия становится новой базовой. На ее основе путем объединения с последующими инкрементальными копиями будет создана следующая синтетическая полная резервная копия, и так далее.
Политика синтетического резервного копирования задает базовое резервное копирование.
Рис.: Базовое резервное копирование
Политика синтетического резервного копирования задает инкрементальное резервное копирование.
Рис.: Инкрементальное резервное копирование
Выполнение синтетического резервного копирования: объединение базовой и инкрементальных копий.
Рис.: Синтетическое резервное копирование
Синтетическое резервное копирование можно настроить только в политике. Политику с необходимыми шаблонами заданий для функции синтетического резервного копирования можно создать с помощью мастера политик или путем копирования примера политики и его последующего изменения в соответствии со своими требованиями. Также можно создать политику вручную и затем добавить в нее необходимые шаблоны заданий.
Для всех связанных шаблонов резервного копирования в политике можно создать стратегию поэтапного резервного копирования (копирование данных на диск и затем на магнитную ленту) с помощью шаблона Дублирование наборов данных резервного копирования.
Сравнение способов резервного копирования
Подготовку нового сервера к работе следует начинать с настройки резервного копирования. Все, казалось бы, об этом знают — но порой даже опытные системные администраторы допускают непростительные ошибки. И дело здесь не только в том, что задачу настройки нового сервера нужно решать очень быстро, но еще и в том, что далеко не всегда бывает ясно, какой способ резервного копирования нужно использовать.
Конечно, идеальный способ, который бы всех устраивал, создать невозможно: везде есть свои плюсы и минусы. Но в то же время вполне реальным представляется подобрать способ, максимально подходящий под специфику конкретно проекта.
В этой статье мы расскажем об основных способах резервного копирования серверов под управлением Linux-систем и о наиболее типичных проблемах, с которыми могут столкнуться новички в этой очень важной области системного администрирования.
Схема организации хранения и восстановления из резервных копий
Часто причиной восстановления данных служит повреждение файловой системы или дисков. Т.е. бекапы нужно хранить где-то на отдельном сервере-хранилище. В этом случае проблемой может стать «ширина» канала передачи данных. Если у вас выделенный сервер, то резервное копирование очень желательно выполнять по отдельному сетевому интерфейсу, а не на том же, что выполняет обмен данных с клиентами. Иначе запросы вашего клиента могут не «поместиться» в ограниченный канал связи. Или из-за трафика клиентов бекапы не будут сделаны в срок.
Далее нужно подумать о схеме и времени восстановления данных с точки зрения хранения бекапов. Может быть вас вполне устраивает, что бекап выполняется за 6 часов ночью на хранилище с ограниченной скоростью доступа, однако восстановление длиной в 6 часов вас вряд ли устроит. Значит доступ к резервным копиям должен быть удобным и данные должны копироваться достаточно быстро. Так, например, восстановление 1Тб данных с полосой в 1Гб/с займет почти 3 часа, и это если вы не «упретесь» в производительность дисковой подсистемы в хранилище и сервере. И не забудьте прибавить к этому время обнаружения проблемы, время на решение об откате, время проверки целостности восстановленных данных и объем последующего недовольства клиентов/коллег.
Инкрементальное резервное копирование
При инкрементальном резервном копировании копируются только файлы, которые были изменены со времени предыдущего бэкапа. Последующее инкрементальное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. В среднем инкрементальное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, плюс данные всех последующих инкрементальных резервных копирований. При этом в отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
Инкрементальное копирование чаще всего производится с помощью утилиты rsync. С его помощью можно сэкономить место в хранилище, если количество изменений за день не очень велико. Если измененные файлы имеют большой размер, то они будут скопированы полностью без замены предыдущих версий.
С более подробной информацией о работе rsync можно ознакомиться на официальном сайте.
Для каждого файла rsync выполняет очень большое количество операций. Если файлов на сервере много или если процессор сильно загружен, то скорость резервного копирования будет существенно снижена.
Из опыта можем сказать, что проблемы на SATA-дисках (RAID1) начинаются примерно после 200G данных на сервере. На самом деле всё, конечное же, зависит от количества inode. И в каждом случае эта величина может смещаться как в одну так и в другую сторону.
После определенной черты время выполнения резервного копирования будет очень долгим или попросту не будет отрабатывать за сутки.
Для того, чтобы не сравнивать все файлы, есть lsyncd. Этот демон собирает информацию об изменившихся файлах, т.е. мы уже заранее будем иметь готовый их список для rsync. Следует, однако, учесть, что он дает дополнительную нагрузку на дисковую подсистему.
Дифференциальное резервное копирование
При дифференциальном резервном копировании каждый файл, который был изменен с момента последнего полного резервного копирования, копируется всякий раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все, что вам необходимо — это последняя полная и последняя дифференциальная резервная копия. Популярность дифференциального резервного копирования растет, так как все копии файлов делаются в определенные моменты времени, что, например, очень важно при заражении вирусами.
Дифференциальное резервное копирование осуществляется, например, при помощи такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементальном резервном копировании.
В целом, если при поиске разницы в данных осуществляется полный перебор файлов, проблемы такого рода резервирования аналогичны проблемам с rsync.
Хотим отдельно отметить, что если в вашей схеме резервного копирования каждый файл копируется отдельно, то стоит удалять/исключать ненужные вам файлы. Например, это могут быть кеши CMS. В таких кешах обычно очень много маленьких файлов, потеря которых не скажется на корректной работе сервера.
Полное резервное копирование
Полное копирование обычно затрагивает всю вашу систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется по пятницам или в течение выходных, когда копирование большого объёма данных не влияет на работу организации. Последующие резервные копирования, выполняемые с понедельника по четверг до следующего полного копирования, могут быть дифференциальными или инкрементальными, главным образом для того, чтобы сохранить время и место на носителе. Полное резервное копирование следует проводить по крайней мере еженедельно.
В большинстве публикаций по соответствующей тематике рекомендуется полное резервное копирование выполнять один или два раза в неделю, а в остальное время время — использовать инкрементальное и дифференциальное. В таких советах есть свой резон. В большинстве случаев полного резервного копирования раз в неделю вполне достаточно. Выполнять его повторно имеет смысл в том случае, если у вас нет возможности на стороне хранилища актуализировать полный бекап и для обеспечения гарантии корректности резервной копии (это может понадобиться, например, в случаях, если вы по тем или иным причинам не доверяете имеющимся у вас скриптам или софту для резервного копирования.
Рассмотрим их характерные особенности на примере:
Резервировать мы будем только /home. Все остальное можно быстро восстановить вручную. Можно также развернуть сервер системой управления конфигурациями и подключить к нему наш /home.
Полное резервное копирование на уровне файловой системы
Типичный представитель: dump.
Утилита создает «дамп» файловой системы. Можно создавать не только полную, но и инкрементальную резервную копию. dump работает с таблицей inode и «понимает» структуру файлов (так, разреженные файлы сжимаются).
Создавать дамп работающей файловой системы «глупо и опасно», потому что ФС может изменяться во время создания дампа. Его надо создавать со снапшота (чуть позже мы обсудим особенности работы со снапшотами более подробно), отмонтированной или замороженной ФС.
Такая схема так же зависит от количества файлов, и время её выполнения будет расти с ростом количества данных на диске. В то же время у dump скорость работы выше, чем у rsync.
В случае, если требуется возобновить не резервную копию целиком, а, например, только пару случайно испорченных файлов), извлечение таких файлов утилитой restore может занять слишком много времени
Полное резервное копирование на уровне устройств
Например, с одним MySQL это будет выглядеть так:
* Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.
Далее можно копировать снапшот в хранилище. Главное — следить за тем, чтобы во время копирования снапшот не самоуничтожился и не забывать, что при создании снапшота скорость записи упадет в разы.
Бекапы СУБД можно создать отдельно (например, используя бинарные логи), устранив тем самым простой на время сброса кеша. А можно создавать дампы в хранилище, запустив там инстанс СУБД. Резервное копирование разных СУБД — это тема для отдельных публикаций.
Копировать снапшот можно с использованием докачки (например, rsync с патчем для копирования блочных устройств bugzilla.redhat.com/show_bug.cgi?id=494313), можно по блокам и без шифрования (netcat, ftp). Можно передавать блоки в сжатом виде и монтировать их в хранилище при помощи AVFS, и примонтировать на сервере раздел с бекапами по SMB.
Сжатие устраняет проблемы скорости передачи, забития канала и места в хранилище. Но, однако если вы не используете AVFS в хранилище, то на восстановление только части данных у вас уйдет много времени. Если будете использовать AVFS, то столкнетесь с её «сыростью».
Альтернатива сжатию блоками — squashfs: можно подмонтировать, к примеру, по Samba раздел к серверу и выполнить mksquashfs, но эта утилита так же работает с файлами, т.е. зависит от их количества.
К тому же при создании squashfs тратится достаточно много ОЗУ, что может легко привести к вызову oom-killer.
Безопасность
Необходимо обезопасить себя от ситуации когда хранилище или ваш сервер будут взломаны. Если взломан сервер, то лучше чтобы не было прав на удаление/изменение файлов в хранилище у пользователя, который записывает туда данные.
Если взломано хранилище, то права бекапного пользователя на сервере так же желательно ограничить по максимуму.
Если канал резервного копирования может быть прослушан, то нужны средства шифрования.
Заключение
У каждой системы резервного копирования свои минусы и свои плюсы. В этой статье мы постарались осветить часть нюансов при выборе системы резервного копирования. Надеемся, что они помогут нашим читателям.
В качестве решений по резервному копированию, можно использовать supload и наше облачное хранилище.
Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.
Veeam Backup & Replication: 10 рекомендаций для начинающих
Что-то давненько мы не писали про наш флагманский продукт. Исправляемся, тем более что подоспела еще одна порция полезных советов от ребят из Veeam Support Team. Сегодня с вами снова мой коллега Евгений Иванов, теперь уже из Бухареста, куда он был призван в качестве наставника для румынской команды технической поддержки.
В ходе своей работы Евгений со товарищи собрали приличную коллекцию «граблей», на которые чаще всего наступают начинающие пользователи при развертывании и настройке Veeam Backup & Replication. А чтобы вы не повторяли их ошибок, Женя разъясняет, как всё сделать правильно.
Итак, добро пожаловать под кат.
#1: Выберите оптимальный метод резервного копирования
Обычно рекомендуются «прямой инкрементный» или «бесконечно инкрементный», поскольку они самые быстрые. Бесконечно-инкрементная цепочка (без периодических полных резервных копий) занимает меньше места и довольно быстро обрабатывается. Обычая инкрементная цепочка места занимает больше, но она и более «жизнестойкая», если можно так выразиться, так как содержит не только инкрементальные бэкапы, но и периодически создаваемые полные.
Реверсивный (обратный) инкрементный метод – самый старинный и, естественно, самый медленный. В зависимости от СХД, он может быть в 3 и даже более раз медленнее других. Тем не менее, в его использовании есть и свои плюсы: последним в цепочке всегда является полный бэкап, и поэтому восстановиться можно быстрее, чем из цепочек других типов. Заметим, однако, что разница с обычной инкрементальной цепочкой не очень значительна (разве что вы держите такую цепочку неоправданно длинной, то есть более чем 30 дней).
Подробнее про методы рассказывается здесь.
#2: Подумайте о настройках синтетических полных бэкапов
Операция создания синтетической полной резервной копии использует точки восстановления, которые хранятся в репозитории. Но нужно иметь в виду, что не всякая СХД в состоянии обеспечить достаточную для этой операции производительность. Поэтому мы советуем в качестве альтернативы создание активных полных резервных копий.
Когда вы задаете настройки создания синтетического полного бэкапа, обратите внимание на опцию “Transform previous backup chains into rollbacks” (преобразовывать предыдущие цепочки в точки отката). Ее использование приведет к тому, что будет запускаться задание преобразования инкрементального бэкапа (.VIB) в точки отката (.VRB) (которое будет, однако, потреблять значительную часть ресурсов СХД репозитория). Например, с помощью этой опции вы сможете преобразовать текущую цепочку в обратно- инкрементальную, в частности, для архивного хранения.
Но если использовать данную опцию как метод резервного копирования, то в итоге создастся очень своеобразная цепочка из файла полной резервной копии и файлов инкрементальных и обратно-инкрементальных резервных копий.
#3: Настройте обработку гостевой ОС
Обработка гостевой ОС позволяет создавать консистентные бэкапы виртуальных машин. А если на ВМ работают такие приложения, как Microsoft Exchange, Active Directory, SharePoint, SQL Server или Oracle, то вы сможете задействовать для их гранулярного восстановления возможности инструментов Veeam Explorers. Работа с гостевой ОC базируется на функциональности VSS (поддерживается Windows), которая должна быть корректно настроена, иначе задания резервного копирования не смогут успешно завершиться.
Для активации настроек обработки гостевой ОС:
#4: Не индексируйте файлы без необходимости
Если активировать опцию VM Guest File System Indexing (индексирование файлов гостевой ОС) в настройках бэкапа, то Veeam Backup & Replication будет создавать каталоги файлов ВМ. Это позволит выполнять поиск по файлам и восстановление в 1 клик через веб-интерфейс Veeam Backup Enterprise Manager.
Если же вы не работаете с Enterprise Manager, то мы советуем не включать данную опцию – так вы сократите окно резервного копирования (порой весьма существенно) и сэкономите место на диске C: сервера Veeam backup. На восстановление файлов ВМ через консоль Veeam Backup & Replication это никак не повлияет.
#5: Делайте дополнительные резервные копии
Ни один производитель СХД не гарантирует абсолютной целостности данных. Конечно, Veeam проверяет файл резервной копии при записи на диск, но при том, что на СХД выполняются миллионы операций, случайная перестановка бит все же возможна, а в результате получается «невидимое» повреждение. Для выявления таких повреждений на ранних этапах Veeam Backup & Replication предлагает воспользоваться функциями SureBackup и health checks. Но и это не панацея, поэтому мы советуем взять на вооружение правило 3-2-1, которое предписывает использовать для бэкапа разные типы носителей и хранить их как минимум на 2 площадках.
Для этого рекомендуется после создания основного задания резервного копирования настроить задание переноса резервных копий. Такое задание может использовать в качестве целевого места хранения резервную СХД или облачное хранилище. Также можно архивировать бэкапы на магнитную ленту.
#6: Финализируйте Мгновенное восстановление
Функция мгновенного восстановления ВМ Instant VM Recovery позволяет запустить машину в кратчайший срок непосредственно из бэкапа. Тем не менее, нужно помнить, что эта машина размещается у вас в репозитории и потребляет его ресурсы, пока вы не перенесете ее в продакшен. Не забывайте про этот важный финальный шаг – поверьте, за годы работы в техподдержке Veeam мы повидали немало случаев с ВМ, которые неделями функционировали в режиме «из бэкапа» без того, чтобы быть перенесенными в продакшен. Итог был обычно довольно плачевен: переполнение СХД и потеря данных.
Подробно про то, как правильно выполнять мгновенное восстановление, читаем здесь.
#7: Подумайте, где размещать репозиторий
Veeam поддерживает самые разные хранилища в качестве репозиториев. Многие наши пользователи из года в год предпочитают использовать для этой цели физический сервер Windows или Linux, поскольку в большинстве случаев это дает максимальную производительность. Об этом можно почитать на нашем форуме.
Репозитории на CIFS share также довольно популярны, несмотря на то, что их производительность по сравнению с другими самая низкая.
Многие современные устройства NAS поддерживают iSCSI, так что лучше все-таки сконфигурировать диск iSCSI и сделать его доступным для сервера Veeam backup (или для прокси). Следует иметь в виду, что в таком сценарии (с использованием репозитория на NAS) не рекомендуется применять метод обратно-инкрементального бэкапа, т.к. он дает большую нагрузку на СХД из-за интенсивности чтения\записи.
#8: Используйте прокси при репликации
Если вы собираетесь выполнять репликацию через WAN, то рекомендуем вам настроить прокси-сервер резервного копирования на удаленной площадке и указать его в настройках задания репликации. Таким образом вы получите надежный канал между двумя площадками. Советуем включить данный прокси в работу в режиме Network (NBD), так как работа в режиме Virtual Appliance (hot-add) при репликации может привести к возникновению «затерянных» снапшотов.
Прокси на удаленной площадке мы рекомендуем использовать и в случае работы через WAN-акселератор. Можно развернуть WAN-акселератор и прокси на разных машинах или даже на одной (разумеется, если у нее в достатке ресурсов).
#9: Учтите важные нюансы при архивировании на ленту
Для передачи данных на ленточное устройство Veeam задействует вспомогательный сервер (tape server). Он ставится на физический сервер, к которому подключается это ленточное устройство.
Важно! Подключение к ВМ с “пробрасыванием” через хост ESXi не поддерживается!
Veeam Backup & Replication получает информацию о ленточной библиотеке от операционной системы, поэтому обязательно убедитесь, что у вас установлены последние версии драйверов, а ленточное устройство корректно отображается в консоли Управления устройствами (device manager).
Больше полезных советов о работе с магнитной лентой можно прочитать в этой статье.
#10: Если все равно что-то пошло не так
Тут уж ничего не поделаешь, придется завести заявку на портале техподдержки. Настоятельно просим сделать пару простых вещей:
Надеюсь, наши рекомендации помогут кому-то избежать типичных ошибок при развертывании и настройке Veeam Backup & Replication. На сегодня у меня всё. С пожеланиями успехов, Veeam Support Team.