инкрементная копия что это
Acronis True Image: стратегии резервного копирования
Методы создания бэкапов
Создание схемы начинается с понимания методов резервного копирования. Таких методов три: полное, инкрементное и дифференциальное резервное копирование (full, incremental, differential backup). Зачем они нужны и в чем разница? Смотрим.
Полное резервное копирование
Тут все очень просто. В файл бэкапа записываются все данные, которые были выбраны для резервного копирования.
На рисунке: все бэкапы — полные.
Такие бэкапы самые надежные, но и самые большие. При этом для восстановления потребуется только один файл.
Инкрементное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — инкрементные бэкапы.
Инкрементные бэкапы гораздо меньше полных. Однако для восстановления потребуется предыдущий полный бэкап (на рисунке — 1.tib) и вся цепочка инкрементных бэкапов заканчивая тем бэкапом, из которого вы хотите восстановить данные.
Дифференциальное резервное копирование
В файл бэкапа записываются только изменения, которые произошли с момента последнего полного резервного копирования.
На рисунке: 1.tib — полный бэкап (первый бэкап всегда полный), 2.tib, 3.tib, 4.tib — дифференциальные бэкапы.
Дифференциальные бэкапы меньше полных, но больше инкрементных. Для восстановления потребуется сам дифференциальный бэкап и предыдущий полный бэкап (на рисунке — 1.tib).
Цепочки и схемы
Ну вот мы и подошли к самому интересному. Разумеется, вы уже догадались. Три метода резервного копирования дают нам массу всевозможных вариантов так называемых цепочек бэкапов. Цепочка – это один полный бэкап и все зависящие от него инкрементные и/или дифференциальные бэкапы. Схема же состоит из одной или нескольких цепочек, а также содержит правила удаления старых бэкапов.
Действительно, вариантов цепочек может быть великое множество. Но это в теории. На практике же в основу цепочки берется только один из методов: полный, инкрементный или дифференциальный.
«Тут же все ясно как белый день! Всегда создавай полные бэкапы!» – скажете вы и будете правы. Но как всегда есть одно больше «но». Полные бэкапы – самые увесистые. Вам не жалко забить ваш 2 ТБ диск бэкапами? Тогда это самое лучшее решение. Но большинству хочется максимальной надежности и вариативности при минимальных потерях дискового пространства. Поэтому, как говорится, давайте разбираться. Вот со схем на основе полных бэкапов и начнем.
Схемы на основе полных бэкапов
Схемы на основе инкрементных бэкапов
При такой схеме создается один полный бэкап и цепочка зависимых от него инкрементных. Достоинства очевидны – бэкапы создаются быстро и весят мало, т.е. можно позволить себе насоздавать их гораздо больше, чем при схеме с полными бэкапами. Как итог, вы получаете максимальную вариативность при выборе точки восстановления. Но есть один серьезный недостаток – низкая надежность. При повреждении любого из бэкапов все последующие превращаются в мусор – восстановиться из них вы не сможете. Можно ли каким-то образом повысить надежность? Да, можно. Самый простой способ – создавать новый полный бэкап после нескольких инкрементных, скажем, после четырех или пяти. Таким образом, мы получаем схему с несколькими цепочками, и повреждение одной из цепочек не повлияет на другие.
Эта схема универсальная, ее можно использовать для защиты как дисков, так и файлов.
Схемы на основе дифференциальных бэкапов
При такой схеме создается один полный бэкап и зависимые от него дифференциальные. Этот подход объединяет в себе достоинства двух предыдущих. Так как дифференциальные бэкапы меньше полных и больше инкрементных, вы получаете среднюю вариативность при выборе точки восстановления и довольно высокую надежность. Но без недостатков все равно не обойдешься. Чем дальше по времени отстоит дифференциальный бэкап от своего полного бэкапа, тем он «тяжелее», и даже может превысить размер полного бэкапа. Решение здесь то же, что и при инкрементном подходе, — разбавляйте ваши дифференциальные бэкапы полными. В зависимости от интенсивности изменения защищаемых данных новый полный бэкап рекомендуется создавать после двух-пяти дифференциальных.
Такой схемой можно защитить ваш системный раздел, если дисковое пространство не позволяет вам хранить несколько полных бэкапов.
Планирование
Здесь все просто. Вы составляете расписание, а True Image обновляет для вас бэкапы точно в назначенное вами время и в соответствии с настроенной схемой. Чем чаще меняются данные, тем чаще рекомендуется их бэкапить. К примеру, системный раздел можно бэкапить раз в месяц, а вот файлы, с которыми вы работаете каждый день, и бэкапить рекомендуется каждый день или даже чаще.
Разумеется, когда вам срочно нужно создать бэкап, не обязательно ждать запланированного времени. Вы всегда можете запустить резервное копирование вручную.
Правила очистки
Как насчет бэкапа в облачное хранилище?
Все, о чем мы до сих пор говорили, относится к бэкапам, которые вы храните у себя на внутреннем или внешнем жестком диске, на NAS-е, FTP-сервере и т.д. А как насчет бэкапа в облако? True Image сохраняет как файловые, так и дисковые бэкапы в Acronis Cloud по простой инкрементной схеме – один полный бэкап и цепочка инкрементных – и не позволяет ее менять. На резонный вопрос «почему» ответ прост – эта схема самая бережливая к дисковому пространству, а сохранность бэкапов в облаке гарантирует Acronis.
Правила очистки облачного бэкапа чуть проще, чем обычного.
Вы можете ограничить бэкап по «возрасту» и по количеству версий каждого из файлов, которые хранятся в облаке. Ограничивать бэкап по объему хранилища было бы не очень логично. Ведь в первую очередь Acronis Cloud используется именно для хранения бэкапов.
Дифференциальные и инкрементальные бэкапы MySQL
Для MySQL существует широко известный инструмент по созданию резервных копий баз данных — mysqldump, который создаёт дамп посредством записи серии SQL-инструкций для восстановления таблиц и данных целевой базы данных.
Он неплохо подходит для резервного копирования небольших баз данных, но когда база данных набирает приличный «вес» и возникает необходимость резервного копирования чаще, чем раз в сутки, скорость создания и размеры дампов могут стать проблемой. В данном случае на помощь приходят утилиты, создающие копию бинарных файлов баз данных, например, такие как Percona XtraBackup.
Percona XtraBackup поддерживает «горячее» резервное копирование для серверов MySQL, Percona, MariaDB и Drizzle (бета) всех версий.
Среди преимуществ такого подхода можно выделить следующие:
Как это работает
XtraBackup начинает копировать файлы баз данных, запоминая номер транзакции на момент начала (LSN), так как копирование файлов занимает какое-то время, данные в них могут измениться, поэтому параллельно XtraBackup запускает процесс, который отслеживает файлы с логами транзакций и копирует все изменения прошедшие с начала копирования.
После того как файлы скопированы, для получения работоспособной копии XtraBackup должен выполнить этап восстановления (crash recovery), используя сохранённый лог транзакций, на данном этапе к файлам баз данных будут применены завершённые транзакции из файла лога транзакций. Транзакции, которые изменили данные, но не были завершены, будут отменены.
После этого этапа файлы баз данных можно использовать для восстановления сервера путём его остановки и копирования файлов в их первоначальное расположение — вручную или используя XtraBackup (обычно это /var/lib/mysql, если сервер MySQL настроен по умолчанию).
Дифференциальные и инкрементальные бэкапы
Часто бывает так, что потеря данных даже за короткий промежуток времени весьма чувствительна, и возникает необходимость делать резервное копирование как можно чаще.
Создание полных бэкапов больших баз данных чаще, чем раз в день, может быть затруднительным — как правило, из-за размера дампов, тут как раз возможность копирования только выполненных изменений будет как нельзя кстати.
В зависимости от стратегии копирования могут использоваться дифференциальные и инкрементальные бэкапы, дополнительно к полным. Дифференциальный бэкап содержит изменения в данных относительно полного бэкапа, инкрементальный — содержит изменения со времени последнего частичного бэкапа – последней инкрементальной копии.
В зависимости от размера баз данных и необходимой частоты резервного копирования стратегии могут заметно отличаться, я же рассмотрю вариант с «недельным» планом, когда в конце недели создаётся полный бэкап, в начале каждого рабочего дня создаётся дифференциальный бэкап, и каждый час в течение рабочего времени — создание инкрементального бэкапа.
Такой план в самом плохом сценарии позволит сохранить данные, не потеряв более одного часа, или восстановить состояние баз на начало любого рабочего часа. А наличие дифференциального бэкапа позволит сократить количество необходимых копий, используемых при восстановлении.
Установка XtraBackup и настройка расписания
Дальнейшие действия выполнялись на CentOS 8, скачать подходящую версию XtraBackup можно с официального сайта.
По умолчанию XtraBackup ищет данные конфигурации сервера и данные подключения пользователя из файлов:
1. Установка:
Скачаем и установим XtraBackup из RPM:
Если планируется использовать компрессию, потребуется установить Qpress:
2. Проверим, что установка прошла успешно:
3. Создадим минимальную версию скрипта, который можно будет вызывать по расписанию в cron:
4. Добавим расписание в /etc/crontab:
Теперь резервное копирование будет выполняться по заданному расписанию в каталог /data/backups/db (как было задано в скрипте), но нужно учесть, что копирование не начнется, пока не будет создан полный и дифференциальный бэкап (в понедельник), поэтому, чтобы проверить работу скрипта, мы создадим их вручную:
Восстановление
Для восстановления состояния баз на требуемое время, нам нужно будет выполнить последовательно этапы:
1. Разархивирование
2. Подготовка:
Теперь, когда в каталоге /data/backups/db/20210913-FULL/ у нас готовые к использованию файлы баз данных, осталось остановить сервер, удалить или перенести старые файлы и скопировать новые файлы в оригинальное расположение и восстановить владельца файлов (mysql).
3. Применение резервной копии:
Заключение
Как известно, администраторы делятся на тех, кто не делает бэкап, и тех, кто уже делает. Последних же можно ещё поделить на тех, кто не проверяет целостность резервных копий, и тех, кто уже проверяет.
Этап с проверкой целостности выходит за пределы данной статьи, что не отменяет его важности, также стоит упомянуть, что статья не описывает всех нюансов использования Xtrabackup, но может послужить отправной точкой для администраторов, решивших делать бэкап чаще, чем раз в сутки.
Инкрементально обновляемый бэкап как стратегия резервного копирования СУБД
На сегодняшний день существует множество вариантов резервного копирования СУБД Oracle, которые позволяют администраторам спать спокойно по ночам и не переживать о том, что могло бы случиться, и как можно было бы этого избежать. Также в помощь – множество программного обеспечения, позволяющего упростить ежедневные рутинные задачи.
Использование Recovery Manager (RMAN), согласно официальной документации, является рекомендованным и одним из наиболее оптимальных способов для резервного копирования и восстановления базы данных Oracle. А возможность выполнять «горячие» бэкапы, оставляя базу доступной для чтений и изменений, делает эту утилиту мощным инструментом для резервирования высокодоступных систем.
В статье я не буду говорить обо всех возможностях Recovery manager, а опишу одну из интересных стратегий резервного копирования, позволяющую по-новому взглянуть на построение системы отказоустойчивости на предприятии. Технология инкрементально обновляемого бэкапа появилась в 10-й версии Oracle. Она предоставляет те же возможности по восстановлению, что и копирование образа базы (image copy), но более быстрая и оказывает меньшую нагрузку на ресурсы системы. Также эта опция сокращает время восстановления за счет меньшего количества журналов, которые необходимо применить для актуализации данных.
Концепция
Суть сохранения данных при помощи Recovery manager в том, что мы один раз делаем полную копию базы, а затем только копируем изменения, при этом – каждый раз при выполнении инкрементального бэкапа предыдущий накатывается на образ базы, актуализируя данные. В результате наш бэкап на физическом уровне состоит всегда из копии данных и файла изменения.
Рассмотрим пример выполнения:
RUN
<
RECOVER COPY OF DATABASE
WITH TAG ‘incremental’;
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG ‘incremental’
DATABASE;
>
Эту команду мы можем поставить в расписание на ежедневное выполнение. Вот как она будет интерпретироваться:
День 0
День 1
День 2 и последующие
Рассмотрим пример команды восстановления с окном в 7 дней:
RUN
<
RECOVER COPY OF DATABASE
WITH TAG ‘incremental’
UNTIL TIME ‘SYSDATE — 7’;
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG ‘incremental’
DATABASE;
>
Оптимизация
Вместе с инкрементально обновляемым бэкапом мы можем использовать еще одну технологию – BLOCK CHANGE TRACKING. При выполнении резервного копирования recovery manager исследует каждый блок данных, отслеживая изменения. Время выполнения такой процедуры прямо пропорционально размеру файлов данных. Она может быть достаточно длительной, даже если было изменено всего лишь несколько блоков. Начиная с 10-й версии в Oracle была представлена новая технология — BLOCK CHANGE TRACKING мы можем создать специальный файл, который записывает модифицированные блоки с момента предыдущего бэкапа. Затем RMAN использует его, чтобы определить изменения. Уже не нужно полностью изучать все доступные данные. Таким образом, скорость выполнения инкрементальной копии прямо пропорциональна измененным блокам. Благодаря реализации такого функционала можно существенно уменьшить время выполнения резервирования.
Быстрое восстановление
SWITCH DATABASE TO COPY;
RECOVER DATABASE;
Инкрементное копирование
Инкрементное копирование (Incremental Backup) — это метод сохранения информации, при котором архивируются только измененные с момента последнего бэкапа данные.
Каждая последующая операция по резервированию добавляет на носитель новые или измененные файлы без замены старых. Этим достигается более высокая скорость копирования, чем при процедуре полного или дифференциального копирования.
В различных системах существуют свои инструменты и методы для определения времени копирования. В Windows для этих целей применяется один из файловых атрибутов, так называемый архивный бит, включающийся в работу при изменении файла и сбрасываемый при процедуре бэкапа. С другой стороны, процедура восстановления информации после инкрементного копирования проходит значительно дольше.
Причина этого — в необходимости восстановления в первую очередь архивов полного копирования и только затем — данных последних инкрементных копирований. Применение данного типа копирования нельзя назвать полноценным, решающим все вопросы архивации. Необходимость в процедуре полного резервного копирования останется.
Алгоритм в этом случае прост: восстанавливается крайняя копия Full Backup, а затем на нее накладывается копия Incremental за последнюю дату резервного копирования. Когда обоснованна данная схема копирования?
В первую очередь, при необходимости минимизации времени создания бэкапа в обстоятельствах жесткого графика или в случае обработки достаточно больших массивов данных. Также благодаря методу инкрементного копирования, можно заметно сократить количество и объем носителей архивных копий.
К недостаткам технологии инкрементного копирования можно отнести увеличенное время восстановления системы из-за расположения архива на нескольких носителях. Необходимо строго соблюдать условия хранения базы данных, основанной на принципе инкрементного копирования.
Архивация быстрых, небольших объемов данных в жестком временном графике с непременной периодической процедурой полного резервного бэкапа — это идеальная среда для инкрементного копирования.
Виды резервного копирования: полный, инкрементальный и дифференциальный бэкап
ЗАЧЕМ НУЖНО РЕЗЕРВНОЕ КОПИРОВАНИЕ
О резервном копировании в последнее время много говорят и пишут. И мы, SIM-Networks, в том числе. 🙂
Модная тема неизбежно мифологизируется. Нам свойственно заполнять пробелы в своих познаниях выдуманными фактами и субъективными оценками. Так происходит, в частности, в том, что касается услуги резервного копирования и вопроса ее организации провайдерами хостинга. Должен ли хостер предоставлять своим клиентам резервное копирование автоматически, по умолчанию? Ответ на этот вопрос можно найти в нашем материале “5 мифов о бэкапе и хостинг-провайдерах”
Повышенный интерес к теме бэкапов неудивителен: учитывая активное развитие зловредов, опережающее развитие антивирусов, наиболее рационально строить ИТ-безопасность вокруг системы резервного сохранения информации – вместо того, чтобы тратить ресурсы на предотвращение атак и борьбу с вирусами, гораздо проще, дешевле и легче поднять систему и сохраненные данные из актуальных резервных копий.
Кроме того, актуальный бэкап поможет нивелировать последствия вмешательства форс-мажорных обстоятельств или человеческого фактора, а также сбоя оборудования вследствие разных причин. Не зря ведь одна из заповедей сисадмина гласит: готовя новый сервер к работе, вначале настрой резервное копирование!
КАК НАСТРОИТЬ БЭКАП
Бэкап можно делать самостоятельно – инструментов на сегодняшний день хватает, 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, заказать услугу резервного копирования SIM-Cloud BaaS Backup-as-a-Service, проще простого, в пару кликов. Всё уже настроено и будет подключено автоматически, как только вы дадите команду. Кстати, когда наши инженеры разрабатывали SIM-Cloud BaaS, они проанализировали эффективность разных типов бэкапа и остановили свой выбор на методе инкрементального копирования. Наше резервное копирование в облаке оптимизировано таким образом, что показатель RTO (время восстановления данных из копии) составляет в среднем от 15 до 30 минут в зависимости от объема данных. Облачный BaaS от SIM-Networks соответствует всем заявленным выше критериям высококачественного резервного копирования.
Резервное копирование критически важных для бизнеса данных в наши дни стало насущной необходимостью. А еще – частью комплексных мер по обеспечению информационной безопасности компании, о которых мы писали в материале Кибербезопасность организации: защищаем информационный периметр
Создайте собственный выделенный сервер
Вы можете самостоятельно выбрать, в каком дата-центре организовать хранилище для бэкапов. Первый вариант – локальное хранение: ваши резервные копии хранятся в том же ДЦ, где развернута ваша основная инфраструктура. Это дает возможность ускорить RTO и RPO. Второй вариант – бэкапы отправляются на хранение в дата-центр, удаленный от того, в котором развернута основная инфраструктура. Восстановление данных в этом случае будет происходить немного медленнее, но фактор безопасности выше. Если вы сомневаетесь, какой вариант выбрать, обратитесь в нашу службу Customer Care – вам помогут подобрать оптимальное решение.
А приверженцам классического «железа» мы предлагаем аренду удаленного хранилища для резервных копий: надежного, безопасного, высокотехнологичного. И, разумеется, наши высококвалифицированные эксперты поддержки помогут вам настроить необходимую периодичность, глубину и другие параметры резервного копирования вашей системы.