Наш эксперт Михаил Сергеев подготовил подробный материал (в двух форматах: статья и видеоурок), в этом уроке:
- Расскажем, что такое Restic server и Uptime Kuma.
- Установим Restic server с помощью Ansible playbook.
- Установим Uptime Kuma.
- Настроим бэкап файлов сервера Ubuntu 22.04 через Restic с помощью Ansible playbook.
- Настроим мониторинг успешности создания бэкапа через Uptime Kuma.
- Восстановим удаленные с сервера файлы.
Что такое Restic server и Uptime Kuma
В этом уроке мы рассмотрим один из вариантов, как сделать бэкап в Linux с помощью Restic server.
В чём же основная проблема бэкапов (резервного копирования)? Их основная проблема в том, что все эти системы резервного копирования в большинстве случаев работают на серверах, где лежат (хранятся) оригинальные файлы. То есть если сервер скомпрометирован, то злоумышленник может получить доступ не только к самому серверу, но и бэкапам и удалить их.
Для того, чтобы бэкапы делались автоматически по расписанию, через клон, у вас на сервере должен храниться ключ, позволяющий автоматизировать этот процесс. Чтобы не нужно было каждый раз вводить пароль. Соответственно, если ключ лежит на сервере, то его можно забрать и уже подключиться к серверу с бэкапами. Есть хорошие инструменты для резервного копирования, например, block backup или duplicate, но они подвержены этой проблеме. Если вы бэкапите для защиты от смерти сервера (физического удаления, человеческой ошибки), то они вполне подходят. Но если вы хотите предусмотреть ситуацию, когда вас взламывают, то тогда вам нужно уже другое решение, которое есть в Restic server. Оно есть не в самой Restic server, делающей бэкапы, а в его опции, позволяющей вам только добавлять бэкапы, а не модифицировать или удалять их. Поэтому это решает проблему взлома сервера, чтобы злоумышленник не смог удалить или зашифровать ваши бэкапы. И вы всегда могли их восстановить в случае чего. Ну и плюс Restic работает по HTTPS вместо SSH. Это более надёжное решение, которые работатет ощутимо быстрее, потому что шлёт данные кусками по 32 КБ.
HTTPS — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.
SSH — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений. Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли.
Для начала рассмотрим, что такое Restic server.
Restic server — это серверное приложение, разработанное для обеспечения централизованного хранения и управления резервными копиями, созданными с помощью инструмента резервного копирования Restic. Restic сам по себе является современным и гибким инструментом командной строки, который обеспечивает шифрование, дедупликацию, сжатие и аутентификацию данных при создании резервных копий.
Restic Server позволяет создавать централизованные хранилища резервных копий, к которым можно подключаться с нескольких клиентских устройств для отправки и восстановления резервных копий. Он предоставляет сетевой интерфейс, который клиенты могут использовать для взаимодействия с сервером и выполнения операций резервного копирования, восстановления и проверки целостности данных.
С помощью Restic Server можно создавать политики резервного копирования, управлять правами доступа, а также отслеживать и контролировать процесс создания и восстановления резервных копий. Он также поддерживает инкрементальные резервные копии, что означает, что только измененные или добавленные файлы отправляются на сервер, что уменьшает объем передаваемых данных и ускоряет процесс резервного копирования.
Restic Server является открытым и бесплатным программным обеспечением, распространяемым по лицензии MIT. Он имеет поддержку различных операционных систем и может быть использован как на серверах, так и на домашних компьютерах или сетевых накопителях для создания надежных резервных копий ваших данных.
Помимо инструмента резервного копирования, нам также понадобится инструмент, позволяющий проверить успешность создания резервной копии. Потому что в какой-то момент что-то сломается, копии перестанут создаваться, а вы даже не узнаете об этом. Поэтому самое важное — это настроить мониторинг успешности создания резервной копии.
Есть несколько вариантов проверки бэкапов. Многие делают так, когда создался бэкап и если он выдал ошибку, то шлёт alert (тревога). Но бывают ситуации, когда сервер выключен, или когда его удалили и нет скрипта (script), который должен прислать вам сообщение о тревоге. В этом случае вы даже не узнаете о проблеме. Поэтому такой вариант нам не подходит.
Мы будем делать так, чтобы наш бэкап выполнялся, а в конце, если он выходит с кодом 0 (успешно), то он делает curl в определённый url. И система мониторинга смотрит, что пришёл curl, и помечает, что сервис доступен. А если в течение рабочего дня или суток его не дёрнули, этот url, то значит, что бэкап не создался.
cURL — кроссплатформенная служебная программа командной строки (распространяемая по лицензии MIT), позволяющая взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL. Название расшифровывается как "client for URL".
Оригинальным автором является Даниэль Стенберг.
Uptime Kuma — это инструмент для мониторинга и отслеживания времени работы (uptime) веб-сайтов и онлайн-сервисов. Он позволяет владельцам веб-сайтов и администраторам серверов контролировать доступность своих ресурсов и получать уведомления в случае сбоев или перерывов в работе.
Uptime Kuma позволяет мониторить не только бэкапы, а всё, что угодно. Но чаще всего его используют для мониторинга сайтов, чтобы фиксировать определённый код. Например, код 200, когда сайт работает. Для удобства есть несколько попыток, для исключения лишних или ложных срабатываний, например, когда соединение сначала не прошло, а затем сразу восстановилось.
Uptime Kuma предоставляет возможность непрерывного мониторинга, проверяя работоспособность веб-сайтов путем отправки запросов на определенные страницы или проверки наличия ответа от сервера. Он осуществляет проверки на регулярной основе и анализирует время ответа, чтобы определить, насколько доступен ресурс.
В случае обнаружения недоступности или нештатной работы сайта или сервиса, Uptime Kuma может отправлять уведомления по электронной почте, SMS или через мессенджеры, чтобы администраторы могли немедленно реагировать на проблемы и восстановить работу ресурса.
Uptime Kuma также предоставляет статистику и отчеты о доступности веб-сайта, позволяя анализировать время простоя и оптимизировать работу ресурса. Этот инструмент может быть полезен для любого владельца веб-сайта или онлайн-сервиса, кто ценит непрерывную доступность своего ресурса для пользователей.
Установка Restic server с помощью Ansible playbook
Я подготовил 3 ВМ (виртуальных машины) в облаке CorpSoft24:
ru-cs24-site ansible_host=194.126.161.153
ru-cs24-uptimekuma ansible_host=194.126.161.11
ru-cs24-backup ansible_host=194.126.162.54
У каждой из них свой внешний IP-адрес. На первой виртуальной машине будет наше тестовое приложение, резервную копию которого мы и будет создавать. Вторая виртуальная машина это Uptime Kuma, на неё мы установим мониторинг, отслеживающий работу именно нашего сайта, который мы развернём, и будем отслеживать работу бэкапа. Третья виртуальная машина будет хранилищем бэкапов, куда они будут сохраняться с первой ВМ. Я сделал все 3 ВМ в облаке CorpSoft24, но рекомендую вам делать бэкап отдельно в другом дата-центре (data center) и у другого провайдера в другой стране. Чтобы в случае проблем, можно было оперативно всё восстановить.
На всех виртуальным машинах установлена операционная система Ubuntu 22.04.2 LTS. Они чистые, на них ещё ничего не установлено. Нам нужно на все 3 ВМ установить docker.
Отчет о распределенной по бизнес-процессам деятельности сотрудника Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации, контейнеризатор приложений.
Есть удобный способ установки через Ansible playbook. Во время установки автоматически скачиваются и устанавливаются дополнительные пакеты, добавляются репозитории, добавляются ключи. Всё это добавляется в автозапуск. И единственное, что я себе добавляю, это алиасы (alias), чтобы не вводить длинные команды.
Alias — короткое, удобное для запоминания имя, использующееся вместо более длинного и сложного имени.
Рис.2 Установка Docker через ansible playbook. Затем на чистую ВМ нужно установить firewall (сетевой экран). Он очень важен, поскольку у каждого приложения рано или поздно появляются уязвимости. Заходить на сервера нужно исключительно с разрешённых IP-адресов. Для этого можно использовать VPN.
VPN — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений поверх чьей-либо другой сети.
Установка Uptime Kuma
После установки docker и firewall можно устанавливать мониторинг Uptime Kuma. В процессе установки мониторинга я создаю папку app, поскольку в неё удобно заходить из Linux. Затем мы создаём в этой папке папку для данных cadydata, и затем создаём сеть caddy командой docker network create caddy. Мы используем не сам caddy, а caddy-docker-proxy, который выполняет 2 функции. Первая: Web server, создающий и поддерживающий SSL-сертификат. Вторая: он позволяет нам ограничивать доступ к нашему приложению через авторизацию или белый список IP-адресов, так называемый white list.
Веб-сервер — сервер, принимающий HTTP-запросы от клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы, как правило, вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными.
SSL-сертификат – это цифровой сертификат, удостоверяющий подлинность веб-сайта и позволяющий использовать зашифрованное соединение.
mkdir -p /app/uptimekuma
cd /app/uptimekuma
mkdir cadydata kumadata
chmod 777 cadydata kumadata
docker network create caddy
cat << \EOF > docker-compose.yml
version: "3.7"
services:
caddy:
image: lucaslorentz/caddy-docker-proxy:2.8.4
restart: always
ports:
- 80:80
- 443:443
environment:
- CADDY_INGRESS_NETWORKS=caddy
networks:
- caddy
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./cadydata/:/data
uptimekuma:
hostname: uptimekuma
container_name: uptimekuma
restart: always
image: louislam/uptime-kuma:1.22.1
volumes:
- ./kumadata/:/app/data/
networks:
- caddy
labels:
caddy.@denied.not: "remote_ip 194.126.161.153 194.126.161.11 194.126.162.54 95.217.236.3"
caddy.abort: "@denied"
caddy: mon.194.126.161.11.sslip.io
caddy.reverse_proxy: "{{upstreams http 3001}}"
networks:
caddy:
external: true
EOF
Рис.3 Настройка Uptime Kuma для отправки алертов, мы используем Telegram. В настройках мы выставляем 5 попыток опроса сайта, и если они все будут неудачными, то после них будет приходить тревожное уведомление в Telegram. Частоту опроса оставляем по умолчанию, каждые 60 секунд. Мы будем использовать push, пассивный тип монитора.
Затем пробуем создать сайт на WordPress. Для этого создаём директорию wordpress, создаём папки, прописываем им права, создаём сеть caddy.
WordPress — свободно распространяемая система управления содержимым сайта с открытым исходным кодом; написана на PHP; сервер базы данных — MySQL; выпущена под лицензией GNU GPL версии 2. Сфера применения — от блогов до достаточно сложных новостных ресурсов.
mkdir -p /app/wordpress
cd /app/wordpress
mkdir wordpress_files mariadb_files caddy_files
chmod -R 777 wordpress_files mariadb_files caddy_files
docker network create caddy
cat << \EOF > ./docker-compose.yml
version: '3.3'
services:
caddy:
image: lucaslorentz/caddy-docker-proxy:2.8.4
restart: always
ports:
- 80:80
- 443:443
environment:
- CADDY_INGRESS_NETWORKS=caddy
networks:
- caddy
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./caddy_files/:/data
db:
image: mariadb:11
command: '--default-authentication-plugin=mysql_native_password'
volumes:
- ./mariadb_files:/var/lib/mysql
networks:
- caddy
restart: always
environment:
- MYSQL_ROOT_PASSWORD=somewordpress
- MYSQL_DATABASE=wordpress
- MYSQL_USER=wordpress
- MYSQL_PASSWORD=wordpress
wordpress:
image: wordpress:6.2.2-php8.2-apache
volumes:
- ./wordpress_files:/var/www/html
networks:
- caddy
restart: always
environment:
- WORDPRESS_DB_HOST=db
- WORDPRESS_DB_USER=wordpress
- WORDPRESS_DB_PASSWORD=wordpress
- WORDPRESS_DB_NAME=wordpress
labels:
caddy_0: site.194.126.161.153.sslip.io
caddy_0.reverse_proxy: "{{upstreams http 80}}"
caddy_1: www.site.194.126.161.153.sslip.io
caddy_1.redir: https://site.194.126.161.153.sslip.io
networks:
caddy:
external: true
EOF
Не забываем разрешить доступ к ВМ по 80 и 443 портам.
# разрешить доступ к ВМ по 80 и 443 порту:
ufw allow 80
ufw route allow proto tcp from 0.0.0.0/0 to any port 80
ufw allow 443
ufw route allow proto tcp from 0.0.0.0/0 to any port 443
Рис.4 Личный кабинет в WordPress.Затем добавляем мониторинг нашего сайта. Переходим на сайт Uptime Kuma, вводим наши логин и пароль и попадаем в личный кабинет. По умолчанию в нём нет мониторов, поэтому прописываем настройки для монитора и ставим галочку, чтобы нас предупреждали, если будет заканчиваться один из сертификатов.
Рис.5 Интерфейс монитора нашего сайта. Настройка бэкап файлов сервера Ubuntu 22.04 через Restic с помощью Аnsible playbook
Но мы ставили Uptime Kuma не для мониторинга сайта, а для бэкапов, поэтому теперь настроим на одной из ВМ бэкап файлов сервера. На https://github.com/restic/rest-server смотрим инструкцию по установке.
cat << \EOF > /etc/systemd-m.conf #!/bin/bash CONTAINER_NAME="mysql-container" DB_USER="root" DB_PASSWORD="yourpassword" BACKUP_DIR="/path/to/backups" TELEGRAM_BOT_TOKEN="your_bot_token" TELEGRAM_CHAT_ID="your_chat_id" GOOD_URL="https://" if [ ! -d "$BACKUP_DIR" ]; then mkdir -p "$BACKUP_DIR" fi for db in $(docker exec $CONTAINER_NAME mariadb -u $DB_USER -p$DB_PASSWORD -e 'show databases' -s --skip-column-names| grep -v -e '^information_schema$\|^performance_schema$\|^sys$') do FILENAME="$BACKUP_DIR/$db-$(date +%Y-%m-%d).sql.gz" docker exec $CONTAINER_NAME mariadb-dump -u $DB_USER -p$DB_PASSWORD $db | gzip > $FILENAME if [ $? -ne 0 ]; then curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \ -d chat_id="$TELEGRAM_CHAT_ID" \ -d text="Ошибка при создании бэкапа для базы данных mysql - $db" fi done if [ $? -eq 0 ]; then curl "$GOOD_URL" fi chmod -R 600 $BACKUP_DIR EOF chmod 700 /etc/systemd-m.conf (crontab -l ; echo "0 1 * * * /etc/systemd-m.conf 2>&1 | tee /tmp/systemd-m.txt")| crontab -
Для настройки бэкапа нам нужно будет ввести сервер-клиент и сервер-бэкапа. Соответственно копию какого сервера мы будем создавать и где она будет храниться.
Настройка мониторинга успешности создания бэкапа через Uptime Kuma
Заходим на Uptime Kuma и прописываем мониторинг создания бэкапа. В качестве источника мониторинга указываем сервер-бэкап и его название, чтобы было понятней. Если бэкап происходит раз в сутки, то частоту опроса выставляем 100 000 секунд (это каждые 1 666,66 минуты или 27,77 часа). Если нужно делать опрос ровно каждые сутки, то ставьте 86 400 секунд. Число попыток ставим 1.
Рис.6 Настройка мониторинга успешности создания бэкапа через Uptime Kuma. У вас будет выбор, хранить пароль на сервере бэкапов, или каждый раз вводить его заново и потом очищать. Сами бэкапы будут занимать мало места, поскольку будут дописываться только изменяемые данные. Это позволяет чистить старые бэкапы раз в месяц или реже. В итоге мы сделали автоматический бэкап, выполняемый в 2 часа ночи.
# ручной запуск бэкапов systemctl start systemd-rest systemctl status systemd-rest vi /etc/systemd/system/systemd-rest.service systemctl daemon-reload
Восстановление удаленных с сервера файлов
Теперь попробуем удалить наш сайт и восстановить его из бэкапа. Например, вы нечаянно удалили всю папку с вашим сайтом.
Рис.7 Удаление папки с нашим сайтом Удаляем папку с нашим сайтом и проверяем, что сайт теперь не загружается, а мониторинг резервной копии показывает жёлтый индикатор, означающий, что сайт недоступен. После второй попытки опроса сайта вам придёт алерт в Telegram.
Теперь давайте восстановим из резервной копии наш сайт и запустим его снова для проверки работоспособности. Для восстановления переходим на сервер. Если ваш сервер вышел из строя, то заходим на другой и разрешаем доступ к серверу бэкапов с нового сервера. У нас уже всё разрешено. Имейте ввиду, что удалённый бэкап доступен только для чтения и добавления файлов, удалить его мы не можем. После монтирования сайта из образа, заходим в WordPress и запускаем резервную копию нашего сайта.
Теперь мониторинг показывает, что сайт доступен и в браузере можно также убедиться, что сайт загружается.
Используемые сайты: