Acronis инкрементное резервное копирование
Acronis Backup предоставляет возможность использования популярных схем резервного копирования, таких как «дед-отец-сын» и «Ханойская башня», а также создания собственных схем резервного копирования. Все схемы резервного копирования строятся на основе методов полного, инкрементного и дифференциального резервного копирования. Термин «схема» в действительности обозначает алгоритм применения этих методов в сочетании с алгоритмом очистки архива.
Сравнение методов резервного копирования между собой не имеет смысла, поскольку в схеме они работают в совокупности. Каждый метод должен выполнять собственную роль в соответствии со своими преимуществами. Грамотная схема резервного копирования позволяет использовать преимущества всех методов резервного копирования, уменьшая влияние их недостатков. Например, еженедельное создание дифференциальных резервных копий облегчает очистку архива, поскольку их легко удалять вместе с набором зависящих от них ежедневных инкрементных резервных копий, сохраняемых в течение недели.
Резервное копирование с помощью методов полного, инкрементного или дифференциального резервного копирования создает резервную копию соответствующего типа.
В полной резервной копии хранятся все данные, выбранные для резервного копирования. Полная резервная копия лежит в основе любого архива и формирует базу для инкрементных и дифференциальных резервных копий. Архив может содержать несколько полных резервных копий или состоять только из них. Полная резервная копия является самодостаточной: чтобы восстановить из нее данные, доступ к любой другой резервной копии не требуется.
Широко известно, что полная резервная копия — самая медленная для создания и самая быстрая для восстановления. С помощью технологий Acronis восстановление из инкрементной резервной копии может выполняться так же быстро, как из полной.
Полное резервное копирование наиболее полезно в случаях, когда:
- требуется восстановить систему до исходного состояния;
- исходное состояние изменяется редко, поэтому нет необходимости для регулярного резервного копирования.
Пример: интернет-кафе, школа или университетская лаборатория, в которых администратор часто отменяет изменения, сделанные студентами или гостями, но базовую резервную копию обновляет редко (только после установки обновлений программного обеспечения). Время создания резервной копии в этом случае не является решающим, а время восстановления будет минимальным, если восстанавливать систему из полной резервной копии. Для обеспечения дополнительной надежности администратор может иметь несколько полных резервных копий.
В инкрементной резервной копии хранятся изменения данных относительно последней резервной копии . Чтобы восстановить данные из инкрементной резервной копии, необходим доступ к другим резервным копиям из того же архива.
Инкрементное резервное копирование наиболее полезно в следующем случае:
- требуется восстановить одно из нескольких сохраненных состояний;
- изменения данных относительно невелики по сравнению с общим размером данных.
Широко известно, что инкрементные резервные копии менее надежны, чем полные, так как, если повреждена одна копия в «цепочке», следующие копии уже нельзя использовать. Тем не менее хранение нескольких полных резервных копий не является оптимальным вариантом, если требуется иметь несколько предыдущих версий данных, потому что надежность слишком большого архива еще более сомнительна.
Пример: резервное копирование журнала транзакций базы данных.
В дифференциальной резервной копии хранятся изменения данных относительно последней полной резервной копии . Для восстановления данных из дифференциальной резервной копии необходимо иметь доступ к полной резервной копии. Дифференциальное резервное копирование наиболее полезно в следующем случае:
- необходимо сохранить только последнее состояние данных;
- изменения данных относительно невелики по сравнению с общим размером данных.
Обычно считается, что «дифференциальные резервные копии дольше создаются и быстрее восстанавливаются, а инкрементные быстрее создаются и медленнее восстанавливаются». В действительности не существует физической разницы между инкрементной резервной копией, прилагаемой к полной, и дифференциальной копией, прилагаемой к той же полной резервной копии, на один и тот же момент времени. Упомянутая выше разница подразумевает, что дифференциальная резервная копия создана после (или вместо) создания нескольких инкрементных резервных копий.
Инкрементная или дифференциальная резервная копия, созданная после дефрагментации диска, может иметь значительно больший объем, чем обычно, потому что в процессе дефрагментации изменяется расположение файлов на диске и резервная копия отражает эти изменения. После дефрагментации диска рекомендуется заново создавать полную резервную копию.
В следующей таблице указаны общепризнанные преимущества и недостатки каждого типа резервного копирования. В действительности эти параметры зависят от множества факторов, таких как объем, скорость и характер изменения данных, их природа, физические характеристики устройств, установленные параметры резервного копирования и восстановления. Лучшим учителем в выборе оптимальной схемы резервного копирования является опыт.
Acronis True Image 2021 предлагает три метода резервного копирования. полное, инкрементное и дифференциальное.
Полное резервное копирование
Результат операции полного резервного копирования (называемый также полной версией резервной копии) содержит все данные, существовавшие на момент создания резервной копии.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию этого документа методом полного резервного копирования. Acronis True Image сохраняет весь документ при каждом выполнении резервного копирования.
1.tibx, 2.tibx, 3.tibx, 4.tibx — это файлы полных версий резервной копии.
Полная версия резервной копии образует основу для последующих инкрементных и дифференциальных резервных копий. и его можно также использовать для создания автономной резервной копии. Создание автономной полной резервной копии может быть оптимальным решением, если вы часто возвращаете систему в исходное состояние или не хотите управлять разными версиями резервных копий.
Восстановление: В приведенном выше примере, чтобы восстановить всю работу из файла 4.tibx, нужна только одна версия резервной копии — 4.tib.
Инкрементное резервное копирование
Результат операции инкрементного резервного копирования (называемый также инкрементной версией резервной копии) содержит только те файлы, которые изменились с момента ПОСЛЕДНЕЙ ОПЕРАЦИИ РЕЗЕРВНОГО КОПИРОВАНИЯ.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию методом инкрементного резервного копирования. Acronis True Image сохраняет новую страницу при каждом выполнении резервного копирования.
Примечание. Сначала всегда создается полная версия резервной копии.
- 1.tibx — это файл полной версии резервной копии.
- 2.tibx, 3.tibx, 4.tibx — это файлы инкрементных версий резервной копии.
Инкрементные резервные копии наиболее полезны, если нужно часто создавать версии резервных копий и иметь возможность вернуться к состоянию на определенный момент времени. Как правило, инкрементные версии резервной копии существенно меньше полных или дифференциальных. С другой стороны, инкрементные версии резервной копии требуют больше работы от программы при восстановлении.
Восстановление: В приведенном выше примере, чтобы восстановить всю работу из файла 4.tibx, нужны все версии резервной копии — 1.tibx, 2.tibx, 3.tibx и 4.tibx. При утере или повреждении инкрементной версии резервной копии все последующие инкрементные версии резервной копии оказываются бесполезными.
Дифференциальное резервное копирование
Результат операции дифференциального резервного копирования (называемый также дифференциальной версией резервной копии) содержит только те файлы, которые изменились с момента СОЗДАНИЯ ПОСЛЕДНЕЙ ПОЛНОЙ РЕЗЕРВНОЙ КОПИИ.
Пример: каждый день вы пишете одну страницу документа и создаете резервную копию методом дифференциального резервного копирования. Acronis True Image сохраняет весь документ, кроме первой страницы, хранящейся в версии полной резервной копии.
Примечание. Сначала всегда создается полная версия резервной копии.
- 1.tibx — это файл полной версии резервной копии.
- 2.tibx, 3.tibx, 4.tibx — это файлы дифференциальных версий резервной копии.
Дифференциальный метод является промежуточным между двумя предыдущими. При данном подходе требуется меньше времени и места для хранения по сравнению с полным резервным копированием, но больше по сравнению с инкрементным. Для восстановления данных из версии дифференциальной резервной копии Acronis True Image требуется только дифференциальная версия и последняя полная версия. Поэтому восстановление из дифференциальной версии будет проще и надежней, чем из инкрементной.
Восстановление: В приведенном выше примере, чтобы восстановить всю работу из файла 4.tibx, нужны две версии резервной копии — 1.tibx и 4.tibx.
Чтобы выбрать метод резервного копирования, необходимо задать пользовательскую схему резервного копирования. Дополнительные сведения см. в разделе Пользовательские схемы.
Инкрементная или дифференциальная резервная копия, созданная после дефрагментации диска, может иметь значительно больший размер, чем обычная. Это вызвано тем, что программа дефрагментации изменяет местоположение файлов на диске и эти изменения отражаются в резервной копии. Поэтому после дефрагментации диска рекомендуется заново создать полную резервную копию.
Changed Block Tracking (CBT)
Технология CBT ускоряет процесс резервного копирования при создании локальных инкрементных или дифференциальных версий резервных копий дисков. Изменения в содержимом диска непрерывно отслеживаются на уровне блоков. При запуске резервного копирования изменения могут быть сразу сохранены в резервной копии.
Acronis Backup & Recovery 10 предоставляет возможность использования популярных схем резервного копирования, таких как «дед-отец-сын» и «Ханойская башня», а также создания собственных схем резервного копирования. Все схемы резервного копирования строятся на основе методов полного, инкрементного и дифференциального резервного копирования. Термин «схема» в действительности обозначает алгоритм применения этих методов в сочетании с алгоритмом очистки архива.
Сравнение методов резервного копирования между собой не имеет смысла, поскольку в схеме они работают в совокупности. Каждый метод должен выполнять собственную роль в соответствии со своими преимуществами. Грамотная схема резервного копирования позволяет использовать преимущества всех методов, уменьшая влияние их недостатков. Например, еженедельное создание дифференциальных резервных копий облегчает очистку архива, поскольку их легко удалять вместе с набором зависящих от них ежедневных инкрементных резервных копий, сохраняемых в течение недели.
Резервное копирование с помощью методов полного, инкрементного или дифференциального резервного копирования создает резервную копию соответствующего типа.
В полной резервной копии хранятся все данные, выбранные для резервного копирования. Полная резервная копия лежит в основе любого архива и формирует базу для инкрементных и дифференциальных резервных копий. Архив может содержать несколько полных резервных копий или состоять только из них. Полная резервная копия является самодостаточной: чтобы восстановить из нее данные, доступ к любой другой резервной копии не требуется.
Широко известно, что полная резервная копия — самая медленная для создания и самая быстрая для восстановления. С помощью технологий Acronis восстановление из инкрементной резервной копии может выполняться так же быстро, как из полной.
Полное резервное копирование наиболее полезно в следующем случае:
- требуется восстановить систему до исходного состояния,
- исходное состояние изменяется редко, поэтому нет необходимости для регулярного резервного копирования.
Примеры: интернет-кафе, школа или университетская лаборатория, в которых администратор часто отменяет изменения, сделанные студентами или гостями, но базовую резервную копию обновляет редко (только после установки обновлений программного обеспечения). Время создания резервной копии в этом случае не является решающим, а время восстановления будет минимальным, если восстанавливать систему из полной резервной копии. Для обеспечения дополнительной надежности администратор может иметь несколько полных резервных копий.
В инкрементной резервной копии хранятся изменения данных по отношению к последнему резервному копированию . Чтобы восстановить данные из инкрементной резервной копии, необходим доступ к другим резервным копиям из того же архива.
Инкрементное резервное копирование наиболее полезно в следующем случае:
- требуется восстановить одно из нескольких сохраненных состояний,
- изменения данных относительно невелики по сравнению с общим размером данных.
Широко известно, что инкрементные резервные копии менее надежны, чем полные, так как, если повреждена одна копия в «цепочке», следующие копии уже нельзя использовать. Тем не менее хранение нескольких полных резервных копий не является оптимальным вариантом, если требуется иметь несколько предыдущих версий данных, потому что надежность слишком большого архива еще более сомнительна.
Пример: резервное копирование журнала транзакций базы данных.
В дифференциальной резервной копии хранятся изменения данных по отношению к последнему полному резервному копированию . Чтобы восстановить данные из дифференциальной резервной копии, необходим доступ к соответствующей полной резервной копии. Дифференциальное резервное копирование наиболее полезно в следующем случае:
- необходимо сохранить только последнее состояние данных,
- изменения данных относительно невелики по сравнению с общим размером данных.
Обычно считается, что «дифференциальные резервные копии дольше создаются и быстрее восстанавливаются, а инкрементные быстрее создаются и медленнее восстанавливаются». В действительности не существует физической разницы между инкрементной резервной копией, прилагаемой к полной, и дифференциальной копией, прилагаемой к той же полной резервной копии, на один и тот же момент времени. Упомянутая выше разница подразумевает, что дифференциальная резервная копия создана после (или вместо) создания нескольких инкрементных копий.
Инкрементная или дифференциальная резервная копия, созданная после дефрагментации диска, может иметь значительно больший объем, чем обычно, потому что в процессе дефрагментации изменяется местоположение файлов на диске и резервная копия отражает эти изменения. После дефрагментации диска рекомендуется заново создавать полную резервную копию.
В следующей таблице указаны общепризнанные преимущества и недостатки каждого типа резервного копирования. В действительности эти параметры зависят от множества факторов, таких как объем, скорость и характер изменения данных, их природа, физические характеристики устройств, установленные параметры резервного копирования и восстановления. Лучшим учителем в выборе оптимальной схемы резервного копирования является опыт.
Создание схемы начинается с понимания методов резервного копирования. Таких методов три: полное, инкрементное и дифференциальное резервное копирование (full, incremental, differential backup). Зачем они нужны и в чем разница? Смотрим.
Полное резервное копирование
Тут все очень просто. В файл бэкапа записываются все данные, которые были выбраны для резервного копирования.
На рисунке: все бэкапы — полные.
Такие бэкапы самые надежные, но и самые большие. При этом для восстановления потребуется только один файл.
Инкрементное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — инкрементные бэкапы.
Инкрементные бэкапы гораздо меньше полных. Однако для восстановления потребуется предыдущий полный бэкап (на рисунке — 1.tib) и вся цепочка инкрементных бэкапов заканчивая тем бэкапом, из которого вы хотите восстановить данные.
Дифференциальное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего полного резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — дифференциальные бэкапы.
Дифференциальные бэкапы меньше полных, но больше инкрементных. Для восстановления потребуется сам дифференциальный бэкап и предыдущий полный бэкап (на рисунке — 1.tib).
Acronis Backup Cloud глазами пользователя
Для конечного пользователя работа с системой проста и наглядна. После создания учетной записи пользователя и входа в Личный кабинет необходимо указать компьютер, для которого будет сконфигурировано задание на резервное копирование. Для этого нужно нажать на «+» и выбрать ОС, на которую будет установлен агент. Следующим шагом нужно сконфигурировать задание для резервного копирования.
В консоли управления пользователя отображаются все Задачи, которые выполнялись ранее для конкретного компьютера, помимо этого есть функция «Создать новую Задачу» и «Восстановить данные из облака». Кроме того, доступен просмотр текущего статуса бэкапа для заданного компьютера.
Цепочки и схемы
Ну вот мы и подошли к самому интересному. Разумеется, вы уже догадались. Три метода резервного копирования дают нам массу всевозможных вариантов так называемых цепочек бэкапов. Цепочка – это один полный бэкап и все зависящие от него инкрементные и/или дифференциальные бэкапы. Схема же состоит из одной или нескольких цепочек, а также содержит правила удаления старых бэкапов.
Действительно, вариантов цепочек может быть великое множество. Но это в теории. На практике же в основу цепочки берется только один из методов: полный, инкрементный или дифференциальный.
«Тут же все ясно как белый день! Всегда создавай полные бэкапы!» – скажете вы и будете правы. Но как всегда есть одно больше «но». Полные бэкапы – самые увесистые. Вам не жалко забить ваш 2 ТБ диск бэкапами? Тогда это самое лучшее решение. Но большинству хочется максимальной надежности и вариативности при минимальных потерях дискового пространства. Поэтому, как говорится, давайте разбираться. Вот со схем на основе полных бэкапов и начнем.
Схемы на основе полных бэкапов
- На создание каждого бэкапа уходит много времени.
- Значительная трата дискового пространства.
- Небольшое количество бэкапов, т.е. точек во времени, на которые можно «откатиться».
- Дублирование одной и той же информации в разных бэкапах.
Схемы на основе инкрементных бэкапов
При такой схеме создается один полный бэкап и цепочка зависимых от него инкрементных. Достоинства очевидны – бэкапы создаются быстро и весят мало, т.е. можно позволить себе насоздавать их гораздо больше, чем при схеме с полными бэкапами. Как итог, вы получаете максимальную вариативность при выборе точки восстановления. Но есть один серьезный недостаток – низкая надежность. При повреждении любого из бэкапов все последующие превращаются в мусор – восстановиться из них вы не сможете. Можно ли каким-то образом повысить надежность? Да, можно. Самый простой способ – создавать новый полный бэкап после нескольких инкрементных, скажем, после четырех или пяти. Таким образом, мы получаем схему с несколькими цепочками, и повреждение одной из цепочек не повлияет на другие.
Эта схема универсальная, ее можно использовать для защиты как дисков, так и файлов.
Схемы на основе дифференциальных бэкапов
При такой схеме создается один полный бэкап и зависимые от него дифференциальные. Этот подход объединяет в себе достоинства двух предыдущих. Так как дифференциальные бэкапы меньше полных и больше инкрементных, вы получаете среднюю вариативность при выборе точки восстановления и довольно высокую надежность. Но без недостатков все равно не обойдешься. Чем дальше по времени отстоит дифференциальный бэкап от своего полного бэкапа, тем он «тяжелее», и даже может превысить размер полного бэкапа. Решение здесь то же, что и при инкрементном подходе, — разбавляйте ваши дифференциальные бэкапы полными. В зависимости от интенсивности изменения защищаемых данных новый полный бэкап рекомендуется создавать после двух-пяти дифференциальных.
Такой схемой можно защитить ваш системный раздел, если дисковое пространство не позволяет вам хранить несколько полных бэкапов.
Бэкапить локально – да, быстрее, но менее надежно
Забыл упомянуть про особенность использования бекапов как сервиса – в случае возникновения аварийной ситуации необходимо восстанавливать компьютер (виртуальную машину) целиком. Да, действительно, если сравнивать скорость восстановления сервера, то локальный бекап, конечно, сделать быстрее. Но в данном случае надо сделать выбор – либо в пользу скорости, но без гарантии от косяков, либо в пользу надежности решения, но придется немного пожертвовать скоростью.
Подытожу так – я пришла к выводу, что вопрос о надежности/простоте локальных бекапов и использования BaaS, – это, скорее, вопрос ценностный. Тот, кому информация действительно ценна, скорее выберет сервис, а остальные – первый вариант. Но это уже мое личное мнение, непосредственно к делу не относится.
Резюме
Резюмируя все изложенное выше, хотела бы добавить, что, как говорится, лучше один раз увидеть, чем сто раз услышать. Поэтому лучше поработать с сервисом самостоятельно и сделать свои выводы, благо есть бесплатный тест.
Сравнение с локальными бекапами
Данные пользователей сервиса BaaS хранятся на серверах, которые расположены в сертифицированном дата-центре класса TIER-3.
Благодаря используемой архитектуре обеспечивается защита от сбоя на уровне отдельных серверов и отдельных дисков, что, заметим, невозможно при использовании RAID-массивов, которые используются для создания отказоустойчивых хранилищ. В системе также используется полная проверка целостности данных. Уровень избыточности конфигурируется в консоли управления хранилища. Используемый при разработке хранилища самовосстанавливающийся дизайн позволяет избежать типичных для RAID-массивов потерь в производительности системы.
В случае выхода из строя одного из дисков или даже целого сервера система произведёт автоматическую перебалансировку, что позволяет избежать немедленной замены вышедших из строя компонентов.
Как насчет бэкапа в облачное хранилище?
Все, о чем мы до сих пор говорили, относится к бэкапам, которые вы храните у себя на внутреннем или внешнем жестком диске, на NAS-е, FTP-сервере и т.д. А как насчет бэкапа в облако? True Image сохраняет как файловые, так и дисковые бэкапы в Acronis Cloud по простой инкрементной схеме – один полный бэкап и цепочка инкрементных – и не позволяет ее менять. На резонный вопрос «почему» ответ прост – эта схема самая бережливая к дисковому пространству, а сохранность бэкапов в облаке гарантирует Acronis.
Правила очистки облачного бэкапа чуть проще, чем обычного.
Вы можете ограничить бэкап по «возрасту» и по количеству версий каждого из файлов, которые хранятся в облаке. Ограничивать бэкап по объему хранилища было бы не очень логично. Ведь в первую очередь Acronis Cloud используется именно для хранения бэкапов.
В этой статье я пошагово опишу работу сервиса резервного копирования Acronis Backup Cloud (ранее известный как «Acronis Backup as a Service»), разработанный инженерами компании Acronis. Расскажу, что представляет собой «бекапы как сервис» изнутри, и как все это работает. Перехожу непосредственно к описанию работы самого сервиса.
Про клиентскую часть
Вот какие Агенты (Клиенты) разработаны:
-
Клиенты резервного копирования для Windows, Linux и Mac – отвечают за резервное копирование данных на машинах под управлением ОС Windows/Linux/Mac.
Цепочки и схемы
Ну вот мы и подошли к самому интересному. Разумеется, вы уже догадались. Три метода резервного копирования дают нам массу всевозможных вариантов так называемых цепочек бэкапов. Цепочка – это один полный бэкап и все зависящие от него инкрементные и/или дифференциальные бэкапы. Схема же состоит из одной или нескольких цепочек, а также содержит правила удаления старых бэкапов.
Действительно, вариантов цепочек может быть великое множество. Но это в теории. На практике же в основу цепочки берется только один из методов: полный, инкрементный или дифференциальный.
«Тут же все ясно как белый день! Всегда создавай полные бэкапы!» – скажете вы и будете правы. Но как всегда есть одно больше «но». Полные бэкапы – самые увесистые. Вам не жалко забить ваш 2 ТБ диск бэкапами? Тогда это самое лучшее решение. Но большинству хочется максимальной надежности и вариативности при минимальных потерях дискового пространства. Поэтому, как говорится, давайте разбираться. Вот со схем на основе полных бэкапов и начнем.
Схемы на основе полных бэкапов
- На создание каждого бэкапа уходит много времени.
- Значительная трата дискового пространства.
- Небольшое количество бэкапов, т.е. точек во времени, на которые можно «откатиться».
- Дублирование одной и той же информации в разных бэкапах.
Схемы на основе инкрементных бэкапов
При такой схеме создается один полный бэкап и цепочка зависимых от него инкрементных. Достоинства очевидны – бэкапы создаются быстро и весят мало, т.е. можно позволить себе насоздавать их гораздо больше, чем при схеме с полными бэкапами. Как итог, вы получаете максимальную вариативность при выборе точки восстановления. Но есть один серьезный недостаток – низкая надежность. При повреждении любого из бэкапов все последующие превращаются в мусор – восстановиться из них вы не сможете. Можно ли каким-то образом повысить надежность? Да, можно. Самый простой способ – создавать новый полный бэкап после нескольких инкрементных, скажем, после четырех или пяти. Таким образом, мы получаем схему с несколькими цепочками, и повреждение одной из цепочек не повлияет на другие.
Эта схема универсальная, ее можно использовать для защиты как дисков, так и файлов.
Схемы на основе дифференциальных бэкапов
При такой схеме создается один полный бэкап и зависимые от него дифференциальные. Этот подход объединяет в себе достоинства двух предыдущих. Так как дифференциальные бэкапы меньше полных и больше инкрементных, вы получаете среднюю вариативность при выборе точки восстановления и довольно высокую надежность. Но без недостатков все равно не обойдешься. Чем дальше по времени отстоит дифференциальный бэкап от своего полного бэкапа, тем он «тяжелее», и даже может превысить размер полного бэкапа. Решение здесь то же, что и при инкрементном подходе, — разбавляйте ваши дифференциальные бэкапы полными. В зависимости от интенсивности изменения защищаемых данных новый полный бэкап рекомендуется создавать после двух-пяти дифференциальных.
Такой схемой можно защитить ваш системный раздел, если дисковое пространство не позволяет вам хранить несколько полных бэкапов.
Планирование
Здесь все просто. Вы составляете расписание, а True Image обновляет для вас бэкапы точно в назначенное вами время и в соответствии с настроенной схемой. Чем чаще меняются данные, тем чаще рекомендуется их бэкапить. К примеру, системный раздел можно бэкапить раз в месяц, а вот файлы, с которыми вы работаете каждый день, и бэкапить рекомендуется каждый день или даже чаще.
Разумеется, когда вам срочно нужно создать бэкап, не обязательно ждать запланированного времени. Вы всегда можете запустить резервное копирование вручную.
Права огласите, пожалуйста!
Администраторы IT-Lite имеют доступ к управлению группами и учетными записями пользователей.
Администраторы компаний конечных пользователей имеют права, позволяющие управлять пользователями, находящимися только в их группе! А конечные пользователи в свою очередь получают доступ к консоли, в которой можно добавлять компьютеры и создавать расписание автоматического резервного копирования. Сервис интегрирован с сайтом поставщика услуги, что позволяет пользователям сразу же по заполнению формы на этой странице проходить автоматическую регистрацию.
Работа с сервисом
А теперь рассмотрим, как это работает на практике. Администраторам компании IT-Lite (поставщика услуги) и компаний конечных пользователей предоставляется доступ к управлению сервисом через web-консоль. На приведенной ниже диаграмме показана стандартная архитектура сервиса резервного копирования. Синие стрелки обозначают взаимодействие между компонентами программного обеспечения. Черные стрелки показывают, как администраторы и конечные пользователи получают доступ к сервису резервного копирования.
Правила очистки
- Максимальный «возраст» цепочек бэкапов.
- Максимальное количество цепочек бэкапов.
- Максимальный общий размер бэкапа.
Про серверную часть
Давайте рассмотрим, как устроена серверная часть. Серверная часть сервиса состоит из двух компонентов – управление системой и хранение резервных копий.
Управляющий компонент доступен через интернет и позволяет с помощью веб-браузера управлять резервным копированием удаленных машин и уже созданными резервными копиями; создавать, редактировать и удалять политики резервного копирования и политики хранения; настраивать шифрование создаваемых резервных копий, используя AES или ГОСТ стандарт, и в случае необходимости сохранять отдельные резервные копии локально; следить за состоянием удаленных машин; восстанавливать отдельные файлы/папки, диски/разделы или же целиком машины из облака прямо на «голое железо». Одной из наиболее отличительных и полезных возможностей является создание иерархии подчиненных администраторских и пользовательских учетных записей, в рамках которых распределяются доступ к данным и удаленным машинам. Администраторы могут следить за состоянием подчиненных учетных записей и в случае необходимости оказывать помощь.
Компонент хранения позволяет развернуть масштабируемое, дешевое и при этом надежное хранилище данных. Хранилище для резервных копий состоит из группы серверов, на которые записываются клиентские данные. Для обеспечения достаточного уровня надежности всех хранимых пользовательских данных каждый входящий файл разбивается на «K» блоков и затем добавляются «N-K» (где N – некоторое число большее K) блоков избыточности с использованием алгоритма коррекции ошибок Рида-Соломона. Все блоки хранятся независимо друг от друга, и сохранность любых «K» блоков из записанных «N» гарантирует восстановление хранящихся пользовательских данных.
Как устроен сервис
Сервис состоит из серверной и клиентской части. Используются «агентная» и «безагентная» технологии, в зависимости от инфраструктуры. На клиентском компьютере или хост-сервере виртуализации устанавливается агент, задачей которого является соединение клиентского компьютера/хоста с сервером Acronis Backup Cloud и осуществление задач резервного копирования и восстановления.
Серверные роли
Система хранения данных Acronis строится на физических серверах. Но при этом серверные роли назначаются непосредственно дискам.
Существуют три серверные роли: Сервер Метаданных (Metadata Server (MDS)), Сервер Хранилища (Storage Server (STS)) и Front-end Server (FES).
Сервер Метаданных отвечает за хранение информации о фрагментах, на которые разбит файл, и расположение этих фрагментов на серверах. Это наиболее критический компонент системы.
Для обеспечения высокого уровня доступности и отказоустойчивости хранилища рекомендуется иметь несколько серверов с ролью MDS. Один из серверов становится основным, и метаданные периодически реплицируются с остальными серверами с ролью MDS.
Кроме того, на каждый сервер, имеющий роль MDS, также устанавливается и компонент управления системой (MGMT). В случае если основной сервер MDS перестает работать, компонент управления системой автоматически включается на другом сервере с ролью MDS, таким образом, web-консоль управления хранилищем постоянно доступна.
Сервер Хранилища (STS) предназначен для хранения фрагментов данных.
Front-End сервер позволяет клиентам сервиса Acronis Backup Cloud получать доступ к хранилищу и осуществлять передачу данных между пользовательской стороной и хранилищем данных Acronis.
Читайте также: