📡 Как установить и настроить REST-сервер restic на Linux |

📡 Как установить и настроить REST-сервер restic на Linux

Мануал

Restic – это эффективная и современная дедуплицирующая система резервного копирования, поддерживающая шифрование; она может хранить резервные копии локально и удаленно, через SFTP-соединение или на одной из многих поддерживаемых платформ хранения, таких как ведра Amazon S3 и облачные хранилища Google.

Используя бэкэнд Restic REST API, можно также передавать резервные копии по протоколам HTTP или HTTPS на удаленный сервер, который реализует Restic REST API.

В этом руководстве мы узнаем, как использовать Docker для развертывания и настройки экземпляра сервера restic REST на Linux.

Создание каталога репозитория и генерация учетных данных

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

В рамках этого руководства мы создадим каталог «data» внутри HOME.

Эта директория будет bind-mounted внутри контейнера:

mkdir ~/data

REST-сервер restic, запущенный внутри контейнера docker, по умолчанию поставляется с включенной аутентификацией.

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

Аутентификация сервера restic REST осуществляется через файл .htpasswd; REST-сервер ищет этот файл в том же каталоге, где хранятся снепшоты.

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

В дистрибутивах Fedora и дистрибутивах на базе Fedora эта утилита входит в пакет httpd-tools.

🔐 Что за файл .htpasswd и зачем он нужен?

Мы можем установить ее с помощью dnf:

sudo dnf install httpd-tools

В дистрибутивах Debian и Debian-подобных вместо этого пакета используется apache2-utils:

sudo apt-get update && sudo apt-get install apache2-utils

Чтобы заполнить файл .htpasswd, выполните команду:

htpasswd -B -c ~/data/.htpasswd resticuser

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

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

New password: 
Re-type new password: 
Adding password for user restserver

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

Запуск контейнера restic REST-сервера

REST-сервер restic – это бесплатное программное обеспечение с открытым исходным кодом; как и приложение restic, он написан на языке Go и разрабатывается на GitHub.

Самый быстрый и простой способ развернуть сервер restic REST – использовать Docker (или Podman) для запуска контейнера на основе образа сервера, предоставленного проектом, который доступен на DockerHub. Чтобы создать и запустить контейнер restic REST-сервера, достаточно выполнить следующую команду:

docker run -p 8000:8000 -v ~/data:/data:z --name restic_rest_server docker.io/restic/rest-server

Давайте посмотрим на опции, которые мы использовали в команде.

По умолчанию REST-сервер внутри контейнера прослушивает порт 8000, поэтому мы использовали опцию -p для сопоставления порта 8000 на хосте с тем же портом внутри контейнера (мы могли бы использовать любой порт хоста, например порт 80, но, используя непривилегированный порт, мы можем легко запустить контейнер от имени пользователя, не являющегося root.

Посмотрите это руководство, если вы хотите использовать более высокий порт при запуске Docker или Podman без привилегий root).

Чтобы сделать резервные копии постоянными, как уже говорилось, мы привязали каталог ~/data на хосте к такому же каталогу внутри контейнера, в котором хранятся снепшоты.

🚼 Активный FTP и пассивный FTP сравнение и отличие

В примере мы использовали опцию :z для bind mount: она требуется только при активном SELinux и вызывает изменение контекста для смонтированного каталога, чтобы он был доступен из контейнера.

Инициализация репозитория

На данном этапе мы уже должны уметь инициализировать репозиторий restic с помощью клиента restic, используя URL-адрес rest:http://resticuser:resticpassword@localhost:8000:

restic -r rest:http://resticuser:resticpassword@localhost:8000 init

Если все прошло как ожидалось, репозиторий будет создан и инициализирован правильно:

created restic repository 0216975ff5 at rest:http://resticuser:***@localhost:8000/

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Хотя репозиторий был создан правильно, передача учетных данных по HTTP-соединению в виде простого текста – это то, чего нам следует избегать.

Чтобы использовать REST-сервер restic по HTTPS, нам нужно использовать сертификат SSL/TLS.

Давайте посмотрим, как это сделать.

Здесь я буду считать, что у нас уже есть и сертификат (содержащий открытый ключ), и закрытый ключ, сохраненные как public_key и private_key соответственно.

Самый простой способ использовать их с REST-сервером, запущенным в контейнере docker, – поместить оба в каталог данных, который мы привязали внутри контейнера (тот же каталог, где находится файл .htpasswd), и запустить сервер с помощью опции –tls.

Однако, поскольку мы не запускаем сервер напрямую, нам нужно передать эту опцию через переменную окружения OPTIONS при запуске контейнера:

docker run -p 8000:8000 -v ~/data:/data:z -e OPTIONS="--tls" --name restic_rest_server docker.io/restic/rest-server

Теперь мы можем взаимодействовать с сервером по HTTPS.

Поскольку в данном случае мы использовали самоподписанный сертификат, нам нужно запустить клиент restic с опцией –insecure-tls, которая пропускает проверку сертификата TLS при подключении к репозиторию:

$ restic -r rest:https://resticuser:resticpassword@localhost:8000 --insecure-tls init

Выводы

В этом руководстве мы узнали, как развернуть REST-сервер restic с помощью Docker на Linux.

С помощью restic мы можем создавать резервные копии локально или удаленно, используя SFTP-соединения, один из поддерживаемых сторонних сервисов хранения или сервер restic REST.

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

см. также:

 

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!
Добавить комментарий