Задача
Имеется три хоста. Два в домашней сети и один удалённый. Для резервного копирования требуется независимый бэкап-сервер, который можно подключить к прямо к домашней сети или разместить удалённо. Главная задача: делать регулярные бэкапы как домашних так и удалённых систем. Сервер должен быть максимально экономичным. Все хосты и бэкап-сервер используют операционную систему FreeBSD.
Легче всего в качестве сервера приспособить старый компьютер. Однако он должен дежурить круглосуточно и поэтому будет жрать много электроэнергии. Поэтому я обратил я свой взор на single board computers на ARM процессоре. Этот процессор поддерживается операционной системой FreeBSD.
Оптимальный выбор Banana Pi М1. Подходящий процессор и память. Можно подключить SATA диск. Параметры вполне удовлетворительные для бэкап-сервера, которому особо некуда торопиться.
В качестве программного решения выбран BackupPC. С ним всё хорошо за исключением одной вещи: архивы не шифруются. Для выгрузки копии архива в облако (а тем более в некошерный mail.ru) потребуется дополнительное шифрование. Но это отдельный вопрос не по этой теме. Для доступа к web-интерфейсу BackupPC требуется веб-сервер. В классической установке для BackupPC предлагается Apache. Но рука не поднимается на маленький Banana Pi громоздить такого монстра. Поэтому будет nginx.
Железо
На aliexpress было заказано следующее оборудование:
1. Banana Pi A20 Dual Core 1GB RAM singel-board computer
2. Banana PI M1 Case
3. PC Banana pi Aluminum Heatsink CPU and RAM
4. Banana Pi M1 SATA cable
5. 5v 3a Micro Usb Ac/dc Power Adapter Eu
Плата компьютера сделано аккуратно. Это внушает уверенность, что работать будет нормально. Загрузил FreeBSD 11. Работает. Корпус тоже сделан весьма неплохо. Хотя сначала, вроде бы. не хотел собираться. На вид корпус симметричный. Но если внимательно взглянуть, то можно обнаружить, что с одной стороны один боковой упор на нижней крышке корпуса имеет немного другую форму. Короткая боковая крышка (на которой кнопки Power и Reset) садится ниже, чем противоположная крышка. Всё остальное вполне собралось. Надо только стянуть саморезами. В комплекте есть и резиновые ножки которые клеятся на отверстия с саморезами.
Первоначальная сборка тестовая, поэтому ножки, разумеется, не клеил. Потребуется ещё разобрать, чтобы установить радиаторы. Корпус тёплый. Что там и как нагревается конкретно проверю, когда устройство начнёт работать в нормальном режиме. Был куплен лот с двумя набороми радиаторов. Их четыре штуки в наборе. По одному на каждую микросхему. Набор радиаторов с одним комплектом не прилагается. Поэтому получился запасной. Ещё на Али предлагаются какие-то керамические радиаторы, которые непонятно как должны рассеивать тепло. У них нет рёбер — просто толстая наклейка на чип. Скорее всего это что-то неживое типа китайской памяти, аккумуляторов или LED-ламп.
Вентиляционные свойства корпуса не лучшие. На нижней крышке есть решётка, но она всего одна и сквозного движения воздуха нет. Однако сам корпус удобный. Для всего есть отверстия Сделаны точно. С платой совмещаются идеально. Нет только дырки для микрофона. А он и не нужен. На верхней крышке есть два дополнительных лючка, закрывающие разъёмы, которые я использовать не буду. Также есть световод, который выводит на поверхность корпуса свет от красного светодиода на плате, индицирующего подключение питания. Ещё минус корпуса в том, что нет отверстий для его крепления на стену.
Блок питания рекомендуется на 2А, но я заказал на три, т.к. планирую использовать с внешним 2.5" HDD, для которого весьма неплохо иметь блок питания с запасом мощности. Имеется ввиду пиковый режим. В текущем режиме потребление всей системы должно уложиться в 1А.
Исполнение задачи
Система загружается на SD-карту. Конфигурация базовая. Далее её надо будет адаптировать под свои нужды. Кроме того в rc.conf добавлена опция growfs_enable="YES". Она при первом запуске системы обеспечивает использование полного объёма вашей карты. Ещё одна одноразовая опция — получение IP адреса по DHCP для первоначального доступа к плате.
Для того, чтобы можно было подключиться к плате через SSH изначально в системе предусмотрены два юзера freebsd и root. Пароли совпадают с именами. Не забудьте заменить их на более безопасные. Прежде всего требуется создать новый rc.conf. По умолчанию sendmail отключен. Нам он пригодится для отправки сообщений BackupPC. Поэтому отключающие строки из конфига удалены. Теперь sendmail сможет отправлять почту из localhost.
## common
#apcupsd_enable="YES"
hostname="foo.example.com"
keymap="us.dvorak.kbd"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
sshd_enable="YES"
## net
ifconfig_dwc0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"
ipv6_defaultrouter="2a01:348:1f9:29::1"
## nginx
nginx_enable="YES"
spawn_fcgi_enable="YES"
fcgiwrap_enable="YES"
fcgiwrap_user="bpc"
#apcupsd_enable="YES" — пока отключен, при переходе в production будет подключено резервное питание. Вы видите keymap="us.dvorak.kbd" — это чисто моя персональная вещь. В случае подключения с консоли надо обеспечить нужную мне раскладку клавиатуры. Плата не хранит текущее время. Онo запрашивается с ntp-сервера. Поэтому предусмотрен запуск соответствующего демона.
Добавил привычного юзера, который живёт на всех моих хостах. Добавил также файл .ssh/authorized_keys, установил для него нужный shell. Теперь можно избавиться от начального юзера «freebsd». А можно и не заводить нового юзера, а остаться с имеющимся. И вообще можно обойтись только юзером, которого создаст BackupPC, но тогда его придётся включить в группу wheel и дать парольный доступ для случая использованная консоли. Надо помнить, что ресурсы одноплатного компьютера ограничены. И это устройство для выполнения одной задачи. Лишний софт не нужен.
Обычно на всех своих хостах я пользуюсь системой портов. Сейчас постараюсь обойтись без них.
# pkg install пакетПакеты — менее гибкое решение, но зато сэкономит время. Итак, ставим zsh, vim и mc. Vim — must have. Без zsh можно обойтись — это не desktop. Один раз настроил, прибил на стену и пусть себе там живёт. MC для наглядности иногда полезен, но и без него можно прожить.
SD карта выбрана размером 2 GB. Т.е. правильных гигабайт там будет 1.7. Так что некоторые «излишества» в софте можно себе позволить. Изначально система забрала 1.1 GB. Остальное для юзера. Некоторые карты Banana не видит. Так что если система не загружается, то не стоит впадать в панику, а надо просто попробовать другую SD карту.
Устанавливаем BackupPC. Есть некоторые особенности. Обратите внимание — в rc.conf отсутствует запуск BackupPC. Будем запускать его вручную. Запущенный таким образом BackupPC будет в любое время иметь доступ ко всем хостам, перечисленным в его конфигурации. А вот зайти с бэкап-юзера на любой другой хост просто так не получится. Он спросит парольную фразу, чтобы получить доступ к ключу. Однако, в случае перезагрузки сервера, например, при длительном отсутствии электроэнергии, когда сервер запустится после остановки системой резервного питания, придётся загружать BackupPC заново. Чтобы не пропустить подобное событие cron каждые три часа проверяет наличие активного BackupPC. Если процесс BackupPC не запущен, то сервер будет присылать emails.
Кроме того, и сам BackupPC, если что-то не в порядке, присылает почтовые уведомления. Проверить работу этого сервиса можно командой (разумеется при правильно настроенной секции Email конфигурации backupc):
BackupPC_sendEmail -u your@email.addressВ текущей версии BackupPC не поддерживает IPv6. Придётся немного его попатчить в соответствии со статьёй на Гитхабе. Есть одна особенность. Файл configure.pl отсутствует в установленной конфигурации. Вместо него я внёс изменение в /usr/local/libexec/backuppc/update.pl. После правки файлов BackupPC получил возможность работы с шестыми IP адресами. Никаких проблем не случилось.
Потребуется ещё установить пакет p5-File-RsyncP-0.74 — Perl Rsync client, т.к. будет использоваться метод rsync для реализации бэкапа.
При установке BackupPC создается одноимённый юзер с минимальными правами. Нам потребуется реальный юзер. Имя backuppc слишком длинное и неудобное. Поэтому удобнее использовать более короткое bpc. К нему мы сможем подключаться для запуска BackupPC. И BackupPC будет под его именем заходить на обслуживаемые хосты. В связи с изменением имени юзера директорию /usr/local/www/backuppc надо переименовать в /usr/local/www/bpc.
Теперь хозяин бэкапов выглядит в /etc/passwd таким образом:
bpc:*:301:301:BackupPC user:/home/bpc:/usr/local/bin/zshВ домашней директории юзера присутствуют файлы:
-rwxr--r-- 1 bpc bpc 304 Nov 13 19:02 agent
-rw-r--r-- 1 bpc bpc 110 Nov 20 12:11 agent-info
-rwxr--r-- 1 bpc bpc 158 Nov 19 10:21 mailbpc
-rw-r--r-- 1 bpc bpc 38 Nov 19 09:51 mailtext
agent — скрипт для запуска BackupPC. Вызывается обычно с вашего десктопа или другого компьютера, которому разрешён доступ:
ssh bpc@foo.example.com /home/bpc/agentСодержимое скрипта:
#!/usr/local/bin/zsh
## ssh-agent to the file
pid=`ps ax| grep ssh-agent | grep -v grep`
if [ "$pid" = "" ]
then
ssh-agent | head -2 > ~/agent-info
## Setup Environment for ssh-agent
source ~/agent-info
ssh-add
fi
## Start BackupPC and term the connection
/usr/local/bin/BackupPC -dПроверяет наличие запущенного ssh-agent, и если он не запущен, запускает его, устанавливает среду для него, стартует ssh-add, запускает BackupPC. Соединение с хостом, с которого происходит запуск, закрывается. Если обнаружен процесс ssh-agent, то скрипт завершается сообщением о том, что агент уже запущен.
agent-info — файл с параметрами среды. Его создаёт agent.
mailbpc — скрипт почтового предупреждения о том, что BackupPC упал:
#!/usr/local/bin/zsh
pid=`ps ax | grep perl | grep -v grep`
if [ "$pid" = "" ]
then
mail -s "bpc failure" postmaster@example.com < /home/bpc/mailtext
fiДля проведения проверки (раз в три часа) надо для bpc через crontab -e добавить строку:
3 */3 * * * /home/bpc/mailbpc
mailtext — сюда добавьте текст по вашему усмотрению. Что-то типа: «BackupPC не работает. Надо бы запустить его заново.» Если всё в порядке, emails приходить не будут.
Содержимое ~bpc/.ssh
~ % ls -l .ssh
total 20
-rw-r--r-- 1 bpc bpc 400 Oct 28 11:43 authorized_keys
-rw------- 1 bpc bpc 35 Nov 7 16:15 config
-rw------- 1 bpc bpc 444 Nov 15 12:46 id_ed25519
-rw-r--r-- 1 bpc bpc 90 Nov 15 14:49 id_ed25519.pub
-rw-r--r-- 1 bpc bpc 762 Nov 20 14:39 known_hosts
authorized_keys — сюда добавляются публичные ключи хостов, с которых можно стартовать BackupPC.
config — локальный конфигурационный файл ssh. Нужен в случае, если в BackupPC добавлен новый хост. Обеспечивает автоматический доступ к новому хосту. По умолчанию в этом keyword используется аргумент ask, а backupc не умеет отвечать на вопросы. Содержимое:
Host *
StrictHostKeyChecking no
id_ed25519 — private key, которым BackupPC шифрует сообщения к своим клиентам
id_ed25519.pub — публичный ключ, который надо добавить клиентам в их authorized_keys
known_hosts — список клиентов, который обновляется автоматически в силу указания содержащегося в файле config.
BackupPC можно попробовать до того, как будут настроен запуск через agent. Для пробного запуска надо сделать начальную корректировку backuppc/config.pl — прописать изменённое имя юзера. Проверить пути к файлам, указать название сервера. Достаточно и IP адреса, но IP шестой версии более громоздкий, чем четвёртой. Доменное имя надо прописать в /etc/hosts или в файл зоны DNS сервера вашего домена. Детально конфиг можно будет настроить позднее через вебинтерфейс. Вебинтерфейс программы вполне юзабельный. По всем пунктам есть контекстно-зависимая справка.
Проверим запускается или нет. Для этого надо зайти на сервер под юзером bpc.
ssh bpc@foo.example.comПосле этого сделать пробный запуск:
/usr/local/bin/BackupPC -dПосмотреть результат можно через top или командой ps:
~ % ps aux | grep perl
bpc 753 0.0 1.1 15252 11908 - I 12:11 0:00.19 /usr/local/bin/perl /usr/local/bin/BackupPC -d
bpc 754 0.0 0.8 12748 8084 - IN 12:11 0:00.77 /usr/local/bin/perl /usr/local/bin/BackupPC_trashCleanТеперь возмёмся за nginx. Сначала запустим его в стандартной конфигурации:
# service nginx startЕсли всё хорошо, то приводим nginx.conf к такому виду:
load_module /usr/local/libexec/nginx/ngx_mail_module.so;
load_module /usr/local/libexec/nginx/ngx_stream_module.so;
user bpc bpc;
worker_processes auto;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen [::]:80;
server_name foo.example.com;
index index.html /index.cgi;
root /usr/local/www;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location / {
auth_basic "BackupPC admin";
auth_basic_user_file /usr/local/etc/nginx/.passwd;
}
location ~ .cgi$ {
include fastcgi_params;
fastcgi_pass unix:/var/run/fcgiwrap/fcgiwrap.sock;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_USER $remote_user;
fastcgi_param SCRIPT_FILENAME /usr/local/www/cgi-bin/BackupPC_Admin;
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
}
}
}Не забудем также установить пакеты на которые ссылается данная конфигурация и rc.conf.
fcgiwrap-1.1.0_3 Simple FastCGI wrapper for CGI scripts
spawn-fcgi-1.6.4_2 Spawns fastcgi applicationsСтандартный port 22 для SSH лучше заменить на другой, иначе задолбают тупые брутфорсеры. Правим sshd_config: Port 12345. Чтобы BackupPC мог заходить на другие хосты проделываем подобную операцию с фалом ssh_config.
Теперь надо ограничить доступ к вебинтерфейсу BackupPC. Для этого я хотел воспользоваться htdigest. Но с этим получился облом. Установленный пакет не имеет этой опции. У nginx можно подключать модули. Пытаюсь это сделать. На гитхабе находится нужный модуль. Правда пятилетней давности. Пытаюсь его скомпилировать. Код устарел и уже не даёт положительного результата с современным nginx. Нахожу более современную версию. Всё компилируется. Но радоваться рано. htdigest как подключаемый модуль не создаётся. В результате пришлось обойтись обычным htpasswd и создать пароль при помощи openssl password. Альтернатива — установка из портов или из src. Что есть неоправданно хлопотно. Web-интерфейс BackupPC будет доступен по адресу foo.example.com.
Сделал первый шаг. Вписал первый хост для бэкапа. Нажал кнопку Save. Вроде бы всё в порядке. Надо проверить пинг на этот клиент.
ping6 client.your.domainДалее следует обеспечить, чтобы с другой стороны, т.е. на клиенте кто-то мог вызвать rsync и пробежаться по клиенту, чтобы окучить необходимые для бэкапа файлы.
bpc:*:1006:1006:backuppc from foo:/home/bpc:/bin/cshДля этого на каждом клиенте создаётся юзер bpc, который должен быть наделён правами доступа ко всем файлам. Однако эти права должны быть строго ограничены рамками поставленной задачи. Для этого в /usr/local/etc/sudoers добавляется строка:
bpc ALL=NOPASSWD: /usr/local/bin/rsync --server *Следующим шагом надо проверить доступ к клиенту. Просто пытаемся зайти по ssh на клиент. Ssh тут же поинтересуется парольной фразой для доступа к ключу. Если всё получается, то значит и BackupPC будет заходить. Однако, на практике избежать, чтобы BackupPC ни разу не сообщил: «Unable to read 4 bytes» весьма трудно. Это значит, что он не может подключиться к клиенту. Как правило, причина в таких случаях собственная невнимательность. Исправляем ошибки и voilà — сервер соединяется с хостом.
Не сделана пока одна важная вещь — не подключен SATA диск за отсутствием оного на текущий момент. Пока в отладочных целях в качестве накопителя используется USB флэшка.
Далее требуется стандартная настройка и отладка BackupPC, которая подробно описана в документации и можно найти много чего на эту тему в интернете. При настройке BackupPC будет полезно использовать команду:
BackupPC_dump -v -f bpc@client.your.domainОна даёт подробный вывод, анализ которого хорошо помогает получить работающий backuppc.
Итак все готово. Система работает. Остался последний штрих. Надо сделать резервную копию SD-карты.
# dd if=/dev/da0 of=/путь/bpc.img bs=1mВот теперь действительно работа закончена и есть резервная копия из которой можно в случае чего восстановить систему на новую SD-карту.
В статье не всё отражено достаточно подробно. Собственно процесса настройки BackupPC практически нет. Но главная цель не в подробностях, а в принципиальной возможности размещения BackupPC на Banana Pi M1 под управлением операционной системы FreeBSD 11.
Автор: gryff1
