Какие атрибуты файловой системы учитываются системами резервного копирования

Обновлено: 03.07.2024

Оставлять данные незащищенными, т. е. не делать резервных копий – значит подвергать свой бизнес существенному риску. Исследование организации Disaster Recovery Preparedness Council показывает, что 20 % компаний, у которых случались потери данных от отключения электропитания серверов, понесли потери от 50 тыс. до 5 млн долларов. А 70 % стартапов и небольших компаний были вынуждены прекратить бизнес после масштабных аварий, связанных с потерей данных.

Поэтому ясно, что любая организация, работающая с данными, должна обязательно предусматривать процессы резервного копирования или резервирования данных (backup) и восстановления данных (recovery). Есть еще отдельный вид восстановления – disaster recovery, DR, т. е. восстановления при стихийных бедствиях и катастрофах природного характера, который также называют «катастрофоустойчивость».

Виды резервирования данных

Резервирование данных может быть в виде файлов и в виде образов.

Резервирование файлов (files): определяются целевые данные и файлы, подлежащие резервному копированию тем или иным методом, политикой и регламентом.
Резервирование образов (image): предусматривает полное резервное копирование образа диска вместе с операционной системой, служебными файлами и данными.

Образы (image) иногда называются «снэпшотами» (от английского snapshot – моментальный снимок), но между этими понятиями есть некоторая разница.

Планы резервирования

Как резервирование файлов, так и резервирование образов может выполняться по трем основным планам: полное, дифференциальное и инкрементное резервное копирование.

Полное резервное копирование: при этом все данные, подлежащие защите, копируются с определенным периодом согласно той или иной политике. Восстановление данных при этом происходит путем полного обратного копирования на исходное место резервной полной копии данных. Тут все просто, но у подхода есть свои минусы: необходимость в большом объеме пространства для хранения резервных данных, а также долгое время как самого резервного копирования, так и восстановления резервной копии.
Дифференциальное резервное копирование, при котором периодически резервируются только различия, которые появились между текущей версией данных и последним полным резервным копированием. Восстановление после дифференциального резервирования требует как полной копии всех данных, так и разностного копирования. Такое копирование происходит быстрое, но также требует много места на резервном накопителе.
Инкрементное резервное копирование, при котором копируются только различия, которые появились между текущей версией данных и последним дифференциальным, инкрементным или полным резервным копированием. Преимуществом такого плана резервирования является скорость и невысокие требования к объему резервного носителя. Недостатком является то, что при восстановлении данных требуются все данные с последнего полного копирования и данные каждого инкрементного копирования между полным копированием и восстановлением до точки RPO (recovery-point objective).

Политики резервирования

Существуют три основных политики резервирования для всем видов и планов: 3-2-1, GFS и TOH.

3-2-1 предусматривает, что нужно всегда иметь три резервных копии данных на двух типах носителей (например, диск и лента, диск и облако и пр.), причем одна копия должна храниться в отдельном местоположении (например, в другом здании). При использовании облачного варианта в требовании «2» можно обеспечить как другой тип носителя, так и другое местоположение.

GFS (Grandfather, Father, Son) – «Дед-отец-сын». В таком режиме данные резервируются и сохраняются «в трех поколениях»: раз в месяц («дед»), затем каждую неделю («отец») и каждый день («сын»). В конце недели «сын» становится «отцом», а раз в месяц «отец» становится «дедом». Такая политика очень эффективна и надежна, однако при этом нужно все больше пространства для сохранения резервных копий. Поэтому иногда требуется проводить чистку сохраненного объема данных.

TOH (Tower of Hanoi) – «Ханойская башня». Название метода происходит от одной из популярных головоломок XIX века. В игре есть три стержня, на один из которых нанизаны восемь колец, причем кольца отличаются размером и лежат меньшее на большем. Задача состоит в том, чтобы перенести пирамиду из восьми колец за наименьшее число ходов на другой стержень. Диски большего размера нельзя размещать на дисках меньшего размера.

Схема перемещения дисков в Ханойской башне

Многие думают, что это означает физическое перемещение дисков из стойки в стойку, но на самом деле нет. Такой план резервирования применяется при ограниченном объеме пространства для резервирования, а также при использовании разных типов носителей для резервных копий. В этом случае, «башни» — это разные носители: диски, ленты, облако. Если использовать только один тип носителей, например, дисков, то при отказе системного ПО и дискового привода теряются все данные. Поэтому, чтобы не держать все яйца в одной корзине, используется метод ТОН. Однако он не очень часто используется на практике вследствие сложности алгоритма.

Решения резервирования

Bare-metal. Cистема резервного копирования ставится непосредственно на «голое железо», а не поверх операционной системы. Поэтому резервирование файлов, в отличие от резервирования образов дисков (вместе с ОС), на Bare-metal не работает: нет метаданных системы и загрузочных меток (bootstrapping). Основное преимущество резервирования образов в том, что оно предоставляет не только возможность восстанавливать файлы на работающей операционной системе, но и возможность полного восстановления на «голом железе», даже когда резервирование делается не на системе, идентичной той, на которой обрабатывались резервируемые данные (приложения, данные и ОС). Резервирование файлов может восстанавливать файлы только в работающей операционной системе, но резервирование образов может восстанавливать файлы как в работающей ОС, так и восстанавливать любые данные на «голое железо». Кроме того, ПО резервирования Bare-metal может преобразовывать физический образ в виртуальный образ, который может быть экспортирован в любую обычную систему виртуализации. При выборе системы резервирования на голом железе возможность выполнения этих функций в конкретном вендорском решении нужно обязательно проверить.

Single-pass. Резервирование Single-pass («один проход») означает, что требуется только одна операция (pass), чтобы захватить и сохранить данные, и только одна операция – чтобы их восстановить. Резервирование Single-pass работает быстрее, чем многопроходные варианты (multi-pass backups) и, следовательно, оно позволяет производить резервирование чаще и за более короткий промежуток времени BW (backup window). Однако при наличии программ резервирования для разного контента (файловое резервирование, резервирование образов и резервирование приложений), даже если они все поддерживают резервирование Single-pass, необходимо будет производить три операции (прохода) резервирования.

Непрерывная защита данных CDP (Continuous data protection), также известное как continuous backup или real-time backup, представляет собой создание резервной копии автоматически при каждом изменении данных. При этом становится возможным восстановление данных при любых авариях в любой момент времени, при этом доступна актуальная копия данных, а не те, что были несколько минут или часов назад. Однако это метод довольно затратный и используется только в исключительных случаях.

Удаленная репликация данных (Remote Replication) поддерживает две или более копий данных на двух или более сайтах для предотвращения потери информации в случае аварий.

Существует два типа удаленной репликации: синхронная и асинхронная, они отличатся порядком операций, что ясно из рисунка ниже.

Удаленная репликация данных

Выбор ПО и среды резервирования (Backup Media)

Чтобы выбрать носитель (среду) для резервирования, сначала нужно определить, какая емкость для этого понадобится (хотя бы примерно). Это зависит, прежде всего, от того, сколько копий нужно хранить, за какой период времени (это часто определено в регулировании для той или иной прикладной области), а также от скорости роста объема данных на предприятии, где создается система резервирования данных. Приблизительно можно сказать, что нужно умножить текущий объем данных в 3–5 раз. Однако нужно следить за скоростью роста данных, чтобы вовремя внести коррективы.

После того, как получен требуемый объем системы хранения для резервирования, необходимо выбрать среду (носитель данных) этой системы. Основных типов сред резервирования – три: дисковые СХД, ленточные библиотеки и облако. У каждого из них есть достоинства и недостатки.

Диски: быстро работают, но они относительно дорогие, хотя в последнее время наблюдается постоянное снижение цен на твердотельные диски SSD.

Ленты: обладают большими объемами, также довольно быстрые, но сложные в нахождении нужных данных и в управлении. Кроме того, ленты гораздо менее надежны, чем диски, потому что их легко повредить при обслуживании и перемещении.

Кассеты с лентой для ленточного накопителя

Однако цена ленточных накопителей является достаточно сильным аргументом в пользу их выбора.

Облако. Облако (Cloud) великолепно подходит как резервная система для удаленных офисов компаний и небольших серверов. Для такого сценария, особенно в случае выбора политики резервирования «3-2-1», облако – оптимальный выбор. Недостатком облака являются задержки и зависимость от облачного провайдера, а также надежность канала доступа к нему. Кроме того, немаловажным фактором является безопасность – очень часто предприятия просто боятся выпускать конфиденциальные данные за пределы корпоративного файрволла.

ПО:

У многих производителей серверного оборудования и систем хранения есть стратегическое партнерство с вышеперечисленными производителями программного обеспечения, что позволяет приобретать программные продукты через канал аппаратного вендора.

Железо:

Системы хранения Dell EMC DataDomain DD3300
Готовые решения на базе серверов Fujitsu PRIMERGY RX2540 и ПО Commvault и Veeam
Системы резервного копирования Quantum
Любой сервер с расширенной дисковой корзиной, например, HPE Proliant dl180 Gen10, HPE Proliant dl380 Gen10, Dell PowerEdgeR740XD

Ленты:

Восстановление данных

Snapshot – это «моментальный снимок» содержимого диска, полностью пригодная к использованию копия определенного набора данных на диске на момент съема этой копии. Такая копия используется для частичного восстановления состояния системы на момент копирования. При этом непрерывность работы системы совершенно не затрагивается, и быстродействие не ухудшается.

В технологиях восстановления данных используются три основополагающих понятия:

BW (Backup Window) – «окно резервирования», время, необходимое для системы резевирования для того, чтобы скопировать принятый объем данных рабочей системы.
RPO (Recovery Point Objective) – «Целевая точка восстановления», максимальный период времени и соответствующий объем данных, который допустимо потерять для пользователя СХД.
RTO (Recovery Time Objective) – «допустимое время недоступности», максимальное время, в течение которого СХД может быть недоступной до момента восстановления без критического воздействия на основной бизнес.

Катастрофоустойчивость

Катастрофоустойчивость (DR, Disaster Recovery) – это восстановление данных при стихийных бедствиях. Это довольно важная составляющая серьезных промышленных СХД, хотя и достаточно затратная. Но эти затраты необходимо нести, чтобы не потерять в одночасье то, что «нажито непосильным трудом». Технологии защиты данных (Snapshot, Remote Replication, CDP) хороши до тех пор, пока в населенном пункте, где расположена СХД, не произошло какое-либо стихийное бедствие: цунами, наводнение, землетрясение или что еще похуже. Удаленная репликация данных в политике «3-2-1» подразумевает, что реплицирующая СХД находится в том же населенном пункте, что и основная система, или, как минимум, поблизости. Что, например, при цунами не спасает.

Технология Disaster Recovery предполагает, что центр резервирования, используемый для восстановления данных при стихийных бедствиях, располагается на значительном удалении от места основного ЦОД и взаимодействует с ним по высокоскоростной сети передачи данных, наложенной на транспортную сеть, чаще всего оптическую.

Ни один носитель информации не является абсолютно надежным, из строя может выйти любое устройство хранения данных, и данные могут быть потеряны. Кроме аппаратных сбоев возможна также потеря данных по причине действия вредоносных программ (вирусы, "троянские кони" и т.д.). А самая распространенная причина порчи или удаления данных — ошибки пользователей (как обычных, так и администраторов), которые могут по ошибке удалить или перезаписать не тот файл .

По этой причине возникает необходимость регулярного создания резервных копий информации — файлов с документами, баз данных и состояния операционной системы.

Системы семейства Windows Server имеют встроенный инструмент создания резервных копий — утилиту ntbackup . Данная утилита позволяет сохранять резервные копии на самых различных носителях — ленточных накопителях, магнитооптических дисках, жестких дисках (как на локальных дисках данного сервера, так и на сетевых ресурсах, размещенных на других компьютерах сети). В версии системы Windows 2003 реализован механизм т.н. теневых копий ( Shadow Copy ), который заключается в том, что в начале процедуры архивации система делает моментальный "снимок" архивируемых файлов и уже после этого создает резервную копию из этого снимка. Данная технология позволяет архивировать файлы, которые в момент запуска утилиты ntbackup были открыты пользователями.

Сетевой администратор должен совместно с пользователями определить те данные, которые нужно регулярно архивировать, спланировать ресурсы, необходимые для создания резервных копий, составить расписание резервного копирования, настроить программу резервного копирования и планировщик заданий для автоматического создания резервных копий. Кроме этого, в задачу сетевого администратора входит также регулярное тестирование резервных копий и пробное восстановление данных из резервных копий (чтобы вовремя обнаружить возникающие проблемы в создании резервных копий).

В данном разделе описаны технологии создания резервных копий средствами системы Windows Server , даны рекомендации по планированию и настройке службы резервного копирования.

12.1 Архивирование и восстановление файловых ресурсов

Базовые понятия службы резервного копирования

Системы семейства Windows не содержат компоненты резервного копирования в смысле системной службы ( service ). Все операции по созданию резервных копий и восстановлению данных осуществляются утилитой ntbackup . Эту утилиту можно запустить из Главного меню системы (кнопка " Пуск " — " Все программы " — " Стандартные " — " Служебные " — " Архивация данных "), а можно запустить более быстро из командной строки (кнопка " Пуск " — " Выполнить " — " ntbackup " — кнопка " ОК "). При первом запуске утилиты рекомендуем убрать галочку у поля " Всегда запускать в режиме мастера ".

Рассмотрим основы резервного копирования файловых ресурсов.

Каждый файл, хранящийся на диске компьютера, независимо от типа файловой системы, имеет атрибут archive , который в Свойствах файла отображается как " Файл готов для архивирования " (откройте Свойства файла и нажмите кнопку " Другие "). Если в Свойствах файла вручную убрать галочку у этого атрибута, то при любом изменении в файле операционная система автоматически снова установит этот атрибут. На использовании изменений данного атрибута основаны все используемые в системе Windows методики резервного копирования.

Типы резервного копирования

Утилитой ntbackup можно создавать резервные копии различных типов. Рассмотрим их отличительные особенности и различные варианты их применения.

Обычный (Normal)

При выполнении данного типа архивирования утилита ntbackup архивирует все файлы, отмеченные для архивации, при этом у всех заархивированных файлов очищается атрибут " Файл готов для архивирования ". Данный вид архивирования необходим для создания еженедельных полных резервных копий каких-либо больших файловых ресурсов. Если в компании или организации имеются достаточные ресурсы, то можно ежедневно осуществлять полное архивирование данных.

Разностный (Differential)

При выполнении Разностного архивирования утилита ntbackup из файлов, отмеченных для архивирования, архивирует только те, у которых установлен атрибут " Файл готов для архивирования ", при этом данный атрибут не очищается. Использование Обычного и Разностного архивирования позволяет сэкономить пространство на носителях с резервными копиями и ускорить процесс создания ежедневных копий. Например, если раз в неделю (как правило, в выходные дни) создавать Обычные копии, а в течение недели ежедневно (как правило, в ночное время) — Разностные, то получается выигрыш в объеме носителей для резервного копирования. При такой комбинации архивирования "Обычный + Разностный" процесс восстановления данных в случае утери информации потребует выполнения двух операций восстановления — сначала из последней Полной копии, а затем из последней Разностной резервной копии.

Добавочный (Incremental)

При выполнении Добавочного архивирования утилита ntbackup из файлов, отмеченных для архивирования, архивирует только те, у которых установлен атрибут " Файл готов для архивирования ", при этом данный атрибут очищается. Использование Обычного (раз в неделю по выходным) и Добавочного (ежедневно в рабочие дни) архивирования также позволяет сэкономить пространство на носителях с резервными копиями и ускорить процесс создания ежедневных копий. Но процесс восстановления данных при использовании комбинации "Обычный + Добавочный" уже будет выполняться иначе: в случае утери информации для восстановления данных потребуется сначала восстановить данные из последней Полной копии, а затем последовательно из всех Добавочных копий, созданных после Полной копии.

Копирующий (Copy)

При таком типе архивирования утилита ntbackup заархивирует все отмеченные файлы, при этом атрибут " Файл готов для архивирования " остается без изменений.

Ежедневный (Daily)

Ежедневный тип архивирования создает резервные копии только тех файлов, которые были модифицированы в день создания резервной копии.

Два последних типа не используются для создания регулярных резервных копий. Их удобно применять в тех случаях, когда с какой-либо целью нужно сделать копию файловых ресурсов, но при этом нельзя нарушать настроенные регулярные процедуры архивирования.

Разработка и реализация стратегии резервного копирования

Понятие плана архивации

Создание и реализация плана архивации и восстановления информации — непростая задача. Сетевому администратору надо определить, какие данные требуют архивации, как часто проводить архивацию и т. д.

При создании плана ответьте на следующие вопросы:

Насколько важны данные? Этот критерий поможет решить, как, когда и какую информацию архивировать. Для критичной информации, например, баз данных, следует создавать избыточные архивные наборы, охватывающие несколько периодов архивации. Для менее важной информации, например, для текущих пользовательских файлов, сложный план архивации не нужен, достаточно регулярно сохранять их и уметь легко восстанавливать.
К какому типу относится архивируемая информация? Тип информации поможет определить необходимость архивации данных: как и когда данные должны быть сохранены.
Как часто изменяются данные? Частота изменения влияет на выбор частоты архивирования. Например, ежедневно меняющиеся данные необходимо сохранять каждый день.
Нужно ли дополнить архивацию созданием теневых копий ? При этом следует помнить, что теневая копия — это дополнение к архивации, но ни в коем случае не ее замена.
Как быстро нужно восстанавливать данные? Время — важный фактор при создании плана архивации. В критичных к скорости системах нужно проводить восстановление очень быстро.
Какое оборудование оптимально для архивации и есть ли оно у вас? Для своевременной архивации вам понадобится несколько архивирующих устройств и несколько наборов носителей. Аппаратные средства архивации включают ленточные накопители (это наименее дорогой, но и самый медленный тип носителя), оптические диски и съемные дисковые накопители.
Кто отвечает за выполнение плана архивации и восстановления данных? В идеале и за разработку плана, и собственно за архивацию и восстановление должен отвечать один человек.
Какое время оптимально для архивации? Архивация в период наименьшей загрузки системы пройдет быстрее, но не всегда возможно провести ее в удобные часы. Поэтому с особой тщательностью архивируйте ключевые данные.
Нужно ли сохранять архивы вне офиса? Хранение архивов вне офиса — важный фактор на случай стихийного бедствия. Вместе с архивами сохраните и копии ПО для установки или переустановки ОС.

Для построения правильной и эффективной системы резервного копирования необходимо детально изучить и задокументировать все файловые ресурсы, используемые в компании, а затем тщательно спланировать стратегию резервного копирования и реализовать ее в системе. Для планирования стратегии необходимо ответить на следующие вопросы:

какие именно ресурсы будут архивироваться;
минимальный промежуток времени для восстановления данного ресурса при возникновении аварии;
какой объем данных будет архивироваться;
какова емкость носителей для хранения резервных копий и скорость записи на эти носители;
сколько времени будет занимать архивирование каждого ресурса;
как часто будет производиться архивация каждого ресурса;
если резервные копии записываются на ленты, то как часто будет производиться перезапись лент;
по какому графику будет производиться тестовое восстановление данных.

При ответе на эти вопросы будет спланирована потребность в количестве и емкости накопителей и устройств для выполнения резервных копий, требования к пропускной способности сети для создания резервных копий, график выполнения резервного копирования, план восстановления на случай аварии.

Выбор архивных устройств и носителей

Определив, какие данные и как часто архивировать, можно выбрать аппаратные средства архивации и необходимые носители. Инструментов для архивации данных множество. Одни быстрые и дорогие, другие — медленные и надежные. Выбор подходящего оборудования для организации зависит от многих факторов.

Емкость — количество регулярно архивируемых данных. Справится ли оборудование с нагрузкой в отведенное время?
Надежность аппаратных средств и носителей. Можете ли вы пожертвовать надежностью ради экономии или скорости?
Расширяемость решения. Удовлетворяет ли ваше решение потребностям роста организации?
Скорость архивации и восстановления. Можете ли вы пожертвовать скоростью ради снижения стоимости?
Цена архивации. Приемлема ли она для вашего бюджета?

Типовые решения архивации

Итак, на план архивации влияют емкость, надежность, расширяемость, скорость и цена. Определив, какие из этих факторов наиболее важны для вашей организации, вы примете подходящее решение. Вот некоторые общие рекомендации:

Ленточные накопители — самые распространенные устройства архивации. Данные хранятся на кассетах с магнитной лентой. Лента относительно недорога, но не особенно надежна: она может помяться или растянуться, с течением времени — размагнититься и перестать считываться. Средняя емкость кассет с лентой варьируется от единиц до десятков Гбайт. По сравнению с другими решениями ленточные накопители довольно медленны. Их достоинство — невысокая цена.
Накопители на цифровой ленте ( digital audio tape , DAT) — пришли на смену традиционным ленточным накопителям. Существует несколько форматов DAT. Наиболее часто используются ленты DLT ( Digital Linear Tape ) и Super DLT. Ленты DLT IV обладают емкостью 35-40 Гбайт без сжатия и 70-80 Гбайт со сжатием. В крупных организациях иногда разумнее применять ленты LTO ( Linear Таре Open ) или AIT ( Advanced Intelligent Tape ). Обычно объем лент LTO составляет 100 Гбайт без сжатия и 200 Гбайт со сжатием. Для лент AIT -3 соответствующие емкости составляют 100 и 260 Гбайт.
Ленточная библиотека с автозагрузкой — устройство для создания расширенных архивных томов на нескольких лентах, которых хватает для нужд всего предприятия. Ленты набора в процессе архивации или восстановления данных автоматически меняются. В большинстве таких библиотек применяются DAT-ленты. Их главный "минус" — высокая цена.
Магнитооптические накопители с автозагрузкой подобны ленточным библиотекам, только вместо лент в них используются магнитооптические диски. Цена также очень высока.
Съемные диски, например Iomega Jazz емкостью 1-2 Гбайт, все чаще используются в качестве устройств архивации. Они обладают хорошей скоростью и удобны в работе, но стоят дороже ленточных или DAT-накопителей.
Дисковые накопители обеспечивают наивысшую скорость при архивации и восстановлении файлов. Если при архивации на ленту вам потребуются часы, то дисковый накопитель позволяет завершить процесс за несколько минут. К недостаткам дисковых накопителей следует отнести относительно высокую цену.

При установке устройств архивации необходимо указать ОС контроллеры и драйверы, используемые накопителями.

Подготовку нового сервера к работе следует начинать с настройки резервного копирования. Все, казалось бы, об этом знают — но порой даже опытные системные администраторы допускают непростительные ошибки. И дело здесь не только в том, что задачу настройки нового сервера нужно решать очень быстро, но еще и в том, что далеко не всегда бывает ясно, какой способ резервного копирования нужно использовать.

Конечно, идеальный способ, который бы всех устраивал, создать невозможно: везде есть свои плюсы и минусы. Но в то же время вполне реальным представляется подобрать способ, максимально подходящий под специфику конкретно проекта.

При выборе способа резервного копирования нужно прежде всего обратить внимание на следующие критерии:

Скорость (время) резервного копирования в хранилище;
Скорость (время) восстановления из резервной копии;
Сколько копий можно будет держать при ограниченном размере хранилища (сервере хранения бекапов);
Объем рисков из-за неконсистентности резервных копий, неотлаженности метода выполнения бэкапов, полной или частичной потери бекапов;
Накладные расходы: уровень нагрузки, создаваемой на сервер при выполнении копирования, уменьшение скорости отклика сервиса и т.п.
Стоимость аренды всех использующихся сервисов.

В этой статье мы расскажем об основных способах резервного копирования и о наиболее типичных проблемах, с которыми могут столкнуться новички в этой очень важной области системного администрирования.

Схема организации хранения и восстановления из резервных копий

При выборе схемы организации метода резервирования следует обратить внимание на следующие базовые моменты:

Резервные копии нельзя хранить в одном месте с резервируемыми данными. Если вы храните резервную копию на одном дисковом массиве с вашими данными, то вы потеряете её в случае повреждения основного дискового массива.
Зеркалирование (RAID1) нельзя сравнивать с резервным копированием. Рейд защищает вас только от аппаратной проблемы с одним из дисков (а рано или поздно такая проблема будет, т.к. дисковая подсистема почти всегда является узким местом на сервере). К тому же при использовании аппаратных рейдов есть риск поломки контроллера, т.е. необходимо хранить его запасную модель.
Если вы храните резервные копии в рамках одной стойки в ДЦ или просто в рамках одного ДЦ, то в такой ситуации тоже имеются определенные риски (об этом можно прочитать, например, здесь .
Если вы храните резервные копии в разных ДЦ, то резко возрастают затраты на сеть и скорость восстановления из удаленной копии.

Часто причиной восстановления данных служит повреждение файловой системы или дисков. Т.е. бекапы нужно хранить где-то на отдельном сервере-хранилище. В этом случае проблемой может стать «ширина» канала передачи данных. Если у вас выделенный сервер, то резервное копирование очень желательно выполнять по отдельному сетевому интерфейсу, а не на том же, что выполняет обмен данных с клиентами. Иначе запросы вашего клиента могут не «поместиться» в ограниченный канал связи. Или из-за трафика клиентов бекапы не будут сделаны в срок.

Далее нужно подумать о схеме и времени восстановления данных с точки зрения хранения бекапов. Может быть вас вполне устраивает, что бекап выполняется за 6 часов ночью на хранилище с ограниченной скоростью доступа, однако восстановление длиной в 6 часов вас вряд ли устроит. Значит доступ к резервным копиям должен быть удобным и данные должны копироваться достаточно быстро. Так, например, восстановление 1Тб данных с полосой в 1Гб/с займет почти 3 часа, и это если вы не «упретесь» в производительность дисковой подсистемы в хранилище и сервере. И не забудьте прибавить к этому время обнаружения проблемы, время на решение об откате, время проверки целостности восстановленных данных и объем последующего недовольства клиентов/коллег.

Инкрементальное резервное копирование

При инкрементальном резервном копировании копируются только файлы, которые были изменены со времени предыдущего бэкапа. Последующее инкрементальное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. В среднем инкрементальное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, плюс данные всех последующих инкрементальных резервных копирований. При этом в отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.

Инкрементальное копирование чаще всего производится с помощью утилиты rsync. С его помощью можно сэкономить место в хранилище, если количество изменений за день не очень велико. Если измененные файлы имеют большой размер, то они будут скопированы полностью без замены предыдущих версий.

Процесс резервного копирования с помощью rsync можно разделить на следующие шаги:

Составляется список файлов на резервируемом сервере и в хранилище, по каждому файлу считываются метаданные (права, время изменения и т.д) или контрольная сумма (при использовании ключа —checksum).
Если метаданные файлов разнятся, то файл бьется на блоки и по каждому блоку считается контрольная сумма. Отличающиеся блоки закачиваются в хранилище.
Если во время подсчета контрольных сумм или передачи файла в него было внесено изменение, его резервирование повторяется с начала.
По умолчанию rsync передает данные через SSH, а значит каждый блок данных дополнительно шифруется. Rsync можно также запустить как демон и передавать данные без шифрования по его протоколу.

С более подробной информацией о работе rsync можно ознакомиться на официальном сайте .

Для каждого файла rsync выполняет очень большое количество операций. Если файлов на сервере много или если процессор сильно загружен, то скорость резервного копирования будет существенно снижена.

Из опыта можем сказать, что проблемы на SATA-дисках (RAID1) начинаются примерно после 200G данных на сервере. На самом деле всё, конечное же, зависит от количества inode. И в каждом случае эта величина может смещаться как в одну так и в другую сторону.

После определенной черты время выполнения резервного копирования будет очень долгим или попросту не будет отрабатывать за сутки.

Для того, чтобы не сравнивать все файлы, есть lsyncd. Этот демон собирает информацию об изменившихся файлах, т.е. мы уже заранее будем иметь готовый их список для rsync. Следует, однако, учесть, что он дает дополнительную нагрузку на дисковую подсистему.

Дифференциальное резервное копирование

При дифференциальном резервном копировании каждый файл, который был изменен с момента последнего полного резервного копирования, копируется всякий раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все, что вам необходимо — это последняя полная и последняя дифференциальная резервная копия. Популярность дифференциального резервного копирования растет, так как все копии файлов делаются в определенные моменты времени, что, например, очень важно при заражении вирусами.

Дифференциальное резервное копирование осуществляется, например, при помощи такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементальном резервном копировании.

В целом, если при поиске разницы в данных осуществляется полный перебор файлов, проблемы такого рода резервирования аналогичны проблемам с rsync.

Хотим отдельно отметить, что если в вашей схеме резервного копирования каждый файл копируется отдельно, то стоит удалять/исключать ненужные вам файлы. Например, это могут быть кеши CMS. В таких кешах обычно очень много маленьких файлов, потеря которых не скажется на корректной работе сервера.

Полное резервное копирование

Полное копирование обычно затрагивает всю вашу систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется по пятницам или в течение выходных, когда копирование большого объёма данных не влияет на работу организации. Последующие резервные копирования, выполняемые с понедельника по четверг до следующего полного копирования, могут быть дифференциальными или инкрементальными, главным образом для того, чтобы сохранить время и место на носителе. Полное резервное копирование следует проводить по крайней мере еженедельно.

В большинстве публикаций по соответствующей тематике рекомендуется полное резервное копирование выполнять один или два раза в неделю, а в остальное время время — использовать инкрементальное и дифференциальное. В таких советах есть свой резон. В большинстве случаев полного резервного копирования раз в неделю вполне достаточно. Выполнять его повторно имеет смысл в том случае, если у вас нет возможности на стороне хранилища актуализировать полный бекап и для обеспечения гарантии корректности резервной копии (это может понадобиться, например, в случаях, если вы по тем или иным причинам не доверяете имеющимся у вас скриптам или софту для резервного копирования.

На самом деле полное резервное копирование можно поделить на 2 части:

Полное резервное копирование на уровне файловой системы;
Полное резервное копирование на уровне устройств.

Рассмотрим их характерные особенности на примере:

Резервировать мы будем только /home. Все остальное можно быстро восстановить вручную. Можно также развернуть сервер системой управления конфигурациями и подключить к нему наш /home.

Полное резервное копирование на уровне файловой системы

Типичный представитель: dump.

Утилита создает «дамп» файловой системы. Можно создавать не только полную, но и инкрементальную резервную копию. dump работает с таблицей inode и «понимает» структуру файлов (так, разреженные файлы сжимаются).
Создавать дамп работающей файловой системы «глупо и опасно», потому что ФС может изменяться во время создания дампа. Его надо создавать со снапшота (чуть позже мы обсудим особенности работы со снапшотами более подробно), отмонтированной или замороженной ФС.

Такая схема так же зависит от количества файлов, и время её выполнения будет расти с ростом количества данных на диске. В то же время у dump скорость работы выше, чем у rsync.
В случае, если требуется возобновить не резервную копию целиком, а, например, только пару случайно испорченных файлов), извлечение таких файлов утилитой restore может занять слишком много времени

Полное резервное копирование на уровне устройств

mdraid и DRBD
Фактически настраивается RAID1 с диском/рейдом на сервере и сетевым диском, и время от времени (по частоте выполнения бекапов) дополнительный диск синхронизируется с основным диском/рейдом на сервере.

Самый большой плюс — скорость. Длительность выполнения синхронизации зависит только от количества внесенных за последний день изменений.
Такая система резервного копирования используется довольно часто, но мало кто отдает себе отчет в том, что полученные с ее помощью резервные копии могут быть недееспособными, и вот почему. Когда синхронизация дисков завершена, диск с резервной копией отключается. Если у нас, например, запущена СУБД, которая пишет данные на локальный диск порциями, храня промежуточные данные в кэше, нет никакой гарантии того, что они вообще попадут на бэкапный диск. В лучшем случае мы потеряем часть изменяемых данных. Поэтому такие бэкапы вряд ли стоит считать надежными.

Например, с одним MySQL это будет выглядеть так:

* Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.

Далее можно копировать снапшот в хранилище. Главное — следить за тем, чтобы во время копирования снапшот не самоуничтожился и не забывать, что при создании снапшота скорость записи упадет в разы.

Бекапы СУБД можно создать отдельно (например, используя бинарные логи), устранив тем самым простой на время сброса кеша. А можно создавать дампы в хранилище, запустив там инстанс СУБД. Резервное копирование разных СУБД — это тема для отдельных публикаций.

Сжатие устраняет проблемы скорости передачи, забития канала и места в хранилище. Но, однако если вы не используете AVFS в хранилище, то на восстановление только части данных у вас уйдет много времени. Если будете использовать AVFS, то столкнетесь с её «сыростью».
Альтернатива сжатию блоками — squashfs: можно подмонтировать, к примеру, по Samba раздел к серверу и выполнить mksquashfs, но эта утилита так же работает с файлами, т.е. зависит от их количества.

К тому же при создании squashfs тратится достаточно много ОЗУ, что может легко привести к вызову oom-killer.

Безопасность

Необходимо обезопасить себя от ситуации когда хранилище или ваш сервер будут взломаны. Если взломан сервер, то лучше чтобы не было прав на удаление/изменение файлов в хранилище у пользователя, который записывает туда данные.
Если взломано хранилище, то права бекапного пользователя на сервере так же желательно ограничить по максимуму.

Если канал резервного копирования может быть прослушан, то нужны средства шифрования.

Заключение

У каждой системы резервного копирования свои минусы и свои плюсы. В этой статье мы постарались осветить часть нюансов при выборе системы резервного копирования. Надеемся, что они помогут нашим читателям.

В итоге, при выборе системы резервного копирования под ваш проект, нужно провести тесты выбранного типа резервного копирования и обратить внимание на:

время резервного копирования в текущей стадии проекта;
время резервного копирования в случае, если данных будет в разы больше;
нагрузку на канал;
нагрузку на дисковую подсистему на сервере и в хранилище;
время восстановление всех данных;
время восстановления пары файлов;
необходимость в консистентности данных, особенно БД;
расход памяти и наличие вызовов oom-killer;

В качестве решений по резервному копированию, можно использовать supload и наше облачное хранилище.

Читайте также: