Что значит бэкап системы

Резервное копирование, часть 1: Назначение, обзор методов и технологий

Идеальная программа работает быстро, не течет по оперативной памяти, не имеет дыр и не существует.

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

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

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

Хорошие художники копируют, великие художники воруют.

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

Например, у птиц и у самолетов есть крылья, однако несмотря на функциональную схожесть — принцип действия в некоторых режимах совпадает, и технические проблемы решаются аналогично: полые кости, использование прочных и легких материалов и т.п., — результаты абсолютно разные, хоть и весьма похожие. Лучшие образцы, которые мы наблюдаем в нашей технике, также по большей части заимствованы у природы: герметичные отсеки у кораблей и подводных лодок — прямая аналогия с кольчатыми червями; построение raid-массивов и проверка целостности данных — дублирование цепочки ДНК; а также парные органы, независимость работы разных органов от ЦНС (автоматия работы сердца) и рефлексы — автономные системы в Интернет. Конечно брать и применять готовые решения «в лоб» чревато проблемами, но кто знает, может, других решений-то и нет.

Знать бы, где упадешь — соломки подстелил бы!

—Белорусская народная пословица

Значит, резервные копии жизненно необходимы тем, кто желает:

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

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

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

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

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

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

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

— Есть два вида системных администраторов, те кто не делает резервные копии, и те, кто УЖЕ делает.
— На самом деле три вида: есть еще те, кто проверяет, что резервные копии можно восстановить.

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

Под форматом хранения следует понимать следующее:

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

Не стоит путать горячие и холодные копии с online и offline копиями, которые подразумевают физическую изоляцию данных, и по сути, являются другим признаком классификации способов резервного копирования. Так offline копия — не подключенная непосредственно к системе, где ее надо восстановить, — может быть как горячей, так и холодной (с точки зрения готовности к восстановлению). Online копия может быть доступна непосредственно там, где ее надо восстанавливать, и чаще всего является горячей, но бывают и холодные.

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

Разностные инкрементальные копии — попытка сэкономить размер пространства для хранения резервных копий. Таким образом в резервную копию пишутся только измененные данные с прошлой резервной копии.

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

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

(Кто устережет самих сторожей? — лат.)

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

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

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

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

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

Знает толк в пряностях не тот, кто добавляет их в каждое блюдо, но тот, кто никогда не добавит в него ничего лишнего.

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

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

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

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

В качестве тестового стенда будет применяться виртуальная машина (на базе XenServer) со следующими характеристиками:

Операционная система — Centos 7 x64: разбивка стандартная, дополнительный раздел будет использоваться как источник данных.

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

Prime numbers limit: 20000

Initializing worker threads…

CPU speed:
events per second: 836.69

Throughput:
events/s (eps): 836.6908
time elapsed: 30.0039s
total number of events: 25104

Latency (ms):
min: 2.38
avg: 4.78
max: 22.39
95th percentile: 10.46
sum: 119923.64

Threads fairness:
events (avg/stddev): 6276.0000/13.91
execution time (avg/stddev): 29.9809/0.01

Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global

Initializing worker threads…

Total operations: 50900446 (1696677.10 per second)

49707.47 MiB transferred (1656.91 MiB/sec)

Throughput:
events/s (eps): 1696677.1017
time elapsed: 30.0001s
total number of events: 50900446

Latency (ms):
min: 0.00
avg: 0.00
max: 24.01
95th percentile: 0.00
sum: 39106.74

Threads fairness:
events (avg/stddev): 12725111.5000/137775.15
execution time (avg/stddev): 9.7767/0.10

Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global

Initializing worker threads…

Total operations: 35910413 (1197008.62 per second)

35068.76 MiB transferred (1168.95 MiB/sec)

Throughput:
events/s (eps): 1197008.6179
time elapsed: 30.0001s
total number of events: 35910413

Latency (ms):
min: 0.00
avg: 0.00
max: 16.90
95th percentile: 0.00
sum: 43604.83

Threads fairness:
events (avg/stddev): 8977603.2500/233905.84
execution time (avg/stddev): 10.9012/0.41

Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads…

Throughput:
read: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
write: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

Latency (ms):
min: 0.00
avg: 0.27
max: 18.01
95th percentile: 1.08
sum: 238469.45

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Состав угроз

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

Ресурс	Угроза	Решение
Основная рабочая машина	Физическое разрушение данных	Резервирование данных и ключевых настроек
Основная рабочая машина	Частичное незаметное сразу повреждение данных	Хранение более старых резервных копий в течение некоторого времени
Основная рабочая машина	Утеря доступа к данным	Хранение полного образа машины, либо настроек, для быстрого разворота на другой машине, либо дублирование функций на мобильном ПК
Основная рабочая машина	Несанкционированный физический доступ к данным	Шифрование данных и резервных копий, передача копий в шифрованном виде
Основная рабочая машина	Несанкционированный доступ путём нарушения ПО	Резервирование контрольных сумм ПО и периодическая сверка, системы контроля (пока не реализую)
Мобильная рабочая машина	Утеря машины вместе с данными	Шифрование данных, полное резервирование, либо резервирование ключевых настроек и данных
Роутер ЛВС	Разрушение конфигурации, либо устройства	Резервирование конфигурации, возможно резервирование устройства
Роутер ЛВС	Утеря контроля вследствие взлома	Резервирование конфигурации
Роутер ЛВС	Частичное незаметное повреждение данных	Хранение контрольных сумм ПО и периодическая сверка
NAS	Повреждение настроек служб	Локальное резервирование настроек
NAS	Физическое разрушение данных	Репликация в облако
NAS	Потеря доступа к системе и резервным копиям	Репликация в облако
NAS	Несанкционированный доступ к данным посторонних	Хранение и репликация данных в шифрованном виде, обмен данными в шифрованном виде
NAS	Несанкционированный доступ администратора к данным	Шифрование резервных копий на локальных ключах резервируемых машин

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

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

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

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

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

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

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

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

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

РЕГЛАМЕНТ РЕЗЕРВНОГО КОПИРОВАНИЯ ДАННЫХ В ТЕРРИТОРИАЛЬНЫХ ПОДРАЗДЕЛЕНИЯХ РОСРЕЕСТРА

Оглавление

1 Общие положения

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

Настоящий Регламент разработан с целью:

Под резервным копированием информации понимается создание полных копий производственных БД Управления, для быстрого восстановления работоспособности информационной системы ведения ЕГРП АИС «Юстиция», в случае возникновения аварийной ситуации, повлекшей за собой повреждение или утрату данных.

Резервному копированию подлежат все производственные БД всех территориальных отделов Управления.

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

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

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

Резервное копирование производится штатными средствами СУБД Oracle. Резервное копирование может производится:

Резервное копирование БД производится не реже 1 раза в сутки. Срок хранения резервной копии БД не менее 1 месяца.

Стратегия резервного копирования должна гарантировать синхронное восстановление данных, расположенных в разных схемах БД. Например, схема ХЭД (хранилище электронных документов), должна копироваться одновременно со схемой АИС Юстиция.

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

3 Контроль результатов

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

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

4 Нормативно-правовое обеспечение

Для организации процесса резервного копирования необходимо:

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

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

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

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

6 Восстановление информации из резервной копии

В случае необходимости восстановление данных из резервных копий производится ответственным работником подразделения ИТ, указанным в Приложении N 2.

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

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

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

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

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

7 Приложение 1

Пример запуска утилиты экспорта Oracle из командной строки:

exp userid=JUST_USER/PASSWORD@SERVER owner=(JUST_USER,HED_USER) direct=Y consistent=Y statistics=NONE compress=N file=C:\BACKUP.DMP log=C:\BACKUP.LOG

owner=(JUST_USER,HED_USER) – перечень копируемых схем, в данном примере одновременно экспортируются схема АИС Юстиция и схема ХЭД;

file=C:\BACKUP.DMP – путь и имя создаваемого файла экспорта;

log=C:\BACKUP.LOG – путь и имя создаваемого файла лога экспорта.

8 Приложение 2. Перечень лиц, ответственных за резервное копирование

№ п/п	Выполняемая роль	ФИО ответственного сотрудника
1	Первоначальная настройка системы резервного копирования.
2	Внесение существенных изменений в настройку системы резервного копирования.
3	Анализ логов резервного копирования, отслеживание необходимости изменений настроек резервного копирования, обеспечение ротации носителей.
4	Ротация носителей, проверка корректности резервной копии, обеспечения хранения резервной копии вне офиса на случай катастрофы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор ПО

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

Решения на базе unix-утилит

Решения на основе rsync, tar, rdiff-backup, etc. не рассматриваются по причине большого количества работы, которую потребуется выполнить, и отсутствия необходимого WEB-интерфейса.

Bareos

BareOS (Backup Archiving Recovery Open Sourced) — форк Bacula с 2010 года.

BackupPC

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

Плюсы и возможности:

UrBackup

Клиент-серверная система резервного копирования с агентом.

Плюсы и возможности:

Restic

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

Плюсы и возможности:

BorgBackup

Дедуплицирующая программа для резервного копирования.

Плюсы и возможности:

Lsyncd

Демон, выполняющий резервирование изменяемых файлов через rsync.

Плюсы и возможности:

Box Backup

Автоматическая онлайновая система с открытым исходным кодом.
Вот более подробное описание.

Плюсы и возможности:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

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

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

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

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

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

Источник