Banana Pi — сервер резервного копіювання

Завдання
Є три хоста. Два в домашній мережі та один віддалений. Для резервного копіювання потрібно незалежний бекап-сервер, який можна підключити до прямо до домашньої мережі або розмістити віддалено. Головне завдання: робити регулярні бекапи як домашніх так і віддалених систем. Сервер повинен бути максимально економним. Всі хости і бекап-сервер використовують операційну систему FreeBSD.

Найлегше в якості сервера пристосувати старий комп'ютер. Однак він повинен чергувати цілодобово і тому буде жерти багато електроенергії. Тому я я звернув свій погляд на single board computers на процесорі ARM. Цей процесор підтримується операційною системою FreeBSD.

image
Оптимальний вибір 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="ТАК"
. Вона при першому запуску системи забезпечує використання повного обсягу вашої карти. Ще одна одноразова опція — отримання IP адреси DHCP для початкового доступу до плати.

Для того, щоб можна було підключитися до плати через SSH спочатку в системі передбачені два юзера freebsd і root. Паролі збігаються з іменами. Не забудьте замінити їх на більш безпечні. Насамперед потрібно створити новий rc.conf. За замовчуванням sendmail відключений. Він Нам знадобиться для відправки повідомлень BackupPC. Тому відключають рядки з конфига видалені. Тепер sendmail зможе відправляти пошту з localhost.

## common
#apcupsd_enable="ТАК"
hostname="foo.example.com"
keymap="us.dvorak.kbd"
ntpd_enable="ТАК"
ntpd_sync_on_start="ТАК"
sshd_enable="ТАК"

## net
ifconfig_dwc0_ipv6="inet6 accept_rtadv"
rtsold_enable="ТАК"
ipv6_defaultrouter="2a01:348:1f9:29::1"

## nginx
nginx_enable="ТАК"
spawn_fcgi_enable="ТАК"
fcgiwrap_enable="ТАК"
fcgiwrap_user="bpc"

#apcupsd_enable="ТАК"
— поки відключений, при переході в production буде підключено резервне живлення. Ви бачите
keymap="us.dvorak.kbd"
— це чисто моя персональна річ. У разі підключення консолі треба забезпечити потрібну мені розкладку клавіатури. Плата не зберігає поточний час. Воно запитується з 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 не запущений, то сервер буде надсилати листи.

Крім того, і сам 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 term and 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 7 Nov 16:15 config
-rw------- 1 bpc bpc 444 15 Nov 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 скриптів
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.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.