Модели резервного копирования
Стоит внимательно присмотреться к каждому варианту, чтобы понять, какой из них подходит именно вам. Возможно, в рамках вашей компании для разных типов систем и данных будут актуальны сразу несколько моделей. Учитывайте: с точки зрения эффективности использования ресурсов, времени восстановления данных, уровня их сохранности и других параметров, оптимальным решением будет комбинирование различных моделей.
Full Backup
С одной стороны, регулярное копирование всех корпоративных данных — это самый надежный подход. К плюсам можно отнести высокую скорость восстановления утраченной информации. Однако при полном бэкапе процесс создания каждой копии долог и отнимает много сетевых ресурсов — для большого объема корпоративных данных использовать full backup чаще одного раза в месяц бывает просто нерационально.
Инкрементное
В отличие от предыдущей модели при инкрементном бэкапе придется создать только одну полную копию данных. Все последующие регулярные бэкапы будут затрагивать только те данные, которые были изменены с момента создания прошлой копии. Каждый новый инкремент зависит от предыдущего, следовательно если один из них будет применен некорректно, нарушится вся цепочка. Кроме того, длина инкрементной цепочки напрямую влияет на скорость восстановления данных. К плюсам можно отнести высокую скорость создания регулярных копий и сравнительно низкие требования к объему хранилища.
Дифференциальное
Эта модель в общих чертах похожа на предыдущую: за основу берется Full Backup, к которому на регулярной основе «добавляются» копии, содержащие измененные данные. Модель весьма надежна, а скорость восстановления данных у неё выше, чем при инкрементном подходе. Кроме того, повреждение промежуточной копии не нанесет вреда всем последующим. Существенный минус модели состоит в том, что каждая новая копия создается дольше предыдущей и занимает больше места.
Обратное инкрементное
Модель подразумевает, что в каждой итерации будет создаваться новая полная копия, а место, занимаемое предыдущей РК, будет заменено инкрементом. К плюсам можно записать высокую скорость восстановления «свежих» бэкапов. К минусам — долгое восстановление старых копий и высокие требования к BaaS-серверу.
Синтетическое
Модель подразумевает использование сразу двух заранее созданных копий: полной и инкрементной. С заданной администратором периодичностью они будут «сращиваться» в новую полную копию, к которой затем будет добавлен инкремент. Метод хорош высокой скоростью как создания бэкапов, так и восстановления данных. При этом данными РК можно гибко управлять без существенной нагрузки на сеть. Что касается недостатков — повреждение промежуточных копий негативно скажется сразу на всех последующих бэкапах.
Правила и политики
Политики и правила хранения и создания резервных копий позволят вам быть уверенными в том, что ваши бэкапы находятся в безопасности и в любой момент вы сможете восстановить утраченные данные.
Правило «3-2-1»
Пожалуй, это самое популярное и простое в реализации «правило» резервного копирования. Суть его состоит в следующем: необходимо три копии данных в двух физически разных форматах (носителях), а одна из копий должна быть расположена удаленно.
Поясним каждый из пунктов. три копии — это необходимый минимум, при котором вероятность потерять сразу все данные вследствие инцидента снижается практически до нуля. Разные форматы хранения (носители) позволят восстановить данные, если одно из мест хранения будет физически повреждено или уничтожено. Хранение одной копии вне офиса снижает риски в случае повреждения вашего сервера резервного копирования — всегда можно будет восстановить данные из другого ЦОД в другом городе или даже стране.
Теперь переходим к политикам хранения данных. В сегодняшней статье мы коротко рассмотрим две наиболее применимые схемы.
GFS («дед-отец-сын»)
GFS базируется на трех важных правилах:
- «Grandfather» (дед) — достаточно редко (например, раз в месяц) вы создаете полную копию данных и сохраняете её на «медленном» защищенном носителе.
- «Father» (отец) — также подразумевает создание полной резервной копии на более скоростной носитель. Этот шаг производится чаще, чем предыдущий, например, раз в 1-2 недели.
- «Son» (сын) — дифференциальный или инкрементный бэкап. Производится ежедневно.
Ханойская башня (TOH)
Название этой схемы происходит от старинной математической задачи. Сложность реализации делает эту схемой менее применимой, чем предыдущая, однако упомянуть о ней, безусловно, стоит.
Процесс резервного копирования делится на так называемые интервалы — временные промежутки, разделяющие задачи резервного копирования. В зависимости от требований бизнеса, один интервал может длиться как несколько часов, так и несколько дней. Также потребуется выделить несколько разных носителей для хранения копий. Их число зависит от сложности выстраиваемой «башни».
- Каждый второй интервал производится резервное копирование на первый носитель информации. К примеру, в собственный ЦОД.
- Каждый четвертый интервал создается бэкап на втором носителе — в облако или другой сегмент инфраструктуры.
- Каждый восьмой интервал — на третий носитель, и так далее. Нетрудно посчитать, что принцип ханойской башни основан на формуле 2x = y, где x — это количество носителей, а y — количество интервалов.
Признаемся сами, схема достаточно трудная и запутанная. Однако в ряде случаев именно она способна обеспечить бизнесу наиболее надежное хранение критически важных данных. К тому же, многие решения резервного копирования умеют автоматизировать создание Ханойской башни.
Мы надеемся, что наша статья поможет вам определиться с BaaS-стратегией в вашей компании. Напоследок скажем: грамотно выбирайте пул резервируемых данных и оценивайте важность хранения бэкапов тех или иных систем. Нет ничего хорошего в том, чтобы хранить редко используемые и/или устаревшие данные в ущерб более регулярным бэкапам стратегической информации.
