Эта статья — часть цикла о построении NAS, и написана под конкретный вид системы.
Резервное копирование — вторая основная задача, которую я хотел решить, используя NAS, после системы управления репозиториями.
Решение её затянулось...
Про данную тему уже написана масса статей и даже несколько книг, а в спорах об этом сломано много копий.
Ниже — попытка разобраться в этой куче материала, уложить его в голове и построить небольшую систему относительно грамотно.
Система резервного копирования (СРК) определяется:
Регулярный процесс резервного копирования, делится на следующие основные части:
Точки сопряжения системы с платформой NAS:
Хранилища резервных копий являются отдельными файловыми системами.
Это нужно потому, что их опции могут сильно отличаться, как от нормальных файловых систем, так и между собой.
Например, при необходимости, могут быть включены дедупликация средствами ФС и отключено сжатие.
Стоит понимать, что хотя я описываю здесь частный случай резервного копирования, который заточен под нужды маленькой сети, принципы, наблюдения и закономерности везде общие.
В простых случаях некоторыми из них возможно пренебречь, но знать желательно.
На этих принципах строятся политика и регламент.
Вот несколько основных:
В конце статьи есть ссылки на источники, которые вы можете изучить, чтобы полнее ознакомиться с данными пунктами, а также почитать о других.
Очевидно, что цель всякого резервного копирования — понижение затрат от незапланированного уничтожения данных в нештатных ситуациях.
Достигается эта путём дублирования ценных данных с рабочих машин в сторонние хранилища.
Следующие задачи определяются из целей резервного копирования:
Далее в списке, как функциональные, так и нефункциональные требования вперемешку:
В моём случае он достаточно типичен:
Это то, где, что и от чего следует защитить и каким образом.
Для этого я составил небольшую таблицу угроз.
Все основные угрозы мобильному компьютеру повторяют угрозы стационарному.
Планшетные компьютеры практически не отличаются от мобильного, с этой точки зрения.
Их желательно учесть:
Последний пункт политики я не учитываю, потому что обычно мой рабочий процесс не меняется, и достаточно следить за объёмом некоторое время, только для первоначальной настройки.
Опытным путём было выяснено, что схема "месяц, неделя, день, час" вполне меня устраивает.
Для более крупных систем, возможно потребуется менять частоту бэкапов динамически для каждой системы.
После разработки политики возможно приступать к разработке непосредственно регламента.
В общем случае, регламентов может быть несколько: общий, для администраторов СРК, для пользователей, для ответственных за хранение, для администраторов целевых систем и т.п…
Но в случае небольшой системы это, как правило, один человек, потому и регламент один.
Под спойлером вы можете увидеть, как выглядит регламент в крупной организации, на примере взятого из открытых источников регламента Росреестра.
Регламент Росреестра.
Здесь вы найдёте ещё один пример с небольшим описанием.
Состав резервируемых данных:
Способ резервирования:
Частота резервирования:
Общая процедура восстановления после сбоя для рабочих машин:
Следует заметить, что до третьего пункта я ни разу за время использования Debian не доходил (начиная со Squeeze от 2011 года), и подобная ситуация у меня была лишь когда я использовал Slackware на ReiserFS более десяти лет назад.
Общая процедура восстановления после сбоя для роутера:
Mikrotik вполне меня устраивает, а настройки в RouterOS совместимы.
Предлагается использовать для проверки работоспособности виртуальную машину, запущенную на стационарном компьютере.
Пришло время рассмотреть программное обеспечение, которое может быть использовано для резервного копирования.
При выборе я руководствовался следующими требованиями:
Под спойлером ниже рассмотрены несколько возможных систем для резервного копирования.
Ещё больше вы можете найти здесь, и здесь.
Несколько вариантов систем.
Изо всех решений я выбрал 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-интерфейса сервера и подробно описана в Руководстве администратора.
docker-compose.yml
Официальный Docker образ uroni/urbackup-server редко обновляется, и помимо него есть образ tristanteu/urbackup-docker.
Но он у меня не заработал нормально.
Следующее, что требуется сделать после запуска сервера:
Основные настройки сервера:
Добавление администратора:
LDAP настроить мне не удалось, но это не особенно критично: сервер имеет только одного администратора, сами же агенты имеют доступ только к своим данным.
Запрос группы и класса был следующий:
ou=users,dc=nas,dc=nas?memberOf,objectClass?sub?(&(memberOf=cn=users_backup,ou=groups,dc=nas,dc=nas)(uid={USERNAME}))
Если у кого-то получится, жду рекомендаций в комментариях.
В системе есть одна группа, в которой содержатся настройки по умолчанию, и куда попадают все созданные вновь клиенты.
Но я бы рекомендовал добавить отдельные группы, чтобы проще было манипулировать настройками:
Включение Интернет-режима:
Обратите внимание, что тут задаётся имя сервера, которое будет прописано в архиве с преднастроенным агентом.
Порты, используемые UrBackup:
Соответственно, порт 55415 нужно пробросить на роутере, а порты 35621, 35622, 35623 отобразить на соответствующие порты хоста и разрешить в брандмауэре.
Надо поставить агент на каждом из защищаемых устройств и убедиться в том, что он появился в интерфейсе сервера.
Есть несколько вариантов поставки агента:
Агент в 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 клиента надо выставить отдельные параметры, задав следующие каталоги:
Возможно ещё делать бэкап некоторых пользовательских данных, но это сомнительно, учитывая то, что они и так, по факту, многократно зарезервированы в текущей архитектуре.
После того, как всё готово и установлено, выбрав пункт, "Полный файловый бэкап", будет видно, что индексирование пошло:
На клиенте оно должно выглядеть примерно так:
~# 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 не так просто настраивается и легко запускается, как хотелось бы. В процессе настройки возникали проблемы.
Одна из них — проблема с отключенным Интернет-режимом, либо отсутствие заданного сервера.
Статус может выводить примерно следующее...
Также может появляться следующая ошибка:
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:
ost-Invoke {"test -x /usr/local/bin/urbackupclientctl && /usr/local/bin/urbackupclientctl start -f || true"; };
К статьям о NAS, это уже не относится. Лишь замечу, что резервное копирование может быть выполнено через утилиту mtbackup по SSH, которая запускается на NAS.
Небольшая обвязка на Python может заниматься ротацией бэкапов, а сам каталог, в который они сохраняются, резервироваться штатно через UrBakup, либо в облако.
Есть два варианта:
Последний, в данный момент не сделан: я пока обкатываю работу бэкапа и убираю оттуда лишнее. Так что, это задача на будущее.
Принципиально он является скриптом, который делает следующее:
Задача достаточно тривиальная, но если кому-то интересно, могу потом к ней вернуться.
Статья про резервное копирование получилась достаточно объёмной.
А как мне видно из практики, объёмные и подробные статьи тут мало кому интересны, да и усилия от публикации на Хабре себя не оправдывают.
Поэтому о репликации в облако я как-нибудь напишу отдельно, а пока могу лишь заметить, что в качестве облачного хранилища достаточно интересно Storj.
Подробнее о принципах и рекомендациях, которые возможно применить в процессе разработки системы, возможно почитать в следующих источниках:
Также, в книгах и больших работах:
В большинстве книг описаны серьёзные инфраструктуры.
Следует читать и применять изложенное в них, если вам нужно или очень хочется посчитать и обосновать RTO, RPA, RPO. Впрочем, если вы это делаете, скорее всего вы и так занимаетесь резервированием крупных систем, и моя статья для вас бесполезна.
Кое-что вы можете также найти в разделе литературы о NAS, который, правда, давно не обновлялся.
Источник статьи: https://habr.com/ru/post/421251/
Резервное копирование — вторая основная задача, которую я хотел решить, используя 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-интерфейса сервера и подробно описана в Руководстве администратора.
docker-compose.yml
Официальный Docker образ uroni/urbackup-server редко обновляется, и помимо него есть образ tristanteu/urbackup-docker.
Но он у меня не заработал нормально.
Следующее, что требуется сделать после запуска сервера:
- Добавить администратора. Администратор должен иметь возможность зайти в случае обрыва связи между UrBackup и LDAP сервером.
- Настроить интеграцию с LDAP. С LDAP всё плохо. Он "поддерживается в экспериментальном режиме". Проще говоря, на данный момент он не работает.
- Настроить почтовые оповещения.
- Создать группы агентов и настроить их расписание, согласно регламенту. Делается в интерфейсе. Пример есть на скриншоте ниже. Кроме того, если часть пользовательских данных хранится в NAS, их стоит убрать из бэкапа.
- Активировать Интернет-режим.
Основные настройки сервера:
Добавление администратора:
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 не так просто настраивается и легко запускается, как хотелось бы. В процессе настройки возникали проблемы.
Одна из них — проблема с отключенным Интернет-режимом, либо отсутствие заданного сервера.
Статус может выводить примерно следующее...
Также может появляться следующая ошибка:
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:
ost-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, который, правда, давно не обновлялся.
Источник статьи: https://habr.com/ru/post/421251/