Обзор систем резервного копирования и восстановления данных

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

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

На самом деле важность регулярного бэкапа и хранения резервных копий критически важных данных можно проиллюстрировать на простом примере. После прошлогодних атак вирусов-шифровальщиков WannaCry и NotPetya быстрее всего к работе возвращались те организации, которые просто восстановили резервные копии своих систем. А самый курьезный случай, наверное, случился с компанией Maersk — крупным международным транспортным предприятием. За несколько дней сотрудники в главном офисе восстановили из резервных копий почти все сервера. Но у них не было бэкапов главных контроллеров, которые управляли всей сетью. Единственный экземпляр сохранился в Гане: в день атаки  местный офис остался без электричества и не пострадал от атаки. Заветный жесткий диск с копией контроллеров пришлось передавать в Лондон самолетом через Нигерию, так как на отправку по интернету из-за его медленной скорости в Гане ушли бы дни.

Потерять данные можно не только из-за вирусов и хакерских атак, как в случае с компанией Maersk. Такое может произойти вследствие ошибок пользователей и администраторов сети, поломок оборудования, форс-мажорных обстоятельств (краж, пожаров, стихийных бедствий). Защитить от этого призваны системы  резервного копирования и восстановления данных (Backup and Recovery). Они с заданной периодичностью копируют определенную системными администраторами информацию на резервные носители или в облако. Резервировать можно как конкретные файлы и папки, так и образы систем и серверов, содержимое баз данных и приложений. В случае проблем подобные системы умеют восстанавливать необходимые данные на исходных устройствах. Причем происходит это очень быстро. Современные решения позволяют продолжить работу уже через несколько минут после происшествия.

Для хранения резервных копий используются разные носители. Зачастую — жесткие и твердотельные диски (HDD и SSD) в составе различных специализированных устройств (NAS, RAID-массивов и т. д.). Не обходятся без внимания и облачные хранилища. Можно, конечно, использовать и другие носители, например, Blu-ray, DVD или ленточные устройства хранения. Но у них есть существенные недостатки. Компакт-диски слишком малы по объему (не подходят для крупных предприятий), а ленточные устройства хоть и обеспечивают высокую надежность и долговечность хранения, имеют очень маленькую скорость восстановления. Данные способы подходят для домашнего резервирования и использования в небольших фирмах, где объем данных не так велик. А вот в крупных компаниях они будут весьма неудобны.

Также нужно обратить внимание на модель работы системы резервного копирования и восстановления данных. Это может быть отдельная программа, программно-аппаратный комплекс или услуга по модели SaaS (Software as a Service). У каждой из них есть свои особенности. Программное решение стоит дешево, но в любом случае требует наличия мест для хранения информации в ИТ-инфраструктуре клиента. Программно-аппаратные комплексы предоставляют такие устройства, но и стоят намного дороже. SaaS-решение избавляет от проблем с наличием места, но политика ИБ многих компаний запрещает хранить некоторые типы данных на сторонних серверах. Так что при выборе той или иной модели нужно отталкиваться от собственных потребностей и имеющегося оборудования. Теперь давайте рассмотрим детальнее, какие решения есть на рынке. При их отборе для нашего обзора мы отталкивались от экспертного мнения специалистов Gartner и других ведущих ресурсов.

Dell EMC Avamar

Одна из ведущих ИТ-компаний — Dell EMC — для резервного копирования и восстановления данных предлагает программно-аппаратное средство под названием Avamar. Оно является частью Data Protection Suite Family — набора фирменных решений для защиты информации. Avamar работает со всеми типами корпоративных устройств (стационарными ПК, ноутбуками и серверами), разнообразными виртуальными средами (в том числе VMware и Microsoft Hyper-V) и корпоративными приложениями (SAP, Oracle, MS SQL  и т. д.). Для эффективного использования дискового пространства при хранении резервных копий применяется дедупликация данных, а трафик оптимизируется в зависимости от типа рабочих сетей. По заявлениям разработчиков, интеграция данного средства с Dell EMC Data Domain, увеличивает скорость копирования на 50% и снижает нагрузку на сеть на сеть на 99%.

Система позволяет централизованно работать не только с главным, но и с удаленными офисами. Бэкап в них происходит по стандартной модели. Например, чтобы восстановить данные в удаленном офисе, администратору нужно сделать те же действия, что и при работе на месте. Сама процедура восстановления довольно проста, зачастую для этого необходим всего один шаг. Резервные копии в Dell EMC Avamar можно зашифровать, что обеспечивает повышенный уровень безопасности данных. При этом система хранения Avamar Data Store масштабируется до 124 ТБ. Также решение работает с облачными сервисами AWS и Azure. Поддерживается резервное копирование в облако и аварийное восстановление, имеется функция длительного хранения в облаке.

IBM Spectrum Protect

Восстановление информации с IBM Spectrum Protect происходит очень просто. Управлять резервированием и восстановлением можно как при помощи фирменного программного средства Spectrum Protect Operatons Center, так и с использованием стороннего ПО. Также в IBM Spectrum Protect есть предустановленные планы и конфигурации. Они упрощают развертывание и настройку решения, а также помогают в управлении: можно сразу задать необходимые сценарии работы для тех или иных сред. Так что даже администраторы, которые ранее не сталкивались с подобными задачами, могут без проблем разобраться в системе и управлять ней. Сам разработчик заявляет, что простота — это одна из ключевых особенностей платформы.Компания IBM для резервного копирования и восстановления данных предлагает программно-аппаратный комплекс Spectrum Protect с возможностью масштабирования до 4 ПБ (петабайт). Система работает как с физическими серверами и устройствами, так и в виртуальных средах Microsoft Hyper-V и VMware. Также поддерживается работа с облачными сервисами. IBM Spectrum Protect позволяет хранить резервные копии на самых разнообразных носителях — отдельных жестких дисках, флешках, ленточных накопителях, в сетевых и облачных хранилищах. Причем пользователи могут работать с гибридными моделями и задавать оптимальное сочетание разных мест хранения. Само резервное копирование объектов происходит довольно быстро. По информации разработчика, с помощью инструмента IBM Spectrum Protect Snapshot можно выполнить резервное копирование пяти сотен образов виртуальных машин VMware за семь минут. Действительно, хороший показатель.

Commvault Complete Backup & Recovery

Commvault Complete Backup & Recovery обеспечивает резервирование и архивирование данных с физических и виртуальных серверов, облачных и гибридных сред, обычных ПК и ноутбуков, и даже корпоративных мобильных устройств. Решение поддерживает большинство операционных систем, приложений и баз данных (Documentum, Oracle, MySQL, SAP, Microsoft), виртуальных и облачных сред (AWS, Microsoft Hyper-V, Red Hat Virtualization, VMware и многие другие). Обо всех процедурах продукт выдает детальные отчеты и аналитику, что позволяет оптимизировать его работу и функционирование всего предприятия. Во время процесса резервирования данные автоматически дедуплицируются, причем как при обращении к источнику, так и на серверах резервных копий. Такой подход существенно снижает нагрузку на сеть и экономит место в хранилищах. Решение позволяет создавать резервные копии и «снимки» приложений и оборудования без прерывания работы и с минимальной нагрузкой на систему. А управление всеми процессами осуществляется через единую консоль управления.Средство резервного копирования и восстановления информации от компании Commvault поставляется в виде программного продукта и облачной услуги по модели SaaS. Решение имеет модульный характер, но в то же время все его части созданы на основе единого кода. Такой подход гарантирует бесперебойную совместную работу разных частей данного средства.

Veeam Backup Essentials

Компания Veeam предлагает одно из самых функциональных программных решений для резервного копирования и восстановления данных. В него входят два инструмента: Veeam Backup & Replication и Veeam ONE. Как понятно из названия, первый умеет не только делать бэкапы, но и репликации — синхронизацию содержимого нескольких копий объекта. Данная функция позволяет быстро и безопасно восстанавливать виртуальные машины, данные и приложения после сбоя. Причем восстанавливаются они практически в то же состояние, в котором были до аварии. Таким образом можно быть уверенным, что результаты работы не будут потеряны. Также средство умеет делать откат реплик и позволяет просто переключаться на реплику при отказе виртуальной машины и так же легко возвращаться обратно.

Veeam ONE — решение, позволяющее мониторить инфраструктуру, создавать отчеты и планировать распределение ресурсов платформ VMware vSphere и Microsoft Hyper-V. Оно может сообщать о потенциальных проблемах с виртуальными машинами, физическими серверами и облачными ресурсами до того, как они помешают работе пользователей. То есть позволяет устранить проблемы до их появления и таким образом избежать процедуры восстановления данных, которая наверняка вызовет перебои в работе.

Кроме этих инструментов, Veeam Backup Essentials предлагает стандартные возможности по резервному копированию и восстановлению данных. Программа умеет работать с популярными бизнес-приложениями и базами данных, поддерживает работу с 19 распространенными файловыми системами. Она имеет удобный веб-портал, который позволяет восстанавливать файлы и приложения в один клик. Причем делать это могут не только администраторы, но и обычные пользователи, если речь идет о данных, с которыми они работали и к которым у них есть права доступа.

Acronis Backup

Продукты для резервного копирования и восстановления данных от компании Acronis хорошо известны домашним пользователям. Но и для корпоративного сегмента у данного разработчика есть что предложить. К примеру, программа Acronis Backup поддерживает 21 платформу, включая виртуальные среды (Red Hat, Citrix, VMware и др.), облачные сервисы (Amazon, Microsoft), конечные точки и даже мобильные устройства (Android, iPhone и iPad). Для бизнес-приложений и виртуальных машин доступна функция репликации (для ее работы используются специальные шаблоны для ОС Windows и Linux), а также облачное хранилище  Acronis Cloud. Восстанавливать образы рабочих станций и серверов можно на оборудование, которое отличается от того, с которого была снята резервная копия. Также для любого критически важного приложения или массива информации можно создать точки восстановления, которые при необходимости (например, из-за выхода оборудования из строя или необходимости его замены) могут быть оперативно развернуты в облаке и позволят продолжить работу лишь с небольшим перерывом.

Сама по себе платформа очень проста в управлении. Она быстро развертывается и, по словам разработчиков, не требует специального обучения для работы с ней. Управлять системой можно централизованно, при помощи единого интерфейса. Помимо непосредственно функций резервного копирования и восстановления, в Acronis Backup есть несколько полезных дополнительных инструментов. Это, например, Acronis Notary — средство, которое с помощью технологии блокчейн подтверждает аутентичность пересылаемой и получаемой информации. А для защиты данных от вирусов-вымогателей используется инструмент Acronis Active Protection.

HPE StoreOnce

Для резервного копирования и восстановления данных компания HPE предлагает систему HPE StoreOnce — линейку устройств, которые обеспечивают надежное хранение данных объемом до 104 ПБ и скорость резервного копирования до 139ТБ/час. Данные устройства используются для работы в облачной и виртуальной среде, а также при использовании гибридных моделей. Для работы с устройствами StoreOnce подходит как фирменное ПО HPE Recovery Manager Central, так и решения сторонних разработчиков, например, Veeam или Commvault. Модельный ряд StoreOnce довольно широк и масштабируем. Он покрывает потребности как небольших удаленных офисов, так и крупных корпоративных дата-центров. В устройствах применяется интеллектуальная технология дедупликации, которая (по заявлениям разработчиков) позволяет сократить занимаемый объем данных на 95%.

В рамках этой линейки также предлагается программно-определяемая резервная система хранения данных емкостью до 500 ТБ под названием HPE StoreOnce VSA. Ее объем может регулироваться с шагом в 1 ТБ. Запускается она в виртуальной среде, и может быть бесплатно протестирована на протяжении 90 дней. Также пользователям в качестве отдельного решения доступно облачное хранилище HPE Cloud Bank Storage, которое используется как дополнение к основной системе и интегрируется с веб-службами Amazon и Microsoft.

Arcserve UDP

Компания Arcserve — один из старожилов рынка средств резервного копирования и восстановления информации. Этим делом она занимается с 1990 года и, естественно, имеет колоссальный опыт. Сегодня ведущее решение компании — платформа Arcserve Unified Data Protection. В ее рамках предлагаются программные, аппаратные (объемом до 240 ТБ) и облачные решения для бэкапа и восстановления информации с единой веб-консолью управления, работать с которой можно отовсюду, где есть интернет. Система обеспечивает дедупликацию данных, репликацию в реальном времени, поддерживает виртуальные (VMware, Microsoft Hyper-V, Xen) и физические среды, а также восстановление на различные гипервизоры. В качестве хранилищ для резервных копий могут использоваться дисковые массивы, ленточные хранилища и облачные сервисы. Причем данные способы можно комбинировать, например, проводить одновременно облачный и локальный бэкап. Что же касается фирменных устройств Arcserve UDP Appliance серии 8000, они предлагают 16 разных по объему хранимых данных конфигураций, а также широкие возможности масштабирования.

Платформа Arcserve UDP позволяет проводить резервное копирование как отдельных файлов и папок, так и полных баз данных, например, SQL или Exchange. Для повышения информационной безопасности резервные копии данных могут быть зашифрованы с использованием протоколов SSL и AES. Доступ пользователей к данным также защищается системой двухфакторной аутентификации, когда для входа в систему нужно не только ввести свой логин и пароль, но и подтвердить вход с помощью мобильного устройства.

Unitrends Backup

Компания Unitrends — известный производитель систем резервного копирования и восстановления. В ее арсенале есть как программные, так и аппаратные средства для этих задач. Устройства Recovery Series Appliances являются масштабируемыми решениями, которые предлагают пользователям от двух до 120 ТБ дискового пространства для хранения резервных копий. Работают они под управлением ПО Unitrends Backup (но эта программа может работать и без привязки к ним). Система поддерживает работу с физическими и виртуальными средами, обеспечивают бэкап баз данных и бизнес-приложений, обеспечивает интеграцию с облачными сервисами и умеет работать с репликами Windows и VMware. Также в ней есть защита от вирусов-вымогателей и шифрование хранящихся данных при помощи 256-битного протокола AES.

Unitrends предлагает и бесплатную версию продукта под названием Unitrends Free. Там действуют некоторые ограничения. Например, объем резервируемой информации не может превышать 1 ТБ. Но для небольших предприятий (да и просто ознакомления с продуктом) такого объема вполне достаточно.

Veritas Backup Exec

Компания Veritas предлагает для резервного копирования и восстановления данных инструмент под названием Backup Exec. Этот продукт уже довольно давно зарекомендовал себя на рынке. Разработчик постоянно обновляет его и добавляет новые функции, о чем говорит номер версии: на сегодня доступна двадцатая редакция этой программы. Backup Exec обеспечивает все основные функции, которые требуются от подобного рода решений. Средство работает с физическими и виртуальными средами, большинством распространенных облачных сервисов (Amazon S3, Google Cloud, Microsoft Azure и др.), умеет дедуплицировать данные, моментально создавать копии виртуальных машин и очень быстро восстанавливать их. Например, с помощью технологии мгновенного гранулярного восстановления, виртуальные машины с поддержкой vSphere 2016 возобновляют работоспособность за считанные секунды. Также поддерживаются многие популярные базы данных и бизнес-приложения.

Veritas Backup Exec имеет гибкую систему лицензирования. Всего пользователям доступно три редакции программы: Bronze, Silver и Gold, которые различаются по функциональности. Таким образом, Bronze рассчитана в основном на предприятия среднего и малого бизнеса, редакции Silver и Gold – для более крупных компаний. Также Veritas Backup Exec предлагает удобную систему масштабирования с шагом в 1 TБ. Именно от количества работающих серверов и заказанного объема резервируемой информации и зависит конечная цена для потребителя. Это позволяет эффективно использовать свои ресурсы и платить только за то, чем пользуешься.

Barracuda Backup

Barracuda Backup является унифицированным, экономичным решением по защите данных для физических, виртуальных и облачных (SaaS) сред. Это комплексное решение с удаленным хранилищем, которое легко приобрести, установить и использовать. Barracuda Backup является единым решением для защиты физических серверов и виртуальных машин (VMware и Hyper-V) с функциями моментального отчета о состоянии и выборочного восстановления файлов – с унифицированным управлением для репликации и хранения. Barracuda Backup является комплексным решением от одного поставщика. Оно объединяет в себе программное обеспечение, встраиваемую дедупликацию, внешнюю облачную или частную репликацию без лицензионных сборов за сервер или за приложение.

Barracuda Backup доступно как в виде универсального физического аппаратного комплекса, так и в виде виртуального устройства.

Администрирование управление политиками осуществляется через центральное управление через облачный сервис Barracuda Cloud Control, реализована модель ролевого администрирования.

Облачные сервисы Barracuda Cloud Storage, Cloud Control и Cloud LiveBoot recovery позволяют производить простую удаленную репликацию, бесшовное распределенное администрирование и быстрый доступ к виртуальным машинам во время аварийных сбоев.

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

Краткий итог

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

Таблица сравнения по характеристикам продуктов для защиты и восстановления данных (Backup and Recovery).

 

Автор: Владислав Миронович, для ROI4CIO

Система резервного копирования

Структура работы системы резервного копирования

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

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

Организационные сложности по части защиты данных

• Внутренние противоречия в технической команде
• Администраторы приложений должны отвечать за сохранность данных, SLA и восстановление?
• Централизованный автоматизированный контроль – снижение рисков для ИТ директора : повышается прозрачность, предсказуемость ИТ процессов

Правильная стратегия защиты данных для ЦОДа

Устаревший подход под названием «РЕЗЕРВНОЕ КОПИРОВАНИЕ»^[1]

• Резервное копирование
• Восстановление

Современный подход под названием «УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ»

• Резервное копирование
• Восстановление
• Аналитика по содержимому
• Контекстный поиск
• Мобильный доступ к данным
• Прозрачная интеграция с облаком
• Задачи ИБ
• ЛЮБЫЕ приложения сторонних разработчиков по обработке данных (Открытый API)

Проблема копий

• При отсутствии централизованного подхода количество данных неконтролируемо растет
• Где лежит самая актуальная версия данных ?
• Если потребуется удалить данные по Compliance, где найти все копии ?
• Удалениеи архивирование устаревшей информации. Как определить разумный критерий ценности данных ?

Архитектура и работа системы резервного копирования

Централизованная система резервного копирования имеет многоуровневую архитектуру, в которую входят:

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

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

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

Сервер копирования сохраняет полученные данные на подключенное к нему устройство хранения данных. Информация о процессе (какие файлы копировались, на какие носители осуществлялось копирование и т. п.) сохраняется в базе сервера управления. Эта информация позволяет найти местоположение сохраненных данных при необходимости их восстановления на компьютере-клиенте.

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

Поскольку система резервного копирования предназначена для восстановления данных после сбоя или аварии, созданные резервные копии необходимо проверять на предмет целостности и работоспособности. Кроме того, при построении системы резервного копирования необходимо уложиться в сокращенное «окно» резервного копирования. Вообще говоря, требование круглосуточной работы информационных систем сокращает практически до нуля доступный временной интервал остановки приложений, необходимый для осуществления операции резервного копирования («окно» резервного копирования).

Классификация резервного копирования

По полноте сохраняемой информации

• Полное резервирование (Full backup) — создание резервного архива всех системных файлов, обычно включающего состояние системы, реестр и другую информацию, необходимую для полного восстановления рабочих станций. То есть резервируются не только файлы, но и вся информация, необходимая для работы системы.
• Добавочное резервирование (Incremental backup) — создание резервного архива из всех файлов, которые были модифицированы после предыдущего полного или добавочного резервирования.
• Разностное резервирование (Differential backup) — создание резервного архива из всех файлов, которые были изменены после предыдущего полного резервирования.
• Выборочное резервирование (Selective backup) — создание резервного архива только из отобранных файлов.

По способу доступа к носителю

• Оперативное резервирование (Online backup) — создание резервного архива на постоянно подключенном (напрямую или через сеть) носителе.
• Автономное резервирование (Offline backup) — хранение резервной копии на съёмном носителе, кассете или картридже, который перед использованием следует установить в привод.

Правила работы с системами резервного копирования

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

• Предварительное планирование. В процессе планирования должны учитываться все компоненты инфраструктуры резервного копирования, а все приложения, сервера и тенденции увеличения ёмкости первичных хранилищ данных не должны оставаться без внимания.
• Установление жизненного цикла и календаря операций. Все задания, связанные с резервным копированием, должны быть задокументированы и выполняться согласно расписанию. Ниже приведён список задач, выполнять которые необходимо ежедневно:
  • мониторинг заданий;
  • отчёты о сбоях и успешном выполнении;
  • анализ и разрешение проблем;
  • манипуляции с лентами и управление библиотекой;
  • составление расписания выполнения заданий.
• Ежедневный обзор логов процесса резервного копирования. Поскольку каждый сбой в создании резервных копий может повлечь за собой множество затруднений, проверять ход процесса копирования нужно, по меньшей мере, каждый день.
• Защита базы данных резервного копирования или каталога. Каждое приложение резервного копирования ведёт свою базу данных, потеря которой может означать утрату резервных копий.
• Ежедневное определение временного окна резервного копирования. Если время выполнения заданий начинает выходить за пределы отведённого временного окна, это является признаком приближения к предельной ёмкости системы или наличия слабых звеньев в производительности. Своевременное обнаружение таких признаков может избавить от последующих более крупных сбоев системы.
• Локализация и сохранение «внешних» систем и томов. Необходимо лично проверять соответствие резервных копий своим ожиданиям, в первую очередь полагаясь на сови наблюдения, а не на отчёты программ.
• Максимально возможная централизация и автоматизация резервного копирования. Сведение множества задач по резервированию в одну значительно упрощает процесс создания копий.
• Создание и поддержка открытых отчётов, отчётов об открытых проблемах. Наличие журнала нерешённых проблем может способствовать скорейшему их устранению, и, как следствие, оптимизации процесса резервного копирования.
• Включение резервного копирования в процесс контроля изменений системы.
• Консультации с вендорами. Следует убеждаться, что внедрённая система полностью соответствует ожиданиям организации.

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

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

Резервное копирование с использованием SAN

Применение Сеть хранения данных SAN позволяет полностью перенести трафик резервного копирования с локальной сети на сеть хранения. Существует два варианта реализации: без загрузки локальной сети, или внесетевое копирование (LAN-free backup), и без участия сервера, или внесерверное копирование (Server-free backup).

Внесетевое копирование

При внесетевом копировании данные с диска на ленту и обратно передаются внутри SAN. Исключение сетевого сегмента из пути резервного копирования данных позволяет избежать излишних задержек на передачу трафика через сеть IP и платы ввода-вывода. Нагрузка локальной сети падает, и резервное копирование можно проводить практически в любое время суток. Однако пересылку данных выполняет сервер, подключенный к SAN, что увеличивает нагрузку на него. Благодаря протоколу Fibre Channel с помощью одного оптического кабеля может быть организовано несколько каналов передачи данных. При этом весь объем резервируемых данных с backup-серверов хранения направляется на ленточное устройство, минуя локальную сеть. В этом случае локальная сеть необходима лишь для контроля работы самих backup-серверов со стороны главных серверов. Таким образом, только небольшой объем метаданных, которые содержат информацию о резервируемых данных, передается по локальной сети. Главные серверы отвечают в целом за политику резервного копирования данных в своем сегменте или зоне ответственности. Все backup-серверы по отношению к главному серверу являются клиентами. Считается, что рассматриваемый метод резервного копирования может максимально задействовать пиковую полосу пропускания Fibre Channel.

В качестве протокола, применяемого для передачи данных между серверами и библиотеками, могут использоваться как SCSI поверх Fibre Channel, так и IP поверх Fibre Channel, тем более что большинство FC-адаптеров и FC-концентраторов работают одновременно с обоими протоколами (IP и SCSI) на одном Fibre Channel-канале.

Внесерверное копирование

Данный тип резервного копирования представляет собой дальнейшее развитие метода внесетевого копирования (LAN-free), поскольку уменьшает количество процессоров, памяти, устройств ввода-вывода, задействованных в этом процессе. Данный процесс архивирует разделы целиком, в отличие от пофайлового архивирования, но при этом позволяет восстанавливать отдельные файлы. По определению, при вне-серверном копировании данные копируются с диска на ленту и обратно без прямого участия сервера. Поскольку для резервного копирования требуется наличие некоторого дополнительного третьего узла, полностью отвечающего за процесс копирования, то отсюда происходит и другое название этого подхода — копирование с участием третьей стороны (Third_-Party Copy, 3PC). Так, в качестве подобного оборудования может использоваться маршрутизатор хранилищ данных, который берет на себя функции, ранее выполнявшиеся сервером.

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

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

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

Современные дисковые массивы обладают средствами создания копий данных внутри самого массива. Данные, созданные этими средствами, носят название Point-In-Time (PIT)-копий, т. е. фиксированных на определенный момент времени. Существует две разновидности средств создания PIT-копий: клонирование и «моментальный снимок» (snapshot). Под клонированием обычно понимают полное копирование данных. Для него требуется столько же дискового пространства, как и для исходных данных, и некоторое время. При использовании такой копии нет нагрузки на дисковые тома, содержащие исходные данные. Иными словами, нет дополнительной нагрузки на дисковую подсистему продуктивного сервера.

Механизм работы «моментальных снимков» иной и может быть реализован как программно на продуктивном сервере, так и аппаратно внутри массива. В момент, когда необходимо начать резервное копирование, программа-агент дает команду приложению завершить все транзакции и сохранить кэш-память на диск. Затем создается виртуальная структура — snapshot, представляющая собой карту расположения блоков данных, которую ОС и другое ПО воспринимает как логический том. Приложение прерывает стандартный режим работы на короткое время, необходимое для сохранения данных. После этого приложение продолжает работать в стандартном режиме и изменять блоки данных, при этом перед изменением старые данные блока с помощью драйвера snapshot копируются в область кэш-памяти snapshot и в карте расположения блоков данных указывается ссылка на новое местоположение блока. Таким образом, карта snapshot всегда указывает на блоки данных, полученные на момент завершения транзакций приложением. Блоки данных, которые не были изменены, хранятся на прежнем месте, а старые данные измененных блоков — в области кэш-памяти snapshot. Программа-агент копирует непротиворечивые данные, полученные на момент завершения транзакций приложением, осуществляя доступ к ним через драйвер snapshot, т. е. используя карту расположения блоков. Создание копий с помощью «моментальных снимков» экономит дисковое пространство, но создает дополнительную нагрузку на дисковую подсистему продуктивного сервера. Какой из методов создания PIT-копий выбрать, решается на этапе проектирования системы резервного копирования, исходя из бизнес-требований, предъявляемых к системе.

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

Как правило, резервное копирование происходит автоматически. Для доступа к данным обычно требуются повышенные привилегии. Так что процесс, обеспечивающий резервное копирование, запускается из-под учетной записи с повышенными привилегиями — вот тут-то и закрадывается определенный риск. Читать статью Система резервного копирования (безопасность).

Мировой рынок систем резервного копирования

Согласно анализу проведенному аналитической компанией IDC в начале осени 2008 года рынок (впрочем как и большинство сфер и услуг в области IT) значительно вырос, благо как и прибыли компаний, специализирующихся на производстве средств защиты информации. Читать статью «Резервное копирование данных (мировой рынок)»

Российский рынок систем резервного копирования

Читать статью «Резервное копирование данных (рынок России)»

Примеры систем резервного копирования

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

Смотрите также

Примечания

Системы резервного копирования / Habr

Несколько месяцев назад начал заниматься/разбираться в системах резервного копирования. Все полезные доки/ссылки я сохраняю у себя в заметках.
Много чего накопилось, решил поделиться записями, полезными ссылками и личным опытом.

Наиболее респостраненные ошибки при организации резервного копировани баз данных (взято с citrin.ru/backup.html)

— Эти принципы применимы не только к базам данных, но и к резервному копированию в целом.
Отрывок из книги PostgreSQL. Руководство разработчика и администратора. Гешвинде, Шениг В основном при работе с сервером баз данных допускают шесть ошибок:

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

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

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

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

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

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

Полезные ссылки:
www.ibm.com/developerworks/ru/library/l-backup/index.html — Автоматизация резервного копирования в Linux
www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/backup-basics.html — Основы технологии резервного копирования

ru.wikipedia.org/wiki/Список_ПО_для_резервного_копирования
en.wikipedia.org/wiki/Rsync
rsync.samba.org/examples.html
www.fredshack.com/docs/rsync.html
everythinglinux.org/rsync
howtoforge.org/rsync_incremental_snapshot_backups
www.mikerubel.org/computers/rsync_snapshots

www.debianhelp.co.uk/backup.htm
www.linux-backup.net

Мой выбор:
FlexBackup
flexbackup.sourceforge.net
gentoo-wiki.com/HOWTO_Backup — очень толковая дока, что делать и как.

Умеет differential\incrimental\full backups за что и была выбрана.
Синтаксис очень гибкий, маски включений\исключений. Широкий выбор архиваторов.
Тоолза позиционируется как бекап система для одиночных хостов (это мне и нужно.)

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

Таким образом:
#monthly full backup
30 2 1 * * flexbackup -set all -full
#daily differential backups
0 5 2-31/3 * * flexbackup -set all -differential

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

Чтобы бекапов не накапливалось слишком много, но были как минимум бекапы за текущий и предыдущий месяц:
# Deleting all backups older then 60 days
30 1 1 * * find /mnt/backups/`hostname -s`/flexbackup.0/ -name "*.tar" -a -mtime +60 -delete

Разумеется, что в flexbackup.conf указано сохранять файлы в данную директорию (/mnt/backups/`hostname -s`/flexbackup.0/), а также выставлен тип бекапов «tar»

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

Внимание:
Это все писалось и тестировалось на Linux. На FreeBSD данная система тоже работает, но как минимум в скрипты везде нужно указывать переменные окружения PATH.

Централизованное резервное копирование данных Windows и *nix серверов средствами Bacula / Habr

Приветствую всех хаброжителей!

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

Думаю вполне резонным будет предположение, что данная тема уже набила оскомину, но все же я рискну поделиться своим опытом. На суд читателя будет представлена клиент-серверная реализация схемы резервного копирования. В качестве инструмента я выбрал open source проект Bacula. По более чем полугодовому опыту его использования остаюсь доволен своим выбором.

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

Под хабракатом я опишу все демоны подробно

В моем случае резервному копированию подлежат:

1. Конфигурационные файлы различных демонов со всех серверов.
2. MySQL базы данных.
3. Документооборот с файлового сервера Windows.
4. Различные важные данные с nix серверов(движки сайтов/форумов, etc..)

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

Система резервирования данных Bacula состоит из четырёх основных элементов: Director Daemon, Storage Daemon, File Daemon и Bacula Console. Все эти элементы реализованы в виде самостоятельных приложений.

Director Daemon (DD) – это центральный элемент системы, осуществляющий управление её остальными компонентами. В его задачи входит управление процессом резервирования/восстановления данных, обеспечение интерфейса управления для администраторов и многое другое. Говоря проще – это диспетчер, который инициирует все процессы и отслеживает ход их выполнения.

Storage Daemon (SD) – приложение, отвечающее за чтение/запись данных непосредственно на устройства хранения информации. Принимает управляющие команды от DD, а также резервируемые данные от/к File Daemon.

File Daemon (FD) – этот элемент ещё можно назвать Агентом. Ведь именно он работает в рамках операционной системы, данные которой необходимо резервировать. File Daemon выполняет всю рутину, осуществляя обращение к резервируемым файлам и их дальнейшую передачу к SD. Также на стороне FD выполняется шифрование резервных копий, если это определено конфигурацией.

Bacula Console (BC) – интерфейс администратора сиcтемы. По своей сути, это командный интерпретатор для управления Bacula. Строго говоря, Bacula Console может быть расширена с помощью графических систем управления, которые, как правило, являются всего лишь надстройкой над BC. К таким системам можно отнести Tray Monitor и Bat. Первая устанавливается на компьютере администратора системы и осуществляет наблюдение за работой системы резервирования, а вторая обеспечивает возможность управления посредством графического интерфейса.

Bacula Catalog – база данных, в которой хранятся сведения обо всех зарезервированных файлах и их местонахождении в резервных копиях. Каталог необходим для обеспечения эффективной адресации к требуемым файлам. Поддерживаются MySql, PostgreSql и SqLite.
Такое структурное деление позволяет организовать очень гибкую систему резервирования, когда Storage Daemon разворачивается на выделенном сервере с несколькими устройствами хранения данных. Также Bacula Director может управлять несколькими экземплярами SD, обеспечивая резервирование части данных на одно устройство хранения, а части – на другое.

Теперь, когда у читателя сформировалось представление о работе демонов Bacula, я перейду к описанию того, как я реализовал всю эту красоту у себя.
В качестве аппаратного обеспечения для DD, SD и Bacula Catalog у меня выступает PC со следующими характеристиками

Устройство	Модель	количество	Емкость/Частота
HDD	Hitachi HDS723020BLA642	3	2Tb
CPU	AMD Phenom(tm) II X4 970 Processor	1	3500 Mhz
Motherboard	Gigabyte GA-880GA-UD3H	1	—
RAM			3541 Mb

О используемых на сервере ОС и версиях ПО

# lsb_release -a
LSB Version:    :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch
Distributor ID:    CentOS
Description:    CentOS release 5.7 (Final)
Release:    5.7
Codename:    Final

# uname -a
Linux backupsrv.domain.ru 2.6.18-274.7.1.el5PAE #1 SMP Thu Oct 20 17:03:59 EDT 2011 i686 athlon i386 GNU/Linux

# rpm -qa |grep -E "syslog-ng|bacula|mysql-ser" 
bacula-libs-5. 0.3-1
syslog-ng-2.1.4-9.el5
bacula-mysql-5. 0.3-1
mysql-server-5. 0.77-4.el5_6.6

Хранением данных занимаются несколько software(mdadm) RAID массивов.
Под систему три партиции на трех дисках, грузится можно с любого из них, под бекапы один массив из двух партиций.

Имя массива	из каких партиций	точка монтирования	Файловая система	Уровень массива
md0	/dev/sda1,/dev/sdb1,/dev/sdc1	boot	ext2	1
md1	/dev/sda2,/dev/sdb2,/dev/sdc2	/	ext3	1
md2	/dev/sda3,/dev/sdb3	/backup	ext4	1

Всего у меня сконфигурированы 19 клиентов Bacula, но подробно я остановлюсь на описании бекапа сервера биллинга и документов с файлового сервера Windows. Фокус на эти два сервера обусловлен тем, что остальные клиенты настроены аналогично, и на примере этих серверов-клиентов можно строить свои конфигурации.

Резервное копирование сервера биллинга это, по сути, бекап базы данных mysql и конфигурационных файлов демонов.
BD позволяет выполнять локальный скрипт на клиенте как до, так и после задания.
Каждую ночь, при старте задания на бекап сервере, запускается локальный(на самом сервере биллинга) скрипт, который создает архив базы биллинга, далее этот архив забирает BD и помещает на соответствующий пул томов(на самом деле операциями с чтением/записью управляет SD, но это сейчас не важно). Сразу же после выполнения задания запускается еще один скрипт, который в свою очередь, перемещает созданный архив в отдельную папку на сервере биллинга, для пущей надежности. Таким образом архив БД будет как у Bacula, так и локально на сервере биллинга(да, я параноик). Подробнее эти механизмы и скрипты будут описаны ниже.

С файлового сервера Windows сохраняем весь необходимый документооборот. В воскресенье создается Full бекап, каждый последующий день, с понедельника по субботу, Diff бекапы.

Теперь о конфигурационных файлах демонов Bacula. Начнем с самого объемного — bacula-dir.conf.
Файлы конфигурации всех демонов Bacula состоят из описаний, так называемых, ресурсов. Каждый из ресурсов характеризует определенный функционал демона.
Я буду комментировать каждую строчку в конфиге, поэтому далее будут следовать блоки-ресурсы файлов Bacula(bacula-dir.conf, bacula-sd.conf, bacula-fd.conf), если что-то нужно объяснить более подробно укажите это в комментариях.
Ресурс Dirtector

Director { 
  # имя bacula director'а
  Name = backupsrv.domain.ru-dir 
  # какой порт слушать, у нас default
  DIRport = 9101 
  # путь к скрипту, где лежат sql запросы для работы с Bacula Catalog(mysql database)
  QueryFile = "/usr/lib/bacula/query.sql" 
  # здесь хранятся статус файлы демона
  WorkingDirectory = "/backup/bacula-work/" 
  # pid файл демона
  PidDirectory = "/var/run" 
  # сколько заданий может запускаться одновременно
  Maximum Concurrent Jobs = 1 
  # пароль для доступа в BC и управления демонами 
  Password = "bacula_paS$w0rD10*" 
  # куда слать mail'ы, описано в ресурсе Messages
  Messages = Daemon 
  # на какой адрес биндится процессу
  DirAddress = 10.1.19.2 
} 

Ресурс catalog, описываем подключение к БД

Catalog {
  Name = MyCatalog
  dbname = "bacula"; dbuser = "bacula"; dbpassword = "edsfweo8vhwpe"
}

Ресурс Messages

Messages {
  # это имя прописано в ресурсе Director, помните?
  Name = Daemon
  # команда для отправки email
  mailcommand = "/usr/sbin/bsmtp -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r" 
  # шлем все на майл админам(root алиас на [email protected]) 
  # высылаются только алярмы, ероры и прочую важность
  mail = [email protected] = alert,error,fatal,terminate, !skipped 
  # что выводить на консоль                                                                                       
  console = all, !skipped, !saved
  # что в лог
  append = "/var/lib/bacula/log" = alert,error,fatal,terminate, !skipped
}

Для каждого клиента в заданиях указаны Pool и Storage.
Pool, извините за тавтологию, это пул томов(volume) на который размещаются резервные копии данных клиентов. У меня тома — это файлы в формате bacula, размещенные на software raid массиве. Для разных клиентов могут быть определены разные пулы томов. К примеру у меня созданы 6 пулов, для разных типов клиентов. В примере ниже описан лишь один из них, для данных биллинга.
Storage описывает какие физические устройства будут использованы в качестве томов.
(Storage BGB-ST описан в конфиге SD)
Ресурс Pool

Pool {
  # имя пула, указывается в заданиях резервного копирования
  Name = bgb
  # тип пула, емнип  этой версии только такой поддерживается
  Pool Type = Backup #
  # повторно использовать тома(сначала пишет в 1-ый, потом в 2-ой,
  # потом 3-й, 3-й закончился - снова в 1-й) 
  Recycle = yes 
  # удалять записи из bacula catalog(из mysql базы бакулы)
  # старше нижеуказанных значений
  AutoPrune = yes 
  # период в течении которого информация о томах(volumes)
  # хранится в базе данных, по истечению периода эта информация
  # удаляется
  Volume Retention = 90 days 
  # максимальный объем тома     
  Maximum Volume Bytes = 100G 
  # максимальное количество томов в пуле
  Maximum Volumes = 3 
  # с каких символов начинается имя тома
  LabelFormat = "Vol" 
  } 

Ресурс Storage

Storage {
  # имя хранилища и пароль (о соответствии имен и паролей в разных конфигах
  # демонов Bacula, я расскажу позже)
  Name = BGB-F
  Password = "StoRage_PaSSw0rD" 
  # fqdn имя сервера
  Address = backupsrv.domain.ru 
  # порт оставляем стандартный
  SDPort = 9103 
  # имя девайса описанного в конфиге SD
  Device = BGB-ST 
  # у нас все пишется на софтовый рэйд в файлы собственного формата       
  # bacula(например /backup/bgbilling/Vol0001)
  Media Type = File 
} 

Задание на примере бекапа базы данных биллинга.
Ресурс Client

Client {
  # имя 
  Name = bgbilling-fd 
  # ip адрес клиента
  Address = 10.103.2.5
  # порт, который клиент слушает
  FDPort = 9102
  # имя mysql базы данных Bacula
  Catalog = MyCatalog
  # пароль для FD
  Password = "Fd_paSSw0rd" 
  # период в течении которого информация о файлах задания
  # хранится в базе данных, по истечению периода эта информация
  # удаляется(но не сами данные!!) 
  File Retention = 45 days 
  # тоже самое, только для самого задания
  Job Retention = 90 days 
  # удалять записи из каталога(бд mysql) старше вышеуказанных значений
  AutoPrune = yes 
} 

Само задание.
Ресурс Job

Job {
  # имя задания 
  Name = "BGBilling"
  # тип(backup or restore)
  Type = Backup 
  # уровень(полный, диференциальный или инкрементный)
  Level = Full 
  # имя клиента 
  Client=bgbilling-fd 
  # имя файл-сета(там рассказано что бекапить, а что не бекапить)
  FileSet="bgbilling-set" 
  # имя SD ресурса                            
  Storage = BGB-F 
  # имя пула(для разных клиентов разные пулы томов(volume) куда пишутся сами 
  # бекапы)
  Pool = bgb
  # скрипт запускающийся ДО выполнения задания (путь до скрипта  -
  # это путь НА КЛИЕНТЕ!)
  ClientRunBeforeJob = "/root/sh/before_bg_db_backup.sh" 
  # скрипт запускающийся ПОСЛЕ выполнения задания                                                          
  ClientRunAfterJob = "/root/sh/after_bg_db_backup.sh" 
  # имя ресурса messages, который будет использоваться для этого задания
  Messages = Standard
  # имя шедулера
  Schedule = "DaylyFullBGBilling" 
  # в этом файле содержится информация о том, какие файлы должны будут
  # востанавливаться, на каком вольюме находятся файлы,
  # где конкретно они находятся - это очень важные файлы, их нужно бэкапить
  Write Bootstrap = "/backup/bsr-files/bgbilling.bsr" 
} 

Я обещал подробнее остановиться на скриптах выполняющихся до и после задания.
Скрипт до задания

$ sudo cat  /root/sh/before_bg_db_backup.sh
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
mysql -e "flush tables with read lock" --user=root --password="ololo" bgbilling
lvcreate -L20G -s -n backup_db   /dev/BGB-LVM1/billing_db
mysql -e "unlock tables" --user=root --password="ololo" bgbilling
mount /dev/BGB-LVM1/backup_db  /backup
tar -czf  /usr/backups/`date +%Y-%m-%d_%H-%M`.bgb.tgz /backup/bgbilling/
umount /backup
lvremove -f /dev/BGB-LVM1/backup_db

Скрипт после задания

$ sudo cat  /root/sh/after_bg_db_backup.sh
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
rm /usr/backups/after_run_bacula_backup/*
mv /usr/backups/*.tgz /usr/backups/after_run_bacula_backup/

Ресурс FileSet(что бекапим, а что нет)

FileSet {
  Name = "bgbilling-set" 
  Include {
    Options {
      # разработчики яро рекомендуют юзать это опцию, 
      # создается сигнатура забекапленных файлов в md5
      signature = MD5 
    }
    # перечисляем то, что нужно бекапить
    File = /usr/backups 
    File = /etc 
    File = /root/sh 
  }
  Exclude {
    # а это бекапить нет нужды
    File = /usr/backups/after_run_bacula_backup/* 
    File = /usr/backups/after_run_bacula_backup 
 }
} 

Расписание запуска задания.
Ресурс Schedule

Schedule {
  # имя расписания
  Name = "DaylyFullBGBilling" 
  # когда запускать задание
  Run = Full sun-sat at 1:10 
} 

Подробно комментировать ресурсы для резервного копирования документов с сервера Windows я не буду, приведу соответствующую часть конфига bacula-dir.conf полностью

Storage {                                                                                                                                                    
Name = WINDOWS-F                                                                                                                                             
                                                                                                                                                             
Address = backupsrv.domain.ru       # N.B. Use a fully qualified name here                                                                                  
SDPort = 9103                                                                                                                                                
Password = "StoRage_PaSSw0rD"                                                                                                                                
Device = WINDOWS-ST                                                                                                                                          
                                                                                                                                                             
Media Type = File                                                                                                                                            
}                                                                                                                                                            
                                                                                                                                                             
Pool {                                                                                                                                                       
Name = windows                                                                                                                                               
                                                                                                                                                             
Pool Type = Backup                                                                                                                                           
Recycle = yes                       # Bacula can automatically recycle Volumes                                                                               
AutoPrune = yes                     # Prune expired volumes                                                                                                  
Volume Retention = 60 days                                                                                                                                   
Maximum Volume Bytes = 30G          # Limit Volume size to something reasonable                                                                              
Maximum Volumes = 5                # Limit number of Volumes in Pool                                                                                         
LabelFormat = "Vol-Windows"                                                                                                                                  
                                                                                                                                                             
}                            
                                                                                                                         
Job {                                                                                                                                                        
  Name = "centra-bdk"                                                                                                                                        
  Type = Backup                                                                                                                                              
  Level = Full                                                                                                                                               
  Client= centra-bdk-fd                                                                                                                                      
  FileSet="centra-bdk-fd-fs"                                                                                                                                 
  Storage = WINDOWS-F                                                                                                                                        
  Pool = windows                                                                                                                                             
  Messages = Standard                                                                                                                                        
  Schedule = "Windows_Centra-bdk"                                                                                                                            
  Write Bootstrap = "/backup/bsr-files/centra-bdk.bsr"                                                                                                       
}                                                                                                                                                            
                                                                                                                                                             
                                                                                                                                                             
FileSet {                                                                                                                                                    
  Name = "centra-bdk-fd-fs"                                                                                                                                  
  Include {                                                                                                                                                  
    Options {                                                                                                                                                
      signature = MD5                                                                                                                                        
      Compression=GZIP                                                                                                                                       
    }      
    # обратите внимание на двойной бекслэш и ковычки!                                                                                                                                                  
    File = "D:\\Public\\!!!Абонентский\ Отдел"                                                                                                               
    File = "D:\\Public\\Отдел\ ИТ"                                                                                                                           
    File = "D:\\Public\\tex\\Maps"                                                                                                                 
    File = "D:\\Public\\сервис\ мены "                                                                                                                       
    File = "D:\\Public\\Отдел\ продаж1"                                                                                                                      
}                                                                                                                                                            
Exclude {                                                                                                                                                    
    File = "*.mp3"                                                                                                                                           
    File = "*.avi"                                                                                                                                           
    File = "*.wmv"                                                                                                                                           
 }                                                                                                                                                           
}                                                                                                                                                            
                                                                                                                                                             
                                                                                                                                                             
                                                                                                                                                             
Client {                                                                                                                                                     
  Name = centra-bdk-fd                                                                                                                                       
  Address = 10.1.19.50                                                                                                                                       
  FDPort = 9102                                                                                                                                              
  Catalog = MyCatalog                                                                                                                                        
  Password = "Fd_paSSw0rd"          # password for FileDaemon                                                                                                
  File Retention = 30 days            # 30 days                                                                                                              
  Job Retention = 2 months            # two months                                                                                                           
  AutoPrune = yes                     # Prune expired Jobs/Files                                                                                             
}                                                                                                                                                            
                                                                                                                                                             
Schedule {                                                                                                                                                   
Name = "Windows_Centra-bdk"                                                                                                                                  
Run = Level=Full on sun at 07:10                                                                                                                             
Run = Level=Differential on mon-sat at 22:15                                                                                                                 
} 

Конфигурационный файл BD на этом завершен. Переходим к конфигурации SD — описанию файла bacula-sd.conf

Ресурс Storage

Storage { 
  # имя для SD
  Name = backupsrv.domain.ru-sd 
  # порт стандартный
  SDPort = 9103 
  # рабочая директория процесса(для статус файлов)
  WorkingDirectory = "/var/lib/bacula" 
  # pid будет здесь
  Pid Directory = "/var/run/bacula" 
  # биндится на этом ip
  SDAddress = 10.1.19.2 
} 

Ресурс Director(связь с BD описанном в конфиге bacula-dir.conf)

Director {
  # имя DD, того самого, который был описан ранее
  Name = backupsrv.domain.ru-dir 
  # пароль  
  Password = "StoRage_PaSSw0rD" 
} 

Начинается описание различных девайсов, всего у меня используется 4 разных девайса. Я приведу в качестве примера два, для биллинга и для Windows.
Ресурс Device для биллинга.

Device {
  # имя,  о соответствии имен и паролей будет сказано ниже
  Name = BGB-ST 
  # тип
  Media Type = File 
  # директория где лежат файлы этого устройства(тома, volumes)  
  Archive Device = /backup/bgbilling 
  # новые тома будут обзываться согласно настроек Pool'а(здесь Vol*) см. 
  # конфиг DD
  LabelMedia = yes;
  # для устройства типа File должно быть так
  Random Access = Yes; 
  # если устройство открыто, использовать его
  AutomaticMount = yes;
  # думаю понятно =)
  RemovableMedia = no; 
  # открывать только тогда, когда стартует соответствующие задание
  AlwaysOpen = no; 
} 

Ресурс Device для файлового сервера Windows

Device {                                                                                                                                                     
  Name = WINDOWS-ST                                                                                                                                          
  Media Type = File                                                                                                                                          
  Archive Device = /backup/windows                                                                                                                           
  LabelMedia = yes;                                                                                                                                          
  Random Access = Yes;                                                                                                                                       
  AutomaticMount = yes;                                                                                                                                      
  RemovableMedia = no;                                                                                                                                       
  AlwaysOpen = no;                                                                                                                                           
}  

Ресурс Messeges.

Messages { 
 # имя
 Name = Standard 
 # отправлять  DD = имя директора  = слать все                       
 director = backupsrv.domain.ru-dir = all 
} 

Конфигурационный файл bconsole.conf, доступ в консоль Bacula.

 
Director {
  Name = backupsrv.ray-com.ru-dir
  DIRport = 9101
  address = 10.1.19.2
  Password = "bacula_paS$w0rD10*"
}

Не забудьте создать соответствующие Storage папки и назначить bacula владельцем этих папок.
Совет из комментариев

@/usr/local/etc/bacula/client.conf

@/usr/local/etc/bacula/job.conf

@/usr/local/etc/bacula/pool.conf

@/usr/local/etc/bacula/fileset.conf
Конфиги можно разделить на разные файлы,
Options { signature = MD5 compression = GZIP }
и включить компрессию.

Конфигурирование серверной части завершено.

Конфиг клиента.

Важно отметить, что каждый из клиентов должен резолвить fqdn имя сервера в его ip адрес! Обеспечте это средствами dns или пропишите в hosts!

Ресурс Director.

Director {
# имя BD
Name = backupsrv.domain.ru-dir
# пароль для доступа к BD к клиенту(указан в ресурсе Client у BD)
Password = "Fd_paSSw0rd"
}
Ресурс FileDaemon
FileDaemon { 
# имя клиента
Name = bgbilling-fd
# слушаем порт 9102
FDport = 9102 
WorkingDirectory = /usr/lib/bacula
Pid Directory = /var/run/bacula
FDAddress = 10.103.2.5
}

Ресурс Messeges
Messages {
Name = Standard
director = backupsrv.domain.ru = all, !skipped, !restored
append = "/var/bacula/log" = all, !skipped
}

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

Для мониторинга и востановления ваших резервных копий удобно использовать утилиту bat.
В Ubuntu она ставиться так

# sudo aptitude install bacula-console-qt

В портажах Gentoo я её не нашел, поэтому собирал из исходников.
Конфигурационный файл bat.conf полностью аналогичен bconsole.conf, приведенному ранее.
Итак, к примеру я хочу востановить архив базы данных биллинга за определенное число. Алгоритм, которым пользуюсь я, таков:
1. Открываем bat и находим нужное задание

2. вводим команду list files jobid=3059 для того чтобы убедиться что в задании есть нужные файлы

3. Теперь переходим в консоль(мне так удобнее просто=)). В консоли я восстановлю архив биллинга на другого клиента

$ sudo bconsole
[sudo] password for onotole: 
Connecting to Director 10.1.19.2:9101
1000 OK: backupsrv.domain.ru-dir Version: 5.0.3 (30 August 2010)
Enter a period to cancel a command.
*restore
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog" 

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of comma separated JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Select backup for a client before a specified time
     7: Enter a list of files to restore
     8: Enter a list of files to restore before a specified time
     9: Find the JobIds of the most recent backup for a client
    10: Find the JobIds for a backup for a client before a specified time
    11: Enter a list of directories to restore for found JobIds
    12: Select full restore to a specified Job date
    13: Cancel
Select item:  (1-13): 9
Defined Clients:
     1: 192.168.15.12-fd
     2: 1.1.1.1-fd
     3: 1.1.1.75-fd
     4: ASTERISK-configs-fd
     5: DHCPD-configs-fd
     6: GW1-configs-fd
     7: GW2-configs-fd
     8: NAS-20-configs-fd
     9: NAS-21-configs-fd
    10: NAS-6-configs-fd
    11: NAS-ololo-configs-fd
    12: NS_AND_MAIL-configs-fd
    13: RADIUS-ololo-configs-fd
    14: VIRTSRV1-configs-fd
    15: bgbilling-fd
    16: configs-fd
    17: domain.ru-fd
    18: mydomain.ru-fd
    19: tv.domain.ru-fd
    20: zabbix.domain.ru-fd
Select the Client (1-20): 15
Automatically selected FileSet: bgbilling-set
+-------+-------+----------+----------------+---------------------+------------+
| JobId | Level | JobFiles | JobBytes       | StartTime           | VolumeName |
+-------+-------+----------+----------------+---------------------+------------+
| 3,292 | F     |    1,666 | 10,874,552,420 | 2011-12-19 02:31:08 | Vol0014    |
+-------+-------+----------+----------------+---------------------+------------+
To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of comma separated JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Select backup for a client before a specified time
     7: Enter a list of files to restore
     8: Enter a list of files to restore before a specified time
     9: Find the JobIds of the most recent backup for a client
    10: Find the JobIds for a backup for a client before a specified time
    11: Enter a list of directories to restore for found JobIds
    12: Select full restore to a specified Job date
    13: Cancel
Select item:  (1-13): 12
Enter JobId to get the state to restore: 3059
Selecting jobs to build the Full state at 2011-12-06 02:28:47
You have selected the following JobId: 3059

Building directory tree for JobId(s) 3059 ...  +++++++++++++++++++++++++++++++++++++++++++++
1,535 files inserted into the tree.

You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the "all" keyword on the command line.
Enter "done" to leave this mode.

cwd is: /
$ ls
etc/
root/
usr/
$ ls usr
usr/
$ mark usr 
1,667 files marked.
$ done
Bootstrap records written to /backup/bacula-work//backupsrv.domain.ru-dir.restore.8.bsr

The job will require the following
   Volume(s)                 Storage(s)                SD Device(s)
===========================================================================

    Vol0010                   BGB-F                     BGB-ST                   

Volumes marked with "*" are online.

1,667 files selected to be restored.

Run Restore job
JobName:         restore
Bootstrap:       /backup/bacula-work//backupsrv.domain.ru-dir.restore.8.bsr
Where:           /usr/restore
Replace:         always
FileSet:         bgbilling-set
Backup Client:   bgbilling-fd
Restore Client:  bgbilling-fd
Storage:         BGB-F
When:            2011-12-26 15:01:38
Catalog:         MyCatalog
Priority:        10
Plugin Options:  *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
     1: Level
     2: Storage
     3: Job
     4: FileSet
     5: Restore Client
     6: When
     7: Priority
     8: Bootstrap
     9: Where
    10: File Relocation
    11: Replace
    12: JobId
    13: Plugin Options
Select parameter to modify (1-13): 5
The defined Client resources are:
     1: bgbilling-fd
     2: GW1-configs-fd
     3: GW2-configs-fd
     4: NAS-6-configs-fd
     5: NAS-20-configs-fd
     6: NAS-21-configs-fd
     7: NAS-ololo-configs-fd
     8: DHCPD-configs-fd
     9: ASTERISK-configs-fd
    10: NS_AND_MAIL-configs-fd
    11: VIRTSRV1-configs-fd
    12: mydomain.ru-fd
    13: tv.domain.ru-fd
    14: domain.ru-fd
    15: 1.1.1.1-fd
    16: 1.1.1.75-fd
    17: zabbix.domain.ru-fd
    18: 192.168.15.12-fd
Select Client (File daemon) resource (1-18): 2
Run Restore job
JobName:         restore
Bootstrap:       /backup/bacula-work//backupsrv.ray-com.ru-dir.restore.8.bsr
Where:           /usr/restore
Replace:         always
FileSet:         bgbilling-set
Backup Client:   bgbilling-fd
Restore Client:  GW1-configs-fd
Storage:         BGB-F
When:            2011-12-26 15:01:38
Catalog:         MyCatalog
Priority:        10
Plugin Options:  *None*
OK to run? (yes/mod/no): yes
Job queued. JobId=3453
You have messages.
*

4. Ждем успешного выполнения задания, статус можно отслеживать в том же bat

Еще несколько скриншотов

Благодарю всех кто дочитал мой опус до конца.
В качестве завершения позволю себе еще несколько советов.
Важно не только делать бекапы и отслеживать что они выполнились без ошибок, но так же и регулярно их разворачивать и проверять. Подобная практика даёт еще +100 к указанным в начале спокойствию, крепкости нервов и здоровью. Так же очень хорошей практикой является регулярное резервное копирование базы данных bacula и bsr файлов.

С наступающим Новым Годом вас!!!

Использованые источники:

1. www.ibm.com/developerworks/ru/library/l-Backup_4
2. www.bacula.org/en/?page=documentation

Правило резервного копирования «3-2-1». Часть 1 / Veeam Software corporate blog / Habr

Считается, что бэкап-правило «3-2-1» впервые описал Peter Krogh в своей книге «Управление цифровыми активами для фотографов». И это, наверное, неудивительно, так как потеря личного архива означает для профессионального фотографа полную катастрофу, и он просто обязан придерживаться такой стратегии резервного копирования, которая гарантировано защитит его от потери данных.

Итак, правило «3-2-1» гласит, что для обеспечения надежного хранения данных, необходимо иметь как минимум:

1. ТРИ резервные копии,
2. которые должны быть сохранены в ДВУХ различных физических форматах хранения,
3. причем ОДНА из копий, должна быть передана на внеофисное хранение

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

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

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

Почему копий нужно три, а не две? Потому что в реальной жизни, очень часто, угрозы двум копиям данных оказываются статистически зависимыми в силу логической организации процедуры резервного копирования. К примеру, рассмотрим RAID1 (или дисковый массив с «зеркалированием», см. подробнее пост «технологии дисковых снапшотов»). Если вирус заражает файл на одном диске массива, сразу же происходит заражение второй копии на зеркальном диске. Аналогично, если настроена репликация, то реплика мгновенно будет также испорчена вирусом. Даже, если просто выполняется ежедневное построение полной резервной копии, она также будет заражена, если администратор за день не заметит заражение исходных данных. В целом: двух копий будет не достаточно для восстановления информации во всех случаях, когда время выявления и реакции администратора на повреждение оригинальных данных превышает период между смежными задачами по копированию/реплицированию/зеркалированию этих данных.

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

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

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

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

При этом несомненным плюсом облачных провайдеров является то, что процесс резервного копирования значительно упрощается. Администратору не нужно покупать и настраивать сложное СХД или «возиться» со сменой лент. Часто облачное хранилище прозрачно расширяется по требованию клиента, то есть не имеет для него физического ограничения по размеру (ограничение для клиента скорее носит финансовый характер), что также имеет свои плюсы перед СХД, свободное место на которых может «внезапно» закончиться.

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

Всегда ли нужно жестко следовать правилу «3-2-1»? Нет, все зависит от стоимости ваших данных, с одной стороны, и критичности (стоимости потенциального ущерба) и вероятности угроз данным, с другой стороны. Любая защита не должна превышать по стоимости защищаемый объект. Поэтому, если у вас хранятся не особо ценные данные, или угрозы низко критичны или маловероятны — можно реализовывать правило «3-2-1» частично. Главное — все же составить матрицу угроз данным (то есть составить список всех возможных угроз, оценить их вероятность и критичность) и провести процесс их деактуализии (то есть у каждой угрозы либо написать в таблице либо «деактуализирована такой-то технической мерой» или «признать не актуальной с точки зрения характера бизнеса компании»). После проработки матрицы угроз, станет понятно в какой степени следует реализовывать правило 3-2-1, и какой в итоге потребуется бюджет.

Во второй части данной статьи будет рассказано как можно реализовать бэкап-правило «3-2-1» с помощью продукта Veeam Backup & Replication v7.

Ссылки:
1. Peter Krogh. «The DAM Book: Digital Asset Management for Photographers»

Резервное копирование для дома и малого офиса / Habr

Добрый день, уважаемые хабраюзеры.

Предисловие

На работе появилась нужда в создании резервных копий проектов, для этого было решено поставить сервер. На дорогой, качественный и стабильный сервер денег нет, поэтому пришлось взять обыкновенный двухъядерный компьютер, но при этом закупить 2 надёжных HDD и SmartUPS. Мы ведь хотим в случае перепада напряжения или отключения света, корректно завершить работу сервера, тем самым оставив наши данные в сохранности. С аппаратной частью мы определились, теперь немного о ПО, выбор пал на бесплатную программу Cobian Backup — эта программа удобная и интуитивно понятная. А теперь обо всём по подробнее.

Что я имею

Сервер: Core 2 Duo, 2ГБ ОЗУ, SmartUPS для сервера и 2 HDD для хранения бэкапа
2 клиента (2 рабочии станции, которые нуждаются в постоянном резервном копировании)

ПО

На сервере будет стоять Microsoft Windows XP Professional и Cobian Backup
На клиентах Microsoft Windows XP, Microsoft Windows 7 и Cobian Backup

Установка и настройка ПО

Предварительные настройки

Имена пользователей у клиентов будут User1 и User2, а у сервера — Admin
Резервные копии будут отправляться на сервер по локальной сети, настроим её. У сервера будет ip: 192.168.1.1, у первого клиента (User1) ip: 192.168.1.2, а у второго клиента (User2) ip: 192.168.1.3
Диск C:\ — первый диск на сервере, на нём установлена ОС и на нём будет хранится резервная копия.
Диск D:\ — второй диск на сервере, на нём будет зеркало резервной копии с первого диска C:\

Настройка сервера

Сначала создадим папки на диске C:\ следующим образом:
C:\backups\user1 — папка куда будут резервироваться проекты с первой рабочей станции
C:\backups\user2 — папка куда будут резервироваться проекты со второй рабочей станции

Для доступа к серверу по локальной сети, откроем общий доступ к этим папкам:

1. Перейдите в папку C:\
2. Нажмите правой кнопкой мыши на папку backups и выберете Свойства
3. Перейдите на вкладку Доступ и в разделе Сетевой общий доступ и безопасность, отметьте Открыть общий доступ к этой папке и Разрешить изменение файлов по сети
4. Применить и ОК

Установка и настройка Cobian Backup на сервер

Скачать эту программу можно с официального сайта Cobian Backup 11 (Gravity).

Приступим к установке:

1. Запустите скаченную программу
2. В первом диалоге выберете, Language — RUSSIAN, Далее
3. Прочтите соглашение и отметьте Я принимаю условия, Далее
4. Оставьте по умолчанию, Далее
5. В разделе Параметры службы выберете, Запускать под учётной записью Local System, Далее и на вопрос продолжения установки, Да
6. Установить
7. После завершения установки нажмите Готово

А теперь настроим нашу программу:

1. После установки программа запускается в свёрнутом режиме, в трее (в нижнем правом углу, значок вихря), чтобы открыть интерфейс программы нужно, два раза кликнуть левой кнопкой мыши по значку программы
2. В верху, чуть ниже заголовка программы, откройте Задание, найдите и выберете Новое задание
3. Активируйте раздел Общие, Имя задания: Резервное копирование на второй HDD, снимите галочку Делать отдельные копии с временными отметками
4. Тип копирования: Добавочный, то есть если файлы изменились, то произойдёт резервное копирование, изменившихся файлов, а если файлы не изменились, то копирования не будет
5. Раздел Файлы, в Источники добавляем Каталог: C:\backups, а в Пути назначения указываем второй диск D:\
6. Расписание можно настроить как угодно, меня устроит ежедневно в 13:10
7. Раздел Дополнительно будет последней настройкой на сервере, ставим галочки напротив: Синхронизация, Не копировать пустые каталоги и одну галочку уберём: Копировать с полными путями
8. Принять и можно закрыть программу крестиком

Настройка клиентов

Cobian Backup для работы по сети требует пароль для учётной записи (предположим, что у нас 1 пользователь и без пароля), поэтому создадим нового пользователя на клиентах:

Чтобы создать пользователя с паролем, зайдём в Учётные записи пользователей:

1. Одновременно нажать win+R, в появившейся диалог написать control userpasswords2 и нажать ОК
2. Активировать Требовать ввод имени пользователя и пароля (поставить галочку)
3. Нажать Добавить
4. Пользователь: backup, остальные поля можно оставить пустыми, Далее
5. Пароль: 1234 (можно придумать пароль по сложнее)
6. Уровень доступа: Обычный доступ (Группа «Пользователи»), Готово
7. В списке пользователей выберем пользователя без пароля (User1 или User2) и снимем галочку с Требовать ввод имени пользователя и пароля, применить
8. Появится диалог, Автоматический вход в систему, нажмите ОК и закройте Учётные записи пользователей

Установка и настройка Cobian Backup на рабочих станциях

Процесс установки Cobian Backup такой же как и на сервере, кроме 5 пункта:
В разделе Параметры службы выберете, Запускать под обычной учётной записью, Учётная запись: User1 (для первого клиента) и Пароль: 1234, Далее .

Настройка будет такая же как и на сервере кроме 3-х пунктов:
В разделе Общие, Имя задания: Резервное копирование на сервер, снимите галочку Делать отдельные копии с временными отметками.

В разделе Файлы, Источники добавляем нужные вам каталоги, а в Пути назначения нажать Добавить и выбрать Вручную: \\192.168.1.1\backup\user1, Принять.

Расписание, ежедневно в 13:00

Примечание:

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

Заключение

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

UPD.
Уважаемые, читатели, прошу не минусовать и понять всё-таки про что статья и почему именно так и никак иначе (прочтите мои комментарии).
Ну и всё-таки я новичок тут и не знаю что вы желаете видеть, а что нет. Тут вопрос не стоит что выбрать, а что нет, есть готовый/собранный компьютер-сервер и есть задача сделать резервное копирование.

А если ну вообще не нравится, лучше пройдите мимо, вместо того чтобы писать пустые комментарии и минусовать, ок?

Сравнение средств резервного копирования / Southbridge corporate blog / Habr

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

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

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

Rsync справился с тестовым набором данных за 4 минуты и 28 секунд, показав

такую нагрузку

Процесс восстановления уперся в ограничение дисковой подсистемы сервера хранения резервных копий (пилообразные графики). Также четко видно загрузку одного ядра без особых проблем (низкий iowait и softirq — нет проблем с диском и сетью соответственно). Поскольку две другие программы, а именно rdiff-backup и rsnapshot, основаны на rsync, а также предлагают в качестве средства восстановления обычный rsync, — у них будет примерно такой же профиль нагрузки и время восстановления резервной копии.

Tar справился чуть быстрее, за

2 минуты и 43 секунды:

Полная загрузка системы была выше в среднем на 20% из-за возросшего softirq — возросли накладные расходы при работе сетевой подсистемы.

Если архив дополнительно сжать, то время восстановления возрастает до 3 минут 19 секунд с

такой нагрузкой на основном сервере (распаковка на стороне основного сервера):

Процесс распаковки занимает оба процессорных ядра, поскольку работает два процесса. В целом — ожидаемый результат. Также сравнимый результат (3 минуты и 20 секунд) получился при запуске gzip на стороне сервера с резервными копиями, профиль нагрузки на основном сервере был весьма похожим на запуск tar без компрессора gzip (см. предыдущий график).

В rdiff-backup можно синхронизировать последнюю сделанную резервную копию с помощью обычного rsync (результаты будут аналогичными), но более старые резервные копии все равно надо восстанавливать с помощью программы rdiff-backup, которая справилась с восстановлением за 17 минут и 17 секунд, показав

такую нагрузку:

Возможно так и было задумано, во всяком случае для ограничения скорости авторы предлагают такое решение. Сам процесс восстановление резервной копии занимает чуть меньше половины одного ядра, с пропорционально сравнимой производительностью (т.е. в 2-5 раз медленнее) по диску и сети с rsync.

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

Burp с задачей восстановления резервной копии справился за 7 минут и 2 секунды с

такой нагрузкой:

Отработал достаточно быстро, и, по крайней мере, гораздо удобнее чистого rsync: не надо помнить какие-либо флаги, простой и интуитивный cli-интерфейс, встроенная поддержка нескольких копий, — правда раза в два медленнее. Если данные надо восстанавливать из последней сделанной резервной копии — можно воспользоваться rsync, с небольшими оговорками.

Примерно такую же скорость и нагрузку показала программа BackupPC при включении режима передачи rsync, развернув резервную копию за

7 минут и 42 секунды:

А вот в режиме передачи данных с tar BackupPC справился медленнее: за 12 минут и 15 секунд, нагрузка по процессору при этом была в целом ниже в полтора раза:

Duplicity без шифрования показал чуть лучшие результаты, справившись с восстановлением резервной копии за 10 минут и 58 секунд. Если активировать шифрование с помощью gpg — время восстановления возрастает до 15 минут и 3 секунд. Также при создании репозитория для хранения копий можно указать размер архива, который будет использован при разбиении потока входящих данных. В целом, на обычных жестких дисках, так же в связи с однопоточным режимом работы, особой разницы нет. Она, возможно, появится при разных размерах блоков, когда используются гибридные хранилища. Нагрузка на основном сервере при восстановлении была такой:без шифрования

с шифрованием

Duplicati показал сравнимую скорость восстановления, справившись за 13 минут и 45 секунд. Еще порядка 5 минут заняла проверка корректности восстановленных данных (суммарно около 19 минут). Нагрузка при этом была достаточно высокой:

Когда шифрование aes активировалось внутренними средствами, время восстановления составило 21 минуту 40 секунд, причем загрузка по процессору была максимальной (оба ядра!) во время восстановления; при проверке данных был активен только один поток, занимающий одно процессорное ядро. Проверка данных после восстановления заняла те же 5 минут (суммарно почти 27 минут).Результат

Чуть быстрее duplicati управился с восстановлением при использовании для шифрования внешней программы gpg, но в целом отличия от предыдущего режима — минимальны. Время работы составило 16 минут 30 секунд, с проверкой данных в 6 минут. Нагрузка была такой:

AMANDA, использующая tar, справилась за 2 минуты 49 секунд, что, в принципе, весьма близко к обычному tar. Нагрузка на систему в принципе такая же:

При восстановлении резервной копии средствами zbackup получились следующие результаты:шифрование, сжатие lzma

Время работы 11 минут и 8 секунд

шифрование aes, сжатие lzma

Время работы 14 минут

шифрование aes, сжатие lzo

Время работы 6 минут, 19 секунд

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

BorgBackup в режиме без шифрования справился чуть медленнее tar, за 2 минуты 45 секунд, однако, в отличие от того же tar, появилась возможность дедупликации репозитория. Нагрузка при этом получилась

следующей:

Если активировать шифрование на основе blake, то скорость восстановления резервной копии чуть замедляется. Время восстановления в этом режиме 3 минуты 19 секунд, а нагрузка вышла такая:

Шифрование aes работает чуть медленнее, время восстановления 3 минуты 23 секунды, нагрузка особо не поменялась:

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

Restic справился с восстановлением чуть помедленнее, время работы составило 4 минуты 28 секунд. Нагрузка при этом выглядела

так:

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

С помощью UrBackup получилось восстановить данные за 8 минут и 19 секунд, нагрузка при этом была

такой:

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

Выбор и обоснование критериев для сравнения

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

• Простота в работе
• Универсальность
• Стабильность
• Быстрота

Стоит рассмотреть каждый пункт отдельно более детально.

Простота работы

Лучше всего, когда есть одна кнопка «Сделать все хорошо», но если вернуться к реальным программам — удобнее всего будет некоторый привычный и стандартный принцип работы.
Большинству пользователей, вероятнее всего, будет лучше, если не надо запоминать кучу ключей для cli, настраивать кучу разных, зачастую малопонятных опций через web или tui, настраивать оповещения о неудачной работе. Сюда же относится возможность легко «вписать» решение для резервного копирования в существующую инфраструктуру, а также автоматизация процесса резервного копирования. Тут же возможность установки пакетным менеджером, или в одну–две команды вида «скачать и распаковать». curl ссылка | sudo bash — сложный метод, поскольку надо проверить, что прилетает по ссылке.

К примеру, из рассмотренных кандидатов простым решением является burp, rdiff-backup и restic, имеющие мнемонически запоминаемые ключи для разных режимов работы. Чуть более сложным — borg и duplicity. Самым сложным была AMANDA. Остальные по простоте использования где-то посередине. В любом случае, если надо больше 30 секунд на чтение руководства пользователя, или надо сходить в Google или другой поисковик, а также пролистать длинную простыню help — решение сложное, так или иначе.

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

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

Универсальность

Частично перекликается с предыдущим подразделом в части автоматизации, не должно быть особой проблемой «вписать» процесс резервного копирования в существующую инфраструктуру.
Стоит отметить, что использование нестандартных портов (ну кроме веб-интерфейса) для работы, реализация шифрования нестандартным способом, обмен данными нестандартным протоколом — признаки неуниверсального решения. По большей части все кандидаты так или иначе их имеют по очевидной причине: простота и универсальность обычно не совместимы. В качестве исключения — burp, есть и другие.

В качестве признака — возможность работы используя обычный ssh.

Скорость работы

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

Стабильность

Следует понимать так: с одной стороны, должна быть возможность развернуть обратно резервную копию по-любому, с другой — устойчивость к различным проблемам: обрыв сети, отказ диска, удаление части репозитория.

Сравнение средств резервного копирования

Легенда таблицы:

• Зеленый, время работы меньше пяти минут, или ответ «Да» (кроме столбца «Нужен клиент\сервер?»), 1 балл
• Желтый, время работы пять-десять минут, 0.5 балла
• Красный, время работы больше десяти минут, или ответ «Нет» (кроме столбца «Нужен клиент\сервер?»), 0 баллов

Согласно вышеприведенной таблице наиболее простым, быстрым, а вместе с тем удобным и мощным инструментом для резервного копирования является BorgBackup. Второе место занял Restic, остальные рассмотренные кандидаты разместились примерно одинаково с разбросом в один-два балла в конце.

Благодарю всех, кто дочитали цикл до конца, предлагаю обсудить варианты, предложить свои, если есть. По мере обсуждения таблица может быть дополнена.

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

Анонс

Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования
Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
Резервное копирование, часть 5: Тестирование bacula и veeam backup for linux
Резервное копирование: часть по просьбам читателей: обзор AMANDA, UrBackup, BackupPC
Резервное копирование, часть 6: Сравнение средств резервного копирования
Резервное копирование, часть 7: Выводы