Как составить расписание резервного копирования

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

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

Рекомендации по составлению расписания

Следующие рекомендации могут помочь вам в составлении “идеального” расписания резервного копирования для вашей системы.

• Планируйте выполнение полного резервного копирования в нерабочее время.Если ваша компания не поддерживает непрерывный цикл работы (по 24 часа 7 дней в неделю), то нерабочее время наиболее подходит для резервного копирования.
• Разбейте расписание резервного копирования на несколько дней.Если у вас большая база данных и вы не успеваете выполнить резервное копирование в заданное время, разбейте операцию резервного копирования на части. Вы можете за один раз выполнить резервное копирование файла или группы файлов определенной части базы данных. Через несколько дней у вас будет выполнено резервное копирование всех данных.
• Используйте разностное резервное копирование. Если у вас нет времени, чтобы выполнять полное резервное копирование каждую ночь, создавайте разностные резервные копии в течение недели, а полную резервную копию – в выходные дни.
• Выполняйте настройку плана резервного копирования.Каждая система отличается от других систем, и каждая компания – от других компаний. Разрабатывайте расписание резервного копирования, наиболее отвечающее вашим требованиям.

Практические советы.

Планирование операций резервного
копирования

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

• Небольшая система в условиях “8 на 5” (8-часовой рабочий день 5 дней в неделю). Этот тип системы обычно позволяет выполнять полное резервное копирование каждый вечер. Журнал транзакций, видимо, нужно копировать только раз в день (в зависимости от размера журнала транзакций и количества выполненных транзакций).
• Система среднего масштаба в условиях “24 на 7”. Система среднего масштаба, работающая в условиях “24 на 7” не позволяет выделить слишком много времени для резервного копирования. Однако в системе такого масштаба у вас, скорее всего, есть возможность выполнения резервного копирования в выходные дни. В следующей таблице показано, как может выглядеть расписание резервного копирования для компании среднего масштаба.

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

• Крупная система в условиях “24 на 7” В очень крупных системах может не оказаться возможности полного резервного копирования хотя бы в один из дней недели. Компромиссное решение – разбить полное резервное копирование на несколько дней, как это показано в следующей таблице. (В приведенном расписании полное резервное копирование выполняется за два дня – в субботу и воскресенье.)

  Понедельник	Разностное резервное копирование базы данных
  Вторник	Разностное резервное копирование базы данных
  Среда	Разностное резервное копирование базы данных
  Четверг	Разностное резервное копирование базы данных
  Пятница	Разностное резервное копирование базы данных
  Суббота	Полное резервное копирование групп файлов
  Воскресенье	Полное резервное копирование групп файлов
  Все дни	Резервное копирование журнала транзакций по необходимости

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

Улучшение характеристик
резервного копирования

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

Повышение производительности резервного копирования

Повышение производительности резервного копирования является важной темой, поскольку это позволяет сократить время, в течение которого снижается производительность SQL Server (из-за параллельного выполнения операции резервного копирования). Использование следующих методов поможет в повышении производительности резервного копирования и (в некоторых случаях), поможет также повысить производительность процесса восстановления. (О восстановлении базы данных см.
“Восстановление
и воспроизведение
базы данных”
.)

• Используйте несколько устройств резервного копирования. Использование нескольких устройств резервного копирования позволяет SQL Server выполнять некоторые операции резервного копирования параллельно. SQL Server осуществляет это путем распределения резервной копии между несколькими устройствами. Для этого SQL Server создает несколько потоков, исходя из количества файлов данных и количества устройств резервного копирования. Производительность резервного копирования также повышается за счет дополнительных потоков, используемых для записи на эти устройства. Параллельное выполнение операций снижает суммарное количество времени, необходимое для этих операций, особенно в многопроцессорной системе. Этот метод позволяет повысить производительность резервного копирования, а также процесса восстановления.
• Используйте несколько файлов данных в базе данных.Использование нескольких файлов данных меньшего размера вместо одного большого файла позволяет SQL Server выполнять значительную часть резервного копирования параллельно. Этот метод позволяет повысить производительность резервного копирования, а также процесса восстановления.
• Используйте несколько сегментов локальной сети для резервного копирования. Распределяя резервное копирование между несколькими сегментами локальной сети, вы можете увеличить долю пропускной способности сети, доступную для резервного копирования. Два сегмента локальной сети увеличивают пропускную способность вдвое по сравнению с одним сегментом, три сегмента – втрое, и т.д.
• Выполняйте резервное копирование поэтапно.Чтобы повысить производительность резервного копирования, вы можете выполнять резервное копирование на диск, а затем копировать файлы дисковой резервной копии на ленту. Этот метод повышает производительность, поскольку операции на диске выполняются быстрее, чем на ленте, и это позволяет вам держать несколько последних резервных копий на диске. Этот метод повышает производительность процесса восстановления только для файлов резервного копирования, оставшихся на диске.
• Используйте разностные резервные копии. Разностное резервное копирование повышает производительность каждого резервного копирования, но если вы используете его, то восстановление всей базы данных занимает намного больше времени (см.
  “Восстановление
  и воспроизведение
  базы данных”
  ). Если у вас недостаточно времени для полного резервного копирования, этот метод может стать для вашей системы наилучшим решением. Если восстановление данных требуется редко, то это, возможно, приемлемый компромисс.

Дополнительные рекомендации

Следующие рекомендации по выполнению резервного копирования, возможно, применимы, а возможно, неприменимы к вашим условиям.

• Сохраняйте резервные копии вне рабочего места. Если вы храните резервные копии вне рабочего места, то они, возможно, останутся целы после таких катастроф, как пожар или затопление водой. Данные резервных копий намного важнее, чем сами компьютерные системы.
• Проверяйте резервную копию. Резервная копия не будет вечно в хорошем состоянии. Ленты могут портиться, особенно если вы многократно используете одни и те же ленты. Проверяя резервную копию (хотя бы время от времени), вы будете знать, что лента в хорошем состоянии.
• Не используйте один и тот же носитель каждый день. Используя один и тот же носитель каждый день, вы не сможете восстановить данные, удаленные за несколько дней до вашей попытки восстановления. Чередуйте ленты с резервными копиями, чтобы иметь возможность восстановления информации хотя бы за несколько дней.
• Ведите запись того, как происходит резервное копирование. Вы должны документировать, как выполняется резервного копирования и как восстановить систему при необходимости. Помните, вы не всегда будете на месте, чтобы самому восстановить систему.
• Создавайте резервные копии системных таблиц. Не забывайте периодически выполнять резервное копирование системных баз данных, таких как master и msdb.

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

Заключение

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

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

Преимущества планового регулярного резервного копирования очевидны, хотя руководители многих компаний все еще сомневаются и не решаются вкладывать в это время и деньги. Раньше владельцы малого бизнеса возможно вполне резонно “шарахались” от стоимости достаточно сложных систем создания резервных копий. План разервного копирования является своего рода страховкой ваших данных (системы и программы обработки которых постоянно совершенствуются), и выплачиваемая вами “страховая премия” обычно несоизмерима с получаемым уровнем защиты. Имея в наличии современное сетевое хранилище данных (устройство NAS) и удобную в использовании профессиональную утилиту резервного копирования (например, R-Drive Image) создание и функционирование надлежащего плана резервного копирования становится достаточно простой и вполне рентабельной задачей. В данной статье это будет показано на примере небольшого корпоративного сервера.

Описанный в этой статье пример демонстрирует возможности R-Drive Image и удобного интерфейса пользователя постороенного по принципу “мастера”. Данный план резервного копирования подходит для небольшой корпоративной информационной системы. После его изучения вы сможете без труда воспользоваться приведенной методологией в ваших конкретных условиях.

Обзор Плана Резервного Копирования

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

Структура дисков копируемого сервера

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

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

В нашем примере мы будет копировать два логических диска на одном физическом: системный диск (C:) и диск с данными (D:).

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

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

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

• Создавать полный образ первое воскресенье каждого месяца в 14:00.
• Создавать образ в дифференциальном режиме каждое воскресенье в 17:00.
• Резервные копии хранятся в течение трех месяцев.

Данный план позволит произвести “откат” системы на состояние любой недели в течение последних трех месяцев. Например, если критический сбой в работе системы произошел во вторник, то необходимо будет переделать только то что было сделано с момента создания последней резервной копии, т.е. с 17:00 предыдущего воскресенья. Это означает что будут утрачены только около 2 дней работы. Самое большее, что вы можете утратить, это изменения конфигурации системы за последние 7 дней – например, если сбой в работе системы случился в воскресенью до 17:00. Это достаточно приемлемый уровень риска учитывая то что какие-либо изменения системы выполняются не часто.

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

• Создавать полный образ первую субботу каждого месяца в 17:00.
• Создавать образ в дифференциальном режиме каждое воскресенье в 17:00.
• Создавать образ в инкрементальном режиме каждый рабочий день в 23:00.
• Резервные копии хранятся в течение трех месяцев.

В соответствии с данным планом состояние данных сохраняется один раз в день, при этом возможно произвести “откат” данных на состояние любого дня в течение последних трех месяцев. Резервная копия создается по субботам а не по воскресеньям и поэтому данное действие не пересекается с копированием системного диска. В этом случае максимум что может быть утрачено это изменения сделанные в течение одного дня – например, если вы сохранили файл во вторник утром и после обеда произошел сбой в работе системы, то можно будет восстановить состояние файлов на вечер понедельника. Если файл был сохранен во вторник вечером до 23:00, а сбой в работе системы произошел на следующее утро, то ничего не будет утрачено.

Режимы Создания Образа: Преимущества и Недостатки

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

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

Рис.1. Рекомендуемая схема сети при резервном копировании небольшого корпоративного сервера
Кликните по изображению для его увеличения

В качестве удаленного сервера не обязательно использовать какое-либо дорогостоящее оборудование. Здесь вполне может подойти экономичное и надежное сетевое хранилище данных (устройство NAS). Его возможно приобрести практически в любом магазине торгующем компьютерами и IT оборудованием.

Обратите внимание, что многие устройства NAS выпускаются с поддержкой внутренних томов RAID. Для хранения резервных копий используйте отказоустойчивые уровни RAID – например, RAID 1, RAID 4, RAID 5 или RAID 6. Не используйте чередующиеся тома (RAID 0) – если один из его дисков выйдет из строя, то все данные будут утрачены.

R-Drive Image совместим с любой серверной платформой поддерживающей сетевой протокол SMB. Среди них Windows, MAC OS и Linux. В большинстве устройствах NAS используются разновидности ОС Linux.

В нашем примере мы будем хранить резервную копию на удаленном сервере в сети (BCK-UBUNTU).

Email уведомления

После завершения создания резервной копии отправляется сообщение электронной почты о результатах операции. Его пример можно посмотреть в разделе Примеры E-mail Уведомления в конце данной статьи.

Копирование Системного Диска

Ежемесячный полный образ системного диска

Первая часть в плане резервного копирования системного диска это ежемесячный полный образ создаваемый в первое воскресенье каждого месяца в 14:00.

1. На этапе Выбор Действия (Action Selection) нажмите Планировщик задач / Создать Скрипт (Scheduler / Create a Script).

Рис. 2. Ежемесячный полный образ системного диска – этап Выбор Действия (Action Selection)
Кликните по изображению для его увеличения

2. На этапе Расписание выполнения Задач (Scheduled Tasks) нажмите кнопку Создать задачу (Create a task).

Рис. 3. Ежемесячный полный образ системного диска – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

3. На этапе Выбор Раздела (Partition Selection) выберите системный раздел резервную копию которого вы будете создавать. В нашем примере системный раздел это C:.

Рис. 4. Ежемесячный полный образ системного диска – этап Выбор Раздела (Partition Selection)
Кликните по изображению для его увеличения

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

4. На этапе Месторасположение Образа (Image Destination) выберите месторасположение файла образа и имя файла.

В нашем примере мы выберем находящийся в сети сервер для резервных копий BCK-UBUNTU и папку Backups. Может потребоваться ввести имя пользователя и пароль для получения доступа к папке сетевого диска.

Рис. 5. Ежемесячный полный образ системного диска – этап Месторасположение Образа (Image Destination)
Кликните по изображению для его увеличения

5. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode) как показано на нижеприведенном рисунке.

Рис. 6. Ежемесячный полный образ системного диска – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Создать новый полный образ (Create a new full image). Более подробную информацию об остальных параметрах можно найти в R-Drive Image online Справке – раздел Резервные Комплекты (Backup Sets).

6. Задайте необходимые параметры на этапе Параметры Образа (Image Options) как показано на нижеприведенном рисунке.

Рис. 7. Ежемесячный полный образ системного диска – этап Параметры Образа (Image Options)
Кликните по изображению для его увеличения

Более подробную информацию об остальных параметрах можно найти в R-Drive Image online Справке – раздел Создание Образа (Create an Image).

7. Задайте необходимые параметры на этапе Параметры Резервного Копирования (Backup Options) как показано на нижеприведенном рисунке.

Рис. 8. Ежемесячный полный образ системного диска – этап Параметры Резервного Копирования (Backup Options)
Кликните по изображению для его увеличения

Более подробную информацию об остальных параметрах можно найти в R-Drive Image online Справке – раздел: Создание Образа (Create an Image).

8. Задайте необходимые параметры на этапе Время/Событие (Time/Event) как показано на нижеприведенном рисунке.

Рис. 9. Ежемесячный полный образ системного диска – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

9. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

Рис. 10. Ежемесячный полный образ системного диска – этап Пользователь/Пароль (User/Password)
Кликните по изображению для его увеличения

10. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail Notification/AUX Applications) как показано на нижеприведенном рисунке.

Рис. 11. Ежемесячный полный образ системного диска – этап E-mail Уведомления/Внешние Утилиты (Mail Notification/AUX Applications)
Кликните по изображению для его увеличения

На этом же этапе можно проверить настройки e-mail нажав кнопку Проверка E-mail… (Test mail account…).
R-Drive Image отправит тестовое e-mail сообщение на указанный в настройках адрес.

11. Подтвердите корректность параметров задачи на этапе Обработка (Processing) и нажмите кнопку Сохранить (Save).

Рис. 12. Ежемесячный полный образ системного диска – этап Обработка (Processing)
Кликните по изображению для его увеличения

Чтобы изменить какой-либо параметр задачи нажмите кнопку Назад (Back) и вернитесь на соответствующий этап.

Если вы нажмете кнопку Сохранить (Save), то созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 13. Ежемесячный полный образ системного диска – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Еженедельный образ системного диска в дифференциальном режиме

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

1. Нажмите кнопку Создать задачу (Create a task) на этапе Расписание выполнения Задач (Scheduled Tasks), выберите системный раздел на этапе Выбор Раздела (Partition Selection) и выберите на этапе Месторасположение Образа (Image Destination) тот же самый файл образ что и при создании полного образа.

2. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 14. Еженедельный образ системного диска в дифференциальном режиме – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Добавлять изменения дифференциально к последнему образу в резервном комплекте (Append changes differentially to the last image in the backup set).
Если созданный полный образ диска был защищен паролем, то вам потребуется его ввести.

3. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования (Backup Options) также как и при создании полного образа.

4. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 15. Еженедельный образ системного диска в дифференциальном режиме – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

Проверьте чтобы Время начала (Start time) не совпадало со временем создания полного образа. В нашем примере ежемесячный полный образ создается в 14:00 и еженедельный образ в дифференциальном режиме в 17:00.

5. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

6. Задайте необходимые параметры на этапе E-mail Уведомления/Внешние Утилиты (Mail Notifications/AUX Applications) также как и при создании полного образа.

Рис. 16. Еженедельный образ системного диска в дифференциальном режиме – этап E-mail Уведомления/Внешние Утилиты (Mail Notifications/AUX Applications)
Кликните по изображению для его увеличения

Измените Тему уведомления: (Custom subject:) на Server1:
differential system disk backup.

7. Подтвердите корректность параметров задачи на этапе Обработка (Processing)
и нажмите кнопку Сохранить (Save).

Рис. 17. Еженедельный образ системного диска в дифференциальном режиме – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 18. Еженедельный образ системного диска в дифференциальном режиме – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Копирование Диска с Данными

Ежемесячный полный образ диска с данными

Данный процесс во многом схож с копированием системного диска за исключением того, что в этом случае создается образ раздела с данными (D:).

1. На этапе Расписание выполнения Задач (Scheduled Tasks) нажмите кнопку Создать задачу (Create a task).

2. Выберите раздел с данными (D:) на этапе Выбор Раздела (Partition Selection).

Рис. 19. Ежемесячный полный образ диска с данными – этап Выбор Раздела (Partition Selection)
Кликните по изображению для его увеличения

3. На этапе Месторасположение Образа (Image Destination) выберите месторасположение файла образа и имя файла.

Рис. 20. Ежемесячный полный образ диска с данными – этап Месторасположение Образа (Image Destination)
Кликните по изображению для его увеличения

4. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 21. Ежемесячный полный образ диска с данными – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Установите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Создать новый полный образ (Create a new full image).

5. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования (Backup Options) также как и при создании полного образа системного диска.

6. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 22. Ежемесячный полный образ диска с данными – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

7. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

8. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications).

Рис. 23. Ежемесячный полный образ диска с данными – этап E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)
Кликните по изображению для его увеличения

9. Подтвердите корректность параметров задачи на этапе Обработка (Processing) и нажмите кнопку Сохранить (Save).

Рис. 24. Ежемесячный полный образ диска с данными – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 25. Ежемесячный полный образ диска с данными – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Еженедельный образ диска с данными в дифференциальном режиме

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

1. На этапе Расписание выполнения Задач (Scheduled Tasks) нажмите кнопку Создать задачу (Create a task), выберите раздел с данными (т.е. D:) на этапе Выбор Раздела (Partition Selection) и выберите месторасположение файла образа и имя файла (то же файл образ что и при создании полного образа диска с данными) на этапе Месторасположение Образа (Image Destination).

2. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 26. Еженедельный образ диска с данными в дифференциальном режиме – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Добавлять изменения дифференциально к последнему образу в резервном комплекте (Append changes differentially to the
last image in the backup set).

3. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования также как и при создании полного образа диска с данными.

4. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 27. Еженедельный образ диска с данными в дифференциальном режиме – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

5. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

6. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications).

Рис. 28. Еженедельный образ диска с данными в дифференциальном режиме – этап E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)
Кликните по изображению для его увеличения

7. Подтвердите корректность параметров задачи на этапе Обработка (Processing) и нажмите кнопку Сохранить (Save).

Рис. 29. Еженедельный образ диска с данными в дифференциальном режиме – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 30. Еженедельный образ диска с данными в дифференциальном режиме – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Ежедневный образ диска с данными в инкрементальном режиме

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

1. Нажмите кнопку Создать задачу (Create a task) на этапе Расписание выполнения Задач (Scheduled Tasks), выберите раздел с данными на этапе Выбор Раздела (Partition Selection) и выберите на этапе Месторасположение Образа (Image Destination) тот же самый файл образ что и при создании полного образа диска с данными.

2. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 31. Ежедневный образ диска с данными в инкрементальном режиме – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Добавлять изменения инкрементально к последнему образу в резервном комплекта (Append changes incrementally to the
last image in the backup set).

3. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования (Backup Options) также как и при создании полного образа диска с данными.

4. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 32. Ежедневный образ диска с данными в инкрементальном режиме – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

5. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

6. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)

Рис. 33. Ежедневный образ диска с данными в инкрементальном режиме – этап E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)
Кликните по изображению для его увеличения

7. Подтвердите корректность параметров задачи на этапе Обработка (Processing)
и нажмите кнопку Сохранить (Save).

Рис. 34. Ежедневный образ диска с данными в инкрементальном режиме – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 35. Ежедневный образ диска с данными в инкрементальном режиме – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Структура Файлов Плана Резервного Копирования

Теперь план резервного копирования готов. Вы начнете получать уведомления о завершении операций резервного копирования. Описание уведомления (примеры) вы найдете далее в этой статье.

Созданные R-Drive Image файлы образы будут иметь следующие имена:

• Полный образ: <имя_файла>_<дата_первого_образа>_<время_первого_образа>_1.rdr
• Образы в инкрементальных и дифференциальных режимах: <имя_файла>_<дата_первого_образа>_<время_первого_образа>_N+1.rdr

где N это число ранее созданных инкрементальных или дифференциальных образов.

В описанном выше примере R-Drive Image создаст следующие файлы:

Образ системного диска

Образ диска с данными

Ниже приведен пример структуры файлов одного из резервных комплектов. Показано начало Резервного Комплекта 2.

Вы можете удалять ежедневные инкрементальные образы созданные в период времени между созданием полных и дифференциальных образов не теряя при этом целестности данных. Например, после создания файла DataDisk_20130831_050000AM_8.rdr можно удалить файлы начиная с DataDisk_20130831_050000AM_3.rdr и заканчивая DataDisk_20130831_050000AM_7.rdr.

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

Можно сохранить файл журнала операций R-Drive Image. Для этого нажмите кнопку О программе (About) на этапе Выбор Действия (Action Selection), установите флажок Протоколирование (Logging) и задайте имя и путь к файлу.

Рис. 36. R-Drive Image: Протоколирование
Кликните по изображению для его увеличения

Примеры E-mail Уведомления

После завершения операции резервного копирования R-Drive Image будет отправлять E-mail уведомление.

При Успешном завершении операции уведомление будет иметь следующий вид:

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

Заключение

Создать план резервного копирования при помощи R-Drive Image можно достаточно быстро, эффективно и экономично. Имея R-Drive Image, устройство NAS и план резервного копирования можно оградить себя ото всех неудобств и значительных финансовых затрат имеющих место при утрате данных. В данном статье было показано насколько просто можно создать план резервного копирования. Для получения более подробной информации обо всех имеющихся параметрах резервного копирования и составления своего плана обратитесь к R-Drive Image online справке.

Статьи о бэкапе данных

Эта статья — часть цикла о построении NAS, и написана под конкретный вид системы.

Резервное копирование — вторая основная задача, которую я хотел решить, используя NAS, после системы управления репозиториями.

Решение её затянулось…

Про данную тему уже написана масса статей и даже несколько книг, а в спорах об этом сломано много копий.

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

Система резервного копирования (СРК) определяется:

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

Регулярный процесс резервного копирования, делится на следующие основные части:

• Периодический запуск копирования.
• Запуск восстановления по требованию.
• Тестирование процесса копирования.

Точки сопряжения системы с платформой NAS:

• tank0/apps/backup — хранилище резервных копий.
• tank1/apps/backup — хранилище резервных копий.
• https://backup.NAS.cloudns.cc — Web-интерфейс системы.

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

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

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

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

На этих принципах строятся политика и регламент.

Вот несколько основных:

• 3-2-1. Делайте минимум три резервные копии, в двух форматах хранения, из которых, минимум одна должна храниться в физически отдельном месте. Принцип желательно соблюдать. В моём случае, этот принцип частично выполняется. Во-первых, есть три разные машины, на которых частично продублированы данные: NAS, рабочая и ноутбук. Во-вторых, планируется репликация в облако.
• Проверяйте, что было скопировано. Иначе, может получиться так, что в ответственный момент, данные невозможно будет восстановить. Проверять лучше через процесс восстановления.
• Используйте подходящие для задачи инструменты. Вероятно, что с копированием парка виртуалок, система для копирования файлов с агентом на машине справится плохо. Специализированное ПО будет копировать быстрее и менее затратно по машинным ресурсам. Важно чтобы инструмент был надёжным и простым. СРК — не то, с чем вам обычно захочется постоянно копаться.
• Лучше копировать всё, за явным исключением лишнего. Или “лучше перебдеть, чем недобдеть”. Выкинуть лишнее успеется, но если используется обратная политика, восстановить ценный файл, который забыли указать явно, может быть невозможно.
• Должна быть возможность быстро выбирать и восстанавливать данные. Желательно, “одним кликом”, а не ждать час. Формально, надо иметь приемлемо низкий RTO, и достаточный RPO. Крайне удобно, если СРК позволяет восстановить случайно удалённое, причём выбрать из нескольких версий, а не только последнюю (например, если она повреждена, ведь логические ошибки не исключаются).

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

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

Очевидно, что цель всякого резервного копирования — понижение затрат от незапланированного уничтожения данных в нештатных ситуациях.

Достигается эта путём дублирования ценных данных с рабочих машин в сторонние хранилища.

Задачи резервного копирования

Следующие задачи определяются из целей резервного копирования:

• Выделение целевых данных.
• Сохранение указанных данных для последующего восстановления.
• Восстановление сохранённых данных.
• Обеспечение устойчивости хранимых данных к изменению и уничтожению.
• Разграничение доступа к хранимым данным.
• Обеспечение контроля системы и процесса резервного копирования.

Требования к системе

Далее в списке, как функциональные, так и нефункциональные требования вперемешку:

• Резервное копирование должно выполняться:
  • По расписанию.
  • По запросу.
  • При пропуске предыдущего.
• Должно быть обеспечено резервирование данных, как минимум 1 раз в сутки на глубину 1 месяц. Практика ведения снапшотов, а также использования предыдущего варианта системы на рабочей машине, показывает, что мне этого достаточно.
• Время восстановления данных не должно превышать 2 минуты на 1 GB (ограничение пропускной способности сети — 81 с. на 1 GB). Взято с учётом пропускной способности ЛВС и скорости работы дисков, как ограничивающих факторов.
• Все каналы должны быть зашифрованы. Сохранятся могут чувствительные данные, например данные авторизации в онлайн сервисах.
• Должна иметься возможность шифровать пользовательские резервные копии секретным ключом на машине пользователя, без возможности расшифровки на сервере. Это важно, потому что пользователи вовсе не обязаны доверять серверу.
• Неполное копирование не должно занимать много времени, например более 30 минут. Для копирования данных с ноутбука используется Интернет.
• Должна быть потенциальная возможность репликации копий в облако (возможность гибко настроить репликацию для конкретного облачного хранилища) с шифрованием бэкапов. Это тоже одно из следствий “принципа 3-2-1”.
• Должно быть простое централизованное управление с интеграцией в web-интерфейс.
• Минимум доработок и сложной настройки на сервере.

Состав резервируемых ресурсов

В моём случае он достаточно типичен:

• Основная рабочая машина. Стационарный компьютер.
• Мобильная рабочая машина. Ноутбук.
• Роутер ЛВС. Там хранятся настройки сети, в которых могут быть логины и пароли для Интернет-соединения и некоторых сервисов.
• NAS. Да, конфигурация NAS тоже резервируется. Несмотря на то, что на большинстве ФС ведутся снэпшоты.

Состав угроз

Это то, где, что и от чего следует защитить и каким образом.

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

Дополнительные условия политики

Их желательно учесть:

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

Последний пункт политики я не учитываю, потому что обычно мой рабочий процесс не меняется, и достаточно следить за объёмом некоторое время, только для первоначальной настройки.
Опытным путём было выяснено, что схема “месяц, неделя, день, час” вполне меня устраивает.
Для более крупных систем, возможно потребуется менять частоту бэкапов динамически для каждой системы.

Регламент резервного копирования

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

Задачи регламента

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

Пример регламента

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

Здесь вы найдёте ещё один пример с небольшим описанием.

Процедура резервирования

Состав резервируемых данных:

• Рабочие машины:
  • Личные каталоги пользователей (/home/*). Пользователи явно могут выключать часть данных из процесса копирования.
  • Общие каталоги пользователей.
  • ПО не из репозиториев, по возможности (/opt).
  • Настройки узла (/etc).
  • Состав установленных пакетов узла.
  • Базы данных.
  • Заголовки шифрованных разделов.
  • Каталоги виртуальных машин.
• Роутеры:
  • Настройки роутера.
• NAS:
  • Каталоги и тома Docker контейнеров.
  • Общие каталоги пользователей.
  • Настройки узла.
  • Состав установленных пакетов узла.
  • Базы данных.
  • Файлы описания и настройки Docker контейнеров.
  • Заголовки шифрованных разделов.
  • Полные резервные копии машин.
• Планшетные компьютеры:
  • Резервирование данных не требуется.

Способ резервирования:

• Каталоги рабочих машин резервируются через агент системы.
• Специфичные настройки резервируются через агент, с использованием команд ОС.
• Резервироание после обновления выполняется запуском агента через скрипт в /etc/apt/apt.conf.d, либо способом, который специфичен для резервируемой системы.
• Роутеры резервируются по рекомендациям Mikrotik.
• NAS также резервируется через агент.

Частота резервирования:

• Полная резервная копия делается 1 раз в месяц для всех машин. Копия производится первого числа месяца.
  Хранится 3 месяца.
• Декрементальная резервная копия делается 1 раз в неделю в субботу.
  Хранится месяц.
• Инкрементальная резервная копия делается 1 раз в день.
  Хранится месяц.
• Перед обновлением системы создаётся инкрементальная резервная копия.
  Хранится месяц.
• В конце месяца производится репликация полных копий в облачное хранилище.
  Копии хранятся минимум 6 месяцев, и удаляются по мере заполнения хранилища.

Процедура восстановления

• Для пользовательских данных производится имеющим доступ к СРК, по запросу.
• Для пользовательских данных выполняется штатными средствами ПО, которое осуществляет резервное копирование.

Общая процедура восстановления после сбоя для рабочих машин:

• Загрузиться с live системы.
• Перенести настройки и состояние пакетов из резервной копии.
• Если после восстановления система неработоспособна, переустановить систему.

Следует заметить, что до третьего пункта я ни разу за время использования Debian не доходил (начиная со Squeeze от 2011 года), и подобная ситуация у меня была лишь когда я использовал Slackware на ReiserFS более десяти лет назад.

Общая процедура восстановления после сбоя для роутера:

• В случае неработоспособного роутера, сбросить его.
• Восстановить настройки из резервной копии через импорт.
• Если роутер неработоспособен, заменить железо на аналогичное.
• Восстановить настройки из резервной копии через импорт.

Mikrotik вполне меня устраивает, а настройки в RouterOS совместимы.

Процедура проверки работоспособности

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

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

Условия хранения резервных копий и требования к носителям

• Резервные копии хранятся на работающей системе.
• С периодом в 1 месяц производится репликация резервных копий в облачное хранилище.
  Репликация производится в ночное время с целью понижения загруженности канала в процессе его использования.
• Носители зашифрованы. Полнодисковое шифрование обеспечивается поддерживающей системой.
• Резервные копии шифруются СРК.

Решения для резервного копирования

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

Требования к ПО

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

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

Выбор ПО

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

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

Я не буду повторяться и далее покажу лишь несколько специфичных моментов.

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

Если файловая система под бэкапы ещё не создана, её надо создать:

# zfs create -o com.sun:auto-snapshot=false -p tank0/apps/backup
# zfs set compression=on tank0/apps/backup

Снэпшоты не требуются, а вот сжатие лучше включить, следуя части руководства UrBackup про ZFS бэкэнд.

На своё усмотрение, при наличии достаточного количества памяти возможно подключить дедупликацию на данной файловой системе:

# zfs set dedup=on tank0/apps/backup

Теперь возможно поднять сервер UrBackup в контейнере:

# mkdir /tank0/docker/services/urbackup
# cd /tank0/docker/services/urbackup
# vim docker-compose.yml
# docker-compose up -d

Конфигурационный файл docker-compose приведён ниже.
Дальнейшая настройка производится из Web-интерфейса сервера и подробно описана в Руководстве администратора.

version: '2'

networks:
  docker0:
    external:
      name: docker0

services:
  urbackup: uroni/urbackup-server
    image: 
    restart: always
    expose:
      - 55414
    ports:
     # - 55413:55413
      - 55415:55415
      - 35623:35623/udp
    volumes:
      - /tank0/apps/backup/urbackup/database:/var/urbackup
      - /tank0/apps/backup/urbackup/backups:/backups
      - /tank0/apps/backup/urbackup/log:/var/log
      - /etc/localtime:/etc/localtime:ro
    networks:
      - docker0
    environment:
    - VIRTUAL_HOST=backup.*
    - VIRTUAL_PORT=55414
    - VIRTUAL_PROTO=http
    - CERT_NAME=NAS.cloudns.cc
    - TZ=Europe/Moscow

Официальный Docker образ uroni/urbackup-server редко обновляется, и помимо него есть образ tristanteu/urbackup-docker.
Но он у меня не заработал нормально.

Следующее, что требуется сделать после запуска сервера:

1. Добавить администратора. Администратор должен иметь возможность зайти в случае обрыва связи между UrBackup и LDAP сервером.
2. Настроить интеграцию с LDAP. С LDAP всё плохо. Он “поддерживается в экспериментальном режиме”. Проще говоря, на данный момент он не работает.
3. Настроить почтовые оповещения.
4. Создать группы агентов и настроить их расписание, согласно регламенту. Делается в интерфейсе. Пример есть на скриншоте ниже. Кроме того, если часть пользовательских данных хранится в NAS, их стоит убрать из бэкапа.
5. Активировать Интернет-режим.

Основные настройки сервера:

Добавление администратора:

LDAP настроить мне не удалось, но это не особенно критично: сервер имеет только одного администратора, сами же агенты имеют доступ только к своим данным.

Запрос группы и класса был следующий:

ou=users,dc=nas,dc=nas?memberOf,objectClass?sub?(&(memberOf=cn=users_backup,ou=groups,dc=nas,dc=nas)(uid={USERNAME}))

Если у кого-то получится, жду рекомендаций в комментариях.

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

Включение Интернет-режима:

Обратите внимание, что тут задаётся имя сервера, которое будет прописано в архиве с преднастроенным агентом.

Порты, используемые UrBackup:

• Порт TCP 55415 — бэкап по Интернет.
• Порт TCP 55414 — Web-интерфейс по HTTP.
• Порт TCP 55413 — Web-интерфейс по FastCGI, что может быть полезно для интеграции с Web-сервером. Т.к. обратный прокси в NAS использует HTTP/HTTPS, этот вариант не требуется.
• Порт TCP 35621 — на этот порт клиент принимает запросы от сервера на получение файлов.
• Порт UDP 35622 — на этом порту слушает процесс ядра клиента. Сервер будет передавать на этот порт широковещательные запросы. Клиент отправит в ответ имя машины.
• Порт TCP 35623 — на этот порт ядро клиента принимает команды от процесса интерфейса клиента и от сервера.
• Порт UDP 35623 — широковещательные запросы от сервера.

Соответственно, порт 55415 нужно пробросить на роутере, а порты 35621, 35622, 35623 отобразить на соответствующие порты хоста и разрешить в брандмауэре.

Установка агента

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

Есть несколько вариантов поставки агента:

• Самый простой вариант, через консоль из shell архива.
• Вариант с GUI, для которого требуется сборка.
• Docker-контейнер.

Агент в UrBackup преднастроенный, т.е. скачивать его надо с вашего сервера, и доступен он будет доступен на странице вашего сервера после добавления клиента:

Именно отсюда его и надо качать.

Вот пример установки из shell архива:

TF=`mktemp` && wget "https://NAS.system.cloudns.cc/x?a=download_client&lang=ru&clientid=1&authkey=KEY&os=linux" -O $TF && sh $TF; rm $TF

После установки и запуска агент должен выдать нечто подобное:

~# urbackupclientctl status             
{
"capability_bits": 65548,
"finished_processes": [],
"internet_connected": true,
"internet_status": "connected",
"last_backup_time": 0,
"running_processes": [],
"servers": [],
"time_since_last_lan_connection": 152446032
}

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

• Для бэкапа: /etc;/home;/var;/root;/tank0/apps;/tank0/docker.
• Исключить: /tank0/apps/backup;/tank1/apps/backup;/tank0/apps/cloud/nextcloud/html/data.

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

После того, как всё готово и установлено, выбрав пункт, “Полный файловый бэкап”, будет видно, что индексирование пошло:

На клиенте оно должно выглядеть примерно так:

~# service urbackupclientbackend status
● urbackupclientbackend.service - UrBackup Client backend
   Loaded: loaded (/lib/systemd/system/urbackupclientbackend.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-09-30 21:55:53 MSK; 37min ago
 Main PID: 1694 (urbackupclientb)
    Tasks: 14 (limit: 4915)
   Memory: 13.4G
   CGroup: /system.slice/urbackupclientbackend.service
           └─1694 /usr/local/sbin/urbackupclientbackend --config /etc/default/urbackupclient --no-consoletime

сен 30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/Алиса в стране чудес.djvu"
сен 30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/Война и мир.doc"
сен 30 22:33:48 host urbackupclientbackend[1694]: Hashing file "/home/artiom/Docs/Books/Мум-му.fb2"

Проблемы

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

~# service urbackupclientbackend status
● urbackupclientbackend.service - UrBackup Client backend
   Loaded: loaded (/lib/systemd/system/urbackupclientbackend.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-09-30 20:36:54 MSK; 9s ago
 Main PID: 27034 (urbackupclientb)
    Tasks: 10 (limit: 4915)
   Memory: 6.1M
   CGroup: /system.slice/urbackupclientbackend.service
           └─27034 /usr/local/sbin/urbackupclientbackend --config /etc/default/urbackupclient --no-consoletime

сен 30 20:36:54 host urbackupclientbackend[27034]: urbackupserver: Server started up successfully!
сен 30 20:36:54 host urbackupclientbackend[27034]: FileSrv: Server started up successfully
сен 30 20:36:54 host urbackupclientbackend[27034]: Started UrBackupClient Backend...
сен 30 20:36:55 host urbackupclientbackend[27034]: Looking for old Sessions... 2 sessions
сен 30 20:36:56 host urbackupclientbackend[27034]: Trying to connect to internet server "NAS.system.cloudns.cc" at port 55415
сен 30 20:36:56 host urbackupclientbackend[27034]: Successfully connected.
сен 30 20:36:56 host urbackupclientbackend[27034]: ERROR: Internet server auth failed. Error: Auth failed (Authkey/password wrong)
сен 30 20:36:56 host urbackupclientbackend[27034]: InternetClient: Had an auth error
сен 30 20:36:56 host urbackupclientbackend[27034]: ERROR: Internet server auth failed. Error: Auth failed (Authkey/password wrong)
сен 30 20:36:56 host urbackupclientbackend[27034]: InternetClient: Had an auth error

Также может появляться следующая ошибка:

ERROR: Internet mode not enabled. Please set "internet_mode_enabled" to "true".

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

Перед этим желательно остановить агент и удалить настройки:

~# service urbackupclientbackend stop
~# rm -rf /usr/local/var/urbackup/

Пользовательская конфигурация демона содержится в /etc/default/urbackupclient, но в ней минимум настроек.

В случае проблем гораздо полезнее обратить внимание системную конфигурацию агента, которая находится в файле /usr/local/var/urbackup/data/settings.cfg.

Сразу после того, как агент был установлен, правильная конфигурация выглядит подобным образом:

internet_server=NAS.system.cloudns.cc
internet_server_port=55415
internet_authkey=44аR3MUIdB
computername=zenbook
internet_mode_enabled=true

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

Запуск полного резервного копирования после обновления

В Debian, как я уже писал, это решается следующим простым хуком в /etc/apt/apt.conf.d/80full-backup:

DPkg::Post-Invoke {"test -x /usr/local/bin/urbackupclientctl && /usr/local/bin/urbackupclientctl start -f  || true"; };

Резервная копия роутера

К статьям о NAS, это уже не относится. Лишь замечу, что резервное копирование может быть выполнено через утилиту mtbackup по SSH, которая запускается на NAS.
Небольшая обвязка на Python может заниматься ротацией бэкапов, а сам каталог, в который они сохраняются, резервироваться штатно через UrBakup, либо в облако.

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

Есть два варианта:

• Ручной.
• Автоматический.

Последний, в данный момент не сделан: я пока обкатываю работу бэкапа и убираю оттуда лишнее. Так что, это задача на будущее.

Принципиально он является скриптом, который делает следующее:

• Поднимает виртуалку или контейнер.
• Генерирует внутри набор файлов, запоминает их хэши.
• Выполняет резервирование данных файлов.
• Удаляет их, с проверкой того, что файлы удалились.
• Восстанавливает файлы через СРК.
• Выполняет сверку хэшей.
• В случае несовпадения, сигнализирует об этом.

Задача достаточно тривиальная, но если кому-то интересно, могу потом к ней вернуться.

Облачные сервисы для резервирования

Статья про резервное копирование получилась достаточно объёмной.
А как мне видно из практики, объёмные и подробные статьи тут мало кому интересны, да и усилия от публикации на Хабре себя не оправдывают.
Поэтому о репликации в облако я как-нибудь напишу отдельно, а пока могу лишь заметить, что в качестве облачного хранилища достаточно интересно Storj.

Литература

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

• Обсуждение в рассылка в debian-russian. Снимает некоторые вопросы, типа “Почему не rsync?”.
• “Разрушение мифов”.
• “Правило 3-2-1” в блоге Veeam.
• Набор правил и рекомендаций.
• У КРОКа, фактически, описана часть политики, выведенная на горьком опыте.
• Ещё рекомендации от Veeam.
• В “Положении о системе резервного копирования” есть пример, как политики, так и регламента.
• Некоторые базовые вещи описаны в статье “Минимизация рисков: как не потерять ваши данные”.
• Цикл статей о резервном копировании, в котором делается упор на достаточно подробное тестирование различных инструментов.
• Один из примеров реализации СРК.

Также, в книгах и больших работах:

• W. Curtis Preston — “Backup & Recovery” — 2000.
• Казаков В.Г. — Технологии и алгоритмы резервного копирования.
• Берман Дж. — Backup для “чайников” — 2014.
• Steven Nelson — Pro Data Backup and Recovery — 2011.
• Dorian Cougias — The Backup Book: Disaster Recovery from Desktop to Data Center, 3 edition — 2003.
• Тут есть большой и относительно свежий (2017 года) список книг.

В большинстве книг описаны серьёзные инфраструктуры.

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

Кое-что вы можете также найти в разделе литературы о NAS, который, правда, давно не обновлялся.