Эксперты в подборе IT-оборудования
Видов бэкапа много, но выбор между ними сводится к одному компромиссу: чем быстрее и экономнее копирование, тем дольше и сложнее восстановление. Полная копия снимается долго и занимает много места, зато разворачивается из одного файла. Инкрементальная делается за минуты, но для восстановления нужна вся цепочка. Всё остальное - попытки найти середину.
Ниже разобраны девять схем, которые встречаются на практике, плюс то, о чём обычно забывают: на каком уровне копировать, где хранить копии и как проверять, что они рабочие.
| Схема | Что копирует за раз | Копирование | Восстановление | Место на диске |
|---|---|---|---|---|
| Полный | Все данные целиком | Долго | Быстро, из одного файла | Максимум |
| Инкрементальный | Изменения с прошлого бэкапа любого типа | Быстро | Медленно, нужна вся цепочка | Минимум |
| Дифференциальный | Изменения с последнего полного | Средне, растёт со временем | Быстро: полный + последний диф | Средне |
| Зеркальный | Точную копию файлов как есть | Средне | Мгновенно, файлы доступны напрямую | Максимум |
| Реверсивный инкрементальный | Изменения, но свежая копия всегда полная | Средне, нагружает хранилище | Мгновенно на последнюю точку | Средне |
| Синтетический полный | Ничего лишнего: полный собирается на хранилище | Быстро для продуктива | Быстро | Средне |
| Бесконечно-инкрементальный | Только изменения, полный больше не повторяется | Быстро | Средне | Минимум |
| CDP | Каждое изменение по мере появления | Непрерывно | На любой момент времени | Зависит от глубины журнала |
| Смарт-бэкап | Схему выбирает планировщик | Зависит от схемы | Зависит от схемы | Зависит от схемы |
Полный бэкап (full backup) - копия всех данных целиком. Каждый запуск копирует всё заново, независимо от того, менялось что-то с прошлого раза или нет.
Плюс один и он весомый: для восстановления нужен ровно один файл, и никакие соседние копии искать не придётся. Минусы вытекают из того же: снимается дольше всех, места занимает больше всех и заметно нагружает диски и сеть на всё время выполнения.
Поэтому полный бэкап обычно ставят на выходные или ночь, а в рабочие дни используют более лёгкие схемы. Сколько именно он идёт, зависит от объёма данных и скорости хранилища: сто гигабайт на локальный диск снимутся за минуты, несколько терабайт по сети - за часы.
Инкрементальный бэкап копирует только то, что изменилось с прошлого бэкапа любого типа. Первый запуск всегда полный, дальше каждая копия содержит лишь приращение.
Это самая экономная схема и по времени, и по месту: если за сутки изменился процент данных, копируется процент данных. Расплата - восстановление. Чтобы собрать состояние на нужный момент, система должна развернуть полный бэкап и последовательно наложить все инкременты после него. Цепочка из тридцати звеньев восстанавливается заметно дольше, чем одна полная копия, и любое повреждённое звено рвёт всю цепь после себя.
Дифференциальный бэкап копирует изменения с момента последнего полного бэкапа - и в этом всё отличие от инкрементального, который отсчитывает от предыдущей копии любого типа.
Практическое следствие простое. Каждая следующая дифференциальная копия больше предыдущей: в понедельник она содержит изменения за один день, в пятницу - за пять. Место она ест быстрее инкрементальной. Зато для восстановления нужны всего два файла - последний полный бэкап и последний дифференциальный, и никакой цепочки. Одно повреждённое звено здесь не рушит всё остальное.
Отсюда и типичный выбор: инкрементальный там, где важно окно копирования и экономия места, дифференциальный - там, где важнее предсказуемое и быстрое восстановление.
Зеркальный бэкап (mirror backup) создаёт точную копию файлов на другом носителе - в том же виде, без упаковки в архив и без сжатия. Копия повторяет исходную структуру папок, и любой файл из неё можно взять напрямую, не запуская процедуру восстановления.
Именно отсутствие контейнера и есть главная особенность схемы. Оно же порождает два ограничения. Первое: копия занимает столько же места, сколько исходные данные, - для больших массивов это дорого. Второе, и более коварное: зеркало обычно синхронизируется с источником, поэтому удаление или шифрование файла на источнике так же аккуратно повторится в копии. Зеркало защищает от отказа диска, но не от ошибки человека и не от шифровальщика, если не хранить версии.
Реверсивный инкрементальный бэкап устроен наоборот по сравнению с обычным инкрементальным: самая свежая копия всегда полная. При каждом запуске изменившиеся блоки вписываются прямо в полный бэкап, а то, что там лежало раньше, сохраняется отдельным файлом обратного приращения.
Смысл в скорости восстановления на последнюю точку: разворачивать нужно один файл, цепочку собирать не надо. Восстановление на более старую точку, наоборот, требует отката через приращения и идёт медленнее.
Цена схемы - нагрузка на хранилище. За один цикл система и пишет в полный бэкап, и создаёт файл обратного приращения, поэтому операций ввода-вывода получается больше, чем у любой другой схемы. На медленных дисках и на объектных хранилищах это чувствуется.
Синтетическая полная копия собирается на стороне хранилища из уже имеющихся файлов: берётся прошлый полный бэкап, к нему применяются накопленные инкременты, и на выходе получается новая полная копия. С продуктивного сервера при этом ничего заново не читается.
Выигрыш в том, что нагрузка на боевую систему остаётся как у инкрементального бэкапа, а на руках регулярно оказывается свежий полный - то есть короткая цепочка восстановления. Платит за это хранилище: сборка требует и места, и операций ввода-вывода.
Схему выбирают там, где окно резервного копирования узкое, а восстановление должно быть быстрым.
Бесконечно-инкрементальная схема (forever incremental) начинается с одного полного бэкапа, после чего полные копии больше не снимаются никогда - только приращения. Цепочка не растёт бесконечно: старые точки по мере устаревания сливаются в базовую копию, и глубина хранения остаётся заданной.
Это самая экономная по месту и по нагрузке схема, поэтому её любят там, где бэкап уезжает по узкому каналу или в облако с оплатой за трафик. Обратная сторона - вся конструкция держится на целостности одного файла базовой копии и служебной базы данных резервного копирования. Их сохранность приходится проверять отдельно и регулярно.
CDP (continuous data protection) не работает по расписанию: каждое изменение фиксируется по мере появления. Фактически это журнал изменений, по которому можно вернуться на произвольный момент времени, а не на ближайшую точку по расписанию.
Ради чего это делают, видно в двух показателях. RPO - сколько данных допустимо потерять; у CDP он измеряется секундами, тогда как у ночного бэкапа это сутки работы. RTO - сколько времени занимает восстановление.
Схема требовательная: нужен агент на защищаемой системе, быстрое хранилище под журнал и запас канала. Поэтому CDP обычно включают точечно, на несколько по-настоящему критичных систем, а остальное закрывают обычным расписанием.
Смарт-бэкапом называют схему, в которой тип копии выбирает не человек, а планировщик: он смотрит на объём изменений, время суток и заданные правила хранения и сам решает, снимать сейчас полную копию, инкремент или синтетический полный.
Отдельной технологии за названием нет - это надстройка над остальными схемами, и в разных продуктах она называется по-разному. Из свободных инструментов похожую логику ротации копий даёт rsnapshot: он строит снимки на базе rsync и жёстких ссылок, так что неизменившиеся файлы не занимают место повторно. Работает он на Linux, BSD, Solaris и macOS - это Perl-утилита для UNIX-подобных систем, под Windows её штатно не запустить.
Кроме схемы есть второй выбор, который делают до неё, - что именно считать единицей копирования.
Файловый бэкап работает с файлами и каталогами. Он гибкий: можно исключить временные папки, восстановить один документ, перенести данные на другую машину с другой операционной системой. Но он не сохраняет состояние системы целиком - после отказа сервера операционную систему и настройки придётся ставить заново.
Образ диска или тома снимает раздел целиком, вместе с загрузчиком, системой и настройками. Восстановление возвращает машину в рабочее состояние без переустановки, и это то, что нужно для быстрого подъёма сервиса. Взамен образ занимает больше места и менее гибок: вытащить из него один файл можно, но это отдельная операция.
Копирование на уровне приложения - третий вариант, о котором часто забывают. Базу данных или почтовый сервер правильнее выгружать штатными средствами самой системы: файловая копия работающей базы может оказаться нецелостной. Как это делается для конкретных систем, разбираем отдельно - например, резервное копирование 1С.
Схема и уровень определяют, что копировать. Остаётся вопрос куда, и он решает, переживёт ли бэкап то же событие, что и данные.
Локальное хранение на отдельном сервере под бэкапы и архив даёт максимальную скорость: копия снимается и разворачивается по локальной сети, ничем не ограниченная каналом наружу. Слабое место очевидно - пожар, затопление или шифровальщик, добравшийся до сетевой шары, накрывают и данные, и копии разом.
Удалённая площадка снимает этот риск, но упирается в канал: полная копия нескольких терабайт по обычному интернету поедет сутками. Обычно комбинируют - полные копии держат локально, а наружу отправляют приращения.
Облако снимает заботу об оборудовании, но добавляет плату за объём и за трафик при восстановлении, а также вопрос, где физически лежат данные. Для персональных данных это отдельный разговор с юристами.
Отраслевой ориентир - правило 3-2-1: три копии данных, на двух разных типах носителей, одна из них - вне площадки. Формулировка старая, но именно она отвечает на вопрос, почему одного бэкапа на соседнем диске недостаточно.
Что из оборудования под это берут, разбираем в статье про выбор оборудования для резервного копирования в небольшом офисе.
Выбор начинается не с названия схемы, а с двух вопросов к бизнесу. Сколько данных допустимо потерять при аварии - это RPO, и он задаёт частоту копирования. Сколько времени сервис может лежать - это RTO, и он задаёт требования к скорости восстановления. Дальше схема подбирается под ответы.
Если восстановление должно быть быстрым и предсказуемым, а объёмы умеренные, работает связка «полный на выходных плюс дифференциальный по будням»: разворачивать всегда два файла. Если данных много, а окно копирования короткое, берут инкрементальный или синтетический полный. Если канал узкий или копии уезжают в облако - бесконечно-инкрементальный. Если простой измеряется деньгами за минуту - CDP на эти конкретные системы, а не на весь парк.
Отдельно стоит помнить, что зеркало и RAID бэкапом не являются: они защищают от отказа оборудования, но послушно повторяют удаление и шифрование. Снимок виртуальной машины - тоже не бэкап, и почему именно, разобрано в статье про снимки виртуальных машин.
Расписание строят от RPO: если допустимо потерять сутки, хватит ночного бэкапа; если час - нужны частые приращения. Время запуска выбирают по нагрузке, чтобы копирование не конкурировало с рабочими задачами. Глубину хранения задают заранее - сколько точек и за какой период держим, - иначе хранилище заполняется в самый неподходящий момент.
Бэкап, из которого ни разу не восстанавливались, бэкапом не считается. Проверка целостности файла копии и реальное тестовое восстановление - разные вещи: первое говорит, что файл не побился, второе - что из него действительно поднимается рабочая система.
Тестовое восстановление стоит ставить в регламент хотя бы раз в квартал, а для критичных систем чаще.
Мониторинг заданий закрывает третью типовую беду - молча отвалившийся бэкап. Задание может не выполняться неделями, и узнают об этом ровно в тот момент, когда копия понадобилась. Оповещения о неуспешных заданиях настраиваются один раз и окупаются первым же инцидентом. Как выстроить систему копирования целиком, описывают технологии резервного копирования.
Точкой отсчёта. Инкрементальный копирует изменения с предыдущей копии любого типа, дифференциальный - с последнего полного бэкапа. Отсюда всё остальное: инкрементальный экономнее, но для восстановления нужна вся цепочка; дифференциальный занимает больше места, зато восстанавливается из двух файлов.
Полный - в том смысле, что он не зависит от других копий. Но надёжность схемы определяется не типом, а тем, сколько копий хранится, где они лежат и проверялось ли восстановление. Полный бэкап на том же сервере, что и данные, менее надёжен, чем инкрементальный на отдельной площадке.
Нет. RAID и зеркало защищают от выхода диска из строя, но изменения повторяют мгновенно: удалённый по ошибке файл исчезнет везде, зашифрованный шифровальщиком - зашифруется везде. Бэкап отличается тем, что хранит состояние на прошлый момент времени.
Зависит от выбранной схемы. При связке с дифференциальными копиями полный обычно снимают раз в неделю, чтобы дифференциальные не разрастались. При синтетическом полном отдельный запуск не нужен - копия собирается на хранилище. При бесконечно-инкрементальном полный снимается один раз, при первом запуске.
Три копии данных, на двух разных типах носителей, одна копия - за пределами площадки. Ориентир, который отвечает на вопрос, почему бэкапа на соседнем диске недостаточно: он не переживёт ни пожар, ни шифровальщика, добравшегося до сетевого доступа.
Практически все зрелые решения поддерживают полный, инкрементальный и дифференциальный бэкап; синтетический полный и реверсивный инкрементальный встречаются в продуктах уровня Veeam и Кибер Бэкап. Для виртуальной среды на Proxmox есть Proxmox Backup Server с бесконечно-инкрементальной моделью и дедупликацией. Сравнение конкретных продуктов - отдельная тема, здесь важнее, что схему выбирают под задачу, а продукт уже под схему.
Собираете сервер под резервное копирование?
Инженеры ITTELO подберут конфигурацию под ваш объём данных и глубину хранения, соберут и протестируют машину под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
Серверы резервного копирования · +7 (800) 551-80-12 · info@ittelo.ru
